Une flotte de bateaux rapides plutot qu'un grand navire

J’ai passe la premiere partie de ma carriere chez Microsoft. La densite de talents y etait extraordinaire — certains des ingenieurs et esprits produit les plus brillants avec lesquels j’aie jamais travaille. Et pourtant, livrer quoi que ce soit de significatif donnait l’impression de pousser un rocher en haut d’une colline a travers des sables mouvants.

Une decision qui aurait du prendre un apres-midi engloutissait des semaines. On partait d’une idee raisonnable, puis on passait des jours en reunions d’alignement — se synchroniser avec les equipes partenaires, obtenir la validation des program managers, boucler avec des parties prenantes qui avaient des opinions vagues mais apparemment critiques. Le temps que tout le monde ait donne son avis, l’idee originale avait ete poncee jusqu’a devenir quelque chose qui n’enthousiasmait personne, mais que tout le monde pouvait tolerer. C’est la maladie du grand navire. Le talent est de classe mondiale, mais le systeme transforme la vitesse en consensus.

Cette experience a faconne tout ce que j’ai fait depuis. A travers quatre exits et 25 ans de construction et de mise a l’echelle d’entreprises tech, je suis revenu a la meme conviction encore et encore : une flotte de bateaux rapides depassera un grand navire a chaque fois.

Pourquoi les grands navires ralentissent

Ce n’est pas de la malveillance. C’est de la physique.

Les couts de coordination evoluent de maniere quadratique avec la taille de l’equipe. Fred Brooks nous l’a dit en 1975 et nous continuons a le reapprendre. Une equipe de 5 personnes a 10 canaux de communication. Une equipe de 15 en a 105. Une equipe de 50 en a 1 225. Chaque personne supplementaire n’ajoute pas seulement de la capacite — elle ajoute de la charge a tous les autres.

Les dependances sont le tueur silencieux. Quand l’equipe A a besoin de quelque chose de l’equipe B avant de pouvoir debloquer l’equipe C, on n’a pas trois equipes travaillant en parallele — on a un pipeline serie avec beaucoup de gens qui attendent. J’ai vu des organisations avec des centaines d’ingenieurs dont le debit reel etait pire qu’un seul squad de huit personnes, parce que chaque initiative etait paralysee par des dependances inter-equipes.

Ensuite, il y a la dilution de la responsabilite. Quand la responsabilite est partagee entre trop de personnes, personne ne porte le resultat. Les decisions sont escaladees parce que personne ne veut avoir tort. Le processus remplace le jugement parce qu’il est plus sur de suivre le mode d’emploi que de trancher. Et finalement, l’organisation optimise pour l’alignement interne plutot que pour la valeur client.

C’est comme cela qu’on se retrouve dans un monde ou livrer une fonctionnalite mineure prend un trimestre et personne ne peut expliquer pourquoi.

Le modele du bateau rapide

L’alternative est simple en concept et difficile en execution : de petites equipes cross-fonctionnelles avec la pleine responsabilite d’un domaine.

Un bateau rapide, c’est 5 a 8 personnes — typiquement un product manager, un designer et une poignee d’ingenieurs. Ils sont responsables d’un espace probleme de bout en bout. Pas seulement le code, pas seulement la fonctionnalite, mais le probleme, la solution, le deploiement, le monitoring et le resultat business.

A cette taille, la communication est naturelle. On n’a pas besoin d’une ceremonie de stand-up pour savoir ce que font ses coequipiers — on le sait parce qu’on leur a parle au tableau blanc il y a vingt minutes. Les decisions se prennent vite parce que les personnes qui ont le contexte sont celles qui ont l’autorite. Pas besoin d’ecrire une proposition de six pages et de la faire passer par trois niveaux d’approbation quand toute l’equipe est dans la meme salle et peut regler la question en une heure.

La magie du bateau rapide, c’est qu’il restaure la responsabilite. Quand une petite equipe possede completement un domaine, elle le ressent. La qualite du code lui tient a coeur parce que c’est elle qui est appelee quand quelque chose casse. L’experience utilisateur lui importe parce qu’elle voit les metriques chaque jour. Elle livre plus vite parce qu’il n’y a personne a attendre.

Ce que “autonome” signifie vraiment

