Structurer l’organisation autour du métier pour accélérer le changement

Structurer l’organisation autour du métier pour accélérer le changement

Transformer une fusion en avantage compétitif durable

• Les fusions et acquisitions créent souvent de la valeur financière rapide, mais laissent derrière elles une complexité organisationnelle durable. Au fil du temps, la superposition d’équipes, de processus et de systèmes ralentit l’innovation, augmente les dépendances et dégrade la capacité à délivrer rapidement de la valeur.
• Le véritable enjeu n’est donc pas seulement d’intégrer des systèmes, mais de reconstruire un alignement entre le métier, les équipes et l’organisation.
• Le Domain-Driven Design permet de clarifier le domaine métier, d’identifier les responsabilités stratégiques et de redonner de la cohérence aux activités à travers des frontières fonctionnelles explicites.
  Team Topologies transforme ensuite cette compréhension en performance opérationnelle en structurant les équipes autour du flux de valeur, en réduisant la charge cognitive et en accélérant la livraison.
• Combinées, ces approches permettent de transformer une fusion subie en un avantage compétitif durable : une organisation plus lisible, plus autonome et capable d’évoluer rapidement dans un environnement incertain.

Le Domain-Driven Design est souvent présenté comme une approche destinée avant tout à la conception de logiciels.

Cette vision est légitime : elle met l’accent sur la compréhension du métier, la collaboration étroite avec les experts du domaine et la construction progressive d’un modèle cohérent permettant de soutenir la création de valeur. Pourtant, lorsqu’on observe l’évolution réelle des organisations, on constate que leur histoire suit rarement une trajectoire aussi rationnelle.

La face cachée des fusions et acquisitions

Beaucoup de fusions et acquisitions ont été guidées avant tout par des considérations économiques et financières plutôt que par une cohérence organisationnelle, et c’est parfaitement compréhensible. Ces regroupements successifs ont conduit à l’agrégation d’entités hétérogènes, chacune conservant ses pratiques, sa culture et ses modes de fonctionnement. La cohérence globale ne s’est alors construite qu’a posteriori, souvent au prix d’une complexité croissante.

Photo de yanzheng xia sur Unsplash

J. P. Morgan et les compagnies ferroviaires

L’histoire de la compagnie ferroviaire américaine Southern Railway illustre bien ce phénomène. Fondée en 1827 puis réorganisée en 1894 par J. P. Morgan afin d’assurer sa stabilité financière, elle s’est développée par l’intégration progressive de près de 150 compagnies ferroviaires. Cette expansion répondait avant tout à une logique de consolidation économique plutôt qu’à une véritable harmonisation organisationnelle. Ces tensions organisationnelles ne remettent pas en cause le succès économique de l’opération, mais constituent un problème différé, qui se révèle lorsque les équipes et les modes de fonctionnement doivent s’aligner.

Cet exemple est d’autant plus révélateur que la vision de J. P. Morgan était, à l’époque, particulièrement précoce. Toutefois, les investissements nécessaires étaient freinés par une perception largement négative de la conquête de l’Ouest, souvent décrite par la presse comme une zone dangereuse et instable, ce qui compliquerait son discours auprès des investisseurs potentiels. Son objectif ultime n’était pas d’harmoniser les organisations de l’ensemble des compagnies ferroviaires intégrées, mais avant tout de soutenir le développement économique de l’Ouest américain afin d’en accroître la rentabilité.

Le volet organisationnel des fusions et acquisitions reste souvent le parent pauvre de ces transformations. Les équipes, prises dans le quotidien et parfois en difficulté, ne perçoivent pas immédiatement ce qui se joue à leur détriment. Ce n’est souvent qu’après plusieurs années que deviennent visibles certaines aberrations organisationnelles.

L’objectif est ici d’explorer comment traiter ce type de dysfonctionnements à travers différentes approches, notamment le Domain-Driven Design et Team Topologies.

Organiser le métier par le découpage stratégique du DDD

Pour aborder efficacement une fusion ou une acquisition sur le plan organisationnel, la première étape consiste à clarifier le fonctionnement métier des deux entreprises. Il s’agit de rendre visibles leurs activités, leurs processus et leurs responsabilités, notamment grâce à l’organisation d’un EventStorming Big Picture dans chacune des organisations. Cet atelier offre une vision globale des flux métier et constitue une base commune de compréhension avant toute tentative d’intégration. À l’issue d’un EventStorming Big Picture, le domaine est généralement structuré en sous-domaines métier, puis chaque sous-domaine est affiné en Bounded Contexts.

© Source: Introducing EventStorming – Alberto Brandolini

Le Bounded Context : poser des frontières pour libérer l’autonomie

Le Bounded Context constitue avant tout un choix stratégique. Il délimite la connaissance maîtrisée par une équipe autour d’un périmètre fonctionnel donné. En établissant des frontières explicites, il protège la cohérence du modèle, favorise l’émergence d’un langage métier partagé et crée les conditions nécessaires à l’innovation ainsi qu’à l’excellence technique. Cet espace maîtrisé permet ainsi de concevoir des systèmes robustes, évolutifs et véritablement alignés avec les besoins du métier. Par nature, un Bounded Context vise également une forte autonomie, du fonctionnel jusqu’à la technique. Rien ne devrait dépendre directement d’une autre équipe pour préserver la cohérence du modèle et maintenir la capacité de livrer de manière fluide et indépendante.

La démarche commence généralement par la société cible. Dans le cadre d’une acquisition amicale, celle-ci apporte un périmètre fonctionnel complémentaire. L’objectif est alors de comprendre ses capacités métier, les événements structurants de son activité et les frontières naturelles de ses domaines fonctionnels. Cette exploration permet d’identifier la valeur propre de l’entreprise acquise ainsi que ses points d’articulation avec l’organisation existante.

Du côté de la société acquéreuse, il est rarement nécessaire d’analyser immédiatement l’ensemble du système. Il est généralement plus pertinent de concentrer l’EventStorming Big Picture sur le domaine présentant le plus d’interactions avec celui de l’entreprise cible. L’objectif est d’organiser les nouveaux périmètres afin de les faire collaborer efficacement avec le système existant pour produire de la valeur.

