Introduction du livre

Chapter Info

Calculating... Writing Progress: 90%

!!Le développement logiciel n’a jamais consisté à écrire du code. Il s’agit de prendre des décisions dans l’incertitude — arbitrer entre la pression à court terme et l’évolution à long terme, naviguer dans un environnement où technologie, contraintes métier et facteurs humains se télescopent. La plupart de ces décisions n’ont pas de bonne réponse. Elles impliquent des compromis. Ce livre traite de ces compromis — et des principes qui permettent de s’orienter parmi eux.!!

Concepts fondamentaux

Pourquoi le logiciel est difficile à construire

!!Le développement logiciel est par nature complexe. Il associe la résolution de problèmes abstraits à des systèmes techniques qui doivent coopérer à travers de nombreuses couches.!! Un logiciel doit gérer une multitude de situations, de cas limites et de défaillances. Les développeurs orchestrent les interactions, la concurrence, l’état distribué et les événements asynchrones tout en garantissant fiabilité et sécurité. Ils transforment des besoins métier flous en instructions précises, anticipent les comportements des utilisateurs et collaborent entre équipes. Pendant ce temps, la technologie progresse, le code existant doit rester fonctionnel et la dette technique s’accumule. Ces défis ne s’additionnent pas — ils se multiplient. !!La complexité n’est pas une phase que le logiciel traverse ; c’est le milieu où il vit.!!

Fred Brooks

No Silver Bullet: Essence and Accidents of Software Engineering (1986).

Le logiciel existe pour créer de la valeur

!!Le logiciel n’est pas une fin en soi. Il existe pour résoudre des problèmes concrets, répondre à des besoins humains, et rendre possible ce qui était difficile, voire impossible.!! Sa valeur ne dépend ni du nombre de lignes de code, ni de la sophistication de son architecture, ni des technologies choisies, mais de l’impact qu’il a dans le monde réel. Ce qui compte, ce n’est pas le logiciel lui-même, mais ce que les personnes peuvent accomplir avec lui.

Les personnes derrière le logiciel

!!Créer un logiciel exige des intervenants aux rôles complémentaires. Le produit définit quoi construire et pourquoi, les développeurs traduisent les besoins en systèmes opérationnels, les équipes plateforme fournissent des bases partagées, DevOps permet une livraison rapide et fiable, les architectes orientent les choix structurels, et la sécurité protège systèmes et utilisateurs.!! Ces responsabilités se recoupent souvent, mais chacune apporte un point de vue majeur. Construire un logiciel est un effort collectif qui va bien au-delà de l’écriture du code.

En pratique, les frontières s’estompent

Les rôles dessinent des frontières utiles, mais les équipes réelles ne s’y limitent presque jamais. Les développeurs prennent des décisions architecturales et opérationnelles, les architectes écrivent du code, et les product managers optent pour des solutions techniques. Ce croisement est indispensable : l’ambiguïté et l’évolution des besoins exigent de franchir les frontières. !!Les meilleurs systèmes naissent d’équipes qui partagent le contexte et la responsabilité, pas de spécialistes isolés dans leurs silos.!!

Rien de nouveau sous le soleil de l’architecture

!!Il n’y a rien de neuf sous le soleil architectural.!! La transition du monolithe aux microservices, ou du on-premises au cloud, remplace souvent d’anciens problèmes par de nouvelles variantes des mêmes défis. Le couplage interne devient couplage réseau ; les défaillances centralisées deviennent distribuées. Le schéma se répète avec les LLMs et des protocoles comme MCP : relier des modèles à des outils pose des questions anciennes de contrat, permissions et observabilité, compliquées par le comportement probabiliste. !!La technologie évolue, mais le défi architectural reste constant : construire des systèmes qui s’adaptent, évoluent, tombent en panne sans catastrophe, et restent compréhensibles.!!

Retour aux bases : pourquoi les principes fondamentaux comptent

