Étape 7 du cycle · /sdd drift-check

Drift Lock — code et SPEC dans la même PR

Le spec drift — code qui évolue sans que les artefacts suivent — est le risque numéro un du développement avec agents IA. Le Drift Lock le neutralise par une politique simple et non négociable : code et SPEC synchronisés dans la même PR, vérifié par l'humain et mesuré par la machine.

Un échec de processus, pas une erreur d'agent

C'est le deuxième principe fondateur du SDD Mode : Drift = Échec de Processus. Quand une SPEC se désynchronise du code, le coupable n'est pas l'agent qui a généré le code — c'est le processus qui a permis de merger sans synchroniser. La mise à jour des artefacts fait partie de la Definition of Done : une tâche dont le code est mergé mais la SPEC désynchronisée n'est pas terminée.

Ce cadrage change tout en pratique : un drift détecté est un succès du processus, pas une honte à dissimuler. Le drift le plus dangereux est celui qu'on ne vérifie pas.

La dégradation silencieuse — 1, 5, 20 itérations

Le spec drift ne fait pas de bruit ; il s'accumule. Après une itération non synchronisée, la SPEC est légèrement désalignée — un champ renommé, un cas limite ajouté au code seul. Après cinq itérations, elle est obsolète : l'agent qui la reçoit travaille sur une base erronée et génère du code faux avec assurance. Après vingt itérations, elle est inutilisable — et l'équipe revient au développement sans spécification, en ayant payé le coût de la rédaction sans en garder le bénéfice.

L'Anti-Drift Check — trois questions en fin d'itération

Avant de fermer un ticket, le Product Engineer répond à trois questions pour chaque SPEC utilisée dans la session — dix minutes, sous sa responsabilité :

1. Le comportement livré correspond-il exactement à ce que décrit la SPEC ?
2. Les fichiers impactés listés dans la SPEC sont-ils toujours exhaustifs ?
3. Le CRITÈRE DE DRIFT de l'Intent Statement parent signale-t-il un écart entre l'intention initiale et ce qui a été livré ?

Si la réponse à l'une des trois est non, la SPEC — et éventuellement l'Intent Statement — est mise à jour avant la fermeture. La troisième question est la plus profonde : elle vérifie non pas que le code respecte la SPEC, mais que la livraison respecte l'intention humaine d'origine.

La politique de PR

Le verrou est mécanique : la SPEC mise à jour est committée dans la même PR que le code. Pas dans une PR de suivi « qu'on fera après », pas dans un ticket de documentation : la même. Une PR qui modifie du code applicatif sans toucher la SPEC correspondante déclenche le verdict DRIFT — et ne se merge pas. /sdd drift-check exécute ce contrôle avant chaque PR : si tout est synchronisé, la SPEC passe en statut done, les index sont mis à jour et une entrée est ajoutée à CHANGELOG-ARTEFACTS.md.

La mesure algorithmique (v1.10) — /sdd trace et la CI

Depuis la v1.10, le Drift Lock ne repose plus uniquement sur la discipline humaine : il est mesuré algorithmiquement. Deux contrôles se combinent : l'heuristique git (skill drift-detection — code modifié sans SPEC mise à jour dans la même PR) et la matrice de traçabilité (skill traceability — annotations @intent / @spec / @verified-by / @governance croisées avec .aiad/intents/ et .aiad/specs/).

npx aiad-sdd trace --fail-on-gap   # un gap bloquant fait échouer la pipeline

# Gaps bloquants détectés par la matrice :
#  - SPEC orpheline   : référencée par le code, absente des artefacts
#  - Intent orphelin  : aucun code ne le référence
#  - SPEC validée non-implémentée : aucune annotation @spec ne la cite

En CI, la GitHub Action .github/workflows/sdd-trace.yml invoque cette commande sur chaque PR : un gap bloquant fait échouer la pipeline. La matrice est l'arbitre final — un gap de traçabilité vaut DRIFT même si l'heuristique git dit OK. À chaque passage réussi, le snapshot .aiad/metrics/traceability/trace.{md,json} est régénéré.

Verdict INCONNU — l'absence de preuve n'est pas une preuve

Quand les annotations @spec sont absentes du code applicatif modifié, la détection ne peut pas conclure « pas de drift ». Le verdict obligatoire est INCONNU — jamais OK par défaut. C'est l'application directe de la politique JNSP : absence de preuve de drift ≠ preuve d'absence de drift.

Verdict : INCONNU (JNSP)
Ce qui est mesuré : <fichiers vérifiés et leurs annotations>
Ce qui manque : <fichier(s) sans @spec ou annotation orpheline>
Action humaine : ajouter l'annotation, créer la SPEC manquante,
                 ou whitelist explicite dans .aiad/hook-bypass.yml

Le dernier maillon de la chaîne de preuve

Le Drift Lock ne sert pas qu'à garder la documentation juste. Dans la doctrine v1.9, il est le dernier maillon de la chaîne de preuve qui conditionne le déploiement automatisé : un déploiement sans intervention humaine n'est admissible que si le code est trusted au sens d'une chaîne vérifiable — Intent Statement, SPEC validée à la Gate, vérifications tracées, Drift Lock — et non d'une confiance déclarative dans l'outil ou le modèle. C'est le critère posé par Roblox pour accepter du code agentique en production (QCon AI, 2026) ; AIAD en fait le critère d'entrée du Continuous Deployment pour du code produit par agent. Conséquence pratique pour une organisation aux moyens plus modestes : réserver le déploiement automatisé aux fonctionnalités dont la chaîne de preuve est complète.

La même chaîne rend la responsabilité de l'organisation démontrable : l'Intent Statement documente l'intention et son auteur, la SPEC le périmètre délégué, la trace de la Gate la validation humaine, le Drift Lock la synchronisation entre ce qui était voulu et ce qui a été livré. Elle documente la diligence — et, le cas échéant, la faute : une trace qui ne pourrait que disculper ne serait pas une preuve. Voir Human Authorship et Autonomie de l'agent.

La micro-phase Sync des artefacts — 15 minutes, 4 questions

En complément de l'Anti-Drift Check de fin d'itération, chaque boucle d'implémentation se conclut par la micro-phase Sync des artefacts : quinze minutes, sous la responsabilité du PE, non négociables. Quatre questions :