À l’inverse, intégrer de nouveaux périmètres fonctionnels sans réflexion d’ensemble ni compréhension préalable des frontières existantes conduit souvent à l’apparition de résistances, voire à une certaine défiance entre les équipes nouvellement intégrées et celles déjà en place.

Éclairer les interactions entre les Bounded Contexts

Cette approche met en évidence les zones de contact, les recouvrements fonctionnels et les divergences de langage métier, tout en limitant la complexité de l’analyse initiale.

Le Context Mapping vient compléter la compréhension acquise lors de l’EventStorming. Là où l’EventStorming décrit le fonctionnement du métier à travers ses processus et ses événements, le Context Map met en lumière les relations entre les différents Bounded Contexts. La représentation offerte par le Context Mapping, plus synthétique, rend visibles les dépendances, les flux d’information et les modes de collaboration entre contextes. Elle permet également d’identifier certains éléments structurants. Le label COTS (Commercial Off-The-Shelf) désigne un progiciel standard, prêt à l’emploi, développé par un fournisseur externe et utilisé par plusieurs organisations, par opposition à une solution développée sur mesure.

• Les lettres U et D signifient respectivement Upstream et Downstream, qualification qui permet d’exprimer les relations d’influence et d’assigner une notion de valeur relative entre les différents Bounded Contexts.
• La métaphore de la rivière est l’une des façons les plus simples de comprendre la relation Upstream / Downstream. Imaginons une rivière : ce qui se passe en amont influence inévitablement ce qui se produit en aval.
• Si une personne située en amont décide, par exemple, de jeter des papiers sales dans la rivière, ces papiers seront entraînés par le courant. Tous les points situés en aval finiront par les recevoir, qu’ils le veuillent ou non. Les personnes en aval doivent alors gérer les conséquences d’une décision qu’elles n’ont pas prise.

En d’autres termes, une équipe upstream dispose d’un certain pouvoir d’influence sur les équipes downstream, car ses décisions structurent le cadre dans lequel ces dernières doivent travailler. Les équipes en aval doivent alors s’adapter aux choix faits en amont, parfois sans pouvoir les modifier facilement.

Prioriser l’effort de transformation

Les affinités de valeur permettent d’identifier et de regrouper les éléments qui produisent le plus de valeur pour l’organisation.

Le Domain-Driven Design propose trois affinités de valeur : Generic, Support et Core.

• Le sous domaine core permet de tirer le plus de valeur au sein du domaine métier. Il n'y qu'un seul sous domaine core et donc un seul Bounded Context Core.
• Les sous domaines Support, participent à la réussite du sous domaine core. Ils sont par nature plusieurs à contribuer à la valeur du sous domaine Core.
• Enfin le sous domaine Generic, est nécessaire pour le bon fonctionnement du domaine métier, mais il n'est pas différenciant. En d'autre mots, ils peuvent être incarnés par des progiciels, car le développement, la maintenance n'ont pas d'intérêts métier.

En analysant ces affinités, il devient possible de mieux comprendre quels domaines, fonctionnalités ou initiatives contribuent réellement aux objectifs stratégiques.

Cette approche aide ainsi à orienter et prioriser l’effort de transformation. Plutôt que de transformer l’ensemble du système de manière uniforme, l’organisation peut concentrer ses ressources sur les zones où l’impact sera le plus significatif.

• En se basant sur les affinités de valeur, les équipes peuvent donc décider où investir en priorité, afin d’optimiser les bénéfices obtenus par rapport aux efforts engagés dans la transformation.
• L’analyse des affinités de valeur provoque souvent une véritable prise de conscience collective au sein des équipes. Elle apporte un nouvel éclairage sur l’organisation du système et rend visibles des éléments qui restaient jusque-là implicites. Des tensions organisationnelles, des dépendances critiques, des asymétries de pouvoir entre équipes ou encore des incohérences dans la structuration du modèle apparaissent soudainement de manière claire et partagée.

Dans un contexte de fusion entre deux entreprises, cette approche peut s’avérer particulièrement utile. La confrontation des Context Maps des deux organisations permet de comprendre la topologie de leurs systèmes respectifs, d’identifier les différences de structuration du domaine et d’imaginer une organisation cible plus cohérente. Cette analyse facilite la réflexion sur la manière d’aligner les modèles et les équipes autour d’une vision commune.

• Cependant, il est important de garder à l’esprit qu’un Context Map cible, même s’il est rationnel et justifié par les contraintes existantes, reste imparfait s’il ne prend pas en compte la circulation réelle de l’information au sein du système et la capacité des équipes à livrer rapidement de la valeur.
• Contrairement à un EventStorming, ce type de cartographie n’apporte pas de vision temporelle du fonctionnement du système. Sa vocation est avant tout de rendre explicites les relations entre les Bounded Contexts en fonction de leurs affinités de valeur, et non de décrire comment les équipes collaborent concrètement pour accélérer les processus métier et délivrer de la valeur.
• Ainsi, une cartographie qui semble correcte sur le papier ne garantit pas nécessairement une efficacité opérationnelle. Le modèle doit être évalué comme un mécanisme favorisant le flux de valeur, capable d’absorber les évolutions fonctionnelles et de réduire les dépendances bloquantes entre équipes.

Affiner l’organisation avec l’approche Team Topologies

Team Topologies pourquoi faire ?

La vocation de Team Topologies est de repenser l’organisation autour d’un domaine métier afin de permettre une délivrance continue de valeur. L’objectif est de créer un environnement dans lequel les équipes de développement peuvent livrer fréquemment, recueillir de nombreux retours et améliorer le produit de manière incrémentale.