!!Les principes fondamentaux constituent la base de la conception logicielle. Tout comme les fondations d'un bâtiment, ils offrent un socle stable pour tout ce qui sera construit par la suite.!! Ils aident les ingénieurs à réfléchir face à des situations inconnues, à évaluer les compromis et à prendre des décisions sans dépendre d’un environnement ou d’une technologie en particulier. Une fondation solide n’impose pas chaque détail d’un système : elle nous offre un repère fiable sur lequel s’appuyer, même si tout ce qui est construit au-dessus évolue.

Tout se résume à l’argent

!!Le premier principe du développement logiciel est : « tout est business, tout est argent ».!! On ne crée pas un logiciel pour lui-même — il existe pour servir des objectifs, générer de la valeur, réduire les coûts ou renforcer la compétitivité. Cela influence chaque choix : quoi développer, quand, à quel point de qualité s’arrêter. Les fonctionnalités génératrices de chiffre d’affaires passent souvent avant le refactoring, les tests ou la maintenabilité long terme — non par négligence, mais sous contrainte de compromis financiers. Les ingénieurs qui comprennent cela cessent de défendre la « propreté du code » en tant que principe, et commencent à en parler comme d’un choix financier — et c’est bien l’argument entendu par le business.

Le développement logiciel est une science humaine

!!Beaucoup pensent que le développement logiciel est une science exacte — en réalité, il est profondément humain.!! Les défaillances logicielles viennent rarement du code seul. Derrière chaque bug, panne ou compromis architectural, il y a une décision humaine : une exigence mal comprise, une responsabilité floue, un compromis précipité, ou un échange qui n’a jamais eu lieu. La technologie avance vite, mais la nature humaine évolue lentement. !!L’ambiguïté, la pression, les incitations, l’ego, la confiance, la motivation et la communication influencent l’architecture autant que les frameworks ou les langages.!!

Related chapter

Design by Humans explores the psychology, biases, and organizational dynamics behind software decisions.

Tom DeMarco et Tim Lister

Peopleware: Productive Projects and Teams (1987).

Des décisions meilleures, pas parfaites

!!Ce livre porte sur l’apprentissage de meilleures décisions logicielles : pas des décisions parfaites, mais des décisions conscientes.!! Des décisions qui équilibrent vitesse et qualité, autonomie et contrôle, simplicité et flexibilité, innovation et stabilité. Le but n’est pas d’éliminer les compromis. Le but est de les comprendre avant qu’ils ne décident à votre place.

Architecture et conception logicielles

L’architecture logicielle, c’est des décisions

!!L’architecture logicielle ne consiste pas à faire des schémas ni à choisir des frameworks. Elle porte sur les décisions à prendre — et surtout sur celles à ne pas prendre trop tôt.!! Chaque choix de structure, de limites, de dépendances et de gestion des échecs s’accumule avec le temps. Une bonne architecture préserve les options : elle laisse des portes ouvertes pour évoluer et ferme les voies qui mènent au chaos. Une mauvaise architecture enferme : elle force chaque nouvelle fonctionnalité à rentrer dans un moule devenu inadapté. Ce qui définit l’architecture, ce n’est pas son état du premier jour, mais ce qu’elle permet de réaliser dans 500 jours.

Related chapter

Design by Principles explores the mindset and practices that guide these decisions, and Design by Structural Principles turns them into concrete structural rules.

Concevoir pour réussir

!!Design for Success consiste à construire un logiciel qui atteint son but de manière fiable — non seulement quand tout se passe comme prévu, mais aussi quand des composants échouent, que les conditions changent ou que survient l’imprévu.!! Cela implique de concevoir deux parcours : le chemin idéal où le système délivre de la valeur, et le chemin de défaillance, où les hypothèses se brisent, les dépendances disparaissent, le trafic explose, les données sont erronées ou les utilisateurs se trompent. Le chemin de défaillance ne s’oppose pas au succès : il le rend possible. Un système n’est véritablement « designé pour réussir » que s’il est aussi conçu pour échouer.

Related chapter

Design for Resiliency covers how systems absorb, contain, and recover from failure.

L’architecture est façonnée par les exigences

!!Les exigences ne sont pas une liste à cocher — elles sont les forces qui sculptent le système. Les exigences fonctionnelles définissent ce que le logiciel doit accomplir ; les non-fonctionnelles disent ce qu’il doit supporter.!! L’architecture constitue la réponse à ces forces. Les mal interpréter, c’est répondre à la mauvaise question, quelle que soit l’élégance de la solution.

