Le tour ne dit pas au mécanicien où placer l’arbre. L’oscilloscope ne dit pas à l’ingénieur électricien par où acheminer le signal. La grue ne dit pas à l’ingénieur civil où mettre les murs. Toute discipline d’ingénierie mature l’a compris tôt et n’y est jamais revenue : le problème physique pilote la conception. Les outils sont des moyens, pas des fins.

Le logiciel a été l’exception — et pendant un temps remarquablement long.

I. Le détour de quarante ans

Durant les quatre premières décennies du logiciel commercial, c’est la technologie qui guidait la conception. Pas le problème. « On développe en Java, donc on aura des classes, des interfaces, des fabriques, des managers. » « On fait des microservices, donc l’organisation suit la topologie des services. » « On utilise une base relationnelle, donc le modèle de domaine suit le schéma. » Le marteau déterminait la forme de la maison.

Le livre Domain-Driven Design d’Eric Evans, publié en 2003, n’est essentiellement que le rattrapage du génie logiciel sur ce que les ingénieurs mécaniciens savaient avant la Révolution industrielle. Le domaine est le moteur. La technologie est le moyen. On construit un langage omniprésent autour du problème métier, pas autour de l’ORM. On définit des contextes délimités autour de ce que l’entreprise requiert, pas autour de ce qui est techniquement commode à déployer. On conçoit des agrégats autour des invariants métier, pas autour des règles de normalisation de la base de données.

Un ingénieur en mécanique qui ouvrirait le livre d’Evans le trouverait déconcertant — pas difficile, mais déconcertant. Bien sûr que le problème physique pilote la conception. Qu’est-ce qui d’autre le piloterait ? Mais les ingénieurs logiciels ont passé quarante ans à laisser l’inverse se produire, et DDD a été le correctif qu’il a fallu mettre par écrit, formaliser, débattre en conférences, transformer en 560 pages, parce que le domaine avait genuinement perdu le fil.

II. Pourquoi le logiciel a perdu le fil

Trois raisons structurelles, aucune accidentelle.

La première est le problème de la malléabilité. Le logiciel n’a pas de physique. On peut refactoriser, réécrire, restructurer à volonté. Le métal se fatigue. Les ponts s’effondrent. Le code continue simplement à tourner jusqu’à ce qu’on le supprime. Sans contraintes physiques pour imposer la correction, les contraintes semblent artificielles — négociables — et elles sont négociées au profit de ce que l’outil ou le paradigme actuel rend facile. La commodité remplit le vide que la physique a laissé.

La deuxième est le problème de la visibilité. En logiciel, les outils sont faits du même matériau que ce qu’on construit. Le code qui implémente un patron fabrique est indiscernable, en substance, du code qui implémente la logique métier. Il n’y a pas de ligne évidente entre le marteau et le clou. Quand l’échafaudage et le bâtiment se ressemblent, il est facile d’oublier lequel est lequel.

La troisième est le problème de la jeunesse. Le génie mécanique a des milliers d’années. Le génie civil remonte à Rome et au-delà. Le génie électrique a environ 150 ans. Le logiciel en a 80. Les disciplines accumulent lentement des leçons dures — à travers des échecs, des litiges, des structures effondrées, des villes incendiées — puis les codifient en normes, exigences de certification, règles professionnelles. Le logiciel accumule encore les leçons de son premier siècle.

III. La question inconfortable

Evans a publié son diagnostic en 2003. Nous sommes en 2026 et le débat n’est pas clos.

Les architectures de microservices sont encore conçues autour de la commodité du déploiement — ce que Kubernetes rend facile à faire tourner — plutôt qu’autour des frontières du domaine. Les intégrations LLM se construisent autour de la surface d’API du modèle, de ses limites de tokens, de son interface d’outils, plutôt qu’autour du problème métier que le modèle est censé résoudre. Le schéma n’a pas changé ; seulement la technologie.

Si DDD était déjà évident en 2003, pourquoi chaque nouvelle technologie remet-elle les compteurs à zéro ? Pourquoi chaque génération d’ingénieurs commet-elle la même erreur avec de nouveaux outils ?

La réponse la plus honnête est que le biais vers l’outil n’est pas une erreur corrigible. C’est une caractéristique structurelle de la façon dont le logiciel se construit. La nouvelle technologie arrive avec sa propre API, son propre modèle mental, sa propre communauté d’adopteurs précoces enthousiastes qui ont construit leur identité autour d’elle. Apprendre l’outil est rapide. Apprendre le domaine est lent, coûteux et peu glamour. Les incitations pointent toutes dans la même direction : comprendre la technologie, approximer le domaine.

IV. Diagnostic sans remède

Evans n’a pas résolu le problème. Il l’a nommé. DDD n’a jamais été une méthodologie qui, une fois adoptée, corrigerait la dérive sous-jacente. C’était un rappel — un argument de 560 pages selon lequel le domaine est réel et l’outil ne l’est pas — écrit parce que ce rappel devait exister.

En France, l’ingénieur diplômé des grandes écoles — Polytechnique, Centrale, les Arts et Métiers — porte un titre qui engage sa responsabilité. L’ordre des ingénieurs n’est peut-être pas aussi contraignant qu’un barreau, mais la structure d’imputabilité existe : formations, certifications, responsabilité civile professionnelle pour certaines spécialités. Le logiciel n’a pas d’équivalent. On se déclare architecte logiciel et on conçoit le système autour de la technologie qui enthousiasme cette année. Pas d’ordre professionnel, pas de responsabilité civile, pas de pont effondré pour rendre l’erreur lisible.

C’est peut-être la leçon la plus profonde. DDD a raison sur ce qui devrait guider la conception. Mais devrait fait beaucoup de travail dans un domaine qui a systématiquement évité les structures d’imputabilité qui lui donneraient un sens.

Le domaine finit toujours par se réaffirmer — à travers les coûts de maintenance, les migrations ratées, les systèmes si enchevêtrés dans leurs propres idiomes techniques que personne ne peut expliquer ce qu’ils font réellement. C’est la physique que le logiciel possède quand même : non pas des contraintes matérielles, mais le coût composé de la dette technique. Ça ne tue personne. Ça rend juste tout plus difficile, plus lentement, jusqu’à ce que le projet soit réécrit.

Et la réécriture commence toujours par la même conversation : quel problème résolvons-nous vraiment ?

Pour aller plus loin