Team Topologies : le guide pour les dirigeants d’entreprises logicielles

Quand une entreprise logicielle grandit, le premier réflexe, c’est de recruter. Plus de monde, plus de vitesse : ça semble logique. Pourtant, au-delà d’un certain seuil, ajouter des développeurs ralentit la livraison. Les estimations se dégradent, les mises en production se compliquent, les équipes passent plus de temps à se coordonner qu’à écrire du code.

Le problème se trouve dans la structure. Et Team Topologies, le modèle de Matthew Skelton et Manuel Pais, offre un langage concret pour s’y attaquer.

Cet article traduit ces principes en décisions opérationnelles pour les dirigeants : des choix concrets, qui ont un impact direct sur la vitesse du logiciel.

Pourquoi la structure des équipes détermine la vitesse du logiciel

La loi de Conway, formulée en 1967 et confirmée par des décennies de pratique, dit que la structure du logiciel reflète la structure de l’organisation qui le produit. C’est une contrainte aussi incontournable qu’une loi physique, dont elle emprunte le nom.

Si les équipes sont organisées par technologie (une équipe frontend, une équipe backend, une équipe infrastructure), le logiciel aura trois couches couplées. Chaque fonctionnalité demandera la coordination des trois. Chaque mise en production deviendra un projet multi-équipes.

Si les équipes sont organisées par domaine métier (une équipe paiements, une équipe catalogue, une équipe logistique), le logiciel tendra naturellement vers des modules indépendants. Chaque équipe pourra livrer en autonomie, parce qu’elle possède tout le flux, de l’interface utilisateur jusqu’aux données.

La structure organisationnelle est une véritable décision d’architecture.

Les quatre types d’équipes

Team Topologies définit quatre types fondamentaux d’équipes, chacun avec un objectif précis :

• Les équipes stream-aligned : ce sont les équipes de livraison principales. Chacune est responsable d’un flux de valeur pour le métier (un produit, une fonctionnalité, un segment de clients). Elles possèdent tout ce qu’il faut pour livrer : code, tests, déploiement, monitoring. La plupart des équipes d’une organisation devraient être de ce type
• Les équipes platform : elles construisent et maintiennent les plateformes internes qui rendent les équipes stream-aligned autonomes. Pipelines CI/CD, infrastructure, outils de monitoring. Leur produit, c’est l’expérience de développement des autres équipes
• Les équipes enabling : elles accompagnent temporairement les équipes stream-aligned pour transférer des compétences précises. Elles rendent les autres équipes capables de faire le travail seules. Elles sont temporaires par construction : une fois la compétence acquise, l’équipe enabling se retire
• Les équipes complicated-subsystem : elles gèrent des parties du système qui demandent une expertise spécialisée très poussée (moteurs de calcul, algorithmes complexes, composants de sécurité). Elles existent parce que la charge cognitive de ce sous-système dépasserait la capacité d’une équipe généraliste

La règle fondamentale, c’est que chaque équipe doit savoir clairement de quel type elle relève. Si elle ne le sait pas, elle fait probablement un peu de tout, et cela fait partie du problème.

La charge cognitive : la limite invisible

Chaque équipe a une capacité cognitive limitée. C’est la quantité de connaissances qu’elle peut gérer en même temps : la base de code, les outils, les processus, les domaines métier. Quand cette capacité est dépassée, la productivité s’effondre, les erreurs se multiplient et l’onboarding des nouvelles recrues devient extrêmement lent.

Trois types de charge cognitive pèsent sur les équipes :

• La charge intrinsèque : la complexité du domaine métier lui-même. Elle est inévitable, il faut l’accepter
• La charge extrinsèque : une complexité que l’équipe subit mais ne devrait pas avoir à gérer. Des outils mal configurés, des processus bureaucratiques, une infrastructure à maintenir à la main. Éliminer cette charge est le travail des équipes platform
• La charge pertinente : la complexité des choix techniques que l’équipe doit faire pour résoudre les problèmes du métier. Cette charge se gère avec de la compétence

Réduire la charge cognitive est le levier le plus puissant pour gagner en vitesse. Une équipe avec une charge gérable livre plus vite qu’une équipe deux fois plus nombreuse mais surchargée. C’est pour cela qu’ajouter des développeurs n’améliore souvent pas la vitesse : si la charge cognitive reste la même, plus de monde ne veut dire qu’une chose, plus de coordination.