Caractéristiques architecturales : les qualités qui définissent un système

!!Au-delà de ce que fait un système, l’architecture détermine comment il le fait. Ces qualités — appelées caractéristiques architecturales — sont les dimensions non-fonctionnelles qui guident chaque décision technique !!: scalabilité, résilience, sécurité, performance, disponibilité, testabilité, visibilité. Améliorer un aspect en dégrade souvent un autre. Un système taillé pour la performance pourra sacrifier la simplicité. Un système pensé pour la sécurité maximale ralentira la livraison. Le rôle de l’architecte n’est pas de tout optimiser — c’est d’identifier les caractéristiques clés dans un contexte donné et d’assumer les compromis associés.

Chapters in this book

Explore the related chapters: Simplicity, Security, Visibility, Resiliency, Scalability, Testability, Availability, and Performance.

On ne peut pas tout avoir

Il est impossible de satisfaire parfaitement toutes les exigences. Beaucoup sont contradictoires — haute performance contre haute sécurité, livraison rapide contre tests approfondis, flexibilité contre simplicité. D’autres demandent un effort énorme pour un gain marginal : passer de 99,9 % à 99,999 % de disponibilité peut coûter 10 fois plus de ressources. !!L’architecture n’est pas l’art de tout optimiser — c’est l’art de choisir ce qui compte le plus dans le contexte donné, d’accepter que certaines choses soient « suffisamment bonnes » et de savoir ce que l’on est prêt à sacrifier.!! La question n’est jamais « peut-on tout avoir ? » La question est : « à quoi sommes-nous prêts à renoncer ? »

Quand chaque partie prenante veut autre chose

Chaque partie prenante optimise pour quelque chose de différent. Les développeurs poussent pour la maintenabilité ; les dirigeants pour le time-to-market ; les architectes pensent à long terme ; le DevOps surveille la fiabilité ; les chefs de projet surveillent les délais. Chacun a raison de là où il se trouve — et chacun est incomplet seul. !!Le rôle de l’architecte n’est pas de prendre parti pour une vue, mais de rendre les compromis visibles pour que le choix soit conscient plutôt qu’accidentel.!!

Styles architecturaux : des patterns éprouvés pour guider l’implémentation

Un style architectural est un pattern éprouvé avec un ensemble connu de compromis. Les microservices achètent la scalabilité et le déploiement indépendant au prix de la complexité opérationnelle. L’architecture en couches achète la simplicité au prix de la rigidité. Les systèmes événementiels achètent la résilience et le découplage au prix d’un débogage pénible. Aucun style n’est neutre — chaque choix est un marché. Le bon n’est pas le plus populaire ; c’est celui dont les forces correspondent à vos exigences critiques et dont vous pouvez vous permettre les coûts.

External Material

Architecture Styles Worksheet by Mark Richards. More resources: Developer to Architect.

L’infrastructure cloud moderne

!!L’infrastructure cloud moderne représente un véritable changement de paradigme dans la façon d’architecturer et de déployer.!! L’Infrastructure as Code considère la configuration comme un artefact versionné. La containerisation et Kubernetes orchestrent les traitements sur des clusters à capacité variable. La sécurité suit le modèle zero-trust avec des accès gérés par identité et un chiffrement systématique. Les plateformes d’observabilité offrent une vision d’ensemble à travers le tracing distribué et des logs unifiés. !!Comprendre le design cloud-native n’est plus une option — c’est le socle des systèmes modernes.!!

Related chapter

Design for the Cloud explores these concepts in depth.

Le coût des changements tardifs

!!Une modification faite lors de la conception coûte une unité d’effort. La même intervention durant le développement vaut dix. Après la mise en production, elle en coûte cent.!! Après plusieurs années d’exploitation, lorsque d’autres systèmes s’y sont appuyés, elle coûte mille — parfois, il faudra réécrire tout le système. Cette courbe exponentielle explique l’importance de l’architecture : les choix du premier jour fixent le prix de tous ceux qui suivront. !!Une bonne architecture n’est pas celle qui règle le problème d’aujourd’hui — c’est celle qui rend le changement futur abordable.!!