• Cette approche vise à accélérer les flux métier au niveau organisationnel, en réduisant les frictions entre équipes et en favorisant une structure orientée produit. L’organisation n’est plus pensée uniquement autour de projets ou de composants techniques, mais autour de la capacité à produire et faire évoluer un produit dans la durée.
• Dans ce modèle, plusieurs rôles collaborent étroitement — notamment l’UX, le Product Manager et un représentant technique — afin de qualifier en continu les opportunités métier. Ensemble, ils orientent les décisions pour maximiser la valeur délivrée aux utilisateurs.

© Source: Matthew Skelton & Manuel Pais from Team Topologies

C’est précisément cette capacité à faire circuler rapidement la valeur et les apprentissages que Team Topologies désigne sous le terme de Fast Flow : un flux rapide et continu de changements utiles, permettant au produit d’évoluer en permanence en réponse aux besoins du métier et des utilisateurs.

Au cœur de cette organisation, la notion d’équipe alignée sur le flux (stream-aligned team) joue un rôle central : ces équipes recueillent les feedbacks au fil des livraisons, nourrissent l’apprentissage collectif et contribuent à améliorer progressivement le produit.

Team Topologies Quesaco

Dans un contexte post-fusion, cette approche permet de restaurer la vitesse de livraison attendue en définissant clairement quatre types d’équipes.

Suivez la flêche temporel

Une modélisation de type Team Topologies, débute par l’identification de la flèche qui indique la direction du flux de valeur. Cette flèche matérialise le sens dans lequel la valeur est produite et livrée, depuis l’émergence d’un besoin jusqu’à son utilisation par les utilisateurs finaux. Elle constitue le repère principal du schéma, car elle permet de comprendre comment les équipes contribuent collectivement à la création de valeur.

Cette orientation introduit implicitement un axe temporel. Le flux de valeur n’est pas statique : il se déploie dans le temps, au rythme des interactions, des livraisons et des apprentissages des équipes. En suivant cette direction, il devient possible d’observer comment les collaborations évoluent, comment certaines dépendances apparaissent puis disparaissent, et comment les responsabilités se déplacent au fur et à mesure de la maturation du système.

Quatre types d’équipes pour accélérer le flux

Les organisations peuvent structurer leurs équipes autour de quatre topologies fondamentales, chacune répondant à un rôle précis dans la création et l’accélération du flux de valeur.

© Source: Team Topologies

1. La Stream-aligned team est une équipe organisée autour d’un flux continu de création de valeur, généralement associé à une partie clairement identifiable du domaine métier. Responsable d’un périmètre fonctionnel de bout en bout, elle délivre directement de la valeur aux utilisateurs ou aux acteurs du métier. Grâce aux retours obtenus lors des livraisons successives, elle dispose des éléments nécessaires pour identifier et explorer de nouvelles opportunités métier.
2. L’Enabling team a pour mission de soutenir les Stream-aligned teams en les aidant à dépasser des obstacles techniques, organisationnels ou méthodologiques. Elle agit également comme un catalyseur d’apprentissage en observant l’organisation afin d’identifier les compétences ou capacités qui doivent être développées. En d’autres mots, elle permet d’améliorer La Stream-aligned team afin qu’elle accélère son flux métier.
3. La Complicated Subsystem team intervient lorsqu’un sous-système requiert une expertise technique, scientifique ou algorithmique approfondie, notamment dans des contextes impliquant des calculs complexes ou des connaissances hautement spécialisées. Sa vocation est d’apporter les compétences nécessaires à la Steam-aligned team afin qu’elle possède les compétences nécessaires pour réaliser ses objectifs.
4. Enfin, la Platform team regroupe des capacités techniques communes sous la forme d’un produit interne destiné à soutenir et accélérer le travail des Stream-aligned teams. Elle met à leur disposition des services, des outils et des infrastructures qui permettent de réduire la complexité opérationnelle et de simplifier l’accès aux capacités techniques nécessaires au développement et au déploiement des applications. En fournissant ces fondations communes, la Platform team permet aux Stream-aligned teams de se concentrer sur la création de valeur métier et d’accélérer leurs livraisons. Elle constitue ainsi un levier essentiel pour permettre une délivrance continue de valeur aux utilisateurs.

Trois modes d’interaction pour structurer les collaborations

Team Topologies définit également trois modes d’interaction simples afin d’éviter les dépendances implicites.

1. La collaboration correspond à un travail conjoint et temporaire visant à explorer un problème ou à concevoir une solution. Les équipes collaborent autour d’un objectif précis afin d’améliorer une situation donnée. Par exemple, cette collaboration peut prendre la forme d’un atelier de découverte, comme un Event Storming. Plus simplement, deux équipes peuvent également s’entraider sur un sujet transversal qui concerne leurs deux périmètres. Toutefois, la collaboration ne doit être ni trop longue ni trop fréquente, car elle engendre une charge cognitive non négligeable.

© Source: Team Topologies

1. Le modèle X-as-a-Service établit une relation claire de fournisseur à consommateur, avec un minimum de coordination entre les équipes. L’objectif est qu’une équipe mette à disposition un service, généralement sous la forme d’une Web API, destiné à être utilisé par une ou plusieurs équipes consommatrices. Afin de réduire la charge cognitive de ces équipes, il est essentiel de concevoir ce service de manière à ce que l’API reflète explicitement le modèle métier qu’elle expose, facilitant ainsi sa compréhension par les développeurs qui l’utilisent. Ce mode d’interaction peut d’ailleurs constituer l’aboutissement d’une phase de collaboration entre plusieurs équipes, visant à améliorer la fluidité et la vitesse du flux de delivery.

© Source: Team Topologies

1. La facilitation consiste en un accompagnement temporaire visant à rendre une équipe autonome. Cette interaction s’inscrit dans une démarche d’amélioration des compétences d’une ou plusieurs équipes. Le développement de ces compétences peut être d’ordre technologique, fonctionnel, ou concerner les deux à la fois. L’accompagnement des développeurs autour des pratiques Craft constitue, par exemple, un excellent levier pour améliorer la vitesse du flux de delivery. De la même manière, la présence ponctuelle d’un ou plusieurs experts du domaine métier peut également contribuer à accélérer et à renforcer la qualité du flux métier.

© Source: Team Topologies

