Quels sont les limites que j'ai expérimenté du DDD ?

Si les entreprises ont commencé à adopter des méthodologies comme Agile, XP ou Scrum, c'était avant tout pour résoudre un problème fondamental : réussir à parler la même langue que les développeurs.

Aligner une vision business avec les contraintes techniques est loin d’être trivial.

Ce que le métier perçoit comme “un simple bouton sur une page” peut masquer une chaîne de traitements complexes côté backend.

Prenons un exemple : le bouton “Générer PDF”.

Côté métier, il suffit de cliquer.

Côté technique, il faut :

• récupérer les données
• déclencher un worker pour générer le fichier
• et enfin, streamer le contenu au navigateur

Oublier toute cette mécanique revient à dire : “pour faire décoller un avion, on monte à bord et on vole.”

La réalité, c’est une suite d’étapes critiques et ordonnées.

C’est pour combler cet écart de perception qu’est né le Domain-Driven Design (DDD) : une tentative ambitieuse pour créer un langage commun entre experts métier et développeurs.

Mais entre l’intention et la réalité, il y a un monde et c’est précisément ce fossé que cet article va explorer.

Dans la jungle des méthodologies de productivité en entreprise, le Domain-Driven Design (DDD) se distingue par une promesse forte : permettre à une organisation tech de scaler humainement.

L'Enterprise Architecture (EA) est au management ce que le Domain-Driven Design (DDD) est au code : une tentative de cartographier, structurer et aligner les ressources de l'entreprise (humaines, techniques, organisationnelles) avec ses objectifs stratégiques.

L'EA vise à créer un langage commun entre les métiers, les équipes tech, la direction, et les opérations, pour assurer que toutes les initiatives locales servent une vision d'ensemble.

En pratique, cela se traduit par :

• Définir des domaines fonctionnels (Finance, RH, Supply Chain…)
• Spécifier les systèmes d'information qui les supportent
• Organiser les flux de données, les responsabilités, et les relations d'interdépendance
• Proposer une vision cible et orchestrer les transformations pour l'atteindre

L'Enterprise Architecture devient essentielle quand la complexité d'une organisation dépasse un seuil où l'absence de coordination ralentit plus qu'elle accélère.

Tout comme un projet technique mal pensé peut imploser sans DDD, une entreprise mal alignée peut s’effondrer sans architecture d'ensemble.

En décomposant le système en "domaines", on peut constituer des feature teams autonomes.

Chaque équipe gère son périmètre, avance à son rythme, et théoriquement, toute la boîte accélère, parce que tous les domaines progressent en parallèle.

Je ne vais même pas m’attarder sur la guerre d’ownership que ce découpage rend plus acceptable : chacun a son "domaine", son périmètre, ses responsabilités.

Cela facilite l’émergence de multiples rôles managériaux, Feature Leads, Engineering Managers, Staffs, etc. tout en gardant l’illusion d’un projet cohérent.

Et c’est vrai : faire grandir une équipe sur une codebase unique, sans la diviser, devient très vite ingérable.

Le DDD apporte une solution logique : on découpe, on isole, on assigne.

Mais avez-vous déjà essayé de livrer une feature transverse dans une organisation structurée en domaines bien segmentés ?

Prenons un exemple banal : vendre un produit.

Pour cette "simple" action, il faut :

• Fabriquer le produit (supply chain, production)
• Le mettre en vente (catalogue, e-commerce)
• Générer une facture (facturation)
• Intégrer le paiement en comptabilité (finance)
• Mettre à jour le stock (inventaire)

Sur combien de domaines ce flux s’étale-t-il ?

Et combien de codebases, de pull requests, de reviews, de comités de validation métier faut-il traverser pour livrer une seule fonctionnalité ?

C’est là que le DDD montre sa limite :

Il segmente le système pour mieux le gouverner, mais il multiplie les frictions dès que la réalité dépasse le cadre d’un domaine.

Quand le DDD devient contre-productif

Ce qu’on oublie souvent de dire à propos du Domain-Driven Design, c’est la complexité croissante qu’il génère à mesure qu’on l’industrialise, notamment via une architecture orientée microservices et des équipes toujours plus nombreuses.

Un rappel essentiel : la loi de Brooks

Dans The Mythical Man-Month (1975), Fred Brooks énonce un principe toujours d’actualité :

"Ajouter des personnes à un projet en retard le retarde davantage."

Pourquoi ? Parce que la communication devient un goulet d’étranglement.

Et si l’on y réfléchit bien, le code lui-même est un vecteur de communication.

Multiplier les mains qui écrivent du code, c’est aussi multiplier les styles, les dépendances, les interfaces — bref, les sources de malentendus.

La productivité décroissante des grandes équipes

Une étude menée par Quantitative Software Management (QSM) sur plus de 4000 projets applicatifs montre que :

Les équipes de 3 à 7 personnes sont significativement plus productives que des équipes plus grandes.

Pourquoi ? Moins de friction, plus de focus, meilleure vélocité par individu.

Ce constat est d’ailleurs en phase avec les recommandations historiques de l’agilité : des équipes de 5 à 9 personnes pour rester efficaces, adaptables et autonomes.

Le piège de la scalabilité humaine par le DDD

Et pourtant, que fait-on souvent lorsqu’on applique le DDD à grande échelle ?

On multiplie les domaines fonctionnels, on crée des feature teams dédiées, on staff. Beaucoup.

Le modèle encourage un travail en parallèle sur des périmètres métiers bien segmentés, ce qui paraît séduisant en théorie. Mais dans les faits, cela conduit souvent à faire grossir artificiellement les effectifs pour maintenir chaque "brique" du système.

Résultat : on aboutit à des organisations qui s’éparpillent, où le moindre projet transverse devient une coordination infernale.

