On modernise les technologies, on refond les applications, on parle de transformation. Et pourtant, après quelques années seulement, le système finit souvent par redevenir un legacy.

1. Introduction

On parle beaucoup de transformation du SI : modernisation, migration vers le cloud, microservices, nouveaux frameworks, refonte front. Les mots changent, les promesses restent les mêmes… et bien souvent, les résultats aussi.

Dans mon parcours, je ne prétends pas avoir tout vu, loin de là. Mais, mission après mission, j’ai eu l’étrange impression d’assister au même film : un système jugé “trop vieux” ou “trop endetté”, un grand chantier de refonte technique, et, quelques années plus tard… un nouveau legacy, à peine plus moderne que le précédent.

Je ne dis pas que c’est partout pareil. Mais, dans tous les contextes où j’ai été confronté à ce type de refonte — des environnements multi-équipes, avec des systèmes critiques et fortement interdépendants —, c’est ce schéma que j’ai observé. Et avec le recul, je me rends compte que ces situations avaient beaucoup de points communs. On changeait les technologies, parfois l’architecture apparente, et l’on réorganisait les équipes. Mais ces changements restaient le plus souvent "superficiels" : ils ne remettaient pas en cause le découpage métier, les responsabilités portées par les équipes, ni la manière de penser le système et la création de valeur.

Au fil de ces expériences, j’ai aussi trouvé de nombreux échos dans la littérature : dans ce que j’appelle le “vrai Agile”, celui qui parle depuis plus de vingt ans d’alignement, de collaboration et de responsabilité bien plus que de rituels ; dans le Domain-Driven Design, avec son approche holistique — tactique et stratégique — fondée sur un alignement conceptuel fort ; dans Accelerate et son focus sur l’autonomie des équipes et le flux de livraison ; et enfin dans Team Topologies et sa lecture socio-technique des organisations. Ces lectures n’ont pas créé ces constats ; elles les ont surtout formulés, structurés et corroborés avec d’autres mots.

Parmi elles, un court extrait de Team Topologies m’a particulièrement marqué :

« Lorsque nous voulons passer d’un système logiciel monolithique à des services plus faiblement couplés, nous devons aussi considérer l’impact que la nouvelle architecture aura sur les équipes impliquées. Nous devons prendre en compte leur capacité cognitive, leur localisation et leur intérêt pour les nouveaux services.

Sans considérer l’angle des équipes, nous risquons de découper le monolithe aux mauvais endroits, voire de créer un système complexe de services indépendants.

C’est ce qu’on appelle un monolithe distribué, et cela se traduit par des équipes qui manquent d’autonomie sur leurs services, car presque chaque évolution nécessite des mises à jour dans d’autres services. »

Manuel Pais & Matthew Skelton, Team Topologies

Ce paragraphe est court. Mais il est d’une densité impressionnante. En quelques lignes, il parle à la fois d’architecture, d’équipes, de découpage, d’autonomie et d’échec possible des transformations.

Dans cet article, je propose de prendre cet extrait comme fil conducteur, et de le confronter à ce que j’ai pu observer sur le terrain. Non pas pour en faire une analyse académique, mais comme un retour d’expérience : une tentative de comprendre pourquoi tant de refontes, pourtant bien intentionnées, finissent par reproduire les mêmes problèmes… sous des formes plus modernes.

2. Préambule : pourquoi refondre un système ?

« On ne refond pas un système pour le rendre plus beau, plus moderne ou plus propre. On le refond quand sa structure, sa technologie ou son organisation empêchent de délivrer efficacement la valeur attendue par les utilisateurs. »

Moi 😝

Le but premier d’un système logiciel n’est pas d’être élégant, ni même d’être “moderne”. Il est de répondre à des besoins concrets, et surtout de pouvoir évoluer en permanence pour accompagner à la fois la compréhension du domaine et l’évolution des attentes des utilisateurs. Comme tout système de type E au sens de Lehman, un SI est un système vivant : s’il n’évolue pas, il se dégrade.

Dans cette perspective, l’architecture et la structure ne sont pas des éléments figés. Elles sont là pour soutenir cette évolution, pour rendre le changement possible, soutenable et peu coûteux dans la durée. Tant que le système permet d’absorber les demandes, d’apprendre du métier et d’adapter le logiciel en conséquence, même avec une stack vieillissante ou une structure imparfaite, il remplit encore son rôle.

Une refonte, au sens fort du terme, ne s’impose donc pas dès que le système montre des signes de vieillissement. Un système vivant et adaptatif peut très bien intégrer des évolutions technologiques de manière progressive : remplacer une brique devenue obsolète, faire évoluer un framework, moderniser une partie de l’infrastructure, sans tout remettre à plat. Tant que l’architecture, le code et l’organisation permettent ce type d’évolution incrémentale, il n’y a pas de raison de parler de refonte globale.