Ces modes rendent explicites les relations entre équipes et remplacent les demandes vagues de coordination par des mécanismes concrets.

Les leviers qui libèrent le flux de valeur

Privilégier le flux plutôt que le structure

Le flux correspond à la vitesse à laquelle une idée se transforme en valeur réelle pour le client, sans être ralentie par des blocages organisationnels. La structure n’a de sens que si elle contribue à rendre cette transformation plus rapide et plus fluide. Une organisation peut disposer d’un organigramme parfaitement conçu et pourtant ne produire que des réunions et de la documentation. Une structure élégante ne vaut rien si la valeur met trop de temps à atteindre les utilisateurs.

Instaurer un haut niveau de confiance

La confiance ne doit pas se réduire à un simple slogan d’entreprise : elle constitue le socle sur lequel repose toute organisation performante. Un faible niveau de confiance est souvent le signe de difficultés profondes. Dans ces environnements, on voit apparaître une inflation de documentation ainsi que des processus défensifs et coûteux qui finissent par ralentir l’ensemble du système. De nombreuses organisations dépensent ainsi des ressources considérables dans des cadres procéduraux complexes, conçus avant tout pour compenser un manque de confiance envers leurs propres équipes.

Maintenir des équipes stables

• Privilégier une équipe qui travaille ensemble depuis plusieurs années plutôt qu’un groupe nouvellement constitué, même composé d’experts brillants. Les équipes stables développent un contexte partagé, des réflexes de collaboration et des modes de communication implicites qui accélèrent considérablement la livraison. Le coût caché des réorganisations permanentes est pourtant immense, bien que la plupart des organisations continuent de recomposer leurs équipes sans en mesurer réellement les conséquences.

Respecter leurs limites cognitive

Les équipes ne peuvent absorber qu’un certain niveau de complexité avant de se désorganiser. Chaque nouvel outil, chaque responsabilité supplémentaire ou chaque nouveau domaine fonctionnel vient solliciter davantage leur capacité cognitive. Même des équipes compétentes deviennent inefficaces lorsque l’on continue d’ajouter des charges sans jamais en retirer, finissant par saturer leur bande passante mentale.

Favoriser des changements petits et sûrs

Les équipes capables de livrer de petites améliorations chaque jour surpassent presque toujours celles qui réalisent de grandes mises en production risquées à intervalles trimestriels. Ce principe s’applique aussi bien aux évolutions produit qu’aux ajustements organisationnels. L’objectif est de délivrer de la valeur en continu, par incréments modestes et sécurisés, plutôt que de miser sur des déploiements massifs susceptibles d’échouer de manière spectaculaire.

Connecter directement les équipes aux utilisateurs

De nombreuses équipes n’échangent jamais directement avec les utilisateurs de leurs produits et reçoivent des demandes filtrées par plusieurs niveaux hiérarchiques. Ce jeu de transmission déforme progressivement les besoins réels des clients et ralentit la prise de décision. À l’inverse, les équipes en contact direct avec les utilisateurs prennent des décisions plus pertinentes et plus rapides, car elles comprennent les problèmes concrets à résoudre. Cela renvoie directement à la notion de confiance : il est nécessaire de faire confiance aux équipes pour interpréter correctement les besoins clients, plutôt que de chercher à contrôler chaque interaction.

Accepter la complexité

Les systèmes logiciels modernes sont devenus trop complexes pour être entièrement prédits ou planifiés à l’avance. Pourtant, de nombreuses organisations consacrent encore une énergie considérable à tenter de réduire cette incertitude, plutôt qu’à concevoir des systèmes capables de s’y adapter. Beaucoup de projets échouent précisément parce qu’ils reposent sur l’illusion qu’il serait possible de tout anticiper dès le départ. Or, par nature, une organisation se comporte davantage comme un organisme vivant que comme une machine parfaitement prédictible.

Encourager la découverte continue

Comme indiqué dans le paragraphe d'introduction, Team Topologies prend racine dans le mode produit. Les grandes idées ne naissent pas principalement lors de séminaires prestigieux ou de sessions de réflexion entre dirigeants. Elles émergent surtout lorsque les équipes disposent du temps nécessaire pour expérimenter, explorer et essayer de nouvelles approches. Lorsqu’on écrase les équipes sous des backlogs interminables, elles cessent d’innover et se contentent d’exécuter mécaniquement des tâches. À l’inverse, des équipes auxquelles on accorde ne serait-ce qu’une journée par semaine pour explorer ont souvent démontré une capacité à produire bien davantage de valeur. Ce temps d’exploration n’est pas accessoire : c’est souvent là que naissent les prochaines véritables avancées. Sur ce sujet, je vous conseille la lecture de l’ouvrage Continuous Discovery Habits: Discover Products that Create Customer Value and Business Value pose une question centrale : comment savoir si l’on construit réellement un produit ou un service désiré par ses clients ? Comment s’assurer de l’améliorer en continu ? Et comment garantir que l’équipe crée de la valeur pour les utilisateurs tout en générant de la valeur pour l’entreprise ? ».

Réduire les dépendances entre équipes

Rien ne détruit plus rapidement la productivité qu’une équipe contrainte d’attendre une autre pour pouvoir avancer. Beaucoup d’organisations cherchent à optimiser l’efficacité individuelle des équipes tout en négligeant les délais considérables qui apparaissent entre elles. Il n’est pas rare de voir des entreprises recruter davantage tout en livrant moins, simplement parce que les équipes restent dépendantes les unes des autres. L’amélioration doit donc porter autant sur les points de passage et les interfaces entre équipes que sur les équipes elles-mêmes. réduisant les dépendances et les délais de décision. Cette autonomie leur permet d’ajuster rapidement leurs priorités et de faire évoluer le produit au rythme des apprentissages issus du terrain.

Mais au-delà de la cadence de livraison, leur véritable force réside dans leur capacité à porter et à valoriser la valeur métier qui leur est propre. En étant responsables d’un périmètre fonctionnel clair, elles développent une compréhension approfondie du domaine, ce qui leur permet de prendre des décisions cohérentes et alignées avec les enjeux métier.

