Étape 6 du cycle · /sdd validate
Validation — quatre axes, un verdict
Le code qui compile n'est pas forcément le code qui fonctionne, et le code qui fonctionne n'est pas forcément le code qui respecte l'intention. La validation SDD porte sur quatre axes — technique, fonctionnel, métier, gouvernance — et le code n'est jamais terminé tant que la SPEC n'est pas synchronisée (Drift Lock).
Axe 1 — Validation technique
Le socle objectif : la chaîne d'outillage du projet, exécutée intégralement et reportée en tableau. Aucun jugement, des faits.
| Check | Commande | Résultat |
|---|---|---|
| Lint | [commande projet] | PASS / FAIL |
| Types | [type-check] | PASS / FAIL |
| Tests unitaires | [test] | PASS / FAIL |
| Tests d'intégration | [test:integration] | PASS / FAIL |
| Build | [build] | PASS / FAIL |
| Couverture | [coverage] | X % |
Ne JAMAIS valider un code qui ne passe pas les tests. Ne JAMAIS valider un code contenant des TODO-JNSP: non résolus — ces marqueurs sont des questions en attente de décision humaine, pas des détails cosmétiques.
Axe 2 — Validation fonctionnelle
L'axe fonctionnel confronte le code aux cas de test de la SPEC, critère par critère — contre le code lui-même, pas seulement contre les tests. Entrées spécifiées respectées, étapes de traitement suivies, format de sortie produit, chaque cas limite couvert par un test, tous les critères d'acceptation cochés. Côté équipe, la validation fonctionnelle est portée par le QA Engineer, et l'utilisabilité — UX, accessibilité, performance — par le QA avec le PM.
Axe 3 — Validation métier
La validation métier, portée par le Product Manager, pose la question que les tests ne posent pas : l'intention est-elle respectée, et les outcomes visés sont-ils atteignables ? Le Critère de Drift de l'Intent parent est relu : le signal observable de trahison de l'intention est-il absent ? C'est l'axe où l'on vérifie la fidélité à l'intention — un défaut sémantique qu'aucune chaîne d'outillage ne détecte.
Axe 4 — Validation gouvernance
Les quatre agents Tier 1 — AIAD-AI-ACT, AIAD-RGPD, AIAD-RGAA, AIAD-RGESN — sont appliqués via la skill regulatory-veto. Chacun dispose d'un droit de veto : un VETO bloque, un WARN exige un plan de remédiation avant merge. Cette validation n'est pas optionnelle pour les projets concernés.
Quand un agent de gouvernance ne peut pas décider — référentiel non applicable de façon certaine, information manquante — il retourne UNKNOWN. Ce verdict est traité comme un VETO : on ne merge pas sur un doute réglementaire. C'est la déclinaison gouvernance de la politique JNSP.
La vérification se conçoit, elle ne s'achète pas
La doctrine v1.9 fait un pari : la qualité de la vérification dépend d'abord du design du processus — ce qu'on vérifie, quand et par qui — plutôt que de la puissance du modèle qui relit. C'est une position, pas un résultat démontré : les indices convergent, aucun ne suffit seul. Elle se traduit en quatre règles.
| Règle | Ce qu'elle implique | Force de l'appui |
|---|---|---|
| La conversation critique a lieu d'abord à l'Execution Gate | On discute ce qu'on veut à la Gate ; la revue de code vérifie ensuite la conformité à une intention déjà discutée. Elle détecte ce qui a été mal compris, elle ne découvre pas ce qu'on voulait. | Règle de processus |
| Deux classes de défauts | Les défauts structurellement détectables (compilation, types, règles d'architecture outillées, secrets) se délèguent à l'outillage et aux agents. Les défauts sémantiques — fidélité à l'intention, justesse métier, frontières de conception — restent sous revue humaine, en s'appuyant sur le Test de l'Étranger. | Règle de processus |
| Séparer celui qui produit de celui qui critique | Quand la revue est confiée à un agent, AIAD recommande — sans l'imposer — un relecteur d'une autre famille de modèles que l'agent producteur. Le coût (plusieurs fournisseurs, contrats, analyse RGPD) doit être pesé. Le paquet le permet via /sdd validate --cross-model (revue additive-only en contexte frais). | Une étude de 2026, sur des problèmes de mathématiques et non de code : 35 % de faux rejets en auto-revue contre 2 % en revue croisée |
| Concevoir avant de tester pas à pas | En boucle agent, une conception complète en amont — architecture, types, cas limites, contrats, c'est-à-dire une SPEC — semble plus efficace qu'un TDD incrémental. | Indice à confirmer, pas règle : 3 à 8,5 fois plus de tokens sans gain net pour le TDD incrémental, dans une expérience exploratoire de 2026 |
Exemplars de revue
Le savoir de revue d'une organisation — ce qu'un relecteur senior repère et pourquoi — peut être extrait en exemples annotés, versionnés dans des fichiers dédiés (par exemple .aiad/review-exemplars/) et chargés uniquement dans les sessions de revue — pas dans l'AGENT-GUIDE, injecté à chaque session et réservé aux consignes permanentes. Roblox a décrit cette pratique en 2026. Un exemplar se constitue à partir de revues réelles, se révise comme un artefact, et se retire quand il ne reflète plus les standards de l'équipe.
Verification Tax
Une synthèse de littérature de 2026 nomme ainsi l'écart entre le gain de productivité à l'écriture du code et le gain, bien plus faible, à la livraison d'un logiciel fiable. Le terme décrit ce que l'investissement amont en SPEC et en Gate cherche à réduire. Corollaire côté équipe : l'efficacité n'est pas la qualité — une revue plus rapide n'est pas une revue meilleure (voir le rôle du QA Engineer).
Une composition de skills, sans duplication
/sdd validate est la commande la plus composite du cycle : elle n'implémente aucune logique propre mais compose trois skills réutilisables — ears-validator (couverture des critères testables de §3), drift-detection (écarts code ↔ SPEC sur le diff) et regulatory-veto (les 4 référentiels Tier 1). Chaque skill est aussi invoquée ailleurs dans le cycle (/sdd gate, /sdd drift-check, /sdd security…) : la logique vit en un seul endroit, les commandes l'orchestrent.
Le verdict
| Verdict | Signification | Action |
|---|---|---|
| VALIDÉ | Validation passée sur les quatre axes | Procéder au Drift Lock (/sdd drift-check) |
| CORRECTIONS | Écarts mineurs et localisés | Lister, relancer l'agent sur les points précis |
| REJET | Échec structurel | SPEC imprécise → Human Learning · agent erroné malgré SPEC claire → Lesson Learned |
| JNSP | Validation indécidable | Question(s) à l'humain — ne pas dégrader en « corrections mineures » pour faire avancer le merge |
La distinction Human Learning / Lesson Learned est essentielle pour l'amélioration continue : la première documente un écart entre intention humaine et livraison (la SPEC était le problème), la seconde une erreur récurrente de l'agent (l'exécution était le problème). Les deux alimentent l'AGENT-GUIDE.
Verdict : JNSP — validation impossible sans décision humaine
Ce qui est validé : <axes PASS>
Ce qui bloque : <zones non décidables avec ref §>
Question(s) à l'humain : <reformulation actionnable>Les rôles complémentaires — /sdd security et /sdd audit
Deux commandes d'audit prolongent la validation pour les fonctionnalités à fort enjeu, avec persistance des rapports dans .aiad/metrics/ :
| Commande | Périmètre | Persistance |
|---|---|---|
/sdd security | OWASP Top 10, gestion des secrets, permissions des agents (minimal necessary permissions), exposition des données, conformité AI-ACT/RGPD | .aiad/metrics/security/YYYY-MM-DD-SPEC-NNN.md |
/sdd audit | Conformité code ↔ SPEC, dette technique introduite (complexité, couplage, lisibilité), cohérence avec l'AGENT-GUIDE | .aiad/metrics/audit/YYYY-MM-DD-SPEC-NNN.md |
/sdd security : après toute fonctionnalité touchant des accès, des données utilisateur, des secrets ou un composant IA — recommandé avant toute PR critique, avec un modèle frontier. /sdd audit : pour les fonctionnalités à fort enjeu technique, ou après plusieurs itérations sur un même composant. Les rapports persistés alimentent les métriques et les rétrospectives.