Comment GS-Apps décide — décisions d'architecture et propagation

Vous êtes ici : Comprendre — la gouvernance : comment une règle de la plateforme devient une règle. Ce qu’est une décision d’architecture, comment la lire, et ce qui garantit qu’elle ne reste pas lettre morte. Lecture 7 min. Audience : devs, architectes, auditeurs. Date : 2026-08-11 | Version : 1.0 — créée par la refonte de l’architecture d’information

Le principe central — une décision se grave, elle ne se supprime pas

Quand une décision d’architecture cesse d’être valable, elle n’est pas effacée : elle est marquée comme remplacée, et la nouvelle décision dit ce qu’elle remplace et pourquoi.

La raison est pratique : du code écrit il y a un an obéit à la décision de l’époque. Effacer cette décision rendrait ce code incompréhensible — il ressemblerait à une erreur alors qu’il était conforme. L’historique des décisions est ce qui permet de relire le passé sans le juger avec les règles du présent.

1 · Ce qu’est une décision d’architecture

Un enregistrement de décision (couramment appelé ADR) répond à quatre questions, toujours les mêmes :

Section	Ce qu’elle contient	Pourquoi elle est là
Contexte et problème	La situation, mesurée, qui force un choix	Une décision sans problème est une préférence
Décision	Ce qui est tranché, formulé en règle applicable	C’est la seule partie contraignante
Alternatives écartées	Les options considérées, et pourquoi elles ont perdu	Empêche de rouvrir le débat tous les six mois
Conséquences	Ce que ça coûte, ce que ça facilite, ce qui devient réversible ou non	Une décision honnête déclare son prix

Lire les alternatives écartées en premier

C’est la section la plus utile et la moins lue. Quand une décision paraît étrange, la réponse s’y trouve presque toujours : l’option « évidente » y est nommée, avec la raison précise pour laquelle elle a été rejetée — souvent une contrainte que le lecteur ignorait.

2 · Les statuts

Statut	Ce qu’il veut dire
Proposé	Formulé, argumenté, pas encore tranché. Ne fait pas règle.
Brouillon	En cours de rédaction, vocabulaire ou périmètre non figé.
Accepté	Tranché. Fait règle — le code et les revues s’y conforment.
Remplacé	A fait règle, ne la fait plus. Conservé pour lire le code de son époque.
Rejeté	Étudié puis écarté. Conservé pour ne pas re-proposer la même chose.

Proposé n'est pas accepté — la distinction est opérationnelle

Une proposition peut être excellente, argumentée, et ne pas être en vigueur. Ce site signale explicitement les pages qui décrivent une doctrine proposée — voir par exemple l’aiguillage des couches analytiques.

Confondre les deux est un défaut fréquent et coûteux : on applique une règle que personne n’a validée, ou on croit protégé par une garde qui n’existe pas encore.

3 · Où elles vivent

Les décisions prennent deux formes, selon leur poids :

• Décision autonome — un document dédié, quand le sujet demande du contexte, des alternatives et des conséquences développées.
• Entrée de registre — une décision plus ponctuelle, consignée chronologiquement dans le registre des décisions, sans document propre.

Les deux font également foi. L’index des décisions de ce site liste les décisions autonomes, dérivées du dépôt à chaque construction du site : il ne peut pas être en retard sur lui. Le registre chronologique complet, lui, vit dans le dépôt.

4 · Avant de proposer — le contrat de validation

Toute proposition touchant l’architecture, la sécurité, les données ou l’authentification doit répondre à quatre exigences avant d’être présentée. Une proposition qui en omet une est rejetée sans être discutée sur le fond :

1. Normes de l’état de l’art — ce que fait l’industrie aujourd’hui sur ce problème.
2. Décisions déjà prises — quelles décisions existantes sont concernées, et si la proposition en contredit une.
3. Cohérence long terme — comment la proposition s’inscrit dans la trajectoire du programme.
4. Alternatives évaluées — au moins deux, avec le motif de rejet.

L’objectif n’est pas la cérémonie : c’est d’éviter qu’une bonne idée locale crée une incohérence globale que personne ne détectera avant des mois.

5 · La propagation — une décision non propagée n’existe pas

Une décision gravée mais absente des documents que les gens lisent ne produit aucun effet. La plateforme traite donc la propagation comme une partie de la décision, pas comme un suivi optionnel.

Un registre interne recense les vecteurs — les documents et fichiers qui doivent être mis à jour selon la nature du changement. Une nouvelle décision acceptée, un nouveau standard ou un nouveau savoir-faire déclenche une revue de ces vecteurs, dont ce site fait partie : la question « le site doit-il changer ? » est posée systématiquement, et au minimum l’index des décisions est régénéré.

Pourquoi le site est un vecteur comme les autres

Un site de documentation qui n’est pas branché sur le circuit de propagation devient une photographie : juste le jour de sa publication, faux ensuite, et d’autant plus trompeur qu’il a l’air soigné.

En l’inscrivant au registre, un changement d’architecture pose la question de sa répercussion documentaire au moment où il est décidé — pas six mois plus tard, quand quelqu’un remarque l’écart.

6 · Les robots de la documentation

Trois contrôles automatiques protègent ce site. Ils ne publient jamais de correctif eux-mêmes : ils signalent, un humain corrige.

Robot	Ce qu’il surveille	Effet
Anti-fuite	Qu’aucun motif interdit (identifiants d’infrastructure, adresses internes, comptes, secrets) n’apparaisse dans la source du site	Bloquant — la modification ne passe pas
Fraîcheur des faits	Que les faits affirmés par le site correspondent toujours aux registres internes	Rapport hebdomadaire, ouverture d’un signalement en cas d’écart
Couverture des sources	Que les documents cités par chaque page existent toujours et n’aient pas été modifiés après la dernière revue de la page	Rapport hebdomadaire, ouverture d’un signalement

Deux natures d'erreur, deux robots

Le contrôle de fraîcheur attrape « un fait affirmé est devenu faux ». Il ne peut pas attraper « un pan entier du sujet manque » — on ne détecte pas l’absence en comparant des affirmations.

C’est le rôle du contrôle de couverture : chaque page déclare, dans son en-tête, les documents du dépôt dont elle dérive et la date de la dernière confrontation. Quand une source évolue après cette date, la page devient suspecte et le signale — même si tout ce qu’elle affirme est encore exact.

Pour aller plus loin

• Index des décisions — la liste, générée depuis le dépôt.
• Index des savoir-faire — les pratiques codifiées, générées elles aussi.
• Naissance d’une application — un exemple complet de doctrine et de ses conséquences.
• Où trouver quoi — la carte sujet par sujet.