Concevoir par les principes¶
Chapter Info
Calculating... Writing Progress: 80%
!!La conception logicielle est la discipline qui consiste à faire des choix délibérés avant que la complexité ne les fasse à notre place. Il ne s’agit ni de règles rigides ni de patterns à la mode, mais de comprendre les forces qui façonnent un système — changement, couplage, échelle, contraintes humaines et temps — et de choisir des structures qui le gardent compréhensible à mesure qu’il grandit.!!
Introduction¶
Le Big Ball of Mud : l’option par défaut¶
!!L’architecture la plus répandue au monde est l’absence d’architecture.!! Foote et Yoder lui ont donné un nom — le Big Ball of Mud — précisément parce que c’est le résultat par défaut d’un développement sans conception délibérée : le code s’accumule sans frontières, chaque partie touche toutes les autres, et après quelques années plus personne ne se souvient pourquoi chaque chose est où elle est. Ce n’est pas le fruit de mauvaises intentions ; c’est le fruit de l’absence de décisions. Chaque principe de ce chapitre existe pour une seule raison — résister à cette gravité silencieuse.
Brian Foote et Joseph Yoder
Big Ball of Mud (1997).
Qu’est-ce que la conception logicielle ?¶
!!La conception logicielle est l’art de résoudre des problèmes réels avec des systèmes qui doivent évoluer dans le temps.!! Les exigences changent, les technologies évoluent, les besoins des utilisateurs grandissent — le défi n’est pas seulement de construire quelque chose qui fonctionne aujourd’hui, mais de créer des systèmes capables de s’adapter demain sans s’effondrer sous leur propre complexité. L’ennemi, c’est l’accumulation de complexité. Chaque fonctionnalité ajoutée, chaque raccourci pris, chaque « correctif temporaire » devenu permanent alourdit le système. Ce qui prenait des heures prend désormais des semaines. Ce qui était clair devient opaque. Ce qui était flexible devient rigide.
Robert C. Martin
Clean Architecture: A Craftsman's Guide to Software Structure and Design (2017).
Une bonne conception se construit une décision à la fois¶
Une bonne architecture n’est pas le résultat d’une décision brillante. Elle est façonnée par d’innombrables choix, grands et petits, qui se renforcent ou se sabotent mutuellement. Un raccourci peut sembler inoffensif isolément, mais des raccourcis répétés créent de la complexité ; des choix délibérés peuvent au contraire établir des frontières claires et une structure cohérente. Aucun principe ne garantit à lui seul une bonne architecture. Ensemble, les principes offrent une direction commune pour prendre des décisions qui renforcent le système au lieu de l’affaiblir progressivement.
La conception est partout — et l’affaire de tous¶
La conception apparaît dans chaque décision du cycle de vie logiciel : nommer une variable, structurer une fonction, définir un chemin de déploiement, façonner les logs, choisir l’infrastructure ou définir l’architecture d’un système. La conception est la responsabilité de tous. Ingénieurs logiciel, DevOps, sécurité, infrastructure, équipes plateforme et managers façonnent tous le système par leurs choix, et chacun de ces choix laisse une empreinte sur la lisibilité, la maintenabilité, la fiabilité et l’adaptabilité à long terme.
La conception est un voyage¶
!!La conception n’est pas un acte ponctuel — c’est un processus continu et itératif, façonné par le dialogue, le feedback et la confrontation au réel.!! Contrairement à une destination qu’on atteint et qu’on déclare terminée, la conception est un voyage permanent qui ne s’achève jamais vraiment. Chaque décision ouvre de nouveaux chemins, chaque solution révèle de nouveaux défis, chaque implémentation enseigne de nouvelles leçons. Une bonne conception évolue par essais et erreurs, par des conversations avec les parties prenantes et par la tension entre besoins contradictoires. La première version est rarement la meilleure — ce n’est que le point de départ.
L’état d’esprit de conception¶
La vision donne la direction¶
La vision est ce qui donne une direction à un système. !!C’est l’horizon lointain vers lequel le système avance — et la direction façonne chaque pas fait en son nom!!. Avec une vision, les décisions isolées s’alignent : chaque changement devient un petit pari sur un avenir que l’équipe a convenu de construire, et avec le temps ces paris se cumulent en architecture. Sans elle, les mêmes décisions ne sont raisonnables que localement — globalement incohérentes — et le système s’érode par accumulation, un incrément bien intentionné après l’autre. La vision transforme des décisions isolées en un système cohérent. C’est la différence entre le mouvement et la direction.
Concevoir sans frontières¶
La plupart des conceptions se font à travers une lentille étroite : un seul ticket, un seul sprint, une seule équipe. Le changement est défini pour tenir dans le territoire que cette équipe possède — et c’est précisément le piège de la micro-conception. Notre service, notre code, notre infrastructure deviennent des frontières artificielles pour la solution. Mais le système ne respecte pas ces frontières : dépendances, données, pannes, latence, risques de sécurité et complexité les traversent librement. !!Une bonne conception sort des frontières de la propriété et se demande ce qui est juste pour le système dans son ensemble.!!
Avoir le courage de concevoir sans frontières¶
Concevoir sans frontières demande le courage de quitter le territoire que nous contrôlons, d’entrer dans des territoires qui appartiennent à d’autres et de remettre en cause des décisions ou des priorités en chemin. Cela implique de convaincre, de négocier et parfois d’affronter le conflit pour défendre ce qui est juste pour le système dans son ensemble.
Concevoir les pieds sur terre¶
!!Une bonne conception commence par la compréhension de la réalité dans laquelle le système doit vivre.!! Avant de penser aux patterns, aux technologies ou aux idéaux d’architecture, comprenez le business, les clients, le budget, les personnes, la stack existante, le legacy et les contraintes qui l’ont façonné. La théorie fournit des principes et des idées, mais l’architecture ne se fait pas en théorie. Un bon architecte garde les pieds fermement sur terre et utilise les principes pour améliorer le monde tel qu’il existe — pas pour concevoir un système parfait pour une organisation imaginaire.
Modéliser le métier¶
Un système doit être construit autour des concepts du métier qu’il sert — clients, commandes, virements, comptes — et non autour d’abstractions techniques inventées pour le confort du développeur. Enregistrer un virement bancaire et enregistrer un « like » d’utilisateur peuvent sembler identiques au niveau du code — les deux écrivent une ligne, les deux renvoient un statut — pourtant leur sens métier est radicalement différent : l’un exige auditabilité, forte cohérence et autorisation stricte ; l’autre peut se contenter de garanties bien plus simples. Quand le code et le métier partagent le même vocabulaire, le système devient plus facile à discuter, plus facile à faire évoluer et bien moins susceptible de dériver de ce qu’il est censé faire. C’est l’idée centrale du Domain-Driven Design (DDD) : l’architecture est façonnée par le domaine, pas par le schéma de base de données ni par le framework.
Garder la complexité sous contrôle¶
Facile n’est pas toujours juste¶
Le choix le plus facile aujourd’hui n’est pas toujours le bon. La facilité est un biais puissant : nous préférons naturellement la solution qui correspond à ce que nous connaissons, à ce que nous possédons déjà et à ce qui demande le moins de résistance. Mais une bonne conception ne consiste pas à minimiser l’effort d’aujourd’hui. Elle consiste à faire le choix qui sert le mieux le système dans la durée, même quand ce choix est plus difficile aujourd’hui.
Rich Hickey
Simple Made Easy (2011) distingue la simplicité de la facilité.
La seule façon d’aller vite est d’aller bien¶
Dans son livre fondateur Clean Architecture: A Craftsman's Guide to Software Structure and Design, Robert C. Martin affirme que « la seule façon d’aller vite est d’aller bien » est l’un des principes fondamentaux du développement logiciel durable. !!À long terme, vitesse et qualité ne sont pas des forces opposées.!! Un code propre et bien structuré est ce qui permet aux équipes de continuer à avancer vite dans la durée. Une mauvaise conception peut créer l’illusion de la vitesse au début, mais elle finit par transformer chaque changement en négociation avec la dette technique.
La quête de simplicité : fondation de tous les principes¶
La conception logicielle est guidée par de nombreux principes — modularité, testabilité, sécurité, scalabilité, résilience. Chacun compte. Mais !!un principe domine tous les autres : la simplicité!!. Sans simplicité, tous les autres principes deviennent plus difficiles à atteindre. Un système complexe résiste aux tests. Une architecture complexe cache des failles de sécurité. Un code complexe freine la scalabilité. La simplicité n’est pas un principe parmi d’autres — c’est la fondation qui rend tous les autres possibles. C’est ce qui permet à un système de rester compréhensible, modifiable et digne de confiance dans le temps.
Pour aller plus loin
Chapitre : Concevoir pour la simplicité.
YAGNI – Éviter la sur-ingénierie¶
« You Aren't Gonna Need It » (YAGNI) nous rappelle de ne pas construire de fonctionnalités ou de systèmes avant qu’ils ne soient nécessaires. !!La sur-ingénierie ajoute maintenance et complexité inutiles sans valeur garantie.!! Construisez pour ce dont vous avez besoin aujourd’hui, et concevez avec assez de flexibilité pour vous adapter demain.
Ron Jeffries et l’Extreme Programming
YAGNI (« You Aren't Gonna Need It ») est une pratique de l’Extreme Programming associée à Ron Jeffries.
Marcher avant de courir¶
!!Méritez chaque niveau de sophistication avant de passer au suivant!!. Avant de concevoir pour le multi-cloud, maîtrisez un seul cloud. Avant d’optimiser pour des millions d’utilisateurs, faites fonctionner le système pour des milliers. Avant de construire des abstractions couvrant plusieurs contextes, prouvez leur valeur dans un seul. Le principe ne manque pas d’ambition — il s’agit de mériter sa complexité : chaque niveau doit être justifié par une contrainte réelle à laquelle vous faites face, pas par un futur hypothétique. Les équipes qui se précipitent vers des patterns avancés sans maîtriser les fondamentaux accumulent une complexité qu’elles n’ont aucune expérience à gérer.
Arrêtez d’ajouter votre propre complexité¶
Une partie de la complexité appartient au problème et est inévitable. Mais les systèmes deviennent souvent plus complexes que les problèmes qu’ils résolvent parce que nous ajoutons notre propre complexité : abstractions inutiles, structures confuses, trop de couches ou solutions sur-conçues. Une bonne conception accepte la complexité qu’exige le problème et élimine celle que nous créons nous-mêmes.
Frederick P. Brooks, Jr.
No Silver Bullet—Essence and Accidents of Software Engineering (1986) distingue la complexité essentielle, inhérente à un problème, de la complexité accidentelle introduite par son implémentation.
N’optimisez pas ce qui ne devrait pas exister¶
!!Le code le plus rapide et le plus propre est celui que vous n’avez jamais besoin d’écrire — ni de conserver.!! Avant d’affiner des requêtes, de paralléliser des pipelines ou de gratter des millisecondes, demandez-vous d’abord si la fonctionnalité, le workflow, voire le système est vraiment nécessaire. L’optimisation ancre le gaspillage en lui donnant l’apparence de la valeur et en le rendant plus difficile à supprimer ensuite. Une bonne conception supprime, simplifie et fusionne jusqu’à ce qu’il ne reste que l’essentiel ; alors seulement, optimisez ce qui compte démontrablement. Toute optimisation a un coût de maintenance, une charge cognitive et un verrouillage. Éliminez et clarifiez d’abord ; n’optimisez qu’une fois la nécessité prouvée par l’usage réel et une valeur mesurable.
Rendre le système intelligent pour que les consommateurs n’aient pas à l’être¶
Un système bien conçu absorbe la complexité pour que ses consommateurs n’aient pas à le faire. Qu’il serve des utilisateurs, des développeurs ou d’autres services, il doit fournir des valeurs par défaut sensées, une récupération automatique et des erreurs claires. Cela peut augmenter la complexité interne, mais évite que chaque consommateur résolve les mêmes problèmes. Placez la complexité là où elle peut être gérée une seule fois, plutôt que répétée partout.
Concevoir avec un but¶
Concentrer la conception là où elle compte¶
Toutes les parties d’un système ne méritent pas le même investissement de conception. Les zones stables doivent rester simples. Les zones volatiles — règles métier, intégrations, points de passage à l’échelle, parcours utilisateur — méritent des frontières, des abstractions et des tests plus solides. Une bonne conception ne consiste pas à tout rendre flexible. Elle consiste à identifier où le changement est probable et à empêcher ces zones de devenir coûteuses à modifier. Sur-concevoir les parties stables crée de la complexité inutile ; sous-concevoir les parties volatiles prépare des douleurs futures. !!L’effort de conception doit suivre le changement attendu.!!
La conception commence à l’instant zéro¶
Les propriétés fondamentales d’un système ne sont pas des fonctionnalités qu’on ajoute plus tard — elles sont conçues dès le départ. Sécurité, disponibilité, scalabilité, observabilité, testabilité, performance et résilience sont façonnées par les premières décisions d’architecture. Concevez tôt ce qui est coûteux à rattraper ; faites grandir la capacité et la sophistication à mesure que les besoins réels émergent. L’instant zéro est le moment de la conception : la façon dont les composants communiquent, l’endroit où vit l’état et la gestion des pannes déterminent ce que le système pourra devenir. Traiter ces qualités comme des après-pensées est l’une des erreurs les plus courantes et les plus coûteuses du développement logiciel.
Une tension assumée
Ce principe peut sembler en conflit avec YAGNI et Marcher avant de courir — et cette tension est réelle. Les deux sont vrais. Concevez tôt les décisions coûteuses à inverser, mais retardez la capacité, la sophistication et les abstractions jusqu’à ce que des besoins réels les justifient. Savoir ce qui doit être décidé maintenant et ce qui doit rester ouvert fait partie de la difficulté d’une bonne conception.
Résoudre les problèmes à la source, pas les symptômes¶
!!Une conception mature distingue les symptômes des causes.!! Ne traiter que ce qui est visible ou urgent produit des correctifs superficiels qui apportent un soulagement momentané pendant que le problème sous-jacent continue de grandir. Chaque contournement ajoute de la friction et enfouit le vrai problème plus profondément. La vraie simplicité vient d’une intervention là où se trouve la cause, pas là où apparaît la douleur — en demandant sans cesse pourquoi, en remettant en cause les hypothèses, en résistant au confort du correctif rapide.
« On nettoiera plus tard » n’est pas une stratégie¶
« On nettoiera plus tard » n’arrive que rarement. La pression du marché ne retombe pas, l’urgence de livrer ne fait que croître, et la dette technique se cumule plus vite que n’importe quelle promesse d’équipe à elle-même. Chaque raccourci rend le changement suivant plus difficile, jusqu’à ce que le système soit si coûteux à modifier que « plus tard » soit repoussé indéfiniment. « On nettoiera plus tard » n’est pas une stratégie de conception. Construisez assez proprement dès aujourd’hui, et améliorez la conception en continu à mesure que le système évolue. Une dette technique délibérée peut être un compromis valable lorsqu’elle est explicite, bornée, et accompagnée d’une raison claire et d’un plan pour y revenir.
Le refactoring continu façonne des systèmes durables¶
!!Le refactoring n’est pas une tâche de nettoyage occasionnelle ; c’est ainsi que la qualité de conception survit.!! Une base de code saine évolue par de petites améliorations continues qui gardent la complexité maîtrisable et empêchent la dette technique de se figer. Attendre un futur sprint de refactoring fonctionne rarement. Le refactoring doit faire partie du développement normal : quand une fonctionnalité est terminée, le code ne doit pas seulement fonctionner, mais rester compréhensible, testable et sûr à modifier.
Chapitres associés
Concevoir pour la simplicité et Concevoir pour la testabilité couvrent les qualités structurelles que protège le refactoring continu.
Prendre des décisions¶
Concevoir, c’est prendre la bonne décision¶
Il n’existe pas de conception parfaite dans l’absolu. Il n’y a que des décisions adaptées à un contexte et à un ensemble de priorités. !!Toute conception est un compromis : performance vs simplicité, flexibilité vs rapidité, scalabilité vs coût.!! Une bonne communication de conception rend ces compromis visibles.
Les principes admettent des exceptions — mais rendez-les délibérées¶
Les principes de conception ne sont pas des lois. Le contexte peut justifier une exception, mais les exceptions doivent être délibérées. Avant de vous écarter d’un principe, comprenez ce qu’il protège, pourquoi votre contexte est différent et quel compromis vous acceptez. Chaque exception crée aussi un précédent : d’autres peuvent répéter la décision sans comprendre pourquoi elle était justifiée au départ. Une exception doit donc être rare, explicite et documentée — non seulement pour la décision d’aujourd’hui, mais pour celles qu’elle pourrait encourager demain.
Planifier d’abord¶
Un plan léger avant l’implémentation aide à distinguer l’ingénierie délibérée de l’improvisation. Bien avant l’IA, planifier d’abord — esquisser la direction, identifier les contraintes, décomposer le problème en étapes — était ce qui évitait aux équipes de construire vite la mauvaise chose. Avec l’IA, le principe devient encore plus important : dès que la génération part dans une direction, ce qui a déjà été produit influence ce qui vient ensuite. Une direction initiale faible peut ainsi façonner toute une solution avant que ses hypothèses aient été remises en question. Que la frappe soit faite par un humain ou par une machine, réfléchir avant de construire est ce qui rend le résultat digne d’être conservé.
Savoir quand arrêter de concevoir¶
La conception est itérative, mais l’itération a besoin d’un point d’arrêt. Continuez d’affiner tant que chaque passe lève une incertitude significative, réduit un risque ou améliore réellement le système. Arrêtez-vous quand l’amélioration devient surtout spéculative ou ajoute plus de complexité que de valeur. Une bonne conception n’est pas une conception parfaite — elle est assez bonne pour ce que vous savez aujourd’hui, et assez simple à revisiter demain.
Utiliser un langage précis pour les exigences¶
Les discussions de conception deviennent ambiguës quand requis, recommandé, optionnel et souhaitable sont utilisés indifféremment. La RFC 2119 fournit un vocabulaire utile : MUST signifie que l’exigence est obligatoire ; SHOULD signifie qu’il peut exister de bonnes raisons de s’en écarter, mais que les implications doivent être comprises ; MAY signifie que c’est vraiment optionnel. Un nice to have est plus faible encore : souhaitable, mais pas une exigence. Un langage précis rend les contraintes explicites et empêche les préférences de devenir discrètement des obligations — ou les obligations d’être prises pour des suggestions.
Vivre avec ses décisions¶
Documenter le pourquoi, pas seulement le quoi¶
!!Le code montre ce que fait le système. La documentation montre pourquoi!!. Sans le pourquoi, les équipes futures sont forcées de deviner à partir du seul code — et elles devineront mal, car le code encode rarement les contraintes, hypothèses et compromis qui l’ont façonné. Une bonne documentation n’est pas de la bureaucratie, c’est de la mémoire. Un ADR n’a besoin de capturer que le contexte, la décision, les alternatives écartées et les conséquences acceptées.
Michael Nygard
Documenting Architecture Decisions (2011) a introduit le format Architecture Decision Record (ADR), aujourd’hui largement utilisé.
Chapitre associé
Concevoir par le processus couvre les pratiques qui rendent reproductibles les décisions d’architecture et le travail de livraison.
Revisiter les décisions quand la réalité change¶
Une décision de conception juste le premier jour peut ne plus l’être au cinq centième. !!Les décisions ne sont pas des vérités permanentes — ce sont des réponses à un contexte qui évolue lui-même!! : exigences, échelle, maturité de l’équipe, technologie, priorités business. Un monolithe peut être le bon choix quand un produit est jeune et que la vitesse prime ; le même monolithe peut devenir un goulot d’étranglement quand l’organisation grandit et que les équipes se multiplient. La décision initiale n’était pas mauvaise — la réalité a simplement bougé. Les équipes matures revisitent leur architecture délibérément, par des changements petits et sûrs, au lieu d’attendre le moment où une réécriture douloureuse devient la seule option.
L’effet d’onde¶
!!À l’échelle du système, une seule décision de conception se propage comme une onde à la surface d’un étang.!! Un choix apparemment mineur dans la structure du code peut remodeler la performance demain ; un correctif rapide dans un service peut compromettre discrètement la scalabilité de tout le système ; une requête légèrement inefficace peut ne révéler son impact que sous charge ; une API conçue à la hâte peut limiter les intégrations futures pendant des années. Chaque décision — du nommage d’une variable au schéma de données, d’un modèle de multi-tenancy à un choix de base de données — pèse bien au-delà de son contexte immédiat, car les systèmes logiciels sont des écosystèmes interconnectés où des choix microscopiques déclenchent des effets macroscopiques.
Chaque décision écrit l’ADN de l’entreprise¶
L’effet d’onde ne s’arrête pas au système — il façonne l’organisation elle-même. !!Aucune décision isolée n’écrit l’ADN d’une entreprise, mais leur accumulation, si.!! Quand incohérences, raccourcis et choix mal faits s’empilent au fil des années et des équipes, ils cessent d’être des erreurs individuelles et deviennent l’identité de l’organisation : sa façon de construire, ce qui devient de plus en plus difficile à changer, les contraintes que chaque équipe future hérite sans les avoir jamais choisies. L’ADN d’une entreprise n’est pas déclaré dans un document de stratégie — il s’écrit, une décision discrète à la fois, par le poids cumulé de tout ce qui a jamais été livré.
L’IA et la conception¶
L’IA a des idées — vous avez le contexte¶
!!L’IA peut en savoir beaucoup sur la conception logicielle, mais elle ne vit pas naturellement dans la réalité de votre organisation.!! Elle peut proposer des architectures, des patterns et des alternatives, mais une bonne conception dépend d’un contexte souvent implicite, fragmenté et en constante évolution : conversations avec les clients, retours des développeurs, pression budgétaire, compétences de l’équipe, tensions organisationnelles, systèmes legacy et raisons derrière la stack actuelle. L’IA peut devenir un puissant partenaire de conception lorsqu’on lui donne ce contexte, mais l’architecte reste responsable de relier les idées à la réalité. Plus cette réalité est difficile à capturer, plus le jugement humain devient important.
Planifier avant de générer¶
L’IA donne envie de passer directement de l’idée à l’implémentation. Un prompt devient du code, de l’infrastructure, des API, parfois toute une architecture avant même que les décisions importantes aient été discutées. !!Utilisez l’IA pour planifier avant de l’utiliser pour construire.!! Demandez-lui d’abord de clarifier le problème, d’identifier les contraintes, d’exposer les hypothèses, de proposer des alternatives et de comparer les compromis. L’architecture doit émerger de décisions délibérées — pas de la première solution plausible que le modèle se trouve à générer.
Faire explorer l’IA avant qu’elle ne converge¶
L’IA est très douée pour produire rapidement une solution plausible — parfois trop rapidement. La première architecture qu’elle propose peut ancrer le reste de la discussion, même quand de meilleures alternatives existent. Avant de choisir, demandez des conceptions réellement différentes et rendez les compromis explicites : simplicité, coût, performance, fiabilité, exploitabilité et changements futurs. !!Utilisez l’IA pour élargir l’espace de conception avant de lui demander de le restreindre.!!
L’IA doit challenger la conception, pas seulement la compléter¶
L’IA est la plus utile en conception lorsqu’elle fait plus qu’approuver la direction déjà choisie. Demandez-lui de trouver les hypothèses cachées, les modes de défaillance, la complexité inutile, les contraintes manquantes et les raisons pour lesquelles l’architecture proposée pourrait ne pas survivre au changement. Un modèle qui ne fait que compléter votre réflexion peut renforcer vos angles morts. Un modèle à qui l’on demande de la challenger peut les exposer. !!Utilisez l’IA comme critique de conception, pas seulement comme générateur de conception.!!
Préserver le contexte, pas seulement le code¶
Quand l’IA génère du code, le prompt peut préserver un contexte précieux que le code lui-même ne peut pas : l’intention, les contraintes, les hypothèses et les instructions qui ont façonné le résultat. Mais un prompt n’est pas un enregistrement de conception — il peut ne pas capturer les alternatives envisagées, le raisonnement derrière une décision ni les compromis acceptés. Conservez les prompts utiles comme partie du contexte de conception, aux côtés des ADR et de l’autre documentation — pas à leur place.
Chapitre suivant
Concevoir par les principes structurels transforme ces principes en structure concrète : Separation of Concerns, Single Responsibility, Open-Closed et Dependency Inversion.