Soyons clairs — autonome ne signifie pas anarchique. C’est la que beaucoup d’organisations se trompent. Elles lisent des articles sur les Spotify squads ou la liberte chez Netflix et pensent que la reponse est de supprimer toute structure. C’est la recette du chaos.

L’autonomie fonctionne quand elle est encadree. Chaque bateau rapide a besoin de trois choses :

Une mission claire. Pas une liste de fonctionnalites — un probleme a resoudre. “Reduire le temps de traitement des factures hors bon de commande de 40%” est une mission. “Construire le nouveau tableau de bord” est une instruction. La difference est enorme car la mission donne a l’equipe la marge pour trouver la meilleure solution, tandis que l’instruction la transforme en simple executant.

Des metriques claires. L’equipe doit savoir comment le succes est mesure, et ces metriques doivent etre dans sa zone de controle. Si une equipe est responsable d’un taux de conversion mais ne possede pas le parcours d’achat, on l’a vouee a l’echec.

Des limites claires. Ce qui est dans le perimetre, ce qui en est hors, quels sont les points non negociables (securite, conformite, charte graphique, contrats API avec les autres equipes). A l’interieur de ces limites — pleine liberte sur la maniere d’executer.

C’est la difference entre l’empowerment et l’abandon. L’empowerment, c’est donner une destination a une equipe et la laisser choisir l’itineraire. L’abandon, c’est la pousser dehors sans carte.

Le maitre de port, pas le capitaine

Quand on est CTO ou CPTO et qu’on dirige une flotte de bateaux rapides, son role change fondamentalement. On ne barre pas chaque bateau. On est le maitre de port.

Cela signifie trois choses en pratique. Premierement : fixer la direction — s’assurer que la mission de chaque equipe s’inscrit dans une strategie d’entreprise coherente. Les bateaux doivent naviguer grosso modo dans la meme direction, meme s’ils prennent des routes differentes. Deuxiemement : eviter les collisions — s’assurer que les equipes ne dupliquent pas le travail, ne construisent pas des systemes incompatibles, ne prennent pas de decisions architecturales qui causeront des cauchemars dans deux ans. C’est la qu’interviennent les equipes plateforme, les standards partages et une gouvernance architecturale legere. Troisiemement : degager le chenal — supprimer les obstacles organisationnels, se battre pour les ressources, proteger les equipes du bruit de l’entreprise pour qu’elles puissent se concentrer sur leur mission.

Ce qu’on ne fait explicitement pas, c’est dire aux equipes comment construire les choses. Des l’instant ou l’on commence a dicter les details d’implementation a une equipe d’ingenieurs competents, on a fait rebasculer le modele vers une hierarchie command-and-control avec des etapes supplementaires.

Le lien avec le Product Operating Model

Ce n’est pas seulement mon opinion forgee par l’experience — c’est soutenu par certaines des meilleures reflexions en gestion de produit. Le travail de Marty Cagan sur les equipes produit empowered, notamment dans Empowered et Transformed, expose le meme argument fondamental : les meilleures entreprises produit fonctionnent avec des equipes empowered, pas des feature teams.

Une feature team recoit une roadmap d’outputs et les livre. Une equipe empowered recoit un ensemble de problemes et de resultats attendus et trouve la meilleure facon de les resoudre. La flotte de bateaux rapides est la structure organisationnelle qui rend les equipes empowered possibles. On ne peut pas avoir d’equipes empowered a l’interieur d’un grand navire, parce que les dependances et les chaines d’approbation detruisent l’autonomie que l’empowerment requiert.

Un modele issu du travail de Cagan que j’ai applique avec succes dans plusieurs entreprises est le Product Discovery Team — un trio compose d’un Product Designer, d’un Product Owner et d’un Senior Engineer. Cette petite equipe travaille directement avec les clients pour comprendre leurs vrais problemes et prototyper rapidement des solutions. C’est une maniere extremement agile, orientee client et rapide de decouvrir ce qu’il faut construire. J’ai tellement apprecie cette approche que j’en ai fait le standard dans chaque organisation que j’ai dirigee.

