PD-249 — Rapport de confrontation (Gate 5 — AMBIGUITY)¶

Ce rapport est produit par l'orchestrateur Claude avant la gate PMO. Il confronte les documents produits pour identifier convergences, divergences et zones d'ombre.

1. Sources confrontees¶

2. Convergences¶

CON-01 — Structure en 10 chapitres : Les trois documents (specification, tests, plan) convergent sur une structure exacte de 10 chapitres contractuels. Le plan definit 10 taches de redaction (TASK-01 a TASK-10) qui correspondent un-a-un aux chapitres. Les tests (TC-NOM-01, TC-ERR-03, TC-NEG-01) verifient cette cardinalite. Aucune ambiguite sur ce point.

CON-02 — Perimetre documentaire pur : Les trois documents s'accordent sur l'absence d'implementation logicielle. Le plan (section 1, section 3 "Framework de test") confirme "Non applicable au sens unitaire". La specification (section 2 "Exclu") exclut explicitement toute creation/modification d'API, workers, schemas DB.

CON-03 — Couverture des composants SAE : Le plan couvre exhaustivement les composants listes dans la specification (PD-1, PD-⅘/6, PD-⅞, PD-19, PD-33/34, PD-36, PD-60, PD-250) a travers les taches TASK-02 a TASK-07 et TASK-10. Le mapping (plan section 5) trace chaque INV et CA vers au moins une tache et un test.

CON-04 — Gestion PD-251 (etat partiel) : Specification (INV-249-08, H-249-05), tests (TC-NOM-04, TC-ERR-07) et plan (TASK-06 section 6.4, contraintes techniques) convergent sur le traitement de PD-251 avec statut explicite "En cours" et horizon Q1 2026.

CON-05 — Matrices de conformite : Le plan (TASK-08) reprend fidelement les exigences de la specification (INV-249-04, INV-249-05) avec les scores PD-244 (ISO 77.78%, NF 68.18%) et les 15 gaps. Les tests (TC-NOM-03, TC-NOM-08) verifient cette fidelite.

CON-06 — Integration MkDocs : Le plan (TASK-11) definit les verifications de build HTML et PDF conformement a CA-249-05 et INV-249-10. La specification et les tests (TC-NOM-05, TC-ERR-06) s'accordent sur les criteres de validation.

CON-07 — Glossaire SAE : Le plan (TASK-12) reprend les exigences d'exhaustivite du glossaire (INV-249-09, CA-249-07). Les tests (TC-NOM-07, TC-ERR-08, TC-NEG-06) sont coherents avec le contrat CC-12.

CON-08 — Modele d'etats documentaire : La specification (INV-249-11, flux F5) et le plan (TASK-01, CC-01) s'accordent sur la machine a etats DRAFT -> REVIEWED -> PUBLISHED -> ARCHIVED avec transitions retour autorisees et ARCHIVED comme etat terminal.

CON-09 — Ordonnancement des taches : Le plan definit un ordonnancement coherent (TASK-01 a TASK-10 en parallele, puis TASK-12, puis TASK-11) qui respecte les dependances logiques. Les chapitres sont autonomes entre eux, le glossaire necessite la lecture de tous les chapitres, et l'integration MkDocs necessite tous les fichiers.

CON-10 — Seuil de consolidation 30% : La specification (INV-249-06), les tests (TC-NOM-09, TC-NEG-02) et le plan (section 8, tous les code contracts avec max_verbatim_per_source: 30%) convergent sur le seuil. La regle est reprise dans chaque contrat.

3. Divergences¶

DIV-01 — CA-249-06 : validation RSSI/Compliance hors perimetre operationnel du plan¶