Une organisation efficace privilégie le flux de valeur plutôt que la structure, en s’appuyant sur la confiance, des équipes stables et une charge cognitive maîtrisée. Elle favorise des changements petits et fréquents, le contact direct avec les utilisateurs, l’adaptabilité face à la complexité et l’expérimentation continue, tout en réduisant au maximum les dépendances entre équipes afin d’accélérer durablement la livraison. Ces neuf principes visent un objectif unique : accélérer durablement la livraison de valeur.

Six patterns pour passer à l’action

Les patterns opérationnels apportent aux équipes les leviers pour préserver la vitesse du flux métier. Ils rappellent que toute équipe appartient à l’un des quatre types définis, que les interactions doivent rester explicites et limitées, et que la charge cognitive doit être activement maîtrisée.

1 - Quatre types d’équipe

Nous les avons décrites précédemment, mais en résumé, toutes les équipes d’une organisation peuvent être rattachées à l’un de ces quatre types.

Les équipes alignées sur le flux de valeur, Stream-aligned teams, produisent directement de la valeur pour les clients le long d’un flux de valeur et sont responsables des résultats.

Les équipes plateforme, Platform teams, conçoivent des services et des outils qui permettent aux équipes alignées sur le flux de valeur d’aller plus vite, en leur retirant de la complexité.

Les équipes d’accompagnement, Enabling teams, interviennent temporairement pour aider d’autres équipes à développer leurs compétences ou à surmonter certaines difficultés, puis poursuivent leur mission ailleurs.

Les équipes de sous-systèmes complexes, Complicated subsystem teams, prennent en charge des composants techniques particulièrement complexes qui nécessitent une expertise spécialisée.

Multiplier les types d’équipes ou inventer des hybrides ne fait que créer de la confusion. On voit parfois des organisations tenter de mettre en place des « équipes hybrides plateforme–flux » ou d’autres constructions artificielles qui finissent souvent par échouer.

Ces quatre types suffisent : ils couvrent l’ensemble des situations.

2 - Trois modes d’interaction

Nous les avons déjà décrites, mais en synthèse, la plupart des dépendances entre équipes deviennent complexes et désordonnées parce que personne ne définit clairement la manière dont les équipes doivent collaborer. Ces trois modes d’interaction permettent de clarifier la situation en précisant quand les équipes doivent travailler étroitement ensemble, se fournir des services ou intervenir ponctuellement pour apporter leur aide.

Collaboration

Les équipes travaillent étroitement ensemble.

Bande passante élevée, mais coût organisationnel important.

X-as-a-Service

Une équipe consomme ou fournit un service avec un minimum d’interaction.

Coût faible et frontières claires entre les équipes.

Facilitation

Une équipe aide une autre à lever des obstacles ou à progresser.

L’intervention est temporaire et ciblée.

Ainsi, on évite les frontière vagues et l'incohérence au sein des équipes

3 - Gérer la charge cognitive des équipes

Des équipes surchargées prennent de mauvaises décisions et avancent plus lentement. Surveiller activement et réduire la complexité inutile est essentiel pour préserver l’efficacité des équipes.

Il arrive souvent que le management accumule les responsabilités sur les équipes jusqu’à les mener au point de rupture, puis leur reproche de ne pas être assez performantes, alors que le véritable problème est la surcharge cognitive.

4 - La plateforme minimale viable

Dans de nombreux cas, les plateformes internes finissent par devenir des systèmes lourds et surdimensionnés qui ralentissent les équipes au lieu d’accélérer leur travail.

L’approche TVP (Thinnest Viable Platform) consiste au contraire à concevoir des plateformes qui fournissent uniquement les capacités nécessaires, sans ajouter de complexité superflue.

Une bonne plateforme doit permettre aux équipes alignées sur le flux de valeur de progresser plus rapidement, et non pas générer de nouvelles dépendances supplémentaires à gérer.

5 - Des frontières d’équipe flexibles

Les frontières entre équipes ne doivent pas être figées de manière permanente ; elles doivent évoluer au rythme des produits et des technologies. C’est sans doute la meilleure façon d’éviter un désalignement entre l’architecture du système et l’organisation des équipes, comme l’illustre la loi de Conway.

Les organisations qui permettent aux équipes d’ajuster leurs responsabilités à partir de leur connaissance du terrain évitent des réorganisations lourdes et douloureuses.

Les entreprises les plus efficaces donnent aux équipes la possibilité de négocier directement l’évolution de leurs frontières, plutôt que d’attendre des directives imposées de manière descendante.

6 - Une adaptation continue

À l’instar du mode produit, la conception organisationnelle n’est jamais véritablement terminée. Elle doit évoluer en permanence avec les besoins du métier, les technologies et les personnes.

Mettre en place des boucles de feedback permettant d’identifier rapidement les ajustements nécessaires aide à éviter l’accumulation de dette organisationnelle. Il appartient également à l’organisation de veiller à ce que les équipes disposent de la capacité et de l’autonomie nécessaires pour s’adapter par elles-mêmes.

De petits ajustements réguliers sont bien moins perturbateurs que de grandes réorganisations imposées par des problèmes accumulés au fil du temps.

Team Topologies appliqué à un cas réel

Prenons un exemple issu de la finance de marché. Au sein de la salle de marché, une première équipe intervient sur le flux de calcul des risques. Elle conçoit, produit et fait évoluer les capacités permettant d’évaluer les expositions et de calculer les différentes mesures de risque. Les composants qu’elle développe constituent les fondations utilisées par les traitements officiels de valorisation et d’analyse des risques appliqués à l’ensemble des transactions.

En parallèle, une seconde équipe, rattachée au périmètre Fixed Income, se concentre sur le calcul des prix des instruments de taux. En s’appuyant sur les modèles et les données disponibles, elle réalise le pricing des produits financiers et contribue ainsi directement au flux de valeur des activités de marché.

