Conformité, SoA et contrôles #

Objectif et onglets #

Conformité réunit Évaluations, Référentiels et SoA & contrôles. Les administrateurs gèrent référentiels/exigences ; les évaluateurs renseignent les résultats autorisés.

Référentiels et évaluations #

Un référentiel contient des exigences actives. Créez une évaluation avec référentiel, périmètre, évaluateur et date : RiskPilot génère un résultat par exigence. Renseignez maturité 0–5, statut conforme/partiel/non conforme/non applicable/non évalué, preuve et action corrective.

SoA et tests #

La déclaration d’applicabilité relie exigences, contrôles, risques, actions et preuves. L’approbateur administrateur diffère du responsable. Une version approuvée est immuable ; Réviser crée la suivante. Les tests décrivent conception ou efficacité, procédure, fréquence, testeur, échantillon, résultat, preuves et prochaine revue.

Correspondances et exports #

Les mappings entre exigences réutilisent une preuve avec provenance et couverture. Les évaluations et SoA s’exportent en CSV UTF-8. Le score global exclut non-applicable et non-évalué.

Erreurs et pratiques #

N’utilisez pas « non applicable » pour masquer un manque. Conservez une justification, séparez responsable et approbateur, et planifiez les tests.

Rôles et prérequis #

Un administrateur crée le référentiel et ses exigences. Avant une évaluation, créez le périmètre et désignez un évaluateur actif. Les preuves, contrôles, risques et actions associés doivent appartenir au même tenant.

Onglet Référentiels #

Un référentiel possède un nom, une version et des exigences actives. Utilisez un identifiant stable par exigence et un texte vérifiable. Une modification de version doit être gouvernée : ne changez pas silencieusement le sens d’une exigence déjà évaluée.

Créer une évaluation #

1. Sélectionnez Évaluations puis créez.
2. Choisissez référentiel, périmètre, évaluateur et date.
3. Enregistrez pour générer un résultat par exigence active.
4. Pour chaque résultat, attribuez maturité 0–5 et statut.
5. Ajoutez justification, preuves et action corrective si nécessaire.
6. Revoyez les résultats non évalués avant synthèse.

Statuts et maturité #

La maturité mesure la maîtrise du dispositif et ne doit pas être déduite automatiquement du statut. Le score global exclut Non applicable et Non évalué.

Déclaration d’applicabilité #

Créez la SoA pour un référentiel et un périmètre, puis documentez applicabilité, justification, contrôle, risque, action et preuve pour chaque ligne. Le responsable prépare ; un administrateur distinct approuve. Après approbation, la version est figée. Réviser duplique les lignes dans une nouvelle version.

Tests des contrôles #

Choisissez conception ou efficacité opérationnelle. Documentez procédure, fréquence, testeur, population/échantillon, résultat, preuves et prochaine revue. Un échec doit conduire à une analyse et, si nécessaire, à une action corrective.

Correspondances multinormes #

Une correspondance relie deux exigences et précise la couverture. Une preuve héritée conserve sa provenance : vérifiez qu’elle répond réellement au texte cible avant de la réutiliser.

Exports et contrôles #

Les exports CSV des évaluations et SoA restent tenant-scoped. Avant diffusion, vérifiez version, périmètre, date, éléments non évalués, justifications N/A, approbateur distinct et liens de preuve encore accessibles.

Erreurs fréquentes #

Une exigence absente peut être inactive. Une SoA approuvée est volontairement non modifiable. Une preuve visible dans un autre résultat n’est pas automatiquement suffisante : la couverture du mapping doit être explicitée.

Résultats et plans d’action #

Les résultats de conformité peuvent être reliés directement aux plans d’action. Utilisez cette relation pour suivre responsable, échéance, progression et preuves sans dupliquer la non-conformité. Les relations inter-organisations sont refusées.

Packs de démarrage gouvernés #

La commande Linux/Docker php bin/console app:compliance:install-starter-packs installe quatre bases idempotentes sur le couple nom/version : RGPD 2016/679 (11 exigences), NIS2 2022/2555 (10), ISO/IEC 27001:2022 (8 métadonnées) et EBIOS Risk Manager 2018 (5 ateliers). Une seconde exécution ignore les packs déjà présents.

Les packs RGPD et NIS2 s’appuient sur les textes publics européens. Le pack EBIOS reprend la structure publique des cinq ateliers. Le pack ISO ne reproduit aucun texte protégé : une copie licenciée de la norme reste indispensable. Ces contenus amorcent le pilotage ; ils ne valent ni avis juridique, ni déclaration de conformité, ni certification. Adaptez exigences, preuves, responsables et périmètres avant toute évaluation.

Radar de maturité d’une évaluation #

Après sélection d’une évaluation, la toile d’araignée affiche uniquement les exigences réellement évaluées de 0 à 5. Les exigences NOT_ASSESSED et NOT_APPLICABLE sont exclues du radar et de la moyenne. Les niveaux 0 à 2 apparaissent comme points faibles, 4 à 5 comme points forts, les exigences non évaluées restent à terminer et les non-applicables sont comptées séparément. Le radar apparaît à partir de trois exigences évaluées. Chaque modification optimiste est annulée dans l’interface si l’API la refuse.

Le statut accepte COMPLIANT, PARTIAL, NON_COMPLIANT, NOT_APPLICABLE ou NOT_ASSESSED. Les liens vers action corrective, preuve ou ressource doivent appartenir à la même organisation. Une mise à jour ne doit jamais perdre les relations existantes qui n’ont pas été modifiées.

Création et cycle de vie d’une évaluation #

Lors de la création, RiskPilot affiche le nombre de points actifs du référentiel puis crée automatiquement un résultat NOT_ASSESSED pour chacun. Le référentiel devient immuable après le lancement ; périmètre, évaluateur, date et statut restent modifiables par un administrateur, Risk manager, auditeur ou l’évaluateur désigné.

Le cycle affiché est DRAFT → IN_PROGRESS → COMPLETED, puis ARCHIVED si nécessaire. Passer à COMPLETED notifie l’évaluateur et fige la saisie des résultats dans l’interface. Une évaluation terminée ou archivée doit repasser à IN_PROGRESS avant correction. Le tableau de bord de conformité ne consolide que les évaluations COMPLETED.

Le sélecteur d’état appelle PUT /api/compliance-assessments/{id} avec référentiel, périmètre, évaluateur, date et nouvel état. Le référentiel ne peut pas être remplacé (FRAMEWORK_IMMUTABLE). Les résultats restent modifiables uniquement par les rôles habilités ou l’évaluateur, et les erreurs de mise à jour restaurent immédiatement la valeur précédente dans l’écran.

Assistance IA sur une exigence #

Le bouton Copilote IA d’un résultat appelle d’abord GET /api/compliance-results/{id}/copilot/context. L’utilisateur contrôle les données MINIMAL ou CONTEXTUAL, puis consent explicitement à chaque POST. La conversation transmet au maximum huit messages ; elle cite l’exigence, ne change aucun champ et journalise seulement les métadonnées techniques et l’empreinte de la question. Les erreurs stables et l’exemple JSON sont détaillés dans Copilote IA.