Architecture et conception

Ce thème mesure la capacité d'un logiciel à changer à coût borné : on sait où poser une modification, on connaît l'impact d'un changement avant de le faire, et les décisions structurantes…

Guide≈ 8 min de lectureVérifiéLecture

En bref

Ce thème mesure la capacité d'un logiciel à changer à coût borné : on sait où poser une modification, on connaît l'impact d'un changement avant de le faire, et les décisions structurantes sont écrites, datées et révisables. Il ne juge pas l'élégance des schémas, mais le coût de la prochaine évolution et la rapidité d'intégration d'un nouvel arrivant.

Sur cette page

Pourquoi ce thème
Ce que mesure le thème
Tableau des cinq niveaux
Jalons par niveau
Lecture détaillée par niveau
Atteinte partielle et notation
Passer au niveau suivant
Voir aussi

Niveau : 🟢→🔴 · Code thème : ARC (matrice DL)

Pourquoi ce thème#

Une architecture n'est jamais « bonne » dans l'absolu : elle est adaptée ou non au rythme et à la nature des changements. Quand elle ne l'est plus, chaque évolution touche dix endroits, personne n'ose supprimer quoi que ce soit, et la connaissance des raisons d'un choix disparaît avec la personne qui l'a fait. Le coût est invisible au début, puis exponentiel : la vélocité chute sans que l'on sache pourquoi. Ce thème alimente directement la dette technique (ce qu'on laisse se dégrader) et la performance (ce que l'on peut tenir en charge).

Dans un contexte datamart alimenté par une application terrain (SFA), l'architecture se joue aussi sur les interfaces de données : un schéma de staging, une vue de contrat, une table de faits ont des consommateurs (rapports, exports) qui s'engagent sur leurs colonnes. Voir le thème voisin de la matrice data : sources et contrats de données.

Ce que mesure le thème#

Axe : de « structure émergente non décrite » à « architecture gouvernée par des contraintes vérifiées automatiquement ».
Indicateur clé : rayon d'impact d'un changement type (nombre de modules/dépôts/équipes touchés par une évolution fonctionnelle courante) et délai d'intégration d'un nouvel arrivant (jours avant la première livraison en production).
Unité : modules touchés par changement ; jours ; part de décisions structurantes tracées (%).

Tableau des cinq niveaux#

Niveau	Nom court	Promesse	Indicateur type (ordre de grandeur)
1	Émergente	Le logiciel fonctionne, mais seuls ses auteurs savent pourquoi et où modifier.	Rayon d'impact inconnu ; intégration > 3 mois
2	Décrite	Vous pouvez retrouver où se trouve une fonction et qui en a décidé la forme.	Schéma d'ensemble à jour < 12 mois ; intégration ≈ 6 à 8 semaines
3	Délimitée	Un changement courant reste dans un seul module, et ses effets de bord sont connus avant livraison.	≥ 70 % des changements dans 1 module ; intégration ≈ 3 à 4 semaines
4	Gouvernée	L'architecture se défend toute seule : une règle de dépendance violée fait échouer la livraison, et chaque décision majeure est datée et révisée.	100 % des règles clés vérifiées en CI ; intégration ≈ 1 à 2 semaines
5	Évolutive	On remplace un composant entier, sans interruption, en quelques jours, avec retour arrière immédiat.	Remplacement de composant sans arrêt ; intégration < 1 semaine

Jalons par niveau#

ID	Jalon	Preuve vérifiable
DL-ARC-1.1	Le code est dans un dépôt versionné unique par produit	Chaque composant livré a une source identifiée
DL-ARC-1.2	Les composants principaux sont nommés et reconnus par l'équipe	Demander à trois personnes de nommer les composants : listes cohérentes
DL-ARC-1.3	Les dépendances externes (bases, services, API) sont connues	Liste existante, même informelle
DL-ARC-2.1	Un schéma de contexte et de conteneurs (type C4 niveaux 1-2) existe et date de < 12 mois	Date de dernière modification du schéma
DL-ARC-2.2	Un fichier de décisions (même simple) trace au moins les choix de technologie	Au moins 5 décisions datées avec contexte
DL-ARC-2.3	Les environnements et leurs différences sont décrits	Page décrivant dev/test/prod et écarts
DL-ARC-2.4	Les interfaces publiques (API, vues, fichiers d'échange) sont listées avec leurs consommateurs connus	Inventaire des contrats
DL-ARC-3.1	Les modules ont des frontières explicites (dossiers, projets, schémas) et des responsabilités écrites	Revue d'un changement récent : impact limité à 1 module dans ≥ 70 % des cas
DL-ARC-3.2	Les dépendances entre modules sont orientées (pas de cycle)	Outil d'analyse de dépendances : 0 cycle sur le cœur
DL-ARC-3.3	Les décisions structurantes passent par un ADR (Architecture Decision Record) avec alternatives écartées	≥ 80 % des changements d'architecture ont un ADR
DL-ARC-3.4	Les contrats d'interface sont versionnés et la compatibilité ascendante est une règle	Changement cassant = version majeure ; registre des consommateurs
DL-ARC-3.5	Les exigences non fonctionnelles (perf, disponibilité, sécurité) sont chiffrées par composant	Tableau de budgets par composant
DL-ARC-4.1	Les règles d'architecture sont exécutables (tests d'architecture, linter de dépendances) et bloquent la livraison	Une violation volontaire fait échouer la CI
DL-ARC-4.2	Les ADR sont revus à échéance (ou sur déclencheur) et marqués remplacés/obsolètes	Dernière revue < 12 mois sur ≥ 90 % des ADR actifs
DL-ARC-4.3	Les architectures sont évaluées sur scénarios de qualité (ex. ATAM allégé) avant les gros chantiers	Compte rendu daté pour chaque chantier > 20 jours-homme
DL-ARC-4.4	Les migrations de schéma de données sont compatibles avec la version N-1 du code (expand/contract)	Procédure rejouée en test avec N et N-1
DL-ARC-5.1	Un composant critique est remplacé de façon incrémentale (étranglement progressif / strangler fig) en production, sans arrêt	Historique d'un remplacement réalisé
DL-ARC-5.2	Les contraintes d'architecture sont mesurées en continu (couplage, rayon d'impact, temps de changement) avec tendance	Tableau de bord sur 6 mois
DL-ARC-5.3	Un nouvel arrivant livre en production en moins d'une semaine sans accompagnement individuel	Mesure sur les trois dernières arrivées
DL-ARC-5.4	Les choix à forte irréversibilité sont isolés derrière des interfaces et testés en « répétition de sortie »	Exercice documenté de bascule de fournisseur/technologie

