Personne ne se souvient pourquoi : documenter les décisions d'architecture pour pouvoir les rouvrir

Un architecte arrive dans une organisation et découvre une particularité du système d’information. Tous les échanges avec la facturation passent par une couche d’interfaces construite autour d’un progiciel ancien, alors que le reste du parc a été modernisé. Il pose la question autour de lui. On lui répond que « c’était décidé avant », que « l’éditeur était en difficulté à l’époque », peut-être que « le budget n’avait pas suivi ». Le schéma d’architecture est à jour. Il montre précisément ce qui existe. Il ne dit rien de ce qui a été écarté, ni pourquoi.

Il reste alors deux attitudes, toutes deux coûteuses. La première consiste à respecter l’existant par prudence : puisque personne ne sait pourquoi le choix a été fait, personne n’ose le défaire. La seconde consiste à le remettre en cause par principe : puisque personne ne sait le défendre, il paraît arbitraire. L’organisation oscille entre ces deux réflexes selon les personnes en place, et le même débat se rejoue à chaque arrivée.

Un schéma décrit ce qui a été construit ; il ne dit pas ce qui aurait pu l’être autrement. Documenter une décision ne sert pas à prouver qu’elle a été prise, mais à permettre de la rouvrir le jour où ses raisons ne tiennent plus — et seulement ce jour-là. Un registre de décisions qui n’aide pas à répondre à cette question n’est qu’une archive.

Ce qui disparaît en premier

Une décision d’architecture laisse des traces durables : un système en production, des flux, des contrats. Ce qui disparaît, c’est tout ce qui l’entourait au moment où elle a été prise.

La question. Le problème que la décision cherchait à résoudre se confond vite avec la solution retenue. Quelques années plus tard, on ne sait plus si la couche d’interfaces répondait à un besoin d’isolement, à une contrainte de délai ou à une limite de compétences.

Les options écartées. Elles ne laissent aucune trace dans le système. Or ce sont elles qui donnent son sens au choix : on ne comprend une décision qu’en sachant à quoi elle a été préférée.

Les hypothèses. Les volumes attendus, la pérennité d’un fournisseur, l’état de la réglementation, les compétences disponibles, la durée de vie prévue du système. Ce sont les conditions qui rendaient le choix raisonnable. Elles sont rarement écrites, parce qu’à l’époque elles allaient de soi.

Les contreparties. Ce que l’on savait perdre en décidant ainsi. Une contrepartie oubliée finit par apparaître comme un défaut de conception, et les successeurs passent du temps à « corriger » ce qui avait été accepté en connaissance de cause.

Les deux attitudes décrites plus haut naissent de la même absence. On ne peut ni défendre ni contester sérieusement une décision dont on a perdu les hypothèses.

Pourquoi les registres existants n’y suffisent pas

Beaucoup d’organisations tiennent déjà une forme de registre : des comptes rendus de comité, des dossiers d’architecture, parfois des fiches de décision au format court évoqué dans l’article sur la gouvernance d’architecture. Le format n’est pas en cause. Ce sont les conditions dans lesquelles le registre est rempli qui le vident de son utilité.

La fiche est rédigée après la décision, pour la justifier. Elle est écrite au moment de passer en comité, quand le choix est déjà fait. La rubrique « options considérées » contient alors une option retenue et deux options construites pour être écartées. Le lecteur futur ne peut pas distinguer une alternative sérieuse d’un faire-valoir.

Elle consigne la conclusion, pas les conditions. La décision est énoncée avec soin ; les hypothèses qui la fondent sont absentes ou réduites à une phrase générale. C’est pourtant la seule partie qui permettrait de savoir, plus tard, si la décision tient encore.

Elle ne couvre que ce qui passe en comité. Les décisions les plus structurantes sont souvent prises ailleurs : dans un dossier de consultation, un arbitrage budgétaire, un contrat signé par une direction métier. D’autres ne sont prises par personne : un report reconduit d’année en année finit par devenir un choix. Le registre décrit alors une partie de l’architecture, pas celle qui a le plus pesé.

Elle est modifiée au lieu d’être remplacée. Quand une décision évolue, on corrige la fiche. L’historique disparaît, et avec lui la possibilité de comprendre pourquoi l’organisation a changé d’avis.

