Avant l’IA, réorganisez vos équipes autour des flux de valeur

Avant d’amener l’IA dans votre entreprise, il y a un geste qui rapporte plus que n’importe quel outil ou modèle que vous pourriez choisir : réorganiser vos équipes techniques autour des flux de valeur. J’ai vu trop d’entreprises acheter les outils, déployer les modèles, former les gens — et la livraison reste molle, les équipes sortent plus épuisées qu’avant. La cause racine n’est presque jamais une IA trop faible. C’est que les équipes sont découpées par couches techniques — frontend, backend, algo, ops, sécurité. Une seule fonctionnalité de bout en bout traverse quatre ou cinq équipes, et chaque passage de témoin fait perdre quelque chose. Le besoin perd un peu. Le contexte perd un peu. Le sentiment de responsabilité perd un peu. Mettez les frontières d’équipe au bon endroit, et l’IA trouve un terrain où s’amplifier. Laissez-les mal placées, et l’IA ne fait qu’accélérer la production de dette sur une structure bancale.

Cet article pose une méthode de conception organisationnelle qu’on peut vraiment utiliser — Team Topologies (Skelton & Pais, 2019). Trois idées au cœur : découper les équipes selon les flux de valeur, surveiller la charge cognitive de chaque équipe, et faire tourner la plateforme interne comme un produit. On va ouvrir tout ça à partir d’un cas réel dans l’industrie manufacturière.

Un CIO de l’industrie (cas anonymisé d’un projet réel) m’a raconté ça : sortir une fonction d’inspection qualité par IA n’était pas techniquement dur. Caméras qui détectent les défauts, modèle disponible sur étagère. Le dur, c’était la livraison. L’équipe frontend fait l’interface, l’équipe MES retravaille le flux des ordres de fabrication, l’équipe algo déploie le modèle, l’équipe ops gère les serveurs, et par-dessus tout ça la sécurité doit encore faire son audit. Une fonctionnalité, 5 équipes, 4 passages de témoin officiels, 3 mois de traînage. Personne ne boudait son poste. Mais chaque passage de témoin laissait quelque chose par terre.

1. La loi de Conway ne dit que la moitié

La loi de Conway dit ceci : l’architecture d’un système reproduit la structure de communication de l’équipe qui le construit. Découpez vos équipes en frontend et backend, vous obtiendrez un système coupé en frontend et backend. L’équipe communique comme ça, le système pousse comme ça — la loi a été vérifiée empiriquement, encore et encore.

Mais Conway s’est contenté de dire que ça se passe ainsi. Il n’a pas dit comment concevoir les équipes pour qu’une bonne architecture émerge toute seule. Skelton et Pais ont comblé ce vide avec Team Topologies (2019) : quatre types fondamentaux d’équipes, trois modes d’interaction, et un principe qui traverse tout — surveiller la charge cognitive.

2. Les quatre types d’équipes : des options pour la réorg, pas du vocabulaire à réciter

Je vais passer ces quatre types en revue comme des options qu’on peut saisir pendant une réorganisation. Pas des définitions à mémoriser.

Les équipes stream-aligned — le cheval de trait de votre organisation, et la grande majorité d’entre elles. (Le livre dit « most », sans ratio fixe.) Un « stream » est un flux continu de valeur. Une équipe stream-aligned possède un segment de ce flux de bout en bout : comprendre le besoin, construire, livrer, opérer. Un seul test dit si une équipe est stream-aligned : peut-elle mettre de la valeur entre les mains d’un utilisateur sans dépendre d’une autre équipe ? Revenons au CIO : si sa fonction d’inspection qualité avait appartenu à une seule « équipe du flux qualité » — avec des gens qui connaissent le frontend, l’intégration MES, le déploiement de modèle, et l’ops, tous dans la même équipe — la fonctionnalité part avec zéro passage de témoin. C’est la forme qu’elle devrait avoir.