La refonte devient nécessaire lorsque cette capacité d’évolution elle-même est perdue. Quand le système est devenu si couplé, si opaque, si peu maîtrisé que chaque changement est un pari risqué ; quand la compréhension du domaine est éclatée ou figée dans le code ; quand les équipes passent plus de temps à contourner le système qu’à le faire évoluer. À ce stade, il ne s’agit plus seulement de moderniser, mais de reprendre le contrôle sur un système qui a dérivé au fil des années.

3. Monolithes : le problème ?

La première phrase de l’extrait de Team Topologies parle de passer d’un système monolithique à des services plus faiblement couplés. Lue trop vite, elle peut donner l’impression que le problème serait le monolithe en lui-même, et que la solution consisterait à le découper en une constellation de services. C’est un réflexe que j’ai souvent vu sur le terrain : découper, distribuer, multiplier les briques, comme si la simple fragmentation du système allait, par nature, résoudre ses problèmes.

Pourtant, “exploser” un monolithe n’est pas une fin en soi. On peut très bien faire évoluer un monolithe vers un monolithe modulaire, avec des frontières claires, un couplage maîtrisé et une forte cohésion interne. À l’inverse, on peut obtenir, avec des microservices, un système extrêmement couplé, difficile à faire évoluer, et coûteux à opérer. Autrement dit : le problème n’est pas le monolithe, pas plus que la solution n’est le microservice.

Les travaux de Team Topologies le rappellent d’ailleurs indirectement lorsqu’ils décrivent différentes formes de “monolithes” : monolithe de build, de release, de base de données, de modèle, voire de pensée. On peut avoir un système distribué du point de vue du code, tout en restant monolithique dans la manière de construire, de livrer, de penser et d’organiser le travail. Le monolithe n’est donc pas qu’une forme technique ; c’est avant tout une forme de couplage.

Relire cette phrase comme une opposition “monolithe vs microservices” est donc un piège. Ce dont il est réellement question ici, c’est du découplage : comment réduire les dépendances, comment permettre des évolutions locales, comment éviter que tout changement ne se propage partout. Et ce découplage peut s’obtenir de plusieurs manières techniques, y compris au sein d’un monolithe bien structuré.

Mais surtout, ce découplage n’est pas d’abord un problème de langage, de framework, de middleware ou de choix d’infrastructure. Ce n’est pas Kafka, REST, gRPC, ni même l’IA ou le dernier outil à la mode, qui vont, par eux-mêmes, créer des frontières pertinentes.

Et ce n’est pas non plus un découpage “fonctionnel” au sens classique — regrouper ce qui se ressemble techniquement ou factoriser des fonctions communes — qui, dans mon expérience, est l’une des erreurs les plus fréquentes et les plus coûteuses.

Le découplage dont on parle ici est avant tout un problème de modélisation. Il s’agit de découper le système selon un modèle du domaine qui serve réellement les use cases, qui aligne le logiciel sur la compréhension métier, et qui fasse émerger des responsabilités claires. Un découpage basé sur ce qui doit évoluer ensemble, sur ce qui porte une valeur métier cohérente, et non sur ce qui se ressemble techniquement ou fonctionnellement.

Une fois ce modèle posé, alors seulement, la technique entre en jeu : monolithe modulaire, services, bases séparées ou partagées, protocoles, outils. La forme technique doit venir au service du modèle, pas l’inverse. Quand on commence par la technologie pour espérer faire émerger un bon découplage, on prend le problème à l’envers — et on se prépare souvent à construire un monolithe distribué de plus.

4. De quoi parle-t-on quand on parle de système ?

Avant de parler des impacts sur les équipes, il faut clarifier de quoi on parle quand on parle de “système”. Car ces impacts n’ont de sens que si l’on comprend ce qu’il est vraiment.

Il ne s’agit pas seulement du logiciel, ni même de l’infrastructure qui l’héberge. Le Système — que j’écris ici avec un grand S — est l’ensemble formé par le code, les architectures, les outils, les pipelines, mais aussi par l’organisation des équipes, leurs interactions, leurs responsabilités, leurs modes de décision, et la relation qu’elles entretiennent avec les utilisateurs et le métier. Autrement dit, nous sommes face à un système socio-technique.

Au sens des lois de Lehman, comme j'en ai déjà parlé, il s’agit d’un système de type E (E-type system) : un système intimement lié à son environnement réel. Il doit évoluer en permanence pour rester utile, parce que le métier, les usages et les attentes des utilisateurs évoluent eux aussi. Le logiciel et son contexte humain forment un tout indissociable.