• Source A (Specification) : CA-249-06 definit un critere d'acceptation testable avec observable precis : "Presence des deux tags approved-by-rssi et approved-by-compliance sur le commit de publication (preuve Git tracable)." Le test TC-NOM-06 est explicite.
• Source B (Plan) : Le mapping (section 5) indique CA-249-06 = "Post-implementation (Gate 8 + publication)" sans tache dediee, sans artefact, sans point d'observabilite.
• Source C (Review P1) : Ecart qualifie BLOQUANT — "Validation contractuelle de publication non demontrable dans l'execution du plan."
• Analyse de la confrontation : L'ecart est JUSTIFIE sur le fond mais SUR-EVALUE en gravite. La specification elle-meme reconnaissait que le mecanisme repose sur un "processus tracable" (H-249-04) et que le test TC-NOM-06 est marque "testable (v2)" dans le document de tests (section 2, matrice de couverture). Dans un projet documentaire, les tags Git ne peuvent etre poses qu'apres la redaction complete du manuel, donc apres l'execution du plan. Cependant, le plan devrait contenir une tache ou sous-tache explicite decrivant le processus de validation publication (quand les tags sont poses, par qui, quelle verification). L'absence de cette tache rend effectivement TC-NOM-06 non executable dans le plan tel que redige.
• Verdict confrontation : Ecart MAJEUR (non BLOQUANT). Le plan doit ajouter une tache ou sous-tache de type "processus de publication" decrivant le mecanisme de tags Git, meme si l'execution reelle est post-implementation.

DIV-02 — INV-249-11 : prerequis de transitions d'etats non contractualises¶

• Source A (Specification) : Le flux F5 definit des prerequis explicites pour chaque transition : "DRAFT -> REVIEWED : prerequis completude chapitres 1-10", "REVIEWED -> PUBLISHED : prerequis validation RSSI + Compliance", "PUBLISHED -> ARCHIVED : prerequis remplacement par version plus recente."
• Source B (Plan) : Le contrat CC-01 (section 1.4) exige la "Machine a etats DRAFT -> REVIEWED -> PUBLISHED -> ARCHIVED" avec "Transitions autorisees et interdites explicites. ARCHIVED = terminal." Mais les prerequis de transition du flux F5 ne sont pas repris comme contenu obligatoire.
• Source C (Review P1) : Ecart qualifie BLOQUANT — "Le test des transitions avec prerequis explicitement verifiables ne peut pas etre execute de facon deterministe."
• Analyse de la confrontation : L'ecart est JUSTIFIE et CORRECTEMENT EVALUE. Le test TC-NOM-11 exige explicitement : "Les prerequis de transition sont explicitement verifiables." Le contrat CC-01 mentionne les transitions et l'etat terminal, mais ne mentionne pas les prerequis. Il y a un gap entre le contenu exige par le code contract et le contenu attendu par le test. Le plan doit enrichir le contrat CC-01 pour inclure les prerequis de chaque transition.
• Verdict confrontation : Ecart BLOQUANT confirme. Le contrat CC-01 section 1.4 doit expliciter les prerequis de transition conformement au flux F5 de la specification.

DIV-03 — Tableau de couverture composant -> chapitre -> diagramme absent¶

• Source A (Tests) : TC-NOM-02 exige explicitement : "Un tableau de couverture composant -> chapitre -> diagramme est present et coherent."
• Source B (Plan) : Le mapping (section 5) trace les invariants vers les taches, mais aucune tache ne produit un tableau de couverture transverse dans le livrable final du manuel. Le mapping est un artefact de planification, pas un artefact du manuel lui-meme.
• Source C (Review P1) : Ecart qualifie MAJEUR — "Couverture des composants/diagrammes non prouvable formellement."
• Analyse de la confrontation : L'ecart est JUSTIFIE et CORRECTEMENT EVALUE. Le test TC-NOM-02 est explicite sur la presence d'un tableau dans le manuel. Aucune tache du plan ne cree cet artefact de couverture dans le document livrable. Ce tableau pourrait logiquement etre integre dans TASK-01 (Introduction, section "Perimetre du SAE") ou comme annexe dans TASK-11.
• Verdict confrontation : Ecart MAJEUR confirme. Le plan doit ajouter la production de ce tableau de couverture comme livrable explicite dans une tache identifiee.

DIV-04 — Chemin des fichiers _build/docs/ vs docs/¶