Le problème le plus courant en grande entreprise, c’est que le système court de bout en bout pendant que les équipes sont découpées en tranches horizontales de couches techniques. Chaque livraison de bout en bout doit traverser les frontières hiérarchiques de plusieurs équipes. Changez de secteur, le schéma reste le même. En finance, une fonction de risque crédit doit traverser quatre groupes : l’équipe App, l’équipe système cœur, l’équipe modèle de risque, l’équipe data — chaque groupe avec son backlog, ses priorités, son propre manager à convaincre. L’e-commerce et la télécom condensent la même douleur dans d’autres mots : une fonction promotion traverse catalogue, transaction, marketing, entrepôt ; un changement d’abonnement traverse canaux, facturation, CRM, réseau. A chaque fois, des équipes découpées en travers essaient d’absorber un flux de valeur qui court à la verticale — et les passages de témoin se multiplient. C’est ça, la maladie.

Les équipes plateforme — paver la route pour les équipes stream-aligned. Une équipe plateforme fournit l’infrastructure, le CI/CD, les services mutualisés, pour que les équipes stream-aligned puissent se servir elles-mêmes au lieu d’ouvrir un ticket et d’attendre. Un seul test : votre plateforme interne est-elle exploitée comme un produit — avec des utilisateurs, une feuille de route, un SLA — ou a-t-elle glissé vers le statut de sous-traitant interne qui vit sur les tickets ? La plupart des DSI de grandes entreprises sont coincées dans le second cas. Elles construisent une plateforme que personne n’utilise, les équipes métier la contournent et bricolent leur propre truc, et l’équipe plateforme se ratatine en prestataire interne. Spinnaker chez Netflix (livraison continue) et Backstage chez Spotify (portail développeur) sont les cas d’école de la plateforme gérée comme un produit. Les gens les confondent tout le temps : Spinnaker est à Netflix, Backstage est à Spotify. Ne vous plantez pas devant votre comité.

Les équipes facilitantes — aider les équipes stream-aligned à monter en compétence, avec un but explicite : se rendre obsolètes. Une équipe facilitante ne livre pas le business directement. Elle fait monter les équipes stream-aligned : un coach qui amène une nouvelle technologie, un guide pour une transition DevOps, un consultant sur la sécurité et la conformité. La relation avec l’équipe stream-aligned est mentor et apprenti, pas acheteur et fournisseur. En grande entreprise, c’est exactement le rôle que devrait jouer un accompagnement externe : transférer la capacité, pas fabriquer une dépendance durable.

Les équipes à sous-système complexe — pour les os durs qui veulent une spécialisation profonde. Quand un sous-système demande une vraie profondeur — un moteur de risque, un algo de recommandation, de la cryptographie, du codec vidéo — on le carve out dans sa propre équipe d’experts, au lieu de faire exploser la charge cognitive d’une équipe stream-aligned. Ça doit rester rare. Une organisation qui fait pousser beaucoup d’équipes à sous-système complexe est généralement en train de transformer en silos ce qui aurait dû être une capacité plateforme.

Nommer les types d’équipes ne suffit pas. Il faut aussi définir comment ils interagissent. Team Topologies donne trois modes d’interaction. Collaboration — deux équipes travaillent profondément ensemble, adapté à un terrain nouveau et incertain, mais énergivore, à utiliser par à-coups courts. X-as-a-Service — une équipe offre une capacité comme un produit qu’une autre consomme en autonomie ; c’est le mode le plus efficace et ça devrait être le défaut. Facilitation — réservé aux équipes facilitantes. La question centrale de la conception organisationnelle, c’est comment pousser un maximum d’interactions vers le X-as-a-Service. Si vos équipes s’appuient encore sur la « collaboration » sur la durée, c’est que la platformisation n’a pas eu lieu. Prenez le cas du CIO : l’équipe du flux qualité et l’équipe plateforme devraient interagir en X-as-a-Service. La plateforme expose une entrée CI/CD en self-service, l’équipe qualité l’utilise sans demander l’autorisation. Si chaque déploiement exige encore une réunion de « collaboration » avec l’équipe plateforme, la platformisation manque — et le problème n’est pas une question d’attitude. C’est que la plateforme n’a jamais été gérée comme un produit.

3. Pourquoi « ajouter des gens » et « ajouter du processus » ne sauvent rien : la charge cognitive

C’est la contribution la plus sous-estimée de Team Topologies. Elle place la charge cognitive au centre de la conception organisationnelle.