Barry Boehm

Software Engineering Economics (1981). Les ratios 1× / 10× / 100× sont une heuristique, pas une loi universelle ; l’idée centrale est que les changements tardifs coûtent généralement plus cher.

Le meilleur code est celui qu’on n’écrit pas

!!Chaque ligne de code est un engagement. Elle doit être lue, comprise, testée, sécurisée, déployée, suivie, déboguée, refactorisée, puis finalement remplacée.!! Le code le moins cher, le plus fiable et le plus sûr est celui qu’on n’écrit pas. Avant d’ajouter une fonction, demandez-vous si la fonctionnalité est vraiment indispensable. Avant d’ajouter une dépendance, vérifiez si la bibliothèque standard suffit. Avant de créer une abstraction, interrogez-vous sur la réalité du problème de duplication. !!Les meilleurs ingénieurs ne sont pas ceux qui écrivent le plus de code — ce sont ceux qui en font le plus avec le moins.!!

Related chapter

Design for Simplicity explains how reducing unnecessary complexity keeps systems easier to build and evolve.

Jeff Atwood

« Le meilleur code n’est pas de code du tout. » — The Best Code is No Code at All (Coding Horror, 2007).

L’ère de l’IA

!!La révolution des LLM change fondamentalement la façon dont nous construisons le logiciel, qui le construit et ce qui est construit.!! Cette section présente le changement qui traverse comme un courant de fond chaque chapitre de ce livre.

L’ingénierie à l’ère de l’IA

!!La question n’est pas de savoir si l’IA va transformer le développement logiciel — c’est déjà fait. La question est de savoir où le jugement humain reste irremplaçable.!! Chaque chapitre de ce livre pose cette sous-question : quelle partie de notre discipline l’IA absorbe-t-elle, et laquelle met-elle au contraire en lumière ? La réponse n’est presque jamais « tout » ni « rien » — apprendre à faire la différence fait désormais partie du métier.

Related chapter

Design by AI confronts this directly — from the end of traditional interfaces to the redefinition of the developer role itself.

Du code à l’intention

Pendant soixante-dix ans, programmer signifiait décrire comment un ordinateur doit résoudre un problème — chaque boucle, chaque condition, chaque variable, écrite à la main. Avec les LLM, l’abstraction se déplace : les ingénieurs décrivent ce qu’ils veulent, et le modèle produit le comment. C’est le changement le plus profond de l’ère de l’IA, plus profond que tout changement de framework auparavant. !!La compétence qui compte n’est plus la maîtrise d’un langage — c’est la capacité d’exprimer précisément une intention, de spécifier clairement des contraintes, de raisonner sur les cas limites que le modèle manquerait.!! Le code devient un artefact, comme l’assembleur compilé : toujours important, mais ce n’est plus là que se fait la réflexion.

L’âge d’or des ingénieurs commence maintenant

L’IA réécrit le rôle : d’écrire chaque ligne de code à façonner l’intention, superviser des agents et orchestrer des systèmes. La transition sera perturbatrice — de grandes entreprises se restructurent, et certains rôles d’ingénierie vont se réduire ou changer à mesure que l’IA absorbe une part croissante du travail. Cela mérite d’être dit franchement. Mais les mêmes forces qui compriment les effectifs libèrent quelque chose de plus grand de l’autre côté. !!À mesure que le coût de construction du logiciel s’effondre, il atteint des secteurs, des marchés et de petites entreprises qu’il n’atteignait pas avant — et chacun d’eux a besoin d’ingénieurs.!! Pour ceux qui s’y engagent et s’adaptent, ce n’est pas le crépuscule de la profession. C’est l’âge d’or, qui ne fait que commencer.

Un code moins cher ne veut pas dire un logiciel moins cher

