Série "Ce que les colonies de fourmis enseignent à l'agilité"
Six articles pour démonter une illusion : l'auto-organisation ne se décrète pas.
Sans dispositifs explicites, les organisations dérivent vers le noyau actif (40% portent 80%), le free-riding (passagers clandestins), et l'effondrement du bien commun.
Les six premiers articles ont posé le diagnostic :
- Article 1-2 : Le syndrome du noyau actif existe. Les prothèses cognitives sont nécessaires.
- Article 3-4 : Les silos rigidifient. Le leadership distribué fonctionne quand chacun sait quoi faire.
- Article 5-6 : Le PI Planning s'effondre sans dispositifs anti-free-riding. On peut diagnostiquer un train avec 4 seuils pathologiques.
La question qui reste : OK pour la coordination. OK pour l'alignement. Mais qu'en est-il de la fiabilité ?
Quand vous mettez en production, qui garantit la qualité ? La sécurité ? La stabilité ?
Réponse honnête dans beaucoup d'organisations : 2-3 héros qui rattrapent tout à la fin.
C'est exactement le syndrome du noyau actif appliqué à la release.
Les fourmis, encore. Mais cette fois pour l'hygiène collective.
Les fourmis maintiennent l'hygiène de leur nid collectivement. Quand un cadavre ou un déchet apparaît, ce n'est pas UNE fourmi "chef de l'hygiène" qui s'en occupe. Plusieurs ouvrières détectent le problème via des phéromones et agissent selon des règles simples : transporter hors du nid, isoler dans une zone spécifique.
Certaines espèces vont plus loin. Elles appliquent des substances antimicrobiennes. Elles isolent les individus malades. Elles empêchent la propagation d'infections.
Les scientifiques appellent ça l'immunité sociale : la santé du groupe devient une propriété du système, pas un exploit individuel.
Ce qui m'a frappé en lisant les travaux sur ce sujet :
- Ce n'est pas UNE fourmi qui surveille tout
- C'est un système de détection distribué
- Chaque fourmi détecte et agit selon son seuil
- Pas de débat, pas de comité
- Juste des signaux chimiques + règles locales
Résultat : le nid reste sain sans qu'aucune "fourmi héros" ne porte toute la responsabilité.
Chez nous, c'est rarement le cas.
Précision importante (pour ceux qui découvrent cette série) :
Je ne compare jamais un individu humain à une fourmi. Ce serait absurde.
Ce qui est comparable, c'est le comportement de grands groupes face à des défis similaires : coordination sans chef unique, gestion de ressources communes, prévention d'effondrements.
Les fourmis ont résolu ces problèmes biologiquement. Nous devons les résoudre artificiellement.
Ce qui m'intéresse : quels mécanismes fonctionnent à l'échelle de 70-150 personnes, sur des projets à dizaines de millions d'euros, et comment éviter les pièges systémiques que j'observe depuis 20 ans.
La release "héroïque"
Grande administration française. Projet de refonte stratégique. 3-4 ans.
Le rituel : tout accès à la production passe par un CAB (Change Approval Board). Procédures complexes. Formulaires en cascade. Validations multiples.
Ce que je mets dans "release governance" : la chaîne complète qui va des dépendances/versioning aux gates qualité/sécu jusqu'au go/no-go final.
Le résultat :
- Chaque livraison dure une semaine ou plus
- Les équipes se renvoient la balle
- Personne ne prend vraiment de décision
- Et pourtant... presque toujours, des héros viennent au secours pour que ça marche
Le symptôme : "On a mis en place toute cette gouvernance pour éviter les problèmes... et on continue à dépendre de 2-3 personnes qui rattrapent tout au dernier moment."
Ce n'est pas de la performance. C'est du rattrapage.
La gouvernance est devenue un théâtre, pas une protection.
C'est exactement le syndrome du noyau actif de l'article 1. Mais appliqué à la release, pas à la planification.
Votre organisation fonctionne-t-elle bien ?
Voici un test simple. Répondez honnêtement :
☐ Vos mises en production sont des événements stressants
☐ Les mêmes 2-3 personnes sont systématiquement appelées pour "sauver" une release
☐ Vous découvrez des incompatibilités ou des dépendances manquantes au moment de livrer
☐ Vos environnements de test/pré-prod tombent régulièrement en panne, bloquant les équipes
☐ Vous avez des processus de validation lourds... mais ils ne détectent pas vraiment les problèmes
☐ Les équipes contournent certains "gates" parce qu'ils ralentissent sans apporter de valeur
☐ Quand quelqu'un part en congé dans l'équipe ops/sécu/infra, les releases sont reportées
Si vous avez coché au moins 2 cases, vous avez un problème systémique.
Pas un problème de compétences. Pas un problème de motivation.
Un problème d'architecture : votre système fabrique du noyau actif au lieu de distribuer la responsabilité.
Les deux dérives
J'ai observé deux dérives symétriques dans mes transformations. Les deux produisent le même résultat : des héros qui rattrapent.
Dérive 1 : Le chaos
Pas de garde-fous. Chacun avance dans son coin.
Le mécanisme :
- On va vite en développement
- On repousse l'intégration
- Les dépendances se découvrent tard
- Les environnements ne sont pas stabilisés
- Chaque équipe optimise son silo
La conséquence : la qualité et la stabilité deviennent un "mode pompier". En fin de PI, en fin de sprint, au moment de la release, quelqu'un doit tout rattraper.
Le noyau actif compense. Les héros se révèlent.
Exemple concret : chez un grand assureur du CAC 40, début de transformation. Projet stratégique, plusieurs milliards d'euros de CA, un an pour livrer.
État initial :
- Environnements qui tombent plusieurs fois par semaine
- Équipes de dev bloquées des demi-journées entières
- Renvoi de balle permanent entre dev, ops, sécu, archi
- Mises en production = événements stressants
Chacun faisait son job. Mais personne ne sécurisait le end-to-end.
Dérive 2 : La bureaucratie
Trop de gates. Trop de validations. Trop de process.
Le mécanisme :
- On empile des validations pour "se rassurer"
- CAB rituels qui débattent pendant des heures
- Formulaires qui ne servent à rien
- La gouvernance devient un processus, pas une protection
La conséquence :
- Ralentissement massif
- Contournement (on trouve des chemins détournés pour éviter les gates)
- Perte de sens
Exemple concret : l'administration française mentionnée plus haut.
Des procédures de CAB très lourdes. Des livraisons qui durent une semaine ou plus. Des équipes qui se renvoient la responsabilité.
Et au final, ce sont toujours les mêmes personnes qui font en sorte que ça passe.
Le paradoxe : on a créé toute cette gouvernance pour éviter les problèmes... et elle ne les évite pas.
Le point commun
Dans les deux cas, la responsabilité migre.
Chaos → la responsabilité migre vers les héros en fin de chaîne.
Bureaucratie → la responsabilité migre vers le processus (mais personne ne décide vraiment).
L'équilibre : gouvernance comme prothèse cognitive
Retour à l'article 2 : nous avons besoin de prothèses cognitives.
Le PI Planning est une prothèse cognitive pour l'alignement.
La release governance est une prothèse cognitive pour la fiabilité.
Une bonne gouvernance retire le besoin de héros. Elle fait de la qualité, de la sécurité, de la stabilité une propriété du système, pas un exploit du noyau actif.
Comment ?
Trois principes inspirés de ce que font les fourmis naturellement :
Principe 1 : Détecter tôt, pas tard
Les fourmis inspectent à l'entrée du nid, pas au fond.
Nous : identifier les dépendances et les incompatibilités en amont, pas en fin de PI. Sécuriser les environnements avant qu'ils ne bloquent. Automatiser les vérifications de compatibilité dès le commit, pas à la release.
Principe 2 : Critères simples, décisions binaires
Les fourmis n'organisent pas de débat sur la nourriture. Signal chimique clair → décision immédiate.
Nous : pas de CAB qui débat pendant des heures. Des seuils clairs. Des gates automatiques quand c'est possible. Ça passe ou ça ne passe pas.
Principe 3 : Responsabilité distribuée
Pas "le processus décide". Pas "le héros rattrape".
Chaque couche (dev, ops, sécu, archi) a des critères à respecter. La gouvernance rend visible qui bloque et pourquoi.
Comme les fourmis : chacune joue son rôle, personne ne porte tout.
La construction progressive du système
Retour au grand assureur du CAC 40.
Au départ : chaos complet. Environnements instables. Équipes bloquées. Renvoi de balle. Mises en prod stressantes.
On aurait pu mettre en place un CAB lourd. On aurait reproduit la dérive bureaucratique.
On a fait autre chose.
Étape 1 : Capitaliser sur chaque problème
Chaque panne → analyse. Chaque blocage → automatisation de la correction. Pas de "on verra la prochaine fois".
On a documenté. On a scripté. On a partagé.
Étape 2 : Sécuriser l'infrastructure
Machines stabilisées. Redimensionnement quand nécessaire. Monitoring proactif.
Pas de prouesse technique. Juste du travail méthodique.
Étape 3 : Groupes de travail transverses
Dev + Ops + Sécu + Archi. Pas de silos. Résolution collective des problèmes.
Avec l'appui du management. Sponsor actif, pas spectateur inquiet.
Étape 4 : Automatisation de la chaîne
Gates automatiques : tests, sécu, compatibilité.
Critères binaires : vert → go, rouge → no-go.
Décisions rapides. Pas de débat interminable.
Le résultat au bout de quelques mois :
Les mises en production sont devenues des "non-événements". Ça se fait fluidement. Plus besoin de héros.
Concrètement : releases passées de 1 par mois (événement stressant, week-end mobilisé) à 2-3 par semaine (go/no-go en 20 minutes, équipes sereines). Incidents post-release divisés par 4.
La qualité est devenue une propriété du système.
Les trois couches du système anti-héros
Pas un framework. Juste trois couches simples que j'ai vues fonctionner.
A) Amont : Dépendances & environnements
Rendre visibles les dépendances tôt. Pas au sprint 4.
Sécuriser les environnements AVANT qu'ils ne bloquent.
Automatiser les vérifications de compatibilité.
C'est l'équivalent des fourmis qui inspectent à l'entrée : on détecte les problèmes au bon moment.
B) Milieu : Gates qualité/sécu
Peu de gates, mais automatiques et binaires.
Pas de débat : critères clairs → décision immédiate.
Si c'est rouge, on ne passe pas. On corrige.
C) Aval : Go/No-Go
Décision courte basée sur des signaux verts ou rouges.
Pas un CAB qui débat. Une vérification que tous les feux sont verts.
Responsabilité claire : si c'est rouge, c'est non.
L'objectif : que ces trois couches empêchent l'héroïsme ET évitent le théâtre.
Ce que je retiens
Si votre release dépend de héros, votre système est mal conçu.
La gouvernance n'est pas là pour contrôler. Elle est là pour retirer le besoin de héros.
Entre chaos et bureaucratie, il y a une troisième voie : le système anti-héros.
Détecter tôt. Critères simples. Responsabilité distribuée.
Ces constats viennent de 30+ transformations à l'échelle. 20+ trains agiles accompagnés. Organisations de 70 à 200 personnes. Projets de dizaines de millions d'euros. Secteurs : banque, assurance, industrie, administrations.
Et vous ?
Votre organisation penche-t-elle plutôt chaos ou bureaucratie ?
Quel est votre "gate" le plus utile ? Le plus toxique ?
À quel moment la responsabilité bascule-t-elle vers les héros chez vous ?
Dans le prochain et dernier article : comment choisir le bon modèle d'organisation pour votre contexte. Entre autonomie distribuée et discipline opérative, quelle est VOTRE bonne formule ?
Références
- Gordon, D.M. (2010). Ant Encounters: Interaction Networks and Colony Behavior. Princeton University Press.
- Cremer, S., Armitage, S.A., Schmid-Hempel, P. (2007). "Social Immunity". Current Biology, 17(16), R693-R702.
- Article 1 : Le syndrome du noyau actif
- Article 2 : Auto-organisation : pourquoi vos équipes ont besoin de prothèses cognitives
- Article 3 : De component teams à feature teams
- Article 4 : La reine ne commande rien
- Article 5 : Le PI Planning comme jeu de biens publics
- Article 6 : Diagnostiquer un train agile avec le modèle de seuils
- Transformation grand assureur CAC 40 : système anti-héros construit sur 6-8 mois
- Transformation administration française : gouvernance bureaucratique observée sur 3-4 ans
Aucun commentaire:
Enregistrer un commentaire