Une équipe de 5 à 8 personnes a une charge cognitive finie. Demandez à une équipe de maintenir une dizaine de systèmes sans rapport, d’interfacer six ou sept amonts, et de jongler avec trois frameworks nouveaux en même temps — elle surcharge. La qualité chute. La livraison ralentit. Les gens brûlent.

C’est ce qui intriguait le CIO quand il m’a dit : « J’ai ajouté trois personnes, pourquoi on est toujours lent ? » La racine, c’est que ce groupe portait déjà trop de choses sans rapport entre elles. L’effectif était bon. Ajouter des gens ne fait que mettre plus de corps à tourner dans le même chaos. Ajouter du processus, c’est pire — le processus dévore une nouvelle couche de charge cognitive, et ceux qui pourraient vraiment livrer finissent par passer encore plus de temps sur des formulaires, des réunions et des validations.

La graisse la plus facile à perdre, pour une grande entreprise, c’est la charge qu’elle s’inflige elle-même — frictions inter-équipes, bascules de contexte permanentes, chaînes de validation. La couper ne demande aucune nouvelle technologie. Ça demande moins d’agitation.

Un cas concret. Le responsable d’une équipe de système cœur bancaire avait 7 personnes qui interféraient avec quatre amonts — risque, service client, reporting régulateur, marketing — tout en maintenant trois modules sans lien entre eux. Rien que gérer les signatures croisées, les réunions d’alignement et les bascules de contexte mangeait près de la moitié de l’énergie de l’équipe chaque jour. Donnez à cette équipe le meilleur outil IA du marché, ça ne prendra pas. Ils n’ont plus de bande passante cognitive pour apprendre quoi que ce soit de neuf ou changer leur façon de travailler. Pour les sauver, on allège d’abord : on extrait les modules sans rapport, on laisse l’équipe posséder un seul flux de valeur.

La règle des Two-Pizza Teams d’Amazon parle de coût de communication — l’effectif gonfle, le nombre de canaux de communication entre membres (n(n-1)/2) explose, les décisions ralentissent. Team Topologies va un cran plus loin : au-delà de 8 personnes environ, la charge cognitive échappe aussi au contrôle. Ce que fait vraiment la conception organisationnelle, c’est découper les équipes selon la charge cognitive, pour que le fardeau de chaque équipe reste dans ce qu’elle peut porter — pas tracer des lignes hiérarchiques par fonction.

Un check-up en une phrase pour la grande entreprise : vos « gens les plus occupés » portent-ils chacun plus de 5 choses sans rapport en même temps ? Si oui, aucun effectif ni aucun processus ne les sauvera. Il faut redistribuer.

4. Comment passer à l’acte : la manœuvre de Conway inverse

C’est le levier le plus opérationnel du livre. Ne dessinez pas l’architecture d’abord pour ensuite aligner les équipes dessus. Changez d’abord la structure des équipes, et laissez l’architecture pousser dans la forme que vous voulez.

L’approche classique, c’est un architecte qui dessine une architecture cible (« on passe aux microservices ! ») puis somme les équipes de s’aligner. Ça échoue presque toujours. La structure d’équipes existante ne cesse de tirer l’architecture vers sa propre forme. La loi de Conway, à l’œuvre.

La manœuvre de Conway inverse renverse l’ordre. Réorganisez d’abord les équipes par flux de valeur — carve out les équipes stream-aligned, montez une équipe plateforme — pour que les frontières d’équipe deviennent les futures frontières de service. L’architecture dérive alors toute seule vers un découpage de services cohérent, parce qu’entre équipes on communique naturellement par API plutôt qu’en fouillant dans une base de données partagée.

Retour au CIO. Je ne lui ai pas fait choisir un framework microservices. Je lui ai fait faire un truc beaucoup plus modeste : monter « inspection qualité » comme une équipe de flux autonome. Prendre une personne dans chacune des équipes frontend, MES, algo et ops d’origine. Six personnes, possédant la fonctionnalité d’inspection de bout en bout. Trois choses se sont passées en trois semaines. Semaine un : ils ont découvert qu’une étape bloquée dans le flux des ordres de fabrication MES n’avait en fait pas besoin de l’équipe algo du tout — ils l’ont corrigée à l’intérieur de l’équipe. Semaine deux : ils ont décidé eux-mêmes de passer le déploiement du modèle du mode « file d’attente ops » au self-service interne, parce que l’équipe plateforme leur avait ouvert une entrée CI/CD en libre-service. Semaine trois : ils ont livré une première petite fonctionnalité de bout en bout, sans traverser aucune frontière d’équipe. Pas un effectif ajouté, pas un outil changé — les couches horizontales avaient été recoupées en flux verticaux. Le cycle de livraison est passé de 3 mois à 3 semaines. Un bonus inattendu a suivi : cette équipe s’est mise à proposer des améliorations d’elle-même, parce que pour la première fois elle voyait l’intégralité de son flux et possédait le résultat de bout en bout. Quand ça traversait 5 équipes avant, personne ne se sentait responsable du flux qualité dans son ensemble.

