Une observation revient dans les discussions d'ingénierie de 2026 : les Architecture Decision Records (ADR) connaissent un regain d'intérêt, et la raison est prosaïque. Les agents de code écrivent désormais une part importante du code, et un agent qui ne voit pas pourquoi une chose a été construite d'une certaine manière la « refactorisera » volontiers, en supprimant la raison d'être de ce choix. Pour des agents qui oublient entre deux sessions, l'ADR est l'un des rares artefacts qui survit (BrainGrid, Nexapp).

Le problème : la vitesse sans la mémoire

Le rapport DORA 2026 décrit des organisations où l'IA augmente le volume de code livré, mais où la stabilité de livraison peut se dégrader (InfoQ). Une cause plausible, parmi d'autres, est que le volume dépasse la capacité à relire et à se souvenir : pourquoi cette dépendance, pourquoi cette frontière entre services, pourquoi cette option rejetée. Quand l'agent décide à la vitesse de la machine, la justification doit être capturée à la même vitesse, sinon elle n'existe nulle part.

Ce que contient un ADR « prêt pour les agents »

Les pratiques qui émergent (voir par exemple le standard proposé d'Agent Decision Records) enrichissent l'ADR classique de quelques éléments :

  • un identifiant stable et un statut (proposé, accepté, remplacé, abandonné) ;
  • le contexte et la décision, mais aussi les alternatives écartées et pourquoi : c'est ce qui empêche un agent de les ressusciter ;
  • le périmètre et les relations avec d'autres décisions ;
  • des déclencheurs de réexamen : à quelles conditions la décision doit être rouverte ;
  • une classification des conséquences : ce qui est recommandé, ce qui exige une revue humaine, ce qui peut être vérifié automatiquement ;
  • quand une IA a contribué à la décision, une mention de ce fait (modèle, résumé de la consigne), pour que la provenance reste lisible.

Ce que le Living ADR ajoute

Un ADR enrichi reste un document. Le Living ADR de TEAF pose le problème que ces pratiques ne résolvent pas seules : la péremption silencieuse. Il relie la décision aux contraintes qui l'ont motivée, via le Knowledge Backbone, de sorte qu'un changement significatif la fait apparaître comme « à réviser », avec la raison du déclenchement. Pour un agent de code, cela signifie qu'il peut lire non seulement ce qui a été décidé, mais aussi si la décision est encore présumée valide.

Qui décide quand l'agent propose ?

Un agent peut rédiger un projet d'ADR, et c'est utile. Mais la décision d'architecture reste un acte de gouvernance : TEAF confie le sens de la décision au Decision Steward, et la frontière entre ce qu'un agent peut décider seul et ce qui exige une validation à l'AI Control Officer (voir l'AI Control Plane). Un agent qui rédige un ADR n'est pas un agent qui l'approuve.

Une mise en œuvre sobre

  1. Stocker les ADR avec le code, dans le dépôt, au format texte : l'agent les lit naturellement et ils sont versionnés avec les changements.
  2. Imposer les alternatives écartées dans le modèle : c'est le champ qui coûte le moins à renseigner et rapporte le plus.
  3. Brancher une revue à échéance ou sur événement (changement de fournisseur, de contrainte) plutôt que de compter sur la mémoire de l'équipe.
  4. Tracer la contribution de l'IA sans en faire une cause de suspicion : la transparence sur la provenance aide la relecture.

Rien de cela n'est propre à TEAF ; c'est une bonne pratique d'ingénierie dont le Living ADR est le prolongement de gouvernance. Les anti-patterns TEAF décrivent ce qui arrive quand les décisions ne sont plus reliées à leurs conditions de validité.

  • Les agents de code oublient entre les sessions : l'ADR est la mémoire qui survit.
  • Un ADR prêt pour les agents consigne alternatives écartées, périmètre, déclencheurs de réexamen et provenance.
  • Le Living ADR ajoute le lien aux contraintes et la visibilité de la péremption.
  • Un agent peut proposer une décision ; il ne l'approuve pas.

Sources

Cet enjeu vous concerne ?

Un premier échange gratuit pour l'évaluer ensemble.