• Source A (Plan section 2 "Emplacement des fichiers") : Les fichiers sont crees sous _build/docs/sae-manual/....
• Source B (Plan section 2 "Integration nav MkDocs") : La navigation reference sae-manual/... sans le prefixe _build/docs/.
• Source C (Review P1) : Ecart qualifie MAJEUR — "Le plan cree les fichiers sous _build/docs/sae-manual/... mais reference la navigation sae-manual/... sans expliciter la configuration docs_dir."
• Analyse de la confrontation : L'ecart est JUSTIFIE mais potentiellement SUR-EVALUE. Le dossier _build/docs/ est le docs_dir du projet ProbatioVault-doc (convention MkDocs Material). La navigation MkDocs utilise des chemins relatifs a docs_dir, donc sae-manual/... est correct si docs_dir: _build/docs est configure dans mkdocs.yml. Il ne s'agit pas d'une incoherence reelle mais d'une hypothese implicite non documentee dans le plan. Pour lever l'ambiguite, le plan devrait mentionner explicitement la valeur de docs_dir et confirmer que les chemins de navigation sont relatifs a cette racine.
• Verdict confrontation : Ecart MINEUR (plutot que MAJEUR). La convention est correcte mais le plan devrait expliciter le lien docs_dir = _build/docs pour eviter toute ambiguite d'execution.

DIV-05 — Mecanisme de mesure du seuil 30% verbatim¶

• Source A (Specification INV-249-06) : "Aucun chapitre ne doit reprendre plus de 30% de contenu textuel verbatim provenant d'une source unique."
• Source B (Tests TC-NOM-09) : "Un outil de comparaison textuelle est disponible" (en GIVEN). Le test presuppose un mecanisme de mesure.
• Source C (Plan section 8) : La methode de consolidation est decrite (lire, extraire, reformuler, referencer) mais aucun outil ou methode de mesure quantitative n'est specifie dans les taches.
• Source D (Review P1) : Ecart qualifie MAJEUR — "Verification de conformite potentiellement non reproductible en audit tiers."
• Analyse de la confrontation : L'ecart est PARTIELLEMENT JUSTIFIE. Le test TC-NOM-09 mentionne "Un outil de comparaison textuelle est disponible" comme precondition (GIVEN), ce qui implique qu'un tel outil est presuppose existant. Le plan ne precise pas quel outil sera utilise ni comment la mesure sera effectuee. Toutefois, dans le contexte d'un projet documentaire redige par des agents IA, la methode de consolidation decrite (reformulation + reference) est une approche qualitative qui vise justement a eviter le verbatim. La verification quantitative stricte (mesure de similarite textuelle) peut relever de la phase d'acceptabilite (etape 7) plutot que du plan d'implementation.
• Verdict confrontation : Ecart MINEUR (plutot que MAJEUR). Le plan devrait mentionner la methode de verification envisagee (revue LLM, outil de diff, ou checklist manuelle), mais il n'est pas necessaire d'integrer un outil specifique dans les taches de redaction.

DIV-06 — Incoherence TASK-01 vs CC-01¶

• Source A (Plan section 4, TASK-01) : Liste 6 sections attendues, dont un seul diagramme Mermaid (contexte systeme SAE).
• Source B (Plan section 6, CC-01) : Exige 5 sections + 2 diagrammes obligatoires (contexte systeme SAE ET stateDiagram-v2 des etats documentaires). La section "Conventions du document" (id 1.5) apparait dans le contrat mais pas dans la description de TASK-01.
• Source C (Review P1) : Ecart qualifie MAJEUR — "Contrat d'ecriture incoherent avec le plan d'execution."
• Analyse de la confrontation : L'ecart est JUSTIFIE et CORRECTEMENT EVALUE. Le contrat CC-01 est plus exigeant que la description de TASK-01. Un agent executant TASK-01 d'apres la description pourrait omettre le diagramme stateDiagram-v2 et la section "Conventions du document". L'incoherence interne du plan est factuelle. L'autorite est au contrat (CC-01), mais la description de la tache doit etre alignee pour eviter toute ambiguite d'execution.
• Verdict confrontation : Ecart MAJEUR confirme. La description de TASK-01 doit etre alignee avec le contrat CC-01 (2 diagrammes, 5+ sections incluant "Conventions du document").

DIV-07 — Framework de test "non applicable"¶

• Source A (Plan section 3 "Framework de test") : "Non applicable au sens unitaire."
• Source B (Exigences CLAUDE.md etape 4) : Le plan doit documenter une section "Framework de test" explicitant le runner, les tests d'integration, l'environnement CI.
• Source C (Review P1) : Ecart qualifie MINEUR.
• Analyse de la confrontation : L'ecart est JUSTIFIE mais a CONTEXTUALISER. Le plan explique que les tests sont des "verifications documentaires executees par revue humaine, revue LLM et build MkDocs". Pour un projet purement documentaire, il n'y a effectivement ni Jest, ni Vitest, ni tests d'integration. La section est presente et justifiee. Le plan respecte l'esprit de la contrainte en expliquant pourquoi le framework de test n'est pas applicable, plutot qu'en l'omettant.
• Verdict confrontation : Ecart MINEUR confirme, non bloquant. La mention "Non applicable" avec justification est acceptable pour un projet documentaire.