Pour le décideur, c’est une conclusion contre-intuitive mais à fort effet de levier : arrêtez de vous escrimer sur le schéma d’architecture, et mettez le scalpel dans l’organigramme. L’architecture est un résultat. L’organisation est le levier.

Qui l’utilise

Banque (secteur prioritaire officiel de TT + référence sous forte régulation). teamtopologies.com tient une rubrique experte, « When DORA metrics meet governance in banking ». La recherche DORA qu’elle cite est tranchée : les approbations externes sont corrélées négativement au lead time, à la fréquence de déploiement et au temps de restauration — plus d’approbations inter-équipes a posteriori, plus la livraison ralentit et plus la remise en service après incident s’allonge. Ça corrobore exactement la thèse de cet article : intégrer la conformité dans l’équipe stream-aligned et faire remonter l’approbation en amont, au lieu de compter sur des signatures croisées inter-équipes après coup. Des banques numériques britanniques comme ClearBank reviennent régulièrement dans l’écosystème officiel. La banque est le scénario le plus instructif pour une réorg par flux de valeur sous forte régulation.
Zalando (e-commerce, l’exemple plateforme-produit). Sa plateforme développeur interne sert de capacité en self-service aux équipes stream-aligned — un standard de platformisation souvent cité par la communauté TT.
AutoTrader UK (petites annonces auto). Un cas d’adoption réel que TT cite à l’envi — réorg par flux de valeur plus produit de plateforme interne.
KPMG UK (devenu partenaire solutions officiel TT en 2024). Diffuse TT auprès des grandes entreprises et des clients financiers — un signal que TT est entré dans le conseil entreprise mainstream.
Netflix / Spotify (exemples spirituels de « plateforme comme produit », pas cas d’adoption TT). Tous deux exploitaient leur plateforme comme un produit bien avant la sortie du livre TT en 2019, ce qui valide le principe — mais ce ne sont pas des adoptions du modèle à quatre équipes de TT.

Référence : teamtopologies.com/examples (bibliothèque de cas officiels) · teamtopologies.com/news-blogs-newsletters/when-dora-metrics-meet-governance-in-banking (rubrique experte DORA / banque)

5. Quand ça ne marche pas

Team Topologies n’est pas une balle en argent. Quatre échecs classiques, chacun cartographié sur une pathologie réelle des grandes entreprises.

Renommer sans restructurer. Rebaptiser le « groupe frontend » en « équipe stream-aligned » alors que les lignes hiérarchiques restent organisées par couche technique — la loi de Conway se fiche du nom que vous donnez aux choses. C’est la fin la plus fréquente d’une réforme cosmétique en grande entreprise : des étiquettes neuves, la même vieille structure.

L’équipe plateforme n’est pas gérée comme un produit. Pas de feuille de route, pas d’expérience utilisateur. Les équipes stream-aligned continuent de la contourner, et la plateforme se ratatine en sous-traitant qui prend des tickets.

Tout le monde « collabore ». La collaboration est une interaction à haute énergie, adaptée seulement à des à-coups courts en terrain nouveau et incertain. Compter dessus sur la durée, c’est le signal que la platformisation n’a pas eu lieu. La surface ressemble à « superbe culture de collaboration ». La maladie, c’est l’absence de platformisation.

Les KPI n’ont pas suivi. L’organigramme a changé, mais on mesure toujours par fonction — lignes de code frontend, nombre de bugs — et le comportement de l’équipe snaps directement vers l’ancienne forme.

Ces quatre points convergent vers un jugement : structure d’organisation, structure d’incitation, architecture technique — changez l’un des trois sans bouger les deux autres, et la transformation échoue.