C’est la que ca devient vraiment interessant. Avec les gains de productivite apportes par les outils GenAI comme Claude Code — ou un ingenieur competent peut construire un prototype fonctionnel en heures plutot qu’en semaines — la frontiere entre discovery et delivery s’estompe. Un Product Discovery Team peut desormais decouvrir le probleme ET construire une solution fonctionnelle dans le meme sprint. Cela signifie que ce qui etait auparavant un Product Delivery Team de 5 a 8 personnes peut de plus en plus ressembler a ce qui etait un Discovery Team de trois personnes. Le bateau rapide vient de devenir encore plus rapide et plus petit. Je crois que c’est la direction que prennent les organisations de developpement produit : des flottes a l’echelle de ces bateaux rapides lean et capables de discovery, dont chacun peut passer du probleme client a la solution livree a un rythme inimaginable il y a encore deux ans.

Les compromis

Je serais malhonnete si je pretendais que ce modele n’a aucun cout. Il en a absolument.

On perd un peu de coherence. Quand les equipes ont la liberte de choisir leurs propres approches, elles le feront. Une equipe utilise React, une autre Vue. Une equipe redige une documentation exhaustive, une autre livre vite et itere. Il faut decider quelles incoherences comptent (contrats API, pratiques de securite, formats de donnees) et lesquelles on peut accepter (choix d’outillage interne, style de code).

On a besoin d’un recrutement plus exigeant. Le modele du bateau rapide ne fonctionne pas avec des personnes qui ont besoin qu’on leur dise quoi faire chaque jour. Il faut des ingenieurs autonomes, des product managers capables de penser strategiquement, des designers capables de prendre des decisions sans attendre un comite. Cela releve considerablement la barre du recrutement.

Il faut tolerer des approches differentes. Deux equipes resoudront des problemes similaires de manieres differentes. L’instinct en tant que dirigeant sera de standardiser. Il faut y resister — sauf s’il existe une veritable raison technique de converger. La standardisation prematuree n’est que du controle centralise sous un autre deguisement.

La communication entre les bateaux demande un effort intentionnel. Les canaux de communication naturels au sein d’une petite equipe sont excellents, mais la communication inter-equipes ne se fait pas toute seule. Il faut des rituels — revues d’architecture, demo days, documentation partagee — pour maintenir la coherence de la flotte.

Comment y arriver

Si l’on dirige actuellement un grand navire et que l’on souhaite passer a une flotte, il ne faut pas essayer de tout restructurer en une fois. C’est le meilleur moyen de couler le navire avant que les bateaux ne soient prets.

Commencer par une equipe. Choisir un domaine relativement autonome, le confier a ses meilleurs elements, leur donner une mission claire et une veritable autonomie. Les laisser prouver le modele. Cette premiere equipe rencontrera des problemes — limites floues, capacites plateforme manquantes, resistance du reste de l’organisation. Tant mieux. Chacun de ces problemes est une lecon qui rendra la prochaine equipe plus facile a lancer.

Construire la couche plateforme. A mesure que l’on lance de nouveaux bateaux, on trouvera des besoins communs — CI/CD, observabilite, authentification, modeles de donnees partages. Investir dans une equipe plateforme legere dont la mission est de rendre les bateaux rapides encore plus rapides, pas de jouer les gardiens ou d’imposer des processus.

Changer la facon de mesurer. Arreter de mesurer l’output (fonctionnalites livrees, story points consommes) et commencer a mesurer les outcomes (impact client, metriques business). C’est de loin le changement culturel le plus difficile, et il est non negociable. Si l’on continue a recompenser l’output, les equipes optimiseront pour livrer des choses plutot que pour resoudre des problemes.

Etre patient. La transformation prend 12 a 18 mois pour vraiment s’ancrer. Les premiers mois sembleront plus lents, le temps que les equipes trouvent leurs reperes et gagnent en confiance. Les dirigeants deviendront nerveux et voudront reprendre les renes. Il ne faut pas ceder. Les rendements composes d’une veritable autonomie d’equipe prennent du temps a se materialiser, mais quand ils arrivent, la difference en termes de vitesse et de qualite est transformative.

J’ai vu ce modele fonctionner dans des startups early-stage et dans des entreprises avec des centaines d’ingenieurs. L’echelle change, les principes non. Donnez a de petites equipes une vraie responsabilite, ecartez-vous de leur chemin et regardez ce qui se passe. A chaque fois, elles depasseront le grand navire.