L’IA rend le code considérablement moins cher à produire. Mais quand tout le monde peut construire plus vite, « plus vite » devient la référence : les concurrents livrent plus, les attentes montent, et les entreprises doivent produire, tester, sécuriser et exploiter beaucoup plus de logiciel. !!Le coût de chaque unité de logiciel baisse, mais la demande de logiciel croît encore plus vite.!! L’IA ne réduira peut-être pas les budgets logiciels — elle peut les déplacer du temps de codage humain vers davantage de logiciel, de calcul, d’agents et de tokens.

Les principes survivent à la technologie

L’IA change qui écrit le code, à quelle vitesse il est écrit et à quoi ressemble la journée du développeur. Elle ne change pas les principes. Keep It Simple reste Keep It Simple — que le code soit tapé par un humain ou généré par un agent. Un système mal conçu ne devient pas scalable parce qu’un LLM l’a produit. Une architecture fragile ne devient pas résiliente parce que le prompt était élégant. Couplage, complexité, frontières de sécurité, blast radius, observabilité, compromis — rien de tout cela n’est atténué par l’IA. Tout est amplifié, car l’IA nous permet de construire plus vite et plus gros, ce qui veut dire que les mauvais principes se cumulent aussi plus vite. !!Les frameworks, les langages, les plateformes et maintenant les modèles continueront de tourner. Les principes de ce livre sont la partie qui ne bouge pas.!!

Le contexte a toujours été essentiel

Le contexte a toujours été tout. Une décision ne vaut que par le contexte qui l’a produite. Les humains décident depuis là où ils se trouvent — budget, équipe, legacy, réglementation, marché — ce qui explique pourquoi le même choix d’architecture peut être brillant dans une startup et imprudent dans une banque. L’IA n’a pas inventé cette vérité ; elle l’a révélée. La sortie d’un LLM est déterminée par le contexte qu’on lui fournit : le prompt, les fichiers, les exemples, les outils et l’historique de conversation. Même mécanisme, autres étiquettes. !!Bien construire un logiciel, avant et après l’IA, c’est la discipline de construire le bon contexte avant de s’engager dans une décision.!!

Le scepticisme : la nouvelle compétence clé en ingénierie

!!À l’ère de l’IA, le scepticisme devient l’une des compétences d’ingénierie les plus essentielles. Quand des agents sont capables de générer du code, de proposer des architectures et de résoudre des problèmes en quelques secondes, le défi n’est plus seulement de produire des solutions, mais de les évaluer.!! Une réponse peut sembler parfaitement convaincante tout en reposant sur des hypothèses déconnectées de la réalité. Une solution efficace dans un contexte donné peut être totalement inadaptée à un autre. Les ingénieurs doivent donc remettre en question les hypothèses, challenger les résultats et vérifier que les solutions proposées correspondent réellement au problème qu’ils cherchent à résoudre.

Source

Adapté d’une présentation d’Ian Varley, Principal Architect chez Salesforce.

Deux visions de l’ingénierie avec l’IA

Les ingénieurs et les entreprises imaginent souvent une finalité différente pour l’IA. Les ingénieurs considèrent l’IA comme un puissant collaborateur : ils restent impliqués, orientent les intentions, valident les décisions, testent les résultats et supervisent les agents. Les entreprises voient la possibilité d’aller plus loin — des agents capables de développer, tester, sécuriser et déployer, coordonnés par d’autres agents, avec une intervention humaine seulement lorsque cela exige un jugement. !!Une vision place l’IA autour de l’ingénieur ; l’autre retire progressivement l’ingénieur du circuit.!! Là où nous finirons dépendra moins des attentes de chaque camp que de ce que les agents autonomes pourront réellement accomplir.

Organisation scalable

!!La façon dont une organisation structure ses équipes et ses domaines est l’une de ses décisions les plus lourdes de conséquences.!! Le but est toujours le même : fonctionner sans friction, passer à l’échelle avec la croissance de l’entreprise, rester efficace à toutes les tailles et évoluer quand le terrain bouge. Ce qui rend la chose difficile, c’est que la réponse ne reste jamais figée. !!La structure des équipes est façonnée par la complexité de la technologie disponible, et par son accessibilité — ce que la plateforme rend possible, ce que l’outillage automatise, ce que l’IA met désormais à portée d’un seul ingénieur.!!