Mais pour pouvoir évoluer dans cet environnement, encore faut-il une architecture capable d’absorber le changement. Et c’est là qu’intervient la loi de Conway : la structure du système reflète inévitablement la structure de l’organisation qui le conçoit. Autrement dit, l’architecture n’est pas seulement un choix technique ; c’est aussi le miroir de la manière dont les équipes sont organisées et coopèrent.

Lehman nous rappelle que le logiciel est façonné par le monde humain qu’il sert.
Conway nous rappelle qu’il est façonné par l’organisation humaine qui le construit.

Pris ensemble, ils décrivent un système profondément holistique, où utilisateurs, métier, architecture, code et organisation sont étroitement liés. On ne peut pas en maîtriser une partie sans se soucier des autres.

Parler de maîtrise du Système, ce n’est donc pas seulement parler de qualité du code ou de robustesse de l’infrastructure. C’est parler de la capacité collective à comprendre et piloter cet ensemble : le produit, ses usages, son modèle, son architecture, et la manière dont les équipes coopèrent pour le faire évoluer.

5. Considérer l’impact sur les équipes

« …nous devons aussi considérer l’impact que la nouvelle architecture aura sur les équipes impliquées. Nous devons prendre en compte leur capacité cognitive, leur localisation et leur intérêt pour les nouveaux services. »

Manuel Pais & Matthew Skelton, Team Topologies

Nous venons de voir que l’architecture est intrinsèquement liée à l’organisation humaine. Dans ce cadre, Team Topologies nous invite ici à regarder trois dimensions très concrètes : la capacité cognitive des équipes, leur localisation, et leur intérêt pour les services qu’elles vont porter. Trois angles simples en apparence, mais que j’ai vus trop souvent ignorés dans des refontes menées avant tout par la technique.

5.1. Capacité cognitive

La capacité cognitive, c’est la quantité de complexité qu’une équipe peut comprendre, garder en tête et maîtriser au quotidien : concepts métier, règles, services, flux, outils, incidents, déploiements, interactions, dépendances entre équipes, responsabilités, circuits de décision, processus, priorités, relations avec les utilisateurs… Tout cela forme une charge permanente, que l’équipe doit porter pour simplement faire fonctionner le système.

Et ce n’est pas une question de talent ou de séniorité. Une équipe n’est pas un ensemble homogène, ni une simple addition de compétences individuelles. Elle réunit des profils différents, avec des expériences, des forces et des sensibilités variées, qui se complètent et s’enrichissent mutuellement. C’est précisément cette diversité qui permet à une équipe de progresser, de prendre du recul, et de mieux appréhender la complexité.

Mais même ainsi, une équipe reste un collectif humain. Sa capacité à comprendre, à se représenter et à maîtriser un système est finie. C’est une limite normale, structurelle, qu’aucune accumulation d’expertise ne fait disparaître. La capacité cognitive n’est pas un défaut à corriger : c’est une contrainte à respecter si l’on veut rester efficace et soutenable dans le temps.

5.1.1. Ignorer la contrainte : la surcharge structurelle

Sur le terrain, j’ai souvent vu des refontes produire plus de services, plus de pipelines, plus de configurations, plus d’interactions, sans jamais se demander si une équipe pouvait réellement absorber cette complexité supplémentaire.

Cette question de la charge cognitive est, tout simplement, presque jamais posée. Quand on confie un nouveau périmètre, un nouveau service ou une nouvelle brique à une équipe, on ne se demande pas réellement si la charge est soutenable. On part implicitement du principe que l’équipe saura s’adapter.

Dans ce type de contexte, les équipes se voient confier la responsabilité opérationnelle, mais sans réelle prise sur les choix structurants. La complexité est alors “absorbée” localement, faute d’être pilotée au niveau du Système.

Parfois, les équipes sentent bien que ça ne passera pas. Elles expriment des doutes, des alertes, des limites. Mais ces signaux sont rarement entendus. On leur répond qu’il n’y a pas le budget, pas le temps, pas d’alternative. Qu’“il faut faire avec”.

C’est une forme de déresponsabilisation systémique : on ne pilote plus la soutenabilité du Système, on demande aux équipes d’en porter seules le poids.

5.1.2. Quand la complexité se déplace vers les humains

Lorsque la capacité cognitive est dépassée, la complexité ne disparaît pas. Elle se déplace vers les équipes. Le résultat est prévisible : elles passent plus de temps à comprendre le Système qu’à le faire évoluer. La maîtrise diminue, la charge mentale augmente, et la capacité de delivery se dégrade.

Concrètement, cela se traduit par des périmètres flous, traversés de dépendances. Certaines équipes deviennent structurellement surchargées, parce que trop d’autres équipes — ou trop d’utilisateurs — dépendent d’elles. D’autres se retrouvent bloquées en permanence, contraintes d’attendre des évolutions qu’elles ne maîtrisent pas.

