Concevoir pour la simplicité¶
Chapter Info
Calculating... Writing Progress: 60%
La simplicité est l’une des disciplines les plus difficiles de la conception de systèmes. La complexité s’accumule naturellement à mesure que les systèmes grandissent — à travers de nouvelles exigences, des dépendances, des abstractions, des exceptions et des décisions qui semblent chacune raisonnable prise isolément. Le défi est d’en garder le contrôle. Les grands systèmes ne sont pas simples par accident ; ils restent simples parce que la complexité y est questionnée, contenue et placée délibérément.
Qu’est-ce que la simplicité ?¶
La simplicité est la discipline qui consiste à rendre un système aussi facile à comprendre et à raisonner que le problème le permet. Elle ne signifie pas rendre le système petit, rudimentaire ou moins capable. Elle consiste à retirer ce qui n’a pas besoin d’être là, à clarifier ce qui reste et à empêcher la complexité nécessaire de se propager. Un système simple contient la complexité qu’exige le problème — et le moins possible de complexité accidentelle.
Distiller jusqu’à l’essence¶
« La simplicité ne consiste pas seulement à retirer le superflu. La simplicité, c’est affronter la complexité du monde et tenter d’en distiller la pure essence. » En conception de systèmes, cela signifie décomposer la complexité jusqu’à ce que ses éléments essentiels et leurs relations deviennent clairs. Séparez ce qui est fondamental de ce qui est accessoire ou superficiel, retirez ce qui ne contribue pas au résultat, et simplifiez les relations qui subsistent. L’objectif n’est pas de nier la complexité, mais de la comprendre assez bien pour révéler la structure la plus simple qui représente fidèlement ce qui compte.
Eric Kim
K.I.S.S. — Keep It Simple, Stupid.
« La simplicité ne consiste pas seulement à retirer le superflu. La simplicité, c’est affronter la complexité du monde et tenter d’en distiller la pure essence. »
Isoler ce qui peut changer indépendamment¶
Une fois la complexité décomposée en ses parties essentielles, isolez ce qui peut changer, tomber en panne ou passer à l’échelle indépendamment. Donnez à chaque partie une frontière claire et limitez ce qu’elle doit savoir des autres. Les changements restent ainsi locaux, les pannes sont contenues et chaque partie est plus facile à comprendre. Le même principe se retrouve dans les microservices, les monolithes modulaires, les bounded contexts et les frontières d’isolation des pannes. Séparez ce qui n’a pas besoin de bouger, de changer ou de tomber en panne ensemble.
Que puis-je retirer ?¶
La simplicité exige de retirer ce dont le système n’a pas vraiment besoin. Chaque fonctionnalité, option, abstraction, couche, dépendance, exception ou cas particulier supplémentaire ajoute quelque chose qu’il faut comprendre, tester et maintenir. Demandez-vous pour chacun : la valeur justifie-t-elle la complexité ? Sinon, retirez-le. Acceptez la complexité qu’exige le problème. Retirez celle que la solution n’exige pas.
Cacher la complexité derrière la simplicité¶
La vraie simplicité n’exige pas de faire disparaître toute la complexité sous-jacente. Une partie de la complexité est essentielle et doit rester quelque part dans le système. Le rôle de l’architecte est d’éliminer ce qui est inutile, puis de contenir et de cacher ce qui reste derrière des interfaces et des interactions claires. Pour l’utilisateur, le système peut sembler simple même si une complexité considérable existe en dessous. Les meilleures conceptions n’exposent pas la complexité simplement parce qu’elles doivent la contenir.
Grady Booch
« La tâche de l’équipe de développement logiciel est de concevoir l’illusion de la simplicité. »
Trop simple est inutile, trop complexe est inutilisable¶
La vraie simplicité demande de naviguer entre deux extrêmes dangereux. Trop simple devient inutile — cacher des détails essentiels ou ne pas résoudre le vrai problème. Trop complexe devient inutilisable — couvrir toutes les possibilités au détriment de la compréhension et de la maintenabilité. L’objectif est de préserver la complexité qu’exige le problème tout en retirant celle qu’il n’exige pas.
Complexité cachée : les deux façons de construire¶
Une conception simple rend sa structure et ses faiblesses faciles à voir. La complexité peut faire l’inverse : couches, interactions et cas particuliers peuvent masquer les problèmes sans les résoudre. Préférez les conceptions où les problèmes sont visibles et faciles à corriger.
Tony Hoare
The Emperor’s Old Clothes (conférence du Turing Award de l’ACM, 1980).
« Il y a deux manières de construire une conception logicielle : l’une consiste à la rendre si simple qu’il n’y a manifestement aucune lacune, et l’autre à la rendre si compliquée qu’il n’y a aucune lacune manifeste. » — Tony Hoare
Les bénéfices de la simplicité¶
La simplicité rend les systèmes plus faciles à changer¶
Les systèmes simples sont plus faciles à changer parce que moins de dépendances, d’hypothèses cachées et de cas particuliers doivent bouger ensemble. Un changement local a plus de chances de rester local, avec moins d’effets de bord et moins de coordination à travers le système. Cela réduit le coût et le risque de faire évoluer le logiciel dans le temps. La simplicité rend le changement plus petit, plus sûr et plus facile à contenir.
Robert C. Martin
Clean Architecture (2017).
La simplicité rend les systèmes plus faciles à comprendre¶
Les systèmes simples rendent leur structure et leur comportement plus faciles à comprendre, car les relations, les responsabilités et les dépendances sont plus faciles à suivre. Les ingénieurs passent moins de temps à reconstituer l’assemblage du système et plus de temps sur le problème lui-même. La clarté permet aussi de remarquer et de questionner les décisions inhabituelles, au lieu de les laisser disparaître dans des couches de complexité. Un système est compréhensible quand sa structure aide à l’expliquer.
La simplicité réduit le risque¶
Chaque composant, dépendance, option et cas particulier crée un endroit de plus où le comportement peut s’écarter de nos attentes. Les systèmes plus simples ont moins d’interactions à raisonner, moins de chemins à tester et moins d’hypothèses cachées susceptibles d’échouer en production. Ils sont aussi plus faciles à diagnostiquer quand quelque chose tourne mal. Réduire la complexité inutile réduit la surface d’exposition aux erreurs, aux pannes et aux surprises.
La simplicité compte le plus quand les choses cassent¶
Un système peut sembler simple quand tout fonctionne et devenir impossible à comprendre pendant une panne. La simplicité opérationnelle consiste à rendre le comportement, les dépendances, les modes de défaillance et les chemins de reprise faciles à voir quand le système est dégradé. Des signaux clairs, des flux explicites et un comportement prévisible en cas de panne réduisent le raisonnement nécessaire sous pression. Un système n’est pas vraiment simple si l’exploiter exige de reconstituer son architecture à chaque incident.
La simplicité préserve les options futures¶
Les systèmes simples évoluent plus facilement parce qu’ils s’engagent sur moins d’hypothèses, de dépendances et de contraintes inutiles. Chaque décision qui durcit l’architecture réduit l’éventail des changements qui resteront faciles plus tard. En gardant la structure minimale et en retardant les engagements qui ne sont pas encore nécessaires, la simplicité préserve la marge d’adaptation quand les exigences, l’échelle et la technologie changent. La simplicité d’aujourd’hui crée la liberté de demain.
Le coût de la complexité¶
En grandissant, tout devient plus complexe¶
À mesure que les systèmes grandissent, ils deviennent plus difficiles à comprendre, à coordonner, à exploiter et à changer. La complexité qui accompagne la croissance est universelle. Un musicien soliste devient un orchestre ; une application unique devient un système de composants en interaction. La croissance apporte de nouvelles relations, dépendances, modes de défaillance et coûts de coordination. Le défi n’est pas d’empêcher la complexité de croître, mais de l’empêcher de croître inutilement.
La complexité n’est pas linéaire avec la taille¶
À mesure que les systèmes grandissent, la complexité peut croître plus vite que leur taille, car chaque nouveau composant peut introduire de nouvelles dépendances, interactions et modes de défaillance. Ajouter un élément n’ajoute pas forcément une unité de complexité — cela peut modifier les relations entre de nombreux éléments existants. Passer à l’échelle exige donc plus que d’ajouter de la capacité ou des composants ; il faut contrôler les interactions créées par la croissance.
La charge cognitive est la vraie monnaie¶
La complexité ne coûte pas d’abord des cycles CPU — elle coûte des cycles de cerveau. La mémoire de travail humaine est limitée ; chaque dépendance, couche, exception ou convention tacite dont il faut se souvenir augmente la charge cognitive. À mesure que cette charge grandit, les ingénieurs dépensent plus d’énergie à reconstituer le contexte et moins à résoudre le problème lui-même. Le prix caché apparaît dans un onboarding plus lent, un débogage plus difficile, des revues plus longues et plus d’erreurs. Réduisez ce que les gens doivent garder en tête en même temps.
George A. Miller
« The Magical Number Seven, Plus or Minus Two » (Psychological Review, 1956).
La complexité laisse des signaux¶
La complexité n’est pas toujours visible dans un diagramme. Elle apparaît dans le travail quotidien des équipes : de petits changements touchent de nombreux endroits, les tests exigent une mise en place conséquente, les pannes ont des effets surprenants, les ingénieurs évitent certaines zones, et comprendre un changement demande de reconstituer de larges pans du système. Un onboarding long, un long délai avant un premier changement sûr et une dépendance fréquente à quelques experts sont des signaux organisationnels de complexité cachée. Des métriques comme le couplage, la croissance des dépendances, la corrélation des changements et la complexité des tests peuvent aider à révéler ces signaux. Quand des changements simples exigent systématiquement un travail complexe, le système vous dit quelque chose.
Les principes fondamentaux de simplicité¶
L’abstraction : comment les humains gèrent la complexité¶
L’abstraction est la façon dont les humains survivent à la complexité. Au lieu de gérer chaque détail à la fois, nous regroupons, cachons et simplifions — en nous concentrant uniquement sur ce qui compte à un niveau donné. En logiciel, cela se traduit par des fonctions, des modules et des API qui permettent de raisonner sur un système sans le garder tout entier en tête. Comme l’a noté Fred Brooks, !!l’abstraction n’est pas seulement une technique de code — c’est une nécessité cognitive!!. Sans elle, la complexité nous submerge.
Fred Brooks
The Mythical Man-Month (1975).
Simple n’est pas synonyme de facile¶
Simple et facile ne sont pas la même chose. Facile décrit l’effort requis maintenant ; simple décrit la structure du résultat. Une solution peut être facile à construire rapidement et pourtant créer des dépendances enchevêtrées qui rendent chaque changement futur plus difficile. À l’inverse, une conception simple peut demander plus de réflexion au départ, car les responsabilités et les relations doivent être clarifiées. !!Optimisez la simplicité structurelle, pas la commodité immédiate.!!
Rich Hickey
Simple Made Easy (Strange Loop, 2011).
Préférer l’explication la plus simple qui fonctionne¶
Quand plusieurs conceptions résolvent le même problème, préférez celle qui introduit le moins d’hypothèses, de concepts, de composants et de dépendances inutiles. C’est le rasoir d’Occam appliqué à la conception logicielle : !!ne multipliez pas la complexité sans nécessité.!! La solution la plus simple n’est pas celle qui demande le moins de code ou d’effort, mais celle qui résout le problème en introduisant le moins de structure supplémentaire.
Rasoir d’Occam
Guillaume d’Ockham, XIVe siècle.
La simplicité vient de frontières claires¶
Un système devient plus facile à raisonner quand chaque composant a une responsabilité claire, une forte cohésion et un couplage minimal avec le reste du système. Quand des préoccupations sans rapport sont entremêlées, comprendre ou changer une chose exige d’en comprendre beaucoup d’autres. De bonnes frontières contiennent la complexité : chaque partie peut être comprise, testée, modifiée et remplacée en sachant le minimum sur ce qui l’entoure.
Concevoir pour le prochain lecteur¶
Un logiciel est lu et modifié bien plus souvent qu’il n’est écrit la première fois. Une conception simple rend son intention, sa structure et ses dépendances faciles à découvrir. Les ingénieurs ne devraient pas avoir à reconstituer le système à partir de détails éparpillés ou de relations cachées avant de faire un changement. !!Concevez pour la personne qui devra comprendre le système dans six mois — vous-même compris.!!
Complexité essentielle vs complexité accidentelle¶
Toute complexité n’est pas égale. La complexité essentielle vient du problème lui-même — les règles, contraintes, échelle et capacités que le système exige réellement. La complexité accidentelle vient de la manière dont nous choisissons de le résoudre : mauvaises abstractions, frontières floues, dépendances enchevêtrées, couches inutiles et systèmes qui ont grandi sans intention. La discipline de la simplicité ne consiste pas à éliminer toute complexité — mais à éliminer la complexité accidentelle tout en gérant soigneusement la complexité essentielle qui subsiste.
Placer la complexité délibérément¶
Une bonne architecture n’élimine pas la complexité ; elle élimine la complexité inutile et place ce qui reste là où elle gêne le moins. Chaque décision d’architecture simplifie quelque chose tout en introduisant de la complexité ailleurs. L’objectif n’est pas de la faire disparaître, mais de la concentrer derrière des frontières claires où elle peut être comprise, automatisée et maintenue. La complexité qui doit exister doit avoir un foyer intentionnel.
Les approches clés pour réduire la complexité¶
Les architectes s’appuient sur un petit ensemble de gestes structurels pour garder la complexité maîtrisable : diviser le système (modularité), protéger chaque partie (encapsulation), garder les parties faiblement connectées (découplage) et cacher les détails derrière des concepts utiles (abstraction) — puis rendre le système obtenu intuitif pour ceux qui travaillent avec (expérience développeur). Chacune traite une dimension différente de la complexité ; ensemble, elles rendent les systèmes complexes plus faciles à comprendre, à changer et à maintenir.
Découper le système en modules¶
La modularité découpe un système complexe en parties plus petites et cohérentes. Chaque module a une responsabilité ciblée et une frontière claire, de sorte que les ingénieurs peuvent raisonner sur une partie sans comprendre tout le système d’un coup. Une bonne modularité réduit le périmètre à garder en tête et rend la structure du système plus facile à parcourir. Découpez le système en parties qui peuvent être comprises isolément.
L’encapsulation pour la clarté et la sûreté¶
Une fois le système découpé en modules, chaque module a besoin d’une frontière claire qui protège ses entrailles. L’encapsulation garde le fonctionnement interne des composants caché du monde extérieur. !!En n’exposant que le nécessaire et en cachant le reste, l’encapsulation empêche le code externe d’interagir avec l’état interne, ce qui réduit les erreurs et les effets de bord involontaires.!! Cette séparation nette entre interface et implémentation rend les composants plus faciles à raisonner et la base de code moins sujette aux erreurs.
Le découplage pour la flexibilité¶
Le découplage minimise ce que les composants doivent savoir les uns des autres. Les composants doivent dépendre de contrats clairs plutôt que de détails internes, d’hypothèses ou de choix d’implémentation. Des dépendances moins nombreuses et plus explicites rendent chaque partie plus facile à comprendre, à remplacer et à faire évoluer, sans coordonner de changements inutiles à travers le système. Dépendez de ce qu’un composant promet, pas de la façon dont il fonctionne.
L’abstraction : simplifier en cachant la complexité¶
Le même mécanisme cognitif devient une technique de conception en logiciel. L’abstraction crée des modèles et des interfaces simplifiés qui exposent ce que fait un système tout en cachant comment il le fait. En travaillant avec ces concepts de plus haut niveau, les développeurs peuvent concevoir, comprendre et modifier un système sans naviguer sans cesse dans toute la complexité de son implémentation. Une bonne abstraction réduit ce qu’il faut comprendre d’un coup sans cacher ce qu’il faut savoir.
Convention plutôt que configuration¶
Chaque option de configuration est une décision de plus que quelqu’un doit comprendre et prendre. !!La convention plutôt que la configuration allège ce fardeau en fournissant des valeurs par défaut sensées pour le cas courant!!, et n’exige une configuration explicite que lorsqu’un système doit s’en écarter. De bonnes conventions font du chemin simple le chemin par défaut — réduisant la mise en place, la charge cognitive et les risques d’incohérence, tout en préservant la flexibilité là où elle est vraiment nécessaire.
Les standards réduisent la complexité¶
Les standards réduisent la complexité en transformant des décisions récurrentes en réponses partagées. Sans eux, chaque équipe peut choisir ses propres outils, nommages, interfaces, workflows et pratiques — multipliant le nombre de schémas que les développeurs doivent apprendre et que les systèmes doivent supporter. Un bon standard capture un choix éprouvé une fois pour toutes et permet à chacun de le réutiliser sans reconsidérer le problème depuis zéro. Les standards ne doivent pas empêcher les exceptions justifiées, mais ils doivent rendre le chemin courant prévisible. !!Standardisez ce qui n’a pas besoin d’être différent, pour que l’attention reste sur ce qui l’est vraiment.!!
Améliorer l’expérience développeur (DX)¶
Une fois la structure saine, l’expérience de son usage compte aussi. L’expérience développeur (Developer Experience) simplifie le développement logiciel en rendant les interactions intuitives et directes. Une DX bien conçue réduit la charge cognitive, permettant aux développeurs de construire, maintenir et étendre des systèmes avec un minimum de friction. En privilégiant la facilité d’usage des outils, des frameworks et des workflows, la DX garantit que même des systèmes complexes peuvent être développés efficacement, ce qui réduit le temps d’onboarding et les besoins de support.
Stratégies pratiques pour des systèmes simples¶
Bien nommer est le fondement de la simplicité¶
Phil Karlton disait qu’il n’y a que deux choses difficiles en informatique : l’invalidation de cache et le nommage. !!Un bon nom est une abstraction gratuite — il dit au lecteur à quoi sert quelque chose sans l’obliger à lire l’implémentation.!! Un mauvais nom est une taxe que chaque lecteur paie à perpétuité : chaque identifiant ambigu impose un petit détour par le contexte, multiplié par chaque rencontre future. La simplicité au niveau du code commence ici, avant la structure, avant les abstractions, avant les patterns. !!Si vous ne pouvez pas le nommer clairement, vous ne le comprenez pas encore clairement.!!
Phil Karlton
L’aphorisme sur l’invalidation de cache et le nommage est largement attribué à Karlton ; aucune publication primaire de référence n’est facilement disponible.
Traiter tout le code de la même façon¶
Le code peut servir des buts très différents — logique applicative, infrastructure, automatisation, configuration ou outillage — mais ces différences ne devraient pas créer de différences inutiles dans la façon dont nous le traitons. Traitez le code de manière cohérente : versionnez-le, relisez-le, testez-le, documentez-le et livrez-le via des pratiques claires et reproductibles. Quand chaque catégorie de code invente ses propres conventions et workflows, les développeurs doivent apprendre plusieurs façons de faire le même travail fondamental. Une approche unifiée réduit ces variations, diminue la charge cognitive et rend l’ensemble du système plus facile à comprendre et à maintenir.
Réutiliser avant de construire¶
Avant de construire quelque chose de nouveau, cherchez une solution éprouvée qui résout déjà assez bien le problème. Les bibliothèques, frameworks, composants internes partagés et outils établis peuvent supprimer des catégories entières de travail de conception et de maintenance. Réutiliser, ce n’est pas éviter l’ingénierie ; c’est dépenser l’effort d’ingénierie là où il crée une valeur unique. Résolvez les problèmes courants avec des solutions éprouvées, et réservez le travail sur mesure à ce qui est vraiment spécifique à votre système.
Transférer la complexité au lieu de la porter¶
La simplicité n’exige pas toujours d’éliminer la complexité. Parfois, la meilleure stratégie est de la déplacer hors du système que votre équipe doit posséder. Les services managés permettent à un fournisseur de prendre en charge des préoccupations d’infrastructure difficiles comme le provisionnement, le patching, le scaling, la réplication, les sauvegardes et l’exploitation. !!La complexité existe toujours — mais quelqu’un d’autre est spécialisé pour la gérer.!! Transférer délibérément la complexité peut être aussi précieux que la réduire.
Choisir une technologie ennuyeuse¶
Chaque équipe dispose d’un budget fini de nouveauté — Dan McKinley l’appelle le budget de !!« jetons d’innovation »!!. Dépensez trois jetons sur une nouvelle base de données, un nouveau langage et une nouvelle plateforme d’orchestration, et il ne vous en reste plus pour le produit lui-même. Une technologie ennuyeuse est ennuyeuse parce que ses modes de défaillance sont connus, ses particularités opérationnelles documentées, son vivier de recrutement large, et que Stack Overflow a déjà répondu à la question de demain. !!Gardez vos jetons d’innovation pour le problème que seule votre entreprise a ;!! partout ailleurs, préférez l’outil qui est un cran en deçà de l’état de l’art.
Dan McKinley
« Choose Boring Technology » (2015).
Collaborer avant de réinventer¶
Les équipes font souvent face aux mêmes problèmes de manière indépendante. Sans visibilité ni collaboration, chaque équipe peut construire son propre contournement, outil ou solution — dupliquant l’effort et créant une fragmentation inutile. !!Une culture de collaboration rend les problèmes partagés visibles et encourage les équipes à les résoudre ensemble ou à réutiliser l’existant.!! Avant de construire une nouvelle solution, cherchez ce qui existe, partagez le besoin et collaborez autant que possible. !!Résolvez les problèmes communs une fois, pas indépendamment dans chaque équipe.!!
La simplicité plutôt que l’astuce¶
Le code astucieux flatte son auteur ; le code simple sert son équipe. Le ternaire enchaîné, le tour de métaprogrammation, le one-liner qui compresse dix lignes — chacun peut sembler élégant à l’écriture mais fait payer un coût de compréhension à chaque lecture. Le code est lu et modifié à répétition tout au long de sa vie, donc l’astuce taxe chaque futur lecteur. La simplicité est la discipline la plus difficile, car elle valorise le fait d’être compris plutôt que de paraître sophistiqué. Un code ennuyeux est une qualité, pas un échec — choisissez la version qu’un collègue fatigué peut comprendre à minuit.
Chaque couche doit mériter sa place¶
Chaque couche a un coût. Elle ajoute quelque chose qu’il faut comprendre, maintenir et parcourir, et elle augmente la distance entre un problème et sa solution. Les couches peuvent être précieuses quand elles cachent la complexité, créent une frontière utile ou rendent l’ensemble du système plus facile à raisonner. Mais une couche ne devrait jamais exister simplement parce qu’on peut en ajouter une autre. !!Ne gardez que les couches dont la valeur justifie la complexité qu’elles introduisent.!!
Décider élimine la complexité¶
L’indécision crée souvent de la complexité parce que le système doit garder plusieurs possibilités ouvertes en même temps. Au lieu de choisir une direction, on ajoute des options, de la configuration, des abstractions, des couches de compatibilité et des chemins alternatifs pour pouvoir repousser la décision. Une part d’incertitude est inévitable, mais préserver indéfiniment toutes les possibilités rend le système plus difficile à comprendre et à changer. Quand les éléments sont suffisants, prenez la décision et retirez les alternatives dont vous n’avez plus besoin.
Gregor Hohpe
« La complexité excessive est la punition de la nature pour les organisations incapables de prendre des décisions. »
Simplifier progressivement¶
Les systèmes existants permettent rarement un nouveau départ propre. La simplification doit généralement se faire pendant que le système continue de servir les utilisateurs. Créez des frontières claires autour de la zone à améliorer, remplacez ou simplifiez une partie à la fois, déplacez le comportement graduellement et retirez l’ancien chemin quand il n’est plus nécessaire. Des patterns comme le Strangler Fig appliquent cette approche à plus grande échelle. N’attendez pas une réécriture pour simplifier le système — faites en sorte que chaque changement le laisse plus simple qu’avant.
Remettre en question les exigences pour préserver la simplicité¶
Les exigences façonnent la complexité avant même que l’architecture ne commence. Une exigence qui paraît petite peut imposer des composants supplémentaires, des cas particuliers, des intégrations ou une charge opérationnelle. Traitez les exigences comme des entrées de conception, pas comme des contraintes immuables : comprenez la valeur qu’elles portent et remettez en question celles dont le coût en complexité dépasse la valeur apportée. Parfois, l’architecture la plus simple ne vient pas d’une implémentation plus astucieuse, mais d’un changement de ce que le système doit faire.
Se concentrer sur l’essentiel vital¶
Le principe de Pareto suggère qu’une petite partie d’un système délivre souvent l’essentiel de sa valeur, tandis que les cas limites, options et raffinements restants peuvent représenter une part disproportionnée de sa complexité. La simplicité consiste à identifier les capacités qui comptent le plus et à bien les concevoir avant de s’étendre vers la longue traîne. La répartition 80/20 n’est pas une règle mathématique, mais un rappel : ne laissez pas les derniers 20 % de valeur créer 80 % de la complexité.
Vilfredo Pareto et Joseph M. Juran
Pareto a observé une répartition inégale des richesses dans l’Italie du XIXe siècle. Juran a ensuite nommé et popularisé cette heuristique plus large sous le nom de principe de Pareto, en introduisant l’expression « vital few and useful many » (les peu vitaux et les nombreux utiles).
Quand la complexité en vaut la peine¶
La complexité doit mériter sa place¶
La complexité est justifiée quand elle achète une capacité dont le système a réellement besoin — comme la flexibilité, la performance, la scalabilité, la résilience ou l’extensibilité. La question n’est pas de savoir si la complexité est mauvaise, mais si la valeur qu’elle crée vaut le coût de la comprendre, la tester, l’exploiter et la maintenir. Chaque complexité ajoutée doit avoir une raison claire d’exister.
Simplicité et flexibilité tirent dans des directions opposées¶
La simplicité réduit les concepts, les choix et les interactions ; la flexibilité ajoute des options et des chemins pour qu’un système s’adapte à davantage de situations. Les deux ont de la valeur, mais elles tirent naturellement dans des directions opposées. Trop peu de flexibilité crée de la rigidité, tandis que trop de flexibilité introduit une complexité qui ne servira peut-être jamais. Une bonne conception accepte juste assez de complexité pour fournir la flexibilité dont le système a vraiment besoin — et pas plus.
Trouver l’équilibre¶
Trop peu de flexibilité crée de la rigidité : chaque nouveau besoin exige un fork, une exception ou un contournement. Trop de flexibilité crée de la complexité : chaque comportement devient configurable, abstrait et plus difficile à comprendre. L’objectif n’est pas la flexibilité maximale, mais la quantité dont le système a réellement besoin.
L’optimisation prématurée¶
La façon la plus courante de surpayer en complexité est l’optimisation prématurée — construire pour une échelle que vous n’avez pas, ajouter de l’abstraction pour des cas d’usage qui n’existent pas, concevoir des points d’extension pour des exigences qui ne viendront peut-être jamais. Cela paraît responsable mais c’est souvent de la spéculation. !!Documentez les goulots d’étranglement potentiels, planifiez-les, mais ne les implémentez pas tant qu’ils ne sont pas réels.!! Même une bonne optimisation a un coût : elle rend le code plus difficile à lire et à maintenir. Construisez pour aujourd’hui. Payez le prix de la complexité quand le besoin est réel, pas seulement anticipé.
Attendre la troisième occurrence¶
L’image miroir de l’optimisation prématurée est l’abstraction prématurée. La première fois que vous écrivez quelque chose, écrivez-le ; la deuxième fois, tolérez la duplication ; la troisième fois, envisagez l’abstraction. Avec trop peu d’exemples, il est facile de deviner le mauvais axe de variation et de créer une abstraction contre laquelle les cas futurs devront lutter. Une mauvaise abstraction peut coûter plus cher que la duplication qu’elle devait supprimer. Laissez la répétition révéler le motif avant de l’encoder.
La simplicité à l’ère de l’IA¶
L’IA peut gérer plus de complexité¶
L’IA change une contrainte fondamentale du génie logiciel : la quantité de complexité que l’on peut naviguer à la fois. L’IA peut inspecter de grandes bases de code, suivre des dépendances à travers de nombreux fichiers, comparer des implémentations, générer des changements et raisonner sur plus de contexte qu’un humain ne peut en garder confortablement en mémoire de travail. Des tâches qui exigeaient autrefois de simplifier un système juste pour le rendre compréhensible peuvent de plus en plus être assistées par des machines. L’IA augmente la quantité de complexité avec laquelle nous pouvons travailler — ce qui soulève une question fondamentale : si l’IA peut gérer plus de complexité, la simplicité compte-t-elle encore ?
La simplicité est-elle encore pertinente ?¶
Oui — parce que naviguer dans la complexité n’est pas la même chose que supprimer ses conséquences. Les systèmes complexes contiennent toujours plus d’interactions, d’hypothèses cachées, de modes de défaillance et de façons dont un changement produit des effets imprévus. L’IA peut nous aider à comprendre et à traverser cette complexité, mais la complexité elle-même existe toujours dans le système. L’IA augmente la complexité que nous pouvons gérer ; la simplicité réduit la complexité que nous avons à gérer tout court.
Quand créer ne coûte presque rien, la simplicité devient un filtre¶
L’IA rend la création extraordinairement bon marché. Nous pouvons générer plus de code, plus de texte, plus d’alternatives, plus d’abstractions et plus de solutions presque sans friction. La contrainte se déplace de notre capacité à créer vers notre capacité à décider ce qui mérite de rester. Quand la création devient abondante, la simplicité devient un filtre. Explorez largement avec l’IA, puis réduisez, simplifiez et distillez délibérément jusqu’à ce qu’il ne reste que ce qui compte.
Garder une complexité compréhensible par les humains¶
L’IA peut comprendre, générer et exploiter des systèmes de plus en plus complexes, mais les humains doivent encore prendre les décisions, relire les changements, diagnostiquer les pannes et assumer la responsabilité des résultats. La complexité ne doit pas dépasser ce que les personnes responsables du système peuvent comprendre. Utilisez l’IA pour réduire l’effort nécessaire pour travailler avec la complexité — pas comme une raison de créer des systèmes que les humains ne peuvent plus expliquer.
La simplicité donne un meilleur contexte à l’IA¶
L’IA peut naviguer dans plus de complexité qu’un humain, mais elle dépend toujours de la structure et du contexte qu’on lui donne. Des frontières claires, des conventions cohérentes, des interfaces explicites et des patterns prévisibles réduisent l’ambiguïté et facilitent l’inférence de l’intention. Dans un système enchevêtré, l’IA doit reconstituer des relations cachées et deviner quels patterns sont intentionnels ; dans un système simple, l’architecture elle-même fait office de guide. !!La simplicité rend le système plus facile à comprendre non seulement pour les humains, mais aussi pour que l’IA raisonne dessus et le modifie correctement.!!
