PD-249 — Rapport de confrontation v2 (Gate 5 — AMBIGUITY)¶
1. Sources confrontées¶
| Document | Rôle |
|---|---|
| PD-249-specification.md | Spécification canonique (v2) |
| PD-249-tests.md | Tests contractuels (v2) |
| PD-249-plan.md | Plan d'implémentation (v2, corrigé) |
| PD-249-review-step5-v2.md | Review P1 v2 (ChatGPT) |
2. Analyse des écarts P1 v2¶
Écart 1 — CA-249-06 / TC-NOM-06 (P1 : BLOQUANT)¶
Assertion P1 : "Les tests exigent une preuve via commentaires Git (MR/commit) alors que le plan formalise des tags Git."
Verdict confrontation : NON JUSTIFIÉ. La spécification v2 (CA-249-06) dit explicitement : "tags Git approved-by-rssi et approved-by-compliance sur le commit de publication (preuve Git traçable)." Le test TC-NOM-06 vérifie "la présence des deux tags Git". Le plan (TASK-11, section "Processus de publication") reprend fidèlement ce mécanisme. P1 invente une divergence "tags vs commentaires" qui n'existe dans aucun document source. L'écart est un faux positif de la review.
Réévaluation : Non-écart (retiré).
Écart 2 — INV-249-06 / TC-NOM-09 seuil 30% (P1 : BLOQUANT)¶
Assertion P1 : "Le plan repose sur une revue LLM sans méthode métrique explicite."
Verdict confrontation : PARTIELLEMENT JUSTIFIÉ mais SUR-ÉVALUÉ. Le plan v2 a ajouté une section "Méthode de vérification (TC-NOM-09)" décrivant la revue LLM avec vérification de similarité textuelle. Le GIVEN de TC-NOM-09 dit "Un outil de comparaison textuelle est disponible" — la revue LLM satisfait cette précondition. Pour un projet documentaire rédigé par des agents IA, la reformulation systématique (méthode décrite en 4 étapes) est la première barrière. La vérification LLM est la seconde. Une mesure strictement métrique (cosine similarity) n'est ni exigée par la spec ni par les tests.
Réévaluation : MINEUR (non BLOQUANT). La méthode est décrite, le GIVEN est satisfait.
Écart 3 — TC-ERR-02 inter-sources contradictoires (P1 : MAJEUR)¶
Assertion P1 : "Pas de mécanisme opératoire pour tracer les sources non retenues en cas de contradiction."
Verdict confrontation : JUSTIFIÉ mais SUR-ÉVALUÉ. TC-ERR-02 teste un cas d'erreur (sources contradictoires). La section 8 du plan décrit la méthode de consolidation qui inclut "ajouter une référence explicite vers la source". En cas de contradiction, l'agent rédacteur devra naturellement arbitrer et documenter. Ce n'est pas un mécanisme dédié mais c'est implicite dans le processus de rédaction. Pour un projet documentaire, ce cas est rare et traité par la revue d'acceptabilité (étape 7).
Réévaluation : MINEUR (non MAJEUR).
Écart 4 — Code contract mkdocs.yml (P1 : MAJEUR)¶
Assertion P1 : "Aucun code contract pour mkdocs.yml."
Verdict confrontation : PARTIELLEMENT JUSTIFIÉ mais SUR-ÉVALUÉ. mkdocs.yml est un fichier de configuration, pas un document de contenu. Le plan (TASK-11) décrit précisément les modifications attendues (ajout de la section "Manuel SAE" dans nav) avec le snippet YAML complet. Le CC-11 couvre index.md qui est le livrable principal de TASK-11. Un code contract pour un fichier de configuration existant est excessif — la description dans TASK-11 suffit.
Réévaluation : MINEUR (non MAJEUR).
Écart 5 — H-249-01 verrouillage versions sources (P1 : MAJEUR)¶
Assertion P1 : "L'accès aux sources est vérifié sans verrouillage de version/révision."
Verdict confrontation : NON JUSTIFIÉ. Les sources sont dans des repos Git. Les versions sont implicitement verrouillées par les commits. Le plan Go/No-Go vérifie la présence des artefacts, ce qui est suffisant. Un verrouillage explicite de révision Git pour chaque source serait de la sur-ingénierie pour un projet documentaire consolidant des sources internes déjà versionnées.
Réévaluation : Non-écart (retiré).
Écart 6 — Preuve signée/horodatée des transitions (P1 : MAJEUR)¶
Assertion P1 : "Pas de mécanisme de preuve signée/horodatée pour les transitions d'état documentaire."
Verdict confrontation : NON JUSTIFIÉ. La spec ne demande pas de preuve signée pour les transitions. Les transitions sont documentées dans le WORKFLOW-STATE du workflow de gouvernance (audit trail intégré). Les tags Git constituent une preuve horodatée (timestamp Git). P1 ajoute une exigence qui n'existe pas dans la spécification. Ce serait une exigence de sécurité pour un SAE — mais le plan concerne la documentation du SAE, pas le SAE lui-même.
Réévaluation : Non-écart (retiré).
Écart 7 — Framework de test N/A (P1 : MINEUR)¶
Verdict confrontation : MINEUR confirmé. Identique à v1. Justification acceptable.
3. Synthèse après confrontation v2¶
| Écart P1 v2 | Gravité P1 | Gravité confrontation | Justification |
|---|---|---|---|
| CA-249-06 tags vs commentaires | BLOQUANT | Non-écart | Faux positif : spec, tests et plan convergent sur "tags Git" |
| INV-249-06 seuil 30% | BLOQUANT | MINEUR | Méthode décrite (revue LLM), GIVEN satisfait |
| TC-ERR-02 inter-sources | MAJEUR | MINEUR | Cas d'erreur rare, traité implicitement par rédaction + revue |
| CC mkdocs.yml | MAJEUR | MINEUR | Configuration, pas contenu — description TASK-11 suffit |
| H-249-01 verrouillage | MAJEUR | Non-écart | Sources Git = versions implicites |
| Preuve signée transitions | MAJEUR | Non-écart | Exigence absente de la spec |
| Framework test N/A | MINEUR | MINEUR confirmé | Justification acceptable |
Bilan après confrontation : 0 BLOQUANT, 0 MAJEUR, 4 MINEURS.
4. Recommandation¶
- Procéder — convergence confirmée, aucun conflit bloquant
- Rework nécessaire
- Escalade
Les corrections v2 ont résolu les 4 écarts significatifs identifiés en v1. Les nouveaux écarts identifiés par P1 v2 sont soit des faux positifs, soit des sur-évaluations. Le plan est conforme à la spécification et aux tests.