Une variante pour les secteurs sous forte régulation. La finance et la télécom demanderont : les fonctions de sécurité, de conformité et de risque IT sont exigées indépendantes par le régulateur (segregation of duties). On ne peut pas simplement les plier dans l’équipe stream-aligned. C’est une contrainte légale dure, pas une inertie organisationnelle — ne forcez pas le découpage à la hache. Mais vous n’êtes pas non plus obligés de retomber sur les files d’approbation horizontales. Deux voies. Première : embarquer des représentants conformité et sécurité dans l’équipe stream-aligned — ils siègent dans l’équipe tout en reportant en pointillé vers la fonction conformité, au plus près du flux de valeur tout en préservant l’indépendance. Deuxième : faire tourner la conformité comme une équipe facilitante qui aide les équipes stream-aligned à intégrer les exigences réglementaires dans le flux — contrôles de conformité lancés dans le CI, par exemple — en remontant l’approbation à l’intérieur de l’équipe plutôt qu’en s’appuyant sur des signatures croisées a posteriori. L’exigence réglementaire devient une qualité intégrée à l’équipe stream-aligned, pas une porte de revue externe. C’est la clé pour qu’un secteur sous forte régulation puisse « couler ».

6. Vous allez peut-être demander

« On est découpé par couches techniques depuis dix ans, une réorg ne va-t-elle pas tout dévaster ? Ça dérange, mais bien moins que ce que vous craignez. Pas besoin de raser toute l’entreprise pour repartir de zéro. Choisissez le flux de valeur le plus engorgé — en général celui dont tout le monde se plaint le plus fort — et montez-le comme une équipe stream-aligned pilote. Comme ce CIO : 4 à 8 semaines, une petite équipe, et vous verrez un décrochage net de vitesse de livraison. Laisser les résultats vendre la manche suivante marche bien mieux qu’un PowerPoint.

« Quel rapport avec ma transformation IA en cours ? » Direct. L’IA ne répare pas une organisation mal découpée. Elle amplifie ce qui est déjà là : une équipe haute performance dotée d’IA va plus vite ; une équipe mal alignée dotée d’IA ne fera que fabriquer de la dette plus vite. Le diagnostic organisationnel se classe donc avant l’achat d’outils. C’est aussi pourquoi je place « l’évaluation des capacités » très tôt dans ma méthode signature, le 7-Step AI Transformation Coaching Framework — d’abord l’organisation et les gens, ensuite les outils.

« On n’arrive pas à réunir les quatre types d’équipes. La plupart des organisations n’y arrivent pas, et n’en ont pas besoin. Les deux premiers à avoir sont les équipes stream-aligned (pour garantir la livraison de bout en bout) et une équipe plateforme (pour arrêter de réinventer la roue). Les équipes facilitantes et à sous-système complexe viennent à la demande ; beaucoup d’organisations n’en ont pas au départ, et c’est très bien. Ne fabriquez pas des équipes artificiellement pour compléter les quatre types. Ce serait la queue qui remue le chien.

7. Enseignements pour le décideur

Enseignement un : avant l’IA, dessinez une carte des topologies d’équipes. Avant la dernière fois que vous avez introduit un outil IA, aviez-vous dessiné la topologie de vos équipes ? Avec des équipes découpées par couches techniques, aussi forte soit l’IA, vous ne faites qu’accélérer la dette sur une structure bancale. Ce seul geste peut bloquer au moins la moitié des investissements IT gaspillés en grande entreprise. Action concrète : listez toutes les équipes et marquez quel flux de valeur chacune possède de bout en bout. Celles que vous ne pouvez pas marquer sont découpées par couche technique — ce sont les priorités de réorg.

Enseignement deux : faites un check-up de la charge cognitive. Arrêtez de demander « est-ce qu’on a assez de monde ». Demandez quelles équipes maintiennent plus de 5 systèmes sans rapport à la fois, et quelles personnes interfacent avec plus de 3 amonts. Faire émerger ça est bien plus utile que d’ajouter de l’effectif ou du processus. L’IA peut absorber une partie de la charge — écrire du code, chercher, triage en première passe — à condition de redistribuer la charge délibérément, plutôt que de coller une tâche « déploiement IA » de plus sur une équipe déjà surchargée.

