En bref : Ce guide pratique propose des outils concrets pour organiser les interactions entre équipes distantes. Les auteurs de Team Topologies y détaillent comment définir une « Team API », suivre les dépendances inter-équipes et choisir le bon mode d’interaction. Un manuel opérationnel pour les organisations qui veulent structurer leur travail distribué sans sacrifier l’efficacité.
Matthew Skelton et Manuel Pais, les architectes de Team Topologies
Matthew Skelton et Manuel Pais ne sont pas des théoriciens de bureau. Leur parcours s’est construit sur le terrain, au contact des organisations qui tentent de livrer des logiciels plus vite sans s’effondrer sous leur propre poids. Skelton a fondé Conflux en 2007, une société de conseil spécialisée dans la livraison continue et l’organisation des équipes techniques. Pais, de son côté, a accumulé plus de quinze ans d’expérience dans l’amélioration des flux de travail et des processus de développement.
Leur premier livre, Team Topologies, publié en 2019, a posé les bases d’une nouvelle façon de penser l’organisation des équipes. Le Remote Team Interactions Workbook, sorti en avril 2022, prolonge cette réflexion en l’adaptant aux réalités du travail distribué. En 65 pages environ, ce n’est pas un pavé théorique mais un cahier d’exercices pensé pour être utilisé, annoté, rempli. Une approche pragmatique qui reflète bien la philosophie des auteurs.
La Team API : définir comment votre équipe interagit avec le monde
Le concept central du livre tient en deux mots : Team API. L’idée est simple mais puissante. Tout comme une interface de programmation définit comment un logiciel communique avec d’autres systèmes, une Team API définit comment une équipe interagit avec le reste de l’organisation. Elle explicite ce que l’équipe fait, ce dont elle a besoin, et comment les autres peuvent travailler avec elle.
Concrètement, une Team API documente plusieurs éléments. D’abord, les responsabilités de l’équipe : quels systèmes elle maintient, quels services elle fournit. Ensuite, ses canaux de communication privilégiés : où la contacter, comment soumettre une demande, quels délais attendre. Puis ses dépendances : de quelles autres équipes elle a besoin pour fonctionner. Et enfin, ce qu’elle attend des équipes qui dépendent d’elle.
Cette formalisation peut sembler bureaucratique au premier abord. Elle ne l’est pas. Quand les équipes travaillent dans le même bureau, beaucoup de ces informations circulent naturellement. Une question au café, un coup d’œil par-dessus l’épaule, une conversation de couloir. À distance, ces micro-interactions disparaissent. La Team API les remplace par quelque chose de plus explicite, de plus fiable. Les auteurs proposent des templates et des exercices pour construire cette documentation progressivement, sans tomber dans l’usine à gaz.
Les trois modes d’interaction entre équipes
Skelton et Pais identifient trois façons fondamentales pour les équipes de travailler ensemble. Chacune a ses usages, ses avantages et ses limites. Le piège, c’est de ne pas choisir consciemment et de laisser les interactions se structurer par défaut, généralement de la pire manière possible.
Le premier mode est la collaboration. Deux équipes travaillent ensemble sur un objectif commun pendant une période définie. C’est intense, ça consomme beaucoup d’énergie des deux côtés. Mais c’est parfois nécessaire pour explorer un nouveau domaine ou résoudre un problème complexe. La collaboration doit rester temporaire. Si elle s’éternise, c’est le signe que quelque chose ne va pas dans la structure organisationnelle.
Le deuxième mode, c’est le X-as-a-Service. Une équipe fournit quelque chose que les autres consomment sans avoir besoin de comprendre comment ça fonctionne en interne. Une plateforme, un outil, une API. L’équipe fournisseuse se concentre sur la qualité du service, les équipes consommatrices se concentrent sur leur propre mission. C’est le mode qui passe le mieux à l’échelle, mais il nécessite une vraie maturité côté fournisseur.
Le troisième mode est la facilitation. Une équipe aide les autres à s’améliorer sans faire le travail à leur place. Elle détecte les blocages, propose des solutions, forme les personnes. C’est un rôle ingrat et souvent mal compris. Une équipe de facilitation réussie finit par se rendre dispensable, ce qui peut sembler contre-intuitif dans des organisations où la taille de l’équipe détermine le statut.
Suivre les dépendances pour anticiper les problèmes
Le workbook propose des outils pour cartographier et suivre les dépendances entre équipes. Ce n’est pas un exercice académique. Les dépendances non gérées sont la première cause de ralentissement dans les organisations distribuées. Une équipe attend qu’une autre livre quelque chose. Cette autre équipe est elle-même bloquée par une troisième. Les délais s’accumulent, personne ne sait vraiment où ça coince.
La méthode proposée distingue plusieurs types de dépendances selon leur nature et leur criticité. Certaines sont inévitables et doivent être gérées. D’autres révèlent des problèmes de découpage organisationnel qu’il vaudrait mieux résoudre en restructurant les équipes. Le suivi régulier de ces dépendances, à travers des exercices simples comme la « dependency tracker », permet de repérer les goulets d’étranglement avant qu’ils ne paralysent l’organisation.
Les auteurs insistent sur un point souvent négligé : la charge cognitive. Une équipe qui dépend de dix autres équipes, même si chaque dépendance est bien gérée individuellement, finit par crouler sous la complexité. Le workbook aide à identifier ces situations et à les corriger, soit en réduisant les dépendances, soit en changeant leur nature pour les rendre moins consommatrices d’attention.
Ce que ça change pour un dirigeant
Pour un dirigeant ou un manager, ce workbook offre un cadre pour prendre des décisions organisationnelles plus éclairées. La question n’est plus « comment organiser mes équipes » dans l’absolu, mais « quels modes d’interaction sont appropriés pour quels objectifs ». Cette nuance fait toute la différence.
Les exercices du livre peuvent être utilisés lors de rétrospectives ou de sessions de planification. Ils forcent à expliciter des choses qu’on laisse souvent implicites. Qui dépend de qui ? Pourquoi ? Est-ce que cette dépendance est saine ou problématique ? Les réponses ne sont pas toujours confortables, mais elles permettent d’agir plutôt que de subir. D’ailleurs, comme l’explique Patrick Lencioni dans The Five Dysfunctions of a Team, la clarté sur les rôles et responsabilités est un prérequis pour qu’une équipe fonctionne vraiment.
Le format workbook a un avantage supplémentaire : il peut être utilisé de manière asynchrone. Dans une organisation distribuée, réunir tout le monde au même moment n’est pas toujours possible ni souhaitable. Les équipes peuvent remplir les exercices chacune de leur côté, puis partager et discuter les résultats. Cette approche respecte les contraintes du travail à distance tout en permettant l’alignement.
Les limites de l’approche
Ce livre n’est pas pour tout le monde. Il suppose une familiarité avec Team Topologies, le livre principal dont il découle. Sans cette base, certains concepts paraîtront obscurs ou arbitraires. Les lecteurs qui découvrent le sujet feraient mieux de commencer par le premier livre.
Le format très court, 65 pages, est à la fois une force et une limite. On va à l’essentiel, pas de remplissage. Mais certains sujets mériteraient un développement plus approfondi. Les exemples concrets manquent parfois, et on reste avec des principes généraux qu’il faut ensuite adapter à son contexte spécifique.
Enfin, l’approche fonctionne mieux pour les organisations techniques, celles qui développent des logiciels ou des produits numériques. Les concepts comme la Team API ou le X-as-a-Service viennent du monde du développement logiciel. Ils peuvent s’adapter à d’autres contextes, mais le transfert n’est pas toujours évident. Une entreprise industrielle ou une société de services traditionnelle devra faire un effort de traduction.
Questions fréquentes
Faut-il avoir lu Team Topologies avant ce workbook ?
Fortement recommandé. Le workbook est conçu comme un complément pratique au livre principal. Sans la compréhension des quatre types d’équipes et des trois modes d’interaction décrits dans Team Topologies, les exercices perdent une partie de leur sens et de leur efficacité.
Ce livre convient-il aux petites équipes ?
Les principes s’appliquent dès que plusieurs équipes doivent collaborer, même dans une petite structure. Toutefois, la formalisation proposée peut sembler excessive pour une startup de dix personnes. Le retour sur investissement est plus net à partir d’une cinquantaine de collaborateurs répartis en plusieurs équipes.
Le livre existe-t-il en français ?
Pas à ce jour. Le Remote Team Interactions Workbook n’est disponible qu’en anglais. Team Topologies, le livre principal, a été traduit en français sous le titre « Team Topologies » aux éditions Dunod, ce qui peut faciliter la compréhension des concepts de base.
Combien de temps faut-il pour compléter les exercices ?
Cela dépend de la taille de l’organisation et du nombre d’équipes impliquées. Pour une équipe seule, quelques heures suffisent. Pour cartographier les interactions d’une organisation entière, il faut compter plusieurs sessions étalées sur quelques semaines, avec des itérations pour affiner les résultats.
La Team API n’est-elle pas trop rigide pour un environnement agile ?
C’est une objection courante. La Team API n’est pas un contrat figé mais un document vivant qui évolue avec l’équipe. Elle clarifie les attentes sans les graver dans le marbre. L’idée n’est pas de créer de la bureaucratie mais de rendre explicite ce qui reste souvent implicite et source de malentendus.
Ce workbook remplace-t-il un consultant en organisation ?
Il fournit un cadre et des outils, pas un accompagnement personnalisé. Pour des transformations organisationnelles complexes, un regard externe reste précieux. Le workbook permet cependant de préparer le terrain, de poser les bonnes questions et d’impliquer les équipes dans la réflexion avant toute intervention extérieure.