Très souvent, pour répondre malgré tout à un besoin utilisateur, les équipes finissent par développer “chez elles” des fonctionnalités qui devraient appartenir à d’autres. Non pas par choix, mais parce que l’équipe légitime n’a pas le temps, pas le budget, ou pas la capacité politique de s’en occuper. On contourne, on duplique, on bricole des intégrations. Le système s’étend au mauvais endroit.

Avancer ne consiste alors plus seulement à écrire du code. Il faut d’abord identifier les bons interlocuteurs — quand on sait qu’ils existent —, comprendre qui est responsable de quoi, négocier des priorités. Avancer devient un travail de cartographie sociale autant que technique.

Les personnes clés sont saturées, deviennent des goulots d’étranglement, et, sous la pression, cherchent avant tout à se protéger : les validations se multiplient, les comités apparaissent, les processus se durcissent et se complexifient. Autant de couches censées sécuriser, mais qui ralentissent surtout le delivery sans améliorer réellement ce qui est délivré.

Faute d’être maîtrisée dans le modèle et le découpage, la complexité se reporte sur les interactions humaines et les mécanismes organisationnels. Le système devient alors aussi difficile à comprendre socialement que techniquement.

5.1.3. Autonomie des équipes

Dans ce type de contexte naissent des injonctions contradictoires côté management : on demande aux équipes d’être autonomes, mais on multiplie les dépendances et les validations ; on exige de livrer vite, tout en interdisant de toucher aux zones risquées ; on prône la responsabilisation, mais on ne donne pas la maîtrise du flux de bout en bout.

Comment, en effet, parler d’autonomie lorsqu’il est :

  • impossible de livrer sans une équipe de production,
  • impossible de tester sans une équipe QA dédiée,
  • impossible de suivre sans une équipe de maintien en conditions opérationnelles,
  • impossible de supporter sans une équipe de support,
  • impossible de spécifier sans une équipe d’analystes métier ?

Il ne s’agit pas ici de nier l’utilité de ces rôles, ni les contraintes de certains environnements régulés. Il s’agit de pointer une structure où une équipe ne peut jamais porter une évolution de bout en bout sans dépendre systématiquement d’autres périmètres. Dans un tel cadre, l’autonomie devient un mot, pas une réalité.

Et lorsque ça coince, la faute retombe souvent sur “les développeurs”, jugés trop lents, trop prudents, pas assez engagés.

C'est également sans compter parfois sur l'autonomy-washing, le fait d’afficher l’autonomie dans le discours tout en conservant des dépendances et des contrôles qui la rendent impraticable au quotidien.

5.1.4. Effets sur le code et désalignement conceptuel

Petit à petit, les développeurs font le minimum de changements possibles pour éviter de casser ce qu’ils ne comprennent plus vraiment. On n’ose plus refactorer, on contourne, on empile. Le code se désaligne progressivement du métier.

Ce désalignement conceptuel s’installe souvent sans bruit. Et à terme, la qualité se dégrade. Avec elle, la motivation. Le sentiment de faire “au mieux dans un système qui ne peut pas vraiment marcher” remplace peu à peu l’envie de bien faire.

5.1.5. Normaliser la coordination plutôt que réduire la complexité

Lorsque ces dépendances deviennent ingérables, les organisations mettent en place des mécanismes de coordination à grande échelle : synchronisations, comités, gouvernance, plannings croisés, circuits de validation.

Ce n’est pas forcément un choix idéologique. C’est souvent une réponse pragmatique à une structure qui ne permet pas des évolutions locales. Puisqu’on ne sait pas réduire la complexité structurelle, on organise la coordination.

La charge cognitive augmente encore, absorbée par des couches de processus qui masquent le problème sans le résoudre. On n’apprend plus vraiment à simplifier le système. On apprend surtout aux humains à vivre avec.

5.2. Localisation

La localisation est souvent abordée sous l’angle du télétravail : présentiel ou distanciel, même site ou équipes distribuées, mêmes horaires ou fuseaux différents. Mais dans un système socio-technique, la localisation ne se réduit pas à une distance géographique. Elle recouvre aussi des distances culturelles, organisationnelles et métier : équipes internes et prestataires, IT et métiers, centres de services et équipes “cœur”, proximité ou éloignement des utilisateurs réels.

Deux équipes peuvent partager le même open space et pourtant être très éloignées dans leur compréhension du système. À l’inverse, des équipes distribuées peuvent parfois être plus proches dans le sens qu’elles donnent à ce qu’elles construisent. La vraie question n’est donc pas “où sont les équipes ?”, mais à quel point il est coûteux pour elles de construire et de maintenir une compréhension commune du système.