Sur le schéma ci-dessous, la flèche illustre l’orientation du changement du flux. Elle invite à ne pas considérer cette représentation comme une simple photographie de l’organisation à un instant donné, mais plutôt comme une lecture dynamique de son évolution.

Le schéma met en lumière les moments où les équipes font évoluer leur manière de travailler afin d’améliorer le flux métier : adoption d’une plateforme, réduction progressive de la charge cognitive, autonomisation des équipes orientées flux, ou encore intervention ponctuelle d’équipes d’accompagnement pour faciliter une transformation.

L’axe temporel permet ainsi de raconter l’histoire de la transformation du système socio-technique. Il montre comment l’organisation apprend progressivement, ajuste ses interactions et affine sa structure afin de mieux délivrer de la valeur au fil du temps.

Dans un premier temps, l’équipe chargée des risques a collaboré temporairement avec l’équipe R&D afin d’intégrer de nouveaux modèles financiers. Par la suite, elle a également bénéficié d’un accompagnement visant à développer de nouvelles compétences techniques, notamment autour du TDD, du refactoring et de la réduction des dépendances, afin de renforcer la qualité de son code à raison d’une heure par semaine, pendant trois mois.t

© Source: Team Topologies

De son côté, l’équipe Fixed Income, spécialisée dans les produits de taux, interagit avec l’équipe R&D selon un modèle X-as-a-Service, en consommant un service exposé par cette dernière. Cette interaction permet à l’équipe Fixed Income de se concentrer sur son domaine métier cœur, tout en déléguant certaines capacités techniques à l’équipe fournisseur. Elle réduit ainsi sa charge cognitive et optimise son flux de delivery en s’appuyant sur une capacité clairement encapsulée et maintenue par l’équipe R&D.

Enfin, cette même équipe Fixed Income interagit avec l’équipe Platform afin de déployer son service sur une infrastructure cloud on-premise. La plateforme fournit les capacités techniques nécessaires au déploiement et à l’exploitation, permettant ainsi à l’équipe Stream-aligned de rester concentrée sur la livraison de valeur métier.

Quand la visualisation devient un levier d’action

Grâce aux topologies d’équipes et aux modes d’interaction qui les relient, il devient plus simple de représenter les interactions et les activités dans un espace-temps clair et explicite. Cette représentation permet de mieux comprendre l’articulation des responsabilités, la nature des dépendances et la manière dont les flux de valeur traversent l’organisation.

Cette approche se révèle à la fois visuelle, collaborative et accessible. En rendant l’organisation visible et partageable, elle facilite les échanges entre équipes, fluidifie leurs interactions et contribue à accélérer les flux de travail afin de délivrer de la valeur plus rapidement.

La simplicité des diagrammes permet également d’organiser des ateliers de modélisation organisationnelle. L’objectif est de réunir les équipes concernées ainsi que leurs Product Managers afin de partager une compréhension commune et de repenser collectivement l’organisation pour améliorer son efficacité.

Peut-on combiner DDD et Team Topologies ?

Quand les Bounded Contexts rencontrent les Stream-Aligned Teams

Les Stream-Aligned Teams (équipes alignées sur un flux de valeur métier) et les Bounded Contexts (contextes stratégiques délimités) peuvent être rapprochés dans une certaine mesure, car ils poursuivent des objectifs similaires : un fort alignement avec le métier et une capacité accrue à délivrer de la valeur dans un cadre d’autonomie élevé. Dans les deux cas, l’objectif est de réduire les dépendances inutiles et de concentrer l’attention sur un périmètre cohérent, compréhensible et maîtrisé.

Cependant, ces notions se distinguent par leur nature et leur rôle au sein de l’organisation. Le Bounded Context relève de la modélisation stratégique du Domain-Driven Design : il délimite un espace de connaissance cohérent, porteur d’une valeur stratégique pour l’entreprise. Selon le niveau de complexité, une même équipe peut ainsi prendre en charge un ou deux Bounded Context.

À l’inverse, la Stream-aligned team, telle que définie par Team Topologies, appartient au champ de la structuration organisationnelle et de l’optimisation du flux de livraison. Elle ne caractérise pas en elle-même la valeur stratégique du domaine sur lequel elle travaille ; son objectif principal est de favoriser une livraison continue et fluide le long d’un flux métier.

Ainsi, les Stream-Aligned Teams et les Bounded Contexts ne sont pas équivalents, mais complémentaires. Le premier organise le travail et la responsabilité opérationnelle, tandis que le second structure la compréhension du domaine. Lorsqu’ils sont alignés, ils se renforcent mutuellement en créant un lien direct entre modèle métier, organisation des équipes et capacité à livrer durablement de la valeur.

Collaboration des équipes et patterns du Context Mapping

Les modes de collaboration décrits par Team Topologies se déclinent en trois formes principales d’interaction entre équipes. Ils permettent de comprendre comment les équipes travaillent ensemble pour délivrer de la valeur et gérer leurs dépendances au quotidien.

À l’inverse, le Context Mapping propose une vision plus fine des relations entre modèles, en s’appuyant sur neuf patterns distincts. Ceux-ci décrivent différentes manières d’articuler les Bounded Contexts entre eux et mettent en évidence trois grandes catégories de relations de collaboration.

Ainsi, là où Team Topologies s’intéresse avant tout aux modes de coopération organisationnelle entre équipes, le Context Mapping formalise les interactions structurelles entre modèles et systèmes.