Les trois modes d’interaction

Team Topologies ne définit pas seulement les types d’équipes : il définit aussi comment elles doivent interagir. Trois modes, chacun avec un objectif précis :

• La collaboration : deux équipes travaillent ensemble, côte à côte, pour une durée limitée. Utile pour explorer un nouveau domaine ou construire quelque chose qu’aucune des deux équipes ne pourrait faire seule. C’est temporaire, et si ça dure plus de quelques semaines, quelque chose ne va pas
• X-as-a-Service : une équipe fournit un service à une autre, avec des interfaces claires et documentées. L’équipe qui consomme le service n’a pas besoin de savoir comment il fonctionne en interne. C’est le mode cible pour la plupart des interactions
• La facilitation : une équipe enabling accompagne une équipe stream-aligned pour transférer des compétences. Elle apprend à l’équipe à faire le travail, sans le faire à sa place. La facilitation a une échéance, elle se termine une fois l’équipe autonome

Si deux équipes ont besoin de se coordonner en permanence sans entrer dans l’un de ces modes, c’est le signal que les frontières entre les équipes (et entre les modules logiciels qu’elles possèdent) sont au mauvais endroit.

Comment appliquer ces principes dans une PME

Team Topologies est né de l’expérience de grandes organisations, mais les principes s’appliquent aussi avec 3 ou 4 équipes. L’échelle change ; les contraintes restent les mêmes.

Avec notre service Équipes intégrées, nous intervenons souvent comme équipe supplémentaire dans des organisations qui n’ont encore appliqué aucun cadre de conception organisationnelle. Ce que nous observons presque à chaque fois, c’est la variante la plus répandue du problème : des équipes organisées par technologie (frontend, backend, mobile, data), chacune sur sa couche. Chaque fonctionnalité demande une coordination entre toutes les équipes. Passer à des équipes par domaine paraît simple sur le papier. En pratique, cela prend six à douze mois, principalement pour redessiner la responsabilité de chaque composant, les rôles et les interfaces entre équipes pendant que le produit continue d’être développé.

Dans une PME de 15 à 30 développeurs, les actions concrètes sont :

1. Organiser les équipes par domaine métier : l’équipe « paiements » possède tout le flux, frontend, backend et données, sans « équipe frontend » séparée. Chaque équipe peut livrer en autonomie
2. Définir une équipe platform minimale : ne serait-ce qu’une personne dédiée à maintenir la pipeline CI/CD, le monitoring et les outils de développement. L’objectif, c’est que les équipes stream-aligned n’aient pas à se soucier de l’infrastructure
3. Mesurer la charge cognitive : si une équipe gère plus de 2 ou 3 composants indépendants, la charge est probablement excessive. La réduire, y compris en redistribuant les responsabilités, est la première chose à essayer avant de recruter
4. Rendre explicites les modes d’interaction : chaque binôme d’équipes doit savoir s’il collabore, consomme un service, ou se trouve en phase de facilitation. L’ambiguïté génère une coordination implicite, qui est la plus coûteuse de toutes

Si la structure actuelle des équipes ne reflète pas ces principes, la restructuration n’a pas besoin d’être un big bang. On commence par une équipe, on vérifie que ça fonctionne, puis on étend. C’est la même approche incrémentale que nous appliquons avec notre service Équipes intégrées.

Que faire, concrètement

Trois actions à mener cette semaine :

1. Dessiner la carte actuelle : quelles équipes existent, ce qu’elles possèdent, comment elles interagissent. Tout mettre sur un tableau. Si le dessin est confus, l’organisation l’est aussi
2. Identifier l’équipe qui a le plus de dépendances : c’est celle qui se bloque le plus souvent en attendant d’autres équipes. Les dépendances entre équipes sont le symptôme le plus visible d’une structure désalignée
3. Réduire la charge d’une équipe : choisir une équipe et lui retirer une responsabilité qu’elle ne devrait pas avoir. Un composant qui pourrait appartenir à une autre équipe, un outil que l’équipe platform pourrait gérer. Un seul changement, pour en observer l’effet

La structure des équipes n’est pas un organigramme à mettre à jour une fois par an. C’est une décision d’architecture, à revoir chaque fois que le produit, le marché ou l’organisation changent. Qui la conçoit avec intention avance plus vite ; qui la subit ralentit.