Dans ce cadre, la localisation agit comme un révélateur. Plus un découpage impose des échanges fréquents, fins et informels entre équipes pour simplement avancer, plus la distance devient coûteuse. Quand l’architecture et le modèle sont bien alignés, avec des responsabilités claires et des interfaces explicites, la distance se gère. Quand ils ne le sont pas, la localisation amplifie brutalement les frictions.

Sur le terrain, j’ai vu des systèmes où des équipes éloignées géographiquement étaient pourtant structurellement interdépendantes : impossible de livrer sans synchroniser plusieurs sites, impossible de faire évoluer un service sans coordination quotidienne avec une autre équipe à l’autre bout du pays ou du monde. Chaque décision nécessite un appel, chaque clarification un ticket, chaque malentendu une réunion de plus. La distance transforme la moindre ambiguïté en coût opérationnel.

Comme pour la capacité cognitive, lorsque la complexité n’est pas maîtrisée dans le découpage, elle se reporte sur les humains. Ici, elle se traduit par une inflation de rituels, de comités, de points de synchronisation, de passations formalisées. Puisqu’on ne sait pas réduire les dépendances, on organise la communication. On espère compenser la distance par des processus. Mais ces couches ajoutent surtout de la latence, de la rigidité et de la charge mentale, sans résoudre le problème de fond.

La distance a aussi un effet plus insidieux : elle coupe du contexte vivant. Quand les équipes sont éloignées des utilisateurs, des métiers, ou même des lieux où les décisions se prennent, la compréhension du domaine devient indirecte. Elle passe par des documents, des tickets, des comptes rendus. Le modèle se construit alors à partir de représentations de seconde main, de fragments, d’abstractions figées. Petit à petit, le code cesse d’être nourri par l’usage réel. Là encore, le désalignement conceptuel trouve un terrain favorable.

Dans beaucoup d’organisations, la localisation s’accompagne d’une autre illusion : celle de la fongibilité. Puisque les équipes sont distribuées, on peut en ajouter, en déplacer, en remplacer facilement. Les personnes deviennent des “ressources” interchangeables, affectées à des périmètres comme on déplacerait des blocs sur un organigramme. Mais ce que cette vision nie, c’est la construction lente et fragile d’une compréhension partagée du système : son histoire, ses subtilités, ses compromis, ses invariants implicites. À chaque rupture, cette mémoire se perd, et la charge cognitive augmente pour ceux qui restent.

Autrement dit, la localisation n’est pas un problème en soi. Elle devient critique quand l’architecture et le découpage créent des dépendances qui exigent une communication constante pour compenser ce qui n’a pas été clarifié dans le modèle. Comme pour la capacité cognitive, elle nous rappelle que l’on ne conçoit pas un système abstrait, mais un système porté par des humains, avec leurs contraintes, leurs limites et leur besoin de sens partagé.

5.3. Intérêt des équipes pour les services qu’elles portent

La troisième dimension proposée par Team Topologies — l’intérêt des équipes pour les services qu’elles portent — est sans doute la plus difficile à objectiver. Elle touche à la motivation, au sens, à l’envie de s’impliquer. Et pourtant, elle conditionne directement la capacité d’une équipe à prendre une responsabilité réelle et durable sur un périmètre.

On peut assigner un service à une équipe. On peut lui dire qu’elle en est “owner”. Mais on ne peut pas décréter l’engagement. Sans intérêt pour ce qu’elle construit et maintient, l’ownership reste formel, administratif. Le service devient un lot à faire tourner, pas un produit vivant à faire évoluer. Les travaux sur la motivation vont d’ailleurs tous dans ce sens.

La Self-Determination Theory, développée par Deci et Ryan, montre que l’engagement durable repose sur trois besoins fondamentaux : l’autonomie, la compétence et le sentiment d’appartenance. Daniel Pink les reformule en autonomie, maîtrise et sens. Autrement dit, les équipes s’investissent réellement quand elles ont prise sur ce qu’elles font, quand elles peuvent progresser dans leur pratique, et quand elles comprennent à quoi leur travail sert.

Cette idée d’un engagement qui naît du lien entre ce que l’on fait et ce que cela produit fait également écho aux travaux de Richard Sennett dans son livre Ce que sait la main. Il y décrit le craft non pas comme une simple recherche de qualité technique, mais comme une relation vivante entre le praticien et son ouvrage : on s’investit vraiment quand on peut voir, comprendre et assumer ce que l’on fait vivre. Sans ce lien, le travail devient exécution ; avec lui, il devient responsabilité.