Lecture détaillée par niveau#

🟢 Niveau 1 — Émergente#

Signes observables : « demande à Marc » ; le schéma est dans la tête ; le même concept existe sous trois noms ; une modification de colonne casse un rapport non répertorié.
Ce qu'on gagne : la vitesse initiale, l'absence de formalisme. Pertinent pour un prototype jetable.
Ce que ça ne garantit pas : toute évolution prévisible ; l'intégration d'un nouvel arrivant ; la survie au départ d'un expert.
Difficulté d'atteinte : 1/5 · Effort : 1/5.

🟢 Niveau 2 — Décrite#

Signes : un schéma d'ensemble existe, un fichier « décisions » aussi, un inventaire des interfaces. La connaissance est accessible, pas encore contrainte.
Gain : on retrouve vite où est quoi ; l'onboarding passe de mois à semaines.
Ne garantit pas : que le code respecte le schéma (la documentation peut mentir).
Difficulté : 2/5 · Effort : 2/5.

🟡 Niveau 3 — Délimitée#

Signes : frontières claires (par exemple un schéma SQL par domaine fonctionnel, des vues de contrat entre staging et restitution), dépendances orientées, ADR systématiques sur les choix structurants.
Gain : le rayon d'impact d'un changement courant se réduit ; les revues de conception ont un support.
Ne garantit pas : que les frontières tiennent dans le temps — sans vérification automatique, elles s'érodent.
Difficulté : 3/5 · Effort : 3/5.