Personne ne la relit. Une fiche que l’on n’ouvre jamais après le comité devient un justificatif de conformité. Elle prouve qu’une procédure a été suivie, pas que la décision est encore valable.

Ce qu’une décision doit consigner pour pouvoir être rouverte

Le critère de rédaction change tout. Une fiche écrite pour être approuvée cherche à convaincre. Une fiche écrite pour être rouverte cherche à donner à un lecteur futur, qui ne connaît ni le contexte ni les personnes, de quoi juger si le choix tient encore. Cela suppose sept éléments, dont deux font l’essentiel du travail.

La question posée, formulée comme un problème. « Comment continuer à facturer pendant la refonte des canaux sans dépendre des évolutions du progiciel ? », plutôt que « mise en place d’une couche d’API sur la facturation ». Une question bien formulée permet de reconnaître le jour où elle ne se pose plus.

Les options réellement considérées. Y compris l’option de ne rien faire, qui est presque toujours une option réelle et presque jamais écrite. Pour chacune, la raison précise pour laquelle elle n’a pas été retenue. Si une option n’a pas été sérieusement étudiée, il vaut mieux le dire que de l’inventer après coup.

La décision. C’est la partie que tout le monde rédige déjà ; elle n’appelle pas de commentaire.

Les hypothèses, datées et vérifiables. C’est le cœur de la fiche. Chaque hypothèse est un fait sur le monde dont dépend le choix : « l’éditeur maintient la version actuelle au moins jusqu’à telle échéance », « les volumes de factures restent du même ordre », « l’équipe qui connaît ce progiciel reste en place ». Une hypothèse utile se vérifie : on doit pouvoir dire, à une date donnée, si elle est encore vraie.

Les contreparties acceptées. Ce que la décision coûte, et à qui : une couche supplémentaire à maintenir, des évolutions de facturation plus lentes, une compétence rare à conserver. Les écrire protège la décision contre la critique de ceux qui découvriront ces coûts plus tard sans savoir qu’ils avaient été pesés. C’est la même logique que pour la dette qu’on choisit délibérément de ne pas rembourser.

La condition de révision. C’est l’autre élément décisif. Une date de revue ne suffit pas : une décision réexaminée tous les ans sans raison particulière est en général reconduite sans examen. La condition de révision est un signal observable, tiré des hypothèses : l’annonce d’une fin de support, un seuil de volume franchi, le départ de l’équipe concernée, une évolution réglementaire. Tant que le signal n’apparaît pas, la décision n’a pas à être rediscutée ; dès qu’il apparaît, elle doit l’être.

Le propriétaire. Une personne ou une fonction qui a l’autorité de rouvrir la décision, et à qui le signal doit parvenir. Sans propriétaire, une hypothèse invalidée est constatée par tout le monde et traitée par personne.

Rédigée ainsi, la fiche reste courte. Une page suffit presque toujours. Elle demande moins de rédaction que de franchise : il est plus difficile d’écrire « nous pensons que l’éditeur tiendra trois ans, sans en être sûrs » que de produire un argumentaire.

Ce sont les hypothèses qu’il faut suivre

La plupart des décisions d’architecture ne deviennent pas fausses. Le contexte qui les rendait justes change. Un fournisseur est racheté, une réglementation est révisée, une équipe se disperse, les volumes doublent. La décision reste en place, figée dans le système, alors que ses fondations ont bougé.

Un registre organisé par décisions répond mal à cette situation. Lorsqu’un événement survient, la question utile n’est pas « que dit telle décision ? » mais « quelles décisions reposaient sur ce qui vient de changer ? ». Pour y répondre, il faut que les hypothèses soient consignées de manière à pouvoir être retrouvées, et qu’une même hypothèse puisse être reliée à toutes les décisions qui en dépendent.

L’exemple montre ce que le registre apporte quand il est tenu ainsi. La décision de conserver la facturation, celle de reporter la refonte des référentiels et celle de bâtir le portail sur l’interface existante n’ont pas été prises par les mêmes personnes, ni la même année. Elles reposent pourtant sur la même hypothèse. Sans registre, l’annonce de fin de support serait traitée comme un sujet de facturation ; le portail et les référentiels découvriraient le problème plus tard, à leurs dépens.