Quand une équipe porte un périmètre qui ne lui parle pas — trop éloigné du métier, trop abstrait, ou simplement imposé par un découpage organisationnel — l’engagement devient fragile. On fait ce qu’il faut pour livrer, corriger, maintenir. Mais on investit rarement l’énergie nécessaire pour questionner le modèle, remettre en cause des choix anciens, ou chercher un meilleur alignement avec la réalité métier. Le service est géré, plus que porté.

Comme pour la capacité cognitive, cette situation renvoie souvent à une vision implicite des équipes comme des centres d’exécution : peu importe ce qu’elles font, pourvu qu’elles le fassent bien. L’intérêt est alors vu comme un luxe, un “plus” appréciable, mais non comme une condition de soutenabilité. On attend des équipes qu’elles s’adaptent, encore une fois.

Sur le terrain, cela se traduit par des ownerships de façade. Les équipes sont officiellement responsables, mais les décisions structurantes se prennent ailleurs, les priorités leur sont imposées, la vision produit reste floue, et le lien avec les utilisateurs est lointain. La responsabilité existe sur le papier, mais pas dans les faits: l’équipe n’a ni la maîtrise, ni les leviers, ni parfois même l’envie de faire évoluer réellement ce qu’elle porte.

Les effets sont prévisibles. Faute d’intérêt, on cherche avant tout à limiter les risques : on touche le moins possible, on évite les refactorings profonds, on contourne plutôt que de transformer. Le service s’enferme dans son état actuel. La dette s’installe, le modèle se fige, et le désalignement conceptuel progresse, là encore sans bruit.

Cette fragilité est renforcée par les rotations fréquentes. Les périmètres changent, les équipes sont déplacées au gré des priorités du moment, les services deviennent “moins stratégiques” puis reviennent sur le devant de la scène. Souvent, en plus, ces équipes sont en grande partie composées de prestataires, appelés à tourner eux aussi au fil des contrats et des arbitrages. À chaque fois, le sens est à reconstruire, la compréhension à rebâtir, l’histoire à réapprendre. Le message implicite devient : “De toute façon, ça changera encore.” Pourquoi s’investir profondément dans quelque chose de transitoire ?

À l’inverse, quand une équipe se reconnaît dans le service qu’elle porte — parce qu’elle en comprend l’usage, qu’elle voit ses effets, qu’elle est en contact avec ceux qui en dépendent — quelque chose change. L’ownership devient réel. L’équipe cherche à simplifier, à clarifier, à améliorer. Elle ne se contente plus de faire fonctionner : elle fait évoluer. L’intérêt devient alors un moteur de qualité et d’alignement.

Il ne s’agit pas de prétendre que chaque équipe choisit librement son périmètre, ni que tout travail doit être passionnant. Mais chercher l’alignement entre ce qui fait sens pour les équipes et ce que le système attend d’elles n’est pas un luxe. C’est une condition de soutenabilité. Donner de la visibilité sur le flux de valeur, relier le travail quotidien à des usages réels, laisser une marge d’initiative : ce sont autant de moyens de nourrir cet intérêt.

Comme pour la capacité cognitive et la localisation, cette dimension nous rappelle que l’architecture ne se déploie pas dans l’abstrait. Elle prend vie à travers des équipes humaines. Si ces équipes n’ont ni la capacité de porter la complexité, ni les conditions pour construire un sens partagé, ni l’intérêt pour ce qu’elles font vivre, alors l’alignement ne peut pas tenir dans la durée.

6. Découper aux mauvais endroits

« Sans considérer l’angle des équipes, nous risquons de découper le monolithe aux mauvais endroits, voire de créer un système complexe de services indépendants. »

Manuel Pais & Matthew Skelton, Team Topologies

Cette phrase fait le lien direct entre ce que nous venons de voir — la capacité cognitive, la localisation et l’intérêt des équipes — et un choix d’architecture central : le découpage du système. Elle dit en substance que, si l’on ignore l’angle des équipes, on ne se trompe pas seulement dans l’organisation humaine ; on se trompe dans la structure même du logiciel.

Découper un système, c’est décider où placer les frontières : quelles responsabilités vivent ensemble, quelles règles métier sont cohérentes entre elles, quels changements peuvent rester locaux, et lesquels doivent se propager. C’est, on l’a vu, une décision de modélisation autant que d’architecture. En ce sens, le Domain-Driven Design — et en particulier son approche stratégique — offre un cadre précieux pour penser ces frontières à partir du domaine, à travers des modèles explicites et des bounded contexts, plutôt qu’à partir de considérations purement techniques.

Mais, dans beaucoup de refontes que j’ai observées, ce découpage est abordé avant tout comme un problème technique : comment découper le monolithe, combien de services créer, quels frameworks utiliser, comment organiser les pipelines et les déploiements. On parle de taille des services, de granularité, de patterns d’intégration. Mais on parle beaucoup moins de ce que ces services représentent réellement dans le domaine, ni de ce que les équipes vont devoir comprendre, porter et faire évoluer.