🔴 Niveau 4 — Gouvernée#

Signes : tests d'architecture exécutables (interdiction d'une dépendance, de cycles, d'accès direct aux tables internes), compatibilité N-1 en base, ADR revus. La CI refuse ce qui viole l'intention architecturale.
Gain : l'architecture survit aux rotations d'équipe ; les écarts sont visibles le jour même.
Ne garantit pas : que l'architecture soit bonne — une mauvaise architecture parfaitement appliquée reste mauvaise. D'où les revues sur scénarios de qualité.
Difficulté : 4/5 · Effort : 4/5.

🔴 Niveau 5 — Évolutive#

Signes : on remplace un composant de bout en bout, en production, sans arrêt, par étranglement progressif ; les décisions irréversibles sont repérées et isolées.
Gain : la liberté de changer de technologie ou de fournisseur sans réécriture totale.
Ne garantit pas : l'absence de complexité accidentelle — chaque couche d'isolation a un coût, qu'il faut justifier (jamais d'abstraction « au cas où » sans scénario de sortie).
Difficulté : 5/5 · Effort : 5/5.

Atteinte partielle et notation#

Notez chaque jalon à 0, 0,5 ou 1 selon la règle commune du README. Quelques repères :

0,5 sur DL-ARC-3.1 : les frontières existent pour deux modules sur cinq ; le reste est un « gros bloc ».
0,5 sur DL-ARC-4.1 : les règles d'architecture sont exécutées, mais en simple avertissement non bloquant.
Un 5 partiel : un composant a déjà été remplacé en production par étranglement progressif et les ADR sont vivants, mais le temps d'intégration reste de deux semaines.

⚠️ Piège

Schéma de façade. Symptôme : le schéma est impeccable, mais le code ne le suit pas. Cause : aucune vérification automatique. Remède : ne créditer 1 sur DL-ARC-3.1 que si la preuve (analyse de dépendances) concorde.

Passer au niveau suivant#

Moyens possibles (facultatifs) — la promesse compte, pas le moyen.

1 → 2 : un atelier d'une demi-journée pour dessiner contexte et conteneurs (modèle C4) ; un premier fichier de décisions.
2 → 3 : isoler un domaine (par exemple un schéma SQL par domaine), poser des vues comme contrats, rédiger des ADR au fil des revues de conception.
3 → 4 : outils d'analyse de dépendances en CI, tests d'architecture, migration en deux temps (expand/contract) pour la base.
4 → 5 : choisir un composant à remplacer et le faire en incrémental ; mesurer le rayon d'impact dans la durée.

💡 Astuce d'expert

Faites passer le « test du changement type » : prenez les cinq dernières évolutions livrées, comptez les modules touchés. C'est votre indicateur, plus honnête qu'un diagramme.

⚠️ Piège (loi de Goodhart)

Si l'on récompense le « nombre d'ADR », on obtient des ADR creux. Mesurez leur revue et leur effet (décisions réellement relues avant un chantier), pas leur nombre.

🧪 Exemple

Datamart SFA : la table de staging expose 80 colonnes à 14 rapports. Un renommage coûte 3 jours (niveau 2). Après introduction de vues de contrat versionnées par domaine (niveau 3), le même renommage se traite dans une seule vue en une demi-journée ; un test de compatibilité N-1 (niveau 4) évite la casse de la version précédente des rapports.

Voir aussi#

Thèmes voisins : 02 Qualité du code · 09 Dette technique · 11 Performance et scalabilité · 10 Documentation.
Autres matrices : BI — modèle sémantique · Data — modélisation et architecture · Projet — cadrage et vision.
Pratique : stratégies de branches · CI/CD · GDS et données SQL/BI · comparatif des méthodes.
Glossaire · Notation.

✻ Rédigé par Claude Sonnet 5.5