L’organigramme écrit le code

La structure des équipes n’est pas un sujet annexe de la conception logicielle — elle en fait partie. !!La loi de Conway l’énonce clairement : les organisations produisent des systèmes qui reflètent leur propre structure de communication.!! Des équipes cloisonnées produisent des architectures fragmentées. Des équipes qui collaborent en produisent de cohérentes. L’organigramme est donc un artefact architectural, et la façon dont les équipes sont organisées passe à l’échelle — ou échoue à le faire — exactement comme les systèmes qu’elles construisent.

Related chapter

Design by Humans examines how organizational structures and incentives shape software systems.

Melvin Conway

How Do Committees Invent? (Datamation, 1968).

Des silos aux équipes cross-fonctionnelles

Pendant des décennies, beaucoup d’organisations logicielles étaient structurées en silos fonctionnels — QA, développeurs, DevOps, sécurité et architectes chacun dans leur équipe. Le modèle était ordonné sur le papier mais lent en pratique : chaque changement traversait des passages de relais, chaque spécialiste devenait un goulot d’étranglement et la responsabilité se diluait entre les équipes. Le modèle cross-fonctionnel y a répondu directement. Une équipe, toutes les compétences, tout le cycle de vie — de la conception à l’astreinte. Les préoccupations sont traitées en temps réel, au sein de l’équipe, sans attendre des groupes externes. !!Le résultat : moins de goulots d’étranglement, une livraison plus rapide et une vraie responsabilité : you build it, you run it, you maintain it.!!

Du cross-fonctionnel au cross-équipe

Les équipes cross-fonctionnelles ont résolu le problème des silos à l’intérieur d’une équipe — mais pas entre elles. Livrer une fonctionnalité implique encore souvent de modifier un service voisin : une bibliothèque de base, un composant d’infrastructure, une API dont on n’est pas propriétaire. La réponse traditionnelle est de déposer une demande de dépendance entre équipes et d’attendre que l’équipe propriétaire fasse le travail. L’IA brise ce modèle. Un ingénieur peut désormais lire et comprendre un service voisin suffisamment pour faire le changement lui-même, en ouvrant une pull request dans une base de code auparavant inaccessible. Le rôle de l’équipe propriétaire passe de faire le travail à le relire — confirmer que le changement correspond à la vision de son service sans en absorber le coût. !!La responsabilité ne disparaît pas ; elle passe du faire au valider.!!

Les plateformes rendent les organisations scalables

Les équipes cross-fonctionnelles possèdent tout le cycle de vie — mais aucune équipe ne peut reconstruire seule son infrastructure, sa sécurité, son observabilité et son pipeline de livraison. C’est là qu’interviennent les plateformes centrées sur les développeurs. En abstrayant la complexité opérationnelle et en offrant des paved paths, elles permettent aux équipes produit de se concentrer sur le problème métier tout en héritant de fondations de niveau industriel. !!Une organisation scalable ne tient pas seulement à la façon dont les équipes sont découpées — elle tient à ce qui est construit une seule fois, de façon centrale, pour que chaque équipe en profite sans le reconstruire.!!

Related chapter

Design for Developers explores how platforms empower teams and why developer experience is a strategic advantage.

Le processus fait tourner la machine

Au-delà des équipes et des plateformes, ce qui tient une organisation scalable, ce sont ses processus. La façon dont le code est construit, relu, intégré, déployé, surveillé et annulé (rollback). Quand ils sont manuels, chaque étape devient un goulot d’étranglement et l’organisation cesse de passer à l’échelle au moment précis où elle grandit. !!Des processus automatisés et bien conçus font l’inverse : ils rendent le bon geste facile et le mauvais difficile, de façon invisible, à chaque étape du cycle de vie.!! C’est ce qui permet à des équipes indépendantes d’avancer vite sans se gêner mutuellement.

Related chapters

Design by Process, Design to Be Built (CI), and Design to Be Released (CD) cover the practices that make delivery repeatable and safe.

Nicole Forsgren, Jez Humble et Gene Kim

Accelerate: The Science of Lean Software and DevOps (2018).