Quand l’angle des équipes est ignoré, le découpage devient un exercice abstrait, souvent guidé par des critères qui semblent rationnels sur le papier, mais qui produisent des effets délétères sur le terrain.

6.1. Les découpages “évidents” qui fabriquent de la dépendance

Le premier réflexe est souvent de découper selon des axes techniques : un service pour l’authentification, un pour les référentiels, un pour les calculs, un pour l’accès aux données, un pour les notifications, un pour la facturation, etc. Autrement dit, on projette dans l’architecture distribuée les couches et les composants transverses du monolithe.

Ce type de découpage est séduisant, parce qu’il :

  • correspond à des expertises techniques identifiées ;
  • semble favoriser la réutilisation ;
  • donne une impression de factorisation et de rationalisation.

Mais il crée presque mécaniquement des dépendances fortes entre équipes. Les use cases métiers traversent alors plusieurs services “horizontaux”. Chaque évolution un peu significative implique :

  • de coordonner plusieurs équipes ;
  • d’aligner des priorités différentes ;
  • de gérer des versions et des compatibilités ;
  • et de négocier qui fait quoi.

On obtient exactement ce que nous avons décrit plus haut : une explosion des interactions humaines pour compenser un découpage qui ne permet pas des évolutions locales. La complexité n’a pas disparu ; elle s’est simplement déplacée du code vers les réunions.

Un autre travers fréquent est le découpage par sous-domaines organisationnels existants : on découpe selon les silos déjà en place, les directions, les départements ou les périmètres historiques. On ne part pas du domaine tel qu’il sert les utilisateurs, mais de la manière dont l’entreprise est déjà structurée.

Dans ce cas, on ne fait pas émerger de nouvelles frontières pertinentes : on fige dans le code les frontières de l’organisation actuelle. La loi de Conway joue à plein, mais sans être réellement conscientisée. Le système devient le reflet des compromis, des héritages et parfois des tensions organisationnelles, bien plus que de la logique métier. Et lorsque l’organisation évolue — ce qui est inévitable —, le logiciel, lui, reste coincé avec ces frontières devenues obsolètes.

6.2. Découper sans modèle, c’est découper à l’aveugle

Dans ces situations, le découpage n’est pas porté par un modèle explicite du domaine. Il est guidé par :

  • la structure existante ;
  • les expertises techniques ;
  • les outils disponibles ;
  • ou la pression de “faire des microservices”.

On découpe, mais on ne sait pas toujours très bien quoi on découpe, ni pourquoi telle frontière serait plus pertinente qu’une autre.

Sans ce travail de modélisation, le découpage devient en grande partie arbitraire. Et quand il est arbitraire, il est presque toujours faux du point de vue du métier.

Les symptômes apparaissent rapidement :

  • des services qui ne portent qu’une partie de la logique et doivent en appeler plusieurs autres pour faire quoi que ce soit d’utile ;
  • des données éclatées sans frontière claire, qu’il faut recoller à chaque use case ;
  • des règles métier dupliquées “en attendant mieux”, puis jamais vraiment reprises ;
  • des contrats d’API qui changent sans cesse parce que les responsabilités n’étaient pas claires dès le départ.

Autrement dit, on a découpé le code, mais pas la complexité. On l’a même souvent rendue plus visible, plus coûteuse et plus fragile.

Cette idée fait écho au talk Model Mitosis de Josian Chevalier et Julien Topçu. Ils y expliquent que le design d’un système doit évoluer avec notre compréhension du domaine : tant qu’un modèle reste cohérent, il peut vivre dans un même ensemble ; mais lorsque des tensions apparaissent, c’est le signe qu’il est temps de faire émerger plusieurs modèles, façonnés et découplés de manière itérative. Autrement dit, les frontières pertinentes ne se décrètent pas a priori ; elles se découvrent au fil de l’apprentissage du métier. Vouloir découper sans ce travail de modélisation, c’est précisément découper à l’aveugle.

6.3. Quand le découpage nie la capacité des équipes

C’est ici que le lien avec l’angle des équipes devient évident.

Un découpage qui traverse le domaine de manière incohérente impose aux équipes de comprendre :

  • plusieurs modèles partiels ;
  • des flux distribués sur de nombreux services ;
  • des invariants qui ne sont garantis nulle part ;
  • et des règles qui émergent de l’interaction entre briques plutôt que d’un endroit clairement identifié.

