Duck Conf 2025 - CR - Déjouer les pièges de Conway dans l'agilité à l'échelle
Déjouer les pièges de Conway dans l'agilité à l'échelle
Par Samuel Ahnine et Sara Wino Jolivet
Ce compte-rendu fait écho au replay vidéo de la Duck Conf 2025, disponible ici.
Industrialisation de l’agilité
L’Agile connaît aujourd’hui un essor important. Face à des enjeux de plus en plus complexes, les entreprises ne se contentent plus d’expérimenter l’agilité unitaire au niveau des équipes : elles restructurent désormais des DSI ou des Business Units entières autour de l’agilité à l’échelle.
Pour coordonner cette multitude de petites équipes, des frameworks d’agilité à l’échelle comme SAFe se multiplient. Leur objectif : gérer les interactions entre équipes et offrir un alignement global vers une “entreprise agile”.
Mais un paradoxe persiste, que ces modèles peinent à résoudre : comment préserver l’efficacité des petites équipes sans nuire à l’efficacité globale de l’organisation ?
En effet, plus le nombre d’équipes augmente, plus les interactions nécessaires à leur coordination se multiplient. Cela génère de nombreuses dépendances, qui mobilisent une énergie considérable pour être traitées. Cette dépense de temps et d’efforts impacte directement le coût de chaque fonctionnalité développée, ralentit le delivery, et engendre au final de l’insatisfaction client. Un comble : on obtient l’effet inverse de ce que promettait l’agilité.
Pour développer une fonctionnalité, il y a souvent besoin de nombreuses équipes impliquées.
La situation s’aggrave lorsque les DSI, pour rassurer les métiers, lancent de nouveaux projets au lieu de terminer ceux en cours : le flux de valeur se retrouve saturé et les fonctionnalités mettent de plus en plus de temps à être livrées. Le constat est sans appel : la collaboration rapprochée entre les équipes ne passe pas à l’échelle.
Mise en oeuvre d’une manœuvre de Conway inversée
La loi de Conway démontre que les architectures sont en réalité à l’image des organisations qui les conçoivent et les opèrent.
La structure de l’organisation influe sur vos systèmes que vous le souhaitiez ou non.
Pour conserver l'efficacité de l'agilité à l'échelle de votre organisation, la Conway inversée devient la figure à maîtriser.
La Conway inversée ou comment structurer les équipes autour de vos problèmes métiers :
Prenons l’exemple d’un jeu de casino en ligne :
Étape 1 : La première étape consiste à faire ressortir les sous-domaines métiers en s'appuyant sur l'atelier collaboratif Event Storming Big Picture d'Alberto Brandolini.
Un domaine représente l'ensemble des connaissances, concepts et règles métier d'un problème spécifique que l'on cherche à modéliser dans un logiciel. Nous nous appuyons sur les événements connexes à une problématique métier pour identifier un sous-domaine métier.
Étape 2 : Cartographier les composants techniques qui supportent les sous-domaines identifiés
Cette étape consiste à dresser une vue d'ensemble des composants existants et à déterminer comment ces composants techniques s'alignent avec les sous-domaines métiers mis en évidence précédemment. Cela permet d’identifier clairement les dépendances et points d’intégration nécessaires.
Étape 3 : Cartographier les équipes qui interviennent sur les domaines
Dans cette étape, nous identifions et listons les équipes opérationnelles qui interviennent sur chacun des domaines métiers définis. Cette vue permet de clarifier les responsabilités et les périmètres d’action des équipes.
Étape 4 : Etablir les liens entre les équipes et les composants techniques sur lesquels elles interviennent
Il s’agit ici d’expliciter les interactions existantes entre les équipes et les composants techniques. Cette cartographie facilite la compréhension des dépendances organisationnelles.
Une fois ces 4 étapes réalisées l’enjeu consiste à défaire les couplages en alignant les équipes, les domaines et l'architecture cible
L’intention est de limiter les interactions en alignant les équipes et les composants sur les domaines métier, afin que l’organisation reflète l’architecture.
Avoir comme objectif que les équipes aient 1 composant et un domaine en responsabilité en respectant les lois suivantes :
- Loi 1 : un domaine est géré par une seule équipe
- Loi 2 : une équipe peut gérer deux à trois domaines simples
- Loi 3 : si un domaine est jugé complexe, une équipe devra gérer alors ce seul domaine complexe
Découper les domaines en sous-domaines pour réduire la charge à la taille d’une équipe agile.
Le vocabulaire métier est souvent un marqueur fiable des frontières de contexte. Les ambiguïtés de langage identifiables pendant l’Event Storming Big Picture les révèlent.
Cette étape consiste aussi à comprendre ce que fait vraiment l’équipe et à lui demander de prendre le lead sur les instances de développement pour accélérer les délais de livraison.
Comment créer et opérer une organisation adaptée à ce découplage ?
À l’issue de ce découplage, l’objectif est d’aboutir à un design d'organisation qui ressemble à un schéma d'architecture fonctionnelle. Il reste à concevoir une organisation alignée avec cette architecture.
Identifier les équipes productrices de valeur ainsi que celles qui les supportent :
Il existe deux catégories d'équipes à combiner pour permettre de se concentrer sur la valeur (source : Team Topologies).
La première catégorie est composée des équipes productrices de valeur directe :
- Équipe alignée sur la valeur (Stream aligned team) : qui est en charge de produire les fonctionnalités utilisées par les utilisateurs finaux (valeur brute).
La seconde catégorie est composée des équipes en support des équipes productrices de valeur directe :
- Équipe facilitatrice (Enabling team) : groupe de spécialistes à factoriser qui permettent d’assurer des standards de pratiques dans des domaines transverses comme l’architecture, la sécurité, l’expérience utilisateur…
- Équipes qui prennent en charge des parties complexes du produit (Complicated subsystem stream) : prennent en charge une partie du système / composant qui demande des expertises spécifiques (ex : AS400).
- Équipe plateforme (Platform team) : service utilisable par toutes les équipes. Elle développe des services, outils et infrastructures qui sont consommés par les autres équipes, leur permettant de s’alléger des contraintes technico-fonctionnelles pour maximiser leur production de valeur métier.
Définir les modes d’interactions entre les équipes :
- Collaboration : nécessite une interdépendance forte mais elle est nécessaire pour innover. Une innovation qui se base sur la convergence de plusieurs métiers ou technologies nécessite des collaborations entre équipes. Ensuite le modèle devrait évoluer vers une standardisation des interactions pour passer à l’exploitation du produit.
- X as a service : découplage et standardisation pour permettre un passage à l’échelle.
- Facilitation : équipe qui vient en “coup de main”. Elle ne fait pas à la place des autres équipes mais permet de les rendre autonomes sur divers sujets.
En appliquant les typologies d’équipes et les modes d’interaction, nous obtenons un design d’organisation centrée sur la valeur basé sur notre cartographie qui reflète ce découplage :
Une bonne organisation évolue avec son produit.
Votre modèle d’organisation DOIT évoluer pour permettre au produit de tirer le meilleur de chacune des étapes de maturité, depuis l'innovation jusqu'à son industrialisation et son passage à l’échelle.
Conclusion
S’il ne fallait retenir que l’essentiel pour réussir sa Conway inversée et propulser ses produits :
- Diminuer les interactions entre équipes en limitant les interactions entre composants
- Faire émerger une architecture cible et structurer une organisation par domaine métier
- Aligner et structurer l'organisation autour de la valeur
- Tous les modèles sont faux mais certains sont utiles. Il est important de les faire évoluer selon le contexte.
- Organisation et système techniques sont les deux faces d’une même pièce
Sources
Domain Driven Design, by Eric Evans
Team Topologies : Matthew Skelton and Manuel Pais