Enseignement trois : faites tourner la plateforme interne comme un produit, sinon elle dégénère en sous-traitance. La plateforme a besoin d’utilisateurs, d’une feuille de route, d’un SLA, et de quelqu’un qui rende des comptes sur le taux d’adoption. À l’ère de l’IA, cette plateforme doit aussi absorber la passerelle de modèles, la bibliothèque de prompts et le runtime des agents — c’est la fondation sur laquelle l’article ultérieur « framework d’adoption » s’appuiera.

Enseignement quatre : ne laissez pas l’IA figer les mauvaises frontières. Celui-ci s’adresse aux organisations qui introduisent des agents IA. Quand vous ajoutez des agents IA dans des équipes, un mauvais découpage se trouve amplifié : l’agent va automatiser selon les frontières existantes — mauvaises — et cimenter la structure bancale plus fermement. Avant d’introduire des agents IA, confirmez que les frontières d’équipe sont les bonnes. C’est le cœur du 11e épisode de la série.

Auto-contrôle (répondez sans arranger la réalité) : votre équipe est-elle découpée par flux de valeur, ou par frontend/backend/ops/sécurité ? Votre personne la plus occupée porte-t-elle plus de 3 choses sans rapport à la fois ? Une plateforme interne sans utilisateur, c’est le voyant rouge d’une platformisation ratée. Si l’une des deux réponses vous met mal à l’aise, alors avant d’amener l’IA, réorganisez d’abord les équipes. C’est le geste préalable au plus fort retour.

Ce qui vient ensuite

C’est le 2e épisode de la série « La transformation du génie logiciel à l’ère de l’IA » (épisode 172 de la rubrique « Learn AI Slowly »). On est allé de Conway (l’organisation décide de l’architecture) à Team Topologies (comment concevoir l’organisation). Le prochain épisode (no 3) attaque une question plus fondamentale : quand l’IA rend la production de code presque gratuite, où se déplace le goulot d’étranglement du génie logiciel ?

Note sur la série : cette série suit en continu l’évolution des outils de programmation IA, des structures d’organisation et des paradigmes du génie logiciel — par exemple comment la loi de Conway change à l’ère des agents IA en 2026, ou la maturité du dernier écosystème d’outils. Suivez la série pour des analyses mises à jour en continu.

À propos de cette série

« La transformation du génie logiciel à l’ère de l’IA » est une série de recherches approfondies écrite pour les CIO, CDO, CTO et directions numériques des secteurs télécom, finance, industrie et e-commerce — 15 épisodes au total. Construite sur plus de 200 articles académiques et rapports sectoriels, elle fournit des références de décision annotées par niveau de preuve.

Ancien ingénieur IBM, coach certifié ICF, j’ai piloté des projets IA et numériques chez des opérateurs télécom et de grandes entreprises. Ce qui est écrit ici est le jugement de terrain forgé en accompagnant des entreprises à travers ces pièges.

Si vous finissez cet article en vous demandant « est-ce que mon entreprise ne ressemble pas aussi à ça » — j’ai monté un auto-test Team Topologies en 20 questions, et je propose un appel de diagnostic en 1-contre-1 de 30 minutes pour vous aider à localiser quel flux de valeur réorganiser en premier. Si vous voulez l’un ou l’autre : laissez un message sur le compte WeChat « Insights pour décideurs IA », ou écrivez à coach@iaiuse.com.

Références

Skelton, M. & Pais, M. (2019). Team Topologies. IT Revolution Press. (La source originelle des quatre types d’équipes / trois interactions / charge cognitive — source primaire.)
Conway, M. (1968). How Do Committees Invent? Datamation.
Forsgren, Humble & Kim (2018). Accelerate. IT Revolution Press.
IT Revolution (2024). Team Topologies: Five Years of Transforming Organizations. (Rétrospective d’adoption multi-organisations — secondaire.) https://itrevolution.com/articles/team-topologies-five-years-of-transforming-organizations/
Netflix Spinnaker / Spotify Backstage — exemples de platformisation interne en produit.
AutoTrader UK — cas d’adoption cité par TT officiel (lien teamtopologies.com à compléter).
Bibliothèque de cas officiels : https://teamtopologies.com/examples