Les LLM sont désormais utilisés au quotidien dans les équipes de développement. Ils servent à générer du code, accélérer le refactoring ou encore comparer des options techniques en quelques minutes. Cette capacité à produire rapidement modifie le rythme des projets, parfois plus vite que les équipes ne peuvent en absorber les effets.

La question n’est plus seulement de produire du code plus vite. Elle porte aussi sur la cohérence de l’ensemble : comment les décisions s’articulent-elles entre elles au fil du temps ? Quand les décisions s’enchaînent rapidement, leur traçabilité se perd. Quelques semaines plus tard, les raisons d’un choix technique ne sont plus évidentes, même pour ceux qui l’ont fait.

C’est dans ce contexte que les Architecture Decision Records retrouvent une utilité concrète. Ils permettent de garder une trace claire des décisions structurantes sans générer de charge documentaire supplémentaire. L’objectif n’est pas de documenter davantage, mais de documenter juste.

Mémoriser l’essentiel sans alourdir

Un ADR formalise une décision d’architecture, le contexte dans lequel elle est prise et les conséquences qui en découlent. Le format, popularisé par Michael Nygard, repose sur une structure volontairement simple. Cette simplicité explique en grande partie son adoption : il est rapide à produire et facile à relire.

En pratique, lorsqu’une équipe revient sur un système après plusieurs mois, elle évite deux écueils récurrents : rejouer une décision déjà tranchée, ou la remettre en cause sans en mesurer les impacts. L’ADR sert alors de point de repère, directement exploitable.

Ces documents sont versionnés avec le code et stockés dans le dépôt du projet. Ils forment progressivement un journal de décisions qui documente l’histoire technique du projet au même titre que le code lui-même.

Accélérer sans perdre le fil

Les LLM permettent d’explorer rapidement plusieurs solutions, de tester des approches différentes et de produire du code à un rythme élevé. Cette accélération a un effet secondaire : elle augmente le nombre de choix par défaut au prix de la maitrise.

Une suggestion acceptée rapidement peut introduire un choix structurant sans réelle discussion. Il peut s’agir d’un pattern d’architecture, d’une dépendance technique, d’une convention d’implémentation ou encore d’une évolution du modèle de données. Tant que le système reste stable, ces choix passent inaperçus. Ils deviennent problématiques lorsqu’il faut faire évoluer ou diagnostiquer le système.

Sur le terrain, les projets qui tirent parti des LLM ne se distinguent pas uniquement par leur vitesse de réalisation. Ils mettent également en place des mécanismes simples permettant de tracer et de formaliser les décisions prises. Les ADR remplissent précisément ce rôle et peuvent s’intégrer naturellement dans de nouvelles approches comme le SDD (Specification-Driven Development).

Trouver le bon niveau de formalisation

Toutes les décisions ne nécessitent pas le même niveau de formalisation. Le format minimaliste proposé par Nygard suffit dans la majorité des cas. Il permet de capturer rapidement l'essentiel sans ralentir l'équipe. 

Lorsque la décision engage davantage le système, par exemple en présence de plusieurs alternatives sérieuses ou de contraintes fortes de performance, de sécurité ou de coûts, il devient utile de structurer davantage la réflexion. Des formats comme MADR permettent alors d'expliciter les options et les critères de choix. 

En pratique, une règle simple fonctionne bien : plus une décision implique des choix structurants pour le projet, plus elle mérite d'être documentée avec précision. 

Quelle approche adopter ?

L'apport des LLM se situe surtout dans la préparation et la consolidation des décisions. Ils permettent de produire rapidement un premier brouillon à partir d'un contexte, de contraintes et de quelques options envisagées. Ce brouillon sert de base de discussion, sans prétendre être définitif. 

Leur intérêt est particulièrement visible lors de la phase de relecture. Utilisés comme outil critique, ils permettent d'identifier des angles morts, de faire émerger des alternatives ou de pointer des risques qui n'avaient pas été envisagés. Ils jouent ici un rôle de "sparring partner" plutôt que de décideur. 

La validation reste du ressort de l'équipe. Une fois validé, l'ADR est versionné et lié aux éléments concrets du projet, comme les tickets ou les pull requests. Dans un environnement Microsoft, cette pratique s'intègre naturellement avec Azure DevOps et les repositories Git. 

Cette approche ne se limite pas aux nouveaux projets. Elle prend tout son sens dans les contextes de modernisation ou de migration vers le cloud, où l'historique des décisions est souvent incomplet. 

Dans ces situations, le code et l'infrastructure deviennent les principales sources d'information. Les LLM peuvent alors aider à analyser ces éléments pour identifier des patterns, détecter des choix implicites et formuler des hypothèses de décisions. Ces hypothèses peuvent ensuite être formalisées sous forme d'ADR rétroactifs. 

Par exemple, l'analyse d'un module de facturation peut révéler des choix implicites en matière de gestion des transactions ou de cohérence des données. Ces éléments, une fois explicités et validés avec les équipes, permettent de sécuriser les évolutions futures. 

Il est important de considérer ces productions comme des hypothèses. Une validation humaine reste indispensable avant toute formalisation. 

Faire des ADR une base de référence

Un LLM utilisé sans contexte produit des réponses génériques. Lorsqu'il est alimenté avec les ADR du projet, il s'aligne sur les décisions déjà prises. 

Les ADR présentent plusieurs avantages dans ce rôle. Leur structure est stable, leur contenu correspond à des décisions validées et leur versioning permet de suivre leur évolution. Ils constituent donc une base de connaissances exploitable. 

Concrètement, cela suppose de centraliser les ADR dans le dépôt, de les fournir comme contexte lors de l'utilisation des LLM et de poser quelques règles simples. Une recommandation ne doit pas contredire une décision existante sans le signaler explicitement. À l'inverse, le LLM peut être utilisé pour vérifier la cohérence d'une proposition avec les choix déjà actés. 

Et les ASR dans tout ça ?

Les décisions d'architecture répondent rarement à des considérations purement techniques. Elles traduisent généralement des contraintes plus larges liées à la performance, à la sécurité, à la disponibilité ou encore à la scalabilité. 

Ces exigences, appelées ASR (Architecturally Significant Requirements), structurent les décisions et méritent d'être formalisées en parallèle des ADR. Leur identification et leur articulation avec les décisions feront l'objet d'un approfondissement dédié. 

Pour conclure…

Les LLM accélèrent clairement la production. Cette accélération reste utile uniquement si elle s'accompagne d'une capacité à garder une vision maitrisée et cohérente du système. 

Les ADR apportent cette continuité. Ils permettent de rendre les décisions explicites, de faciliter leur compréhension et de sécuriser les évolutions dans le temps. 

Utilisés ensemble, les LLM et les ADR ne s'opposent pas. Ils se complètent naturellement : l'un accélère, l'autre structure. C'est cet équilibre qui permet de maintenir une architecture maîtrisée malgré l'augmentation du rythme de développement. 

F.A.Q