Cette lecture a une conséquence pratique : il vaut mieux écrire les hypothèses de manière homogène d’une fiche à l’autre, avec les mêmes mots pour les mêmes faits — le nom du fournisseur, de la version, de la réglementation concernée. Le plus modeste des outils de recherche suffit alors à répondre à la question. C’est aussi ce lien qui rend possible l’exercice de confrontation des principes aux décisions passées : une décision dont les raisons sont écrites peut être relue ; une décision réduite à sa conclusion ne peut qu’être constatée.

Remplacer, ne jamais réécrire

Une décision consignée ne se corrige pas. Quand elle est révisée, une nouvelle décision la remplace, avec sa propre question, ses options et ses hypothèses, et une référence explicite à celle qu’elle remplace. L’ancienne fiche reste lisible, marquée comme remplacée.

Cette règle a deux effets. Elle conserve l’histoire du raisonnement, qui est souvent plus instructive que l’état final : on comprend une architecture en voyant par quelles étapes elle est passée, comme on comprend une trajectoire en regardant ses états intermédiaires. Elle change aussi le statut de la révision. Remplacer une décision n’est pas avouer une erreur ; c’est constater que ses hypothèses ont cessé d’être vraies. Le registre permet de faire la différence entre une décision mal prise et une décision bien prise dans un contexte qui a changé.

Deux catégories de décisions méritent une attention particulière.

Les décisions de ne pas agir. Garder un système, reporter une migration, ne pas rembourser une dette. Elles engagent l’organisation autant que les autres, et elles ont des hypothèses, souvent plus fragiles. Ce sont aussi celles qui se reconduisent le plus facilement sans examen. Les conditions du retrait d’un système relèvent de la même logique : écrites au moment de la mise en service, elles transforment un report indéfini en décision assumée.

Les décisions reconstituées. Quand un registre est créé, l’essentiel de l’architecture existe déjà, et ses raisons sont perdues. Il n’est ni possible ni utile de tout reconstituer. Mais lorsqu’un choix ancien devient un sujet — parce qu’on veut le défaire, ou parce qu’on découvre qu’on en dépend —, il vaut la peine d’en écrire une fiche, en indiquant clairement qu’elle est reconstituée et que ses hypothèses sont supposées plutôt que connues. Une hypothèse supposée, signalée comme telle, vaut mieux qu’une absence d’hypothèse.

Quoi consigner, et quoi laisser

Un registre qui veut tout couvrir finit comme les listes de principes trop longues : personne ne le lit. Deux critères suffisent en général pour décider si une décision mérite une fiche.

Le coût de retour en arrière. Une décision qu’on peut défaire en quelques jours, au sein d’une seule équipe, n’a pas besoin d’être consignée au niveau de l’organisation. Une décision qui engage un contrat, une plateforme partagée, une donnée de référence ou un hébergement le mérite, parce qu’on ne la défera pas sans un effort important.

Le nombre de ceux qui en dépendent. Une décision qui contraint d’autres équipes que celle qui l’a prise doit être lisible par elles, et par ceux qui leur succéderont.

Deux règles de tenue complètent ces critères. La fiche est rédigée par ceux qui décident, au moment où ils décident, pas reconstituée ensuite par un architecte à partir d’un compte rendu. Et elle vit à un endroit où l’on peut la retrouver sans connaître son auteur : au plus près du travail des équipes, mais consultable par tous ceux que la décision concerne.

Pouvoir changer d’avis sans se désavouer

Le registre de décisions est souvent présenté comme un outil de mémoire. C’est vrai, mais c’est sa fonction la moins importante. Sa vraie utilité est de rendre la révision légitime. Une organisation qui ne garde pas les raisons de ses choix n’a que deux options devant un choix ancien : le maintenir parce qu’il existe, ou le défaire parce qu’on ne le comprend plus. Dans les deux cas, la décision ne se fonde sur rien.

Une décision qui consigne sa question, ses options, ses hypothèses et sa condition de révision échappe à ce dilemme. Elle peut être conservée en sachant pourquoi, ou remplacée en sachant ce qui a changé. Et l’organisation peut changer d’avis sans que personne n’ait à reconnaître une faute : il suffit de montrer que l’hypothèse qui fondait le choix n’est plus vraie. C’est ce que permet un registre bien tenu, et c’est la question à se poser devant le sien : en le lisant, saurait-on dire quelles décisions il faudrait rouvrir demain si le premier fournisseur du système d’information changeait de stratégie ?