Faut-il vraiment réduire les effectifs pour gagner en efficacité ?

Pas nécessairement.

À condition de réussir à faire travailler les équipes autrement, par silo, ou mieux encore : par projet indépendant.

Le modèle de scalabilité horizontale

Pour moi, une entreprise qui scale efficacement ne le fait pas en empilant des couches sur un seul produit.

Elle le fait horizontalement, en développant plusieurs produits ou initiatives en parallèle, de façon agnostique.

Or, aujourd’hui, le découpage par domaines, tel qu’imposé par le DDD ou les architectures microservices, engendre une interdépendance systémique.

Un changement dans un domaine A peut nécessiter une coordination avec les domaines B, C, D… Résultat : la productivité chute au lieu d’augmenter.

Beaucoup de sociétés l’ont compris et reviennent au monorepo, voire au monolithe.

Parallèlement, elles réduisent leurs effectifs et se concentrent sur un noyau dur capable de maintenir le système.

❌ Le réflexe : réduire pour rentabiliser

Imaginez : vous avez un produit sur le marché, 50 développeurs, un équilibre financier, voire une rentabilité.

Mais vous êtes en situation concurrentielle, vous devez optimiser.

Le choix courant ?

Couper les effectifs et réduire les coûts fixes.

Livrer le même produit, avec moitié moins de monde, c’est le choix le plus simple et le plus immédiat.

Mais est-ce le meilleur ?

✅ L’alternative : diversifier plutôt que couper

Et si, au lieu de réduire, vous utilisiez l'autre moitié de vos effectifs pour lancer un deuxième produit ?

• Un nouveau marché
• Une nouvelle verticale
• Une opportunité.

Dans certains cas, le potentiel de création de valeur dépasse largement les économies générées par un PSE.

Exactement comme en bourse, où l’on recommande de diversifier son portefeuille, une entreprise ne devrait pas concentrer tous ses efforts sur un seul produit.

Elle devrait se rendre antifragile face au marché en diversifiant son offre.

Sony : un échec, plusieurs succès

Prenons un exemple concret : Sony.

On oublie souvent que Sony a échoué à percer dans le monde des smartphones, malgré ses efforts avec les Xperia.

Mais cet échec n’a jamais mis l’entreprise en danger.

Pourquoi ?

Parce que Sony, c’est aussi :

• Une des plus grosses branches jeux vidéo au monde avec la PlayStation
• Un acteur majeur dans la musique (Sony Music)
• Une entreprise qui vend toujours des téléviseurs haut de gamme
• Un producteur de films et de séries à succès (Sony Pictures)

Rien de tout cela n’est directement lié.

Les équipes ne partagent pas le même codebase, ni la même roadmap produit.

Et pourtant, elles évoluent sous le même toit.

Sony réussit parce que chaque division a sa propre autonomie, ses propres objectifs, et surtout: une vraie indépendance stratégique.

Et pourtant, dans les couloirs d’un même campus, des gens de l’équipe PlayStation peuvent croiser ceux de Sony Music ou de Sony Pictures.

Pas besoin de tout imbriquer pour créer de la valeur. Pas besoin non plus de fusionner les roadmaps ou les pipelines CI/CD.

L’entreprise est diversifiée.

Elle apprend de ses échecs, valorise ses réussites, et surtout : elle ne mise pas tout sur un seul produit.

Le problème français : imiter sans transformer

Difficile de ne pas observer notre positionnement à l’échelle internationale.

En France, nos plus grandes entreprises sont souvent celles qui réussissent grâce à leur propre tradition, leurs propres codes, leur propre modèle.

• LVMH est un leader mondial car il suit ses règles, dans le respect d’un artisanat et d’un savoir-faire séculaire
• Total domine l’industrie pétrolière parce qu’il respecte les logiques industrielles du secteur, sans chercher à réinventer son fonctionnement tous les trois ans

Mais dès qu’il s’agit de jouer à armes égales avec des concurrents internationaux dans un environnement technologique mouvant… on peine.

Quelle entreprise française peut aujourd’hui prétendre battre sur son propre terrain une entreprise américaine ou asiatique dans la tech, le software ou l’innovation produit ?

On en voit peu. Très peu.

Le piège du mimétisme méthodologique

À mon sens, l’un des problèmes vient de notre mauvaise exécution des méthodologies importées, adoptées souvent par mimétisme, et rarement par alignement stratégique.

Nous voyons un compétiteur gagner avec un modèle (Agile, DDD, SAFe...), alors on tente de l’appliquer tel quel, en espérant les mêmes résultats.

Mais on oublie que ce compétiteur a souvent inventé le modèle ou l’a façonné sur mesure à son organisation.

Appliquer ces modèles sans se transformer structurellement, c’est comme mettre de l’essence dans un moteur diesel : ce n’est pas une question de carburant, c’est une question d’architecture.

Adapter plutôt qu’imiter

Le DDD n’échappe pas à cette logique.

Il est arrivé chez nous comme une réponse magique aux problèmes de scalabilité, alors qu’il s’agit d’abord d’un cadre conceptuel pour mieux communiquer entre métier et technique.

Ce n’est pas une solution toute faite, ni une recette reproductible à l’identique.

Et surtout : ce n’est pas toujours la bonne réponse, selon la taille, la culture et le niveau de maturité d’une entreprise.

Ce que je crois profondément, c’est que chaque société devrait :

• Prendre le temps de choisir une méthode adaptée à son contexte réel
• Ne pas se figer dans un modèle rigide
• Et surtout : avoir la lucidité de revenir en arrière ou pivoter, si le modèle ne fonctionne plus

Car pendant que certains appliquent des recettes venues d’ailleurs, les véritables leaders, eux, les inventent ou ré-inventent en adaptant le modèle.