4. Zones d'ombre¶

ZO-01 — Emplacement MkDocs non tranche dans la specification¶

La specification (section 10, point 2) mentionne : "Emplacement exact dans la navigation MkDocs : top-level ou sous Infrastructure." Le plan tranche unilateralement "top-level" avec justification. La specification ne tranche pas. Ce choix architectural devrait etre valide explicitement, meme si la justification du plan est pertinente (document transverse, pas lie a un projet specifique).

ZO-02 — Mecanisme de detection des termes manquants dans le glossaire¶

TC-NOM-07 exige l'extraction de "tous les termes normatifs et termes ProbatioVault utilises dans le document" pour verifier l'exhaustivite du glossaire. TASK-12 mentionne "Extraire tous les termes techniques et acronymes utilises dans les chapitres 1-10, verifier que chacun est defini." Mais ni la specification ni le plan ne definissent comment cette extraction sera realisee (scan automatique, revue manuelle, regex). Pour un document de ~200 pages potentielles, la methode d'extraction merite d'etre precisee.

ZO-03 — Estimation de complexite et parallelisation¶

Le plan estime 19h de travail avec parallelisation de TASK-01 a TASK-10 sur 10 agents. La specification ne mentionne aucune contrainte de capacite ou de delai. La question de la faisabilite de la parallelisation a 10 agents simultanees pour un projet documentaire (acces concurrent aux sources, coherence de style entre chapitres) n'est pas traitee dans le plan. L'homogeneite stylistique entre chapitres produits par des agents differents n'est pas abordee.

ZO-04 — Gestion de la version initiale du manuel¶

Le plan (CC-11, section 0.3) mentionne "Etat documentaire: DRAFT, date, version" mais ne precise pas la convention de versionnage du manuel lui-meme (1.0.0 ? 0.1.0 ? date-based ?). La specification ne definit pas non plus cette convention.

5. Recommandation¶

• Proceder -- convergence confirmee, aucun conflit bloquant
• Rework necessaire -- divergences a resoudre avant de continuer
• Escalade -- decision humaine requise sur un point structurant

Justification¶

Le plan d'implementation est globalement bien structure et couvre la grande majorite des exigences de la specification et des tests. Les 10 convergences identifiees confirment un alignement solide sur le fond. Cependant, 1 ecart BLOQUANT et 3 ecarts MAJEURS doivent etre corriges avant soumission a la gate PMO :

Corrections requises (par priorite) :

1. BLOQUANT — DIV-02 : Enrichir le contrat CC-01 (section 1.4) pour inclure les prerequis de transition du flux F5 (completude chapitres, validation RSSI+Compliance, remplacement version). Le test TC-NOM-11 ne peut pas etre execute sans cette information.

2. MAJEUR — DIV-06 : Aligner la description de TASK-01 avec le contrat CC-01 : ajouter le diagramme stateDiagram-v2 et la section "Conventions du document" dans les sections attendues de TASK-01.

3. MAJEUR — DIV-03 : Ajouter la production d'un tableau de couverture transverse composant -> chapitre -> diagramme comme livrable explicite (dans TASK-01 ou TASK-11) pour satisfaire TC-NOM-02.

4. MAJEUR — DIV-01 : Ajouter une tache ou sous-tache decrivant le processus de validation publication (mecanisme de pose des tags Git approved-by-rssi / approved-by-compliance) pour rendre CA-249-06 et TC-NOM-06 executables, meme si l'execution reelle est post-redaction.

Ecarts mineurs (non bloquants pour la gate) :

1. MINEUR — DIV-04 : Expliciter docs_dir = _build/docs dans la section architecture documentaire.
2. MINEUR — DIV-05 : Mentionner la methode de verification du seuil 30% verbatim (revue LLM ou checklist).
3. MINEUR — DIV-07 : Aucune action requise — justification acceptable.

Ecarts P1 reevalues¶