Chaque équipe se retrouve alors responsable d’un morceau qui n’a de sens qu’en relation avec beaucoup d’autres. Pour faire évoluer “son” service, elle doit connaître l’impact sur les voisins, anticiper leurs contraintes, comprendre des règles qu’elle ne maîtrise pas vraiment.

La capacité cognitive est mécaniquement dépassée. Non pas parce que les équipes seraient incompétentes, mais parce que le découpage exige d’elles une vision systémique permanente, sans leur donner les leviers pour agir sur l’ensemble.

C’est exactement dans ces contextes que naissent :

  • les goulots d’étranglement ;
  • les experts transverses saturés ;
  • les équipes qui deviennent des points de passage obligés ;
  • et les autres qui se sentent dépossédées de toute maîtrise réelle.

Le découpage est censé permettre de répartir la complexité. Mal pensé, il la concentre ou la diffuse de manière ingérable.

6.4. De la refonte technique au monolithe distribué

C’est là que la deuxième partie de la phrase prend tout son sens :

« …voire de créer un système complexe de services indépendants. »

Quand on découpe sans modèle, sans angle équipes, sans souci réel du découplage métier, on obtient souvent une constellation de services… mais un système toujours aussi monolithique dans ses dépendances.

Les symptômes sont bien connus :

  • un service ne peut pas être déployé sans en aligner plusieurs autres ;
  • un changement de règle implique une cascade de modifications ;
  • les incidents se propagent en chaîne ;
  • la compréhension d’un flux nécessite de suivre des traces à travers dix briques.

Sur le papier, le système est distribué. Dans les faits, il est toujours monolithique : monolithe de dépendances, de décisions, de coordination et de livraison. Un monolithe distribué.

Et ce monolithe distribué est souvent pire que le monolithe d’origine : plus difficile à comprendre, plus coûteux à opérer, plus lent à faire évoluer, et plus exigeant pour les équipes, qui doivent en porter la complexité au quotidien.

On a modernisé la forme. Mais on n’a pas transformé le Système.

6.5. Découper, c’est choisir ce qui pourra évoluer

Relue à la lumière de tout ce qui précède, la phrase de Team Topologies prend un sens très concret. Découper aux mauvais endroits, ce n’est pas seulement faire un mauvais choix d’architecture. C’est décider, souvent sans s’en rendre compte, que :

  • certaines équipes porteront une complexité qu’elles ne peuvent pas maîtriser ;
  • certaines évolutions resteront structurellement coûteuses ;
  • certaines responsabilités ne seront jamais vraiment claires ;
  • et que l’autonomie restera un mot plus qu’une réalité.

À l’inverse, un découpage aligné sur le domaine et sur les équipes n’est pas une promesse de simplicité absolue. La complexité du métier ne disparaît pas. Mais elle peut être contenue, répartie, rendue intelligible. Elle peut vivre dans des frontières où des équipes ont la capacité, la proximité et l’intérêt de la porter.

Autrement dit, découper, ce n’est pas seulement organiser le code. C’est choisir où la complexité du Système va vivre, et qui va en être responsable.

7. Conclusion : quand moderniser ne suffit pas

Relu à la lumière de tout ce qui précède, l’extrait de Team Topologies prend un sens très concret. Ignorer l’angle des équipes conduit à découper aux mauvais endroits. Découper aux mauvais endroits conduit à un système de services faiblement autonomes, mais fortement dépendants. Et ce système, même distribué en apparence, reste fondamentalement monolithique dans ses flux, ses décisions et ses dépendances : un monolithe distribué.

Dans un tel contexte, la capacité des équipes à maîtriser réellement ce qu’elles portent est structurellement limitée. Ce n’est pas un problème de volonté, de maturité ou de compétence. C’est un problème de structure. Quand presque chaque évolution nécessite de coordonner plusieurs services, plusieurs équipes ou plusieurs périmètres, aucune équipe ne peut faire évoluer “son” morceau de système de manière locale et soutenable.

On peut alors organiser la coordination : rituels, synchronisations, comités, cadres de gouvernance, circuits de validation. Parfois on parle d’autonomie, parfois non. Mais, dans tous les cas, tant que le découpage, le modèle et l’organisation produisent des dépendances fortes, on ne fait que gérer les interactions humaines sans jamais redonner une réelle maîtrise locale.

Peut-être que le cœur du problème est là : nous continuons à penser la transformation comme un projet, avec un début, une fin et une architecture “cible”. Alors que ce dont il s’agit vraiment, c’est de redonner au Système sa capacité à apprendre et à évoluer en permanence, en même temps que le métier qu’il sert.

Tant que nous chercherons avant tout la bonne forme finale, plutôt que les conditions d’un alignement vivant et durable, nous risquons de reproduire encore et encore le même scénario : un nouveau départ technique, pour un même point d’arrivée.