• La collaboration Team Topologies correspond à un travail étroit entre équipes, impliquant un fort niveau d’échanges, d’alignement et donc un coût organisationnel élevé. Dans un Context Map, ce mode se rapproche du pattern Shared Kernel, où plusieurs équipes partagent une partie du modèle et doivent en préserver conjointement la cohérence.
• Le modèle X-as-a-Service décrit par Team Topologies repose sur une relation explicite de fournisseur à consommateur, caractérisée par des frontières clairement établies et un minimum d’interactions nécessaires. Il constitue ainsi le mode de collaboration le moins coûteux en coordination. Dans le Context Mapping, il peut s’apparenter à deux patterns complémentaires : l’Open Host Service, généralement associé à un Published Language, qui permet une intégration stable et découplée. Sur le plan des relations, ce mode s’inscrit dans une dynamique de communication Upstream / Downstream, où le fournisseur expose des capacités consommées de manière autonome par les contextes en aval.
• La facilitation Team Topologies, enfin, correspond à une intervention ciblée et temporaire visant à lever un obstacle ou à accompagner la montée en compétence d’une équipe. Ce mode n’a pas d’équivalent direct dans le Context Mapping, celui-ci décrivant avant tout des relations structurelles entre des Bounded Contexts plutôt que des dynamiques d’apprentissage ou d’accompagnement entre équipes.

Experts DDD et équipes de facilitation : qui fait quoi ?

Les experts du Domain-Driven Design (DDD) et les équipes de facilitation partagent des objectifs proches, notamment la réduction de la charge cognitive des équipes et l’accompagnement de leur montée en compétences. Tous deux interviennent pour aider les équipes à surmonter des obstacles, clarifier des situations complexes et renforcer leur autonomie, contribuant ainsi à améliorer la capacité globale de livraison.

Cependant, leurs champs d’intervention et leurs approches stratégiques présentent des différences notables. Les experts DDD concentrent principalement leur action sur la compréhension du métier, la qualité des modèles conceptuels et l’alignement entre le langage métier et les solutions logicielles. Leur rôle consiste avant tout à clarifier le domaine, à structurer les Bounded Contexts et à favoriser l’émergence d’un modèle cohérent.

À l’inverse, les équipes de facilitation, telles que décrites dans Team Topologies, interviennent avec un périmètre plus large. Elles accompagnent les équipes sur des enjeux techniques, organisationnels ou méthodologiques, qu’il s’agisse de l’adoption de pratiques d’ingénierie, de l’amélioration des modes de collaboration ou de l’évolution des pratiques de delivery. Ainsi, même si leurs missions peuvent parfois se recouper, les experts DDD se concentrent prioritairement sur la compréhension du métier et la qualité du modèle, tandis que les équipes de facilitation disposent d’un champ d’action plus diversifié, visant avant tout à réduire la charge cognitive des équipes alignées sur le flux.

Là où leurs différences créent de la valeur

EventStorming Big Picture

Parmi les différences les plus marquantes, le Domain-Driven Design propose une approche explicite du découpage du domaine métier en sous-domaines, notamment à travers l’atelier EventStorming Big Picture, qui permet de structurer finement la compréhension du problème business. Cette capacité de modélisation stratégique n’est pas directement couverte par Team Topologies, dont l’objectif n’est pas d’analyser ni de segmenter le domaine métier lui-même. Néanmoins, les auteurs de Team Topologies reconnaissent que le découpage en sous-domaines métier, puis en Bounded Contexts, constitue un prérequis nécessaire à la mise en œuvre efficace de leur approche.

Model-Driven Design

Le Domain-Driven Design permet également de distiller progressivement un problème métier jusqu’au code grâce au Model-Driven Design, au travers d’une démarche itérative impliquant étroitement experts métier et équipes de développement. Cette co-construction du modèle, au cœur du processus de conception, dépasse le périmètre de Team Topologies, dont l’objectif n’est pas la modélisation du domaine, mais l’accélération du flux métier au sein de l’organisation.

Accélérer le flux métier

La force de Team Topologies réside dans sa capacité à aborder directement la problématique de l’accélération de la livraison de valeur auprès des utilisateurs. L’approche considère l’organisation des équipes comme un levier central de performance et cherche avant tout à optimiser le flux de livraison, depuis la conception jusqu’à la mise en production. Cette vision systémique place la rapidité d’apprentissage et la capacité d’adaptation au cœur du fonctionnement organisationnel, un aspect que le Domain-Driven Design n’exprime pas de manière explicite.

En effet, le Domain-Driven Design se concentre principalement sur la compréhension du domaine métier et sur la construction de modèles cohérents à travers les Bounded Contexts. Il propose des mécanismes puissants pour aligner le logiciel avec la réalité métier et pour structurer la complexité, mais il reste relativement neutre quant à la dynamique produit et à la cadence de livraison. L’objectif premier du DDD est la justesse du modèle et la clarté des responsabilités conceptuelles, davantage que l’optimisation du flux de delivery.

Orientée Produit

Team Topologies, à l’inverse, adopte une perspective résolument orientée produit. L’organisation des équipes, leurs interactions et leurs responsabilités sont pensées pour favoriser un flux continu de valeur vers l’utilisateur final. Là où le Domain-Driven Design évoque implicitement cette notion à travers l’affinité de valeur portée par les Bounded Contexts, Team Topologies en fait un moteur explicite : la structure des équipes devient un outil stratégique pour soutenir l’évolution du produit et accélérer sa livraison. On comprend ici que l’équipe comprends des membres dédiées

Organisation vivante

Enfin, Team Topologies envisage l’organisation comme un système en évolution continue, au service de l’intégrité du produit et de la vitesse de livraison auprès des utilisateurs. À l’inverse, le Domain-Driven Design se montre moins explicite sur cette dimension organisationnelle : il apparaît davantage comme une collection de patterns et d’approches. Bien que la notion d’évolution soit bien présente dans sa partie stratégique, elle reste souvent mal comprise, notamment parce qu’elle peut s’avérer complexe à appréhender.

Ce qu’il faut retenir

La vocation principale de Team Topologies est d’accélérer la livraison de valeur durablement afin d’atteindre les utilisateurs le plus rapidement possible. En favorisant des flux de travail fluides et des interactions adaptées entre équipes, cette approche permet d’obtenir des retours concrets et continus, essentiels pour guider l’évolution du produit. À l’inverse, le Domain-Driven Design (DDD) vise avant tout à comprendre en profondeur un domaine métier, afin de le structurer en sous-domaines cohérents et de construire un modèle aligné avec la réalité métier.

Ainsi, ces deux approches ne s’opposent pas : elles se complètent fortement. Le DDD apporte la profondeur de compréhension métier et la cohérence du modèle, tandis que Team Topologies fournit les mécanismes organisationnels nécessaires pour livrer plus rapidement afin de recueillir de nombreux feedbacks. Ensemble, elles contribuent à construire une organisation produit à la fois performante, adaptable et résiliente.

Organisation sous stéroïde

Le combo DDD / Team Topologies est-il unique ?

En combinant le Domain-Driven Design et Team Topologies, l’organisation ne se limite plus à intégrer des systèmes hérités d’une fusion. Elle cherche avant tout à reconstruire un alignement durable entre le métier, les équipes et l’accélération du flux de livraison de valeur. L’objectif dépasse alors la simple consolidation technique ou structurelle : il s’agit de redonner de la cohérence à l’ensemble du système organisationnel afin de soutenir l’évolution continue du produit et de l’entreprise.

Cependant, il existe d’autres approches qui pourraient améliorer les performances d’une organisation inconsistante. La proposition de Jurgen Appelo consiste à libérer le potentiel des équipes grâce au modèle unFIX. Celui-ci encourage une approche flexible de la conception organisationnelle, fondée sur des patterns, capable de s’adapter aux besoins spécifiques de chaque organisation. Que l’on soit dirigeant, consultant ou acteur de l’innovation, le modèle unFIX offre une boîte à outils polyvalente pour favoriser l’innovation continue et améliorer l’expérience humaine au travail. Dans les faits, la proposition reprend l’approche Team Topologies en remplaçant le mot Team par Crew en y ajoutant quelques compléments :

• La Governance Crew, inspirée des principes de Management 3.0, assure les activités de management et de gouvernance de l’organisation. Elle veille à la cohérence des décisions, au bon fonctionnement des mécanismes de pilotage et à l’alignement entre les objectifs stratégiques et les actions des équipes.
• L’Experience Crew est responsable de l’expérience utilisateur de bout en bout. Elle s’attache à concevoir et améliorer l’ensemble du parcours utilisateur, en veillant à la cohérence, à la qualité et à la valeur délivrée tout au long de l’interaction avec les produits ou services.
• La Partnership Crew gère les relations avec les partenaires et les fournisseurs. Elle coordonne les collaborations externes, développe les partenariats et s’assure que les contributions des acteurs externes s’intègrent efficacement dans l’écosystème de l’organisation.

L’offre unFIX est aussi 32 patterns organisationnels qui permettent de structurer les équipes autour des produits, d’améliorer la collaboration, de distribuer la prise de décision, de favoriser l’apprentissage organisationnel et d’aligner l’exécution avec la stratégie.

Il n’y a donc pas lieu de s’inquiéter : Domain-Driven Design, Team Topologies et même unFIX sont largement complémentaires. La responsabilité vous revient de les utiliser de manière judicieuse pour transformer efficacement vos organisations.

Photo de Shelby Murphy Figueroa sur Unsplash

Arrêtons les processus de fusion-acquisition qui négligent l’organisation

Les conséquences d’une fusion ne se résument dès lors plus à une opération financière ou stratégique. Elle devient également une transformation organisationnelle consciente, orientée vers l’amélioration de la capacité d’adaptation et de la réactivité face au changement. En plaçant le flux de valeur et la compréhension du domaine au cœur des décisions, l’entreprise se dote des conditions nécessaires pour évoluer durablement dans un environnement en constante mutation. Cet axe organisationnel constitue ainsi un facteur clé de réussite post-fusion et mérite d’être engagé dès la conclusion d’une fusion ou d’une acquisition.

Les fusions et acquisitions constituent un levier classique de croissance et de transformation stratégique. Pourtant, si leur réussite est généralement évaluée à l’aune de critères économiques ou financiers, leurs conséquences organisationnelles restent souvent sous-estimées. Au fil du temps, ces opérations conduisent à la superposition d’organisations construites selon des histoires, des cultures et des modèles opérationnels différents. La cohérence globale ne se construit alors qu’a posteriori, laissant émerger progressivement des dépendances excessives, des responsabilités floues et une complexité croissante qui ralentit la capacité d’évolution de l’entreprise.

Ces difficultés apparaissent rarement immédiatement. Elles deviennent visibles lorsque les équipes doivent collaborer au quotidien, partager des responsabilités ou faire évoluer conjointement des systèmes hérités. L’enjeu dépasse alors l’intégration technique : il s’agit de reconstruire un alignement durable entre le métier, les équipes et la manière dont la valeur est produite et délivrée.

Et si vous considérez que l’organisation est un sujet secondaire…

On pourrait considérer que l’apport combiné de ces deux approches est excessif pour simplement assurer une organisation cohérente. Pourtant, mon expérience m’a montré que la cohérence et l’efficacité d’une organisation restent des équilibres fragiles. Les entreprises confrontées à des problèmes d’organisation sont nombreuses, car contrairement aux apparences, il est difficile de créer un environnement où les équipes sont pleinement engagées à délivrer de la valeur, en collaboration avec des utilisateurs eux-mêmes impliqués dans l’amélioration du produit.

Les situations de fusion ou d’acquisition expliquent souvent ces déséquilibres, mais elles ne sont pas les seules en cause. Bien souvent, même en l’absence d’événement majeur, l’organisation révèle progressivement des dysfonctionnements qui finissent par nuire à la fois aux utilisateurs et à l’entreprise.

Repenser une organisation issue d’une fusion ne consiste pas seulement à consolider des systèmes existants, mais à reconstruire consciemment son fonctionnement. En combinant compréhension métier et conception organisationnelle, l’entreprise peut transformer une complexité héritée en un avantage compétitif : une organisation plus lisible, plus autonome et capable d’évoluer durablement dans un environnement incertain.

Pour aller plus loin sur unFIX, le Café du Produit, dans l’épisode de septembre 2025 : https://blog.octo.com/compte-rendu-du-cafe-du-produit-38--unfix-ou-comment-redonner-du-sens-a-l'organisation-de-vos-equipes-produit-sans-dogme-ni-recette