La règle des « deux pizzas » — petit groupe autonome capable d’être nourri par deux pizzas — perd de sa force dans les entreprises technologiques et au-delà. Entre l’essor de l’IA, la complexité réglementaire et la montée des plateformes internes, responsables et ingénieurs revoient la taille et la composition des équipes pour concilier rapidité, sécurité et montée en charge.
Pourquoi le débat revient au premier plan
La formule, longtemps célébrée pour sa promesse d’agilité, bute aujourd’hui sur des réalités nouvelles. Les projets d’IA exigent des compétences croisées (données, infrastructure, sécurité, conformité), et la multiplication des dépendances techniques rend la coordination plus coûteuse. Parallèlement, la pression sur les coûts pousse certaines organisations à mutualiser des fonctions plutôt qu’à dupliquer des petites équipes.
Les responsables produits et les CTO évoquent aussi un autre facteur : la gestion des risques. Quand une fonctionnalité touche des données sensibles ou des opérations critiques, la gouvernance nécessite souvent plus d’acteurs au cycle de décision — ce qui dilue l’idée même d’une micro-structure isolée.
Points de vue divergents dans la tech
Certains dirigeants plaident pour conserver des équipes compactes, arguant qu’elles favorisent la créativité, raccourcissent les boucles de décision et limitent le bruit organisationnel. D’autres estiment qu’un nombre légèrement supérieur de membres, ou des équipes « en couches », est nécessaire pour couvrir l’éventail de responsabilités actuelles : conformité, fiabilité, observation, support client.
Les grandes plateformes — où la décentralisation rencontre des besoins communs — expérimentent des modèles hybrides : petites équipes produit qui s’appuient sur des équipes plateformes transverses. L’objectif est d’éviter l’accumulation de tâches techniques non différenciantes au sein des squads tout en gardant leur autonomie.
Conséquences concrètes pour les entreprises et les salariés
La redéfinition de la taille d’équipe change plusieurs choses au quotidien :
– Les trajectoires de carrière : les ingénieurs peuvent être invités à se spécialiser (fiabilité, ML Ops, sécurité) plutôt qu’à rester généralistes.
– La planification des projets : davantage de phases d’intégration et de tests multiplient les points de synchronisation.
– La gouvernance produit : renforcement des revues inter-équipes et des contrats de service entre équipes.
– Les coûts fixes : centraliser des compétences réduit les redondances mais augmente la nécessité d’un management inter-équipes efficace.
Comment s’adaptent les méthodes
Plutôt que d’imposer une taille fixe, plusieurs organisations adoptent des règles pragmatiques basées sur la fonction du groupe et la nature du travail. Quelques tendances observables :
- Segmentation entre équipes « produit » et équipes « plateforme » pour déléguer l’infrastructure et l’observabilité.
- Création de « pods » temporaires pour les gros chantiers transverses, puis dissolution une fois le livrable atteint.
- Renforcement des rituels de coordination (revues d’architecture, intégrations continues multi-équipes) plutôt que multiplication des réunions opérationnelles.
Règles pratiques pour décider de la taille d’une équipe
Il n’existe pas de formule universelle, mais des critères opérationnels aident à trancher :
Évaluez la nature du produit : hautement couplé aux systèmes centraux ou indépendant ? Plus il est couplé, plus la nécessité d’interfaces formelles augmente.
Mesurez le coût de coordination : si les points de friction (intégrations, approvals, incidents) augmentent, la solution peut être soit réduire les dépendances, soit ajouter des rôles transverses.
Considérez la criticité : produits impactant la conformité ou la sécurité demandent des instances de revue plus larges.
Ce que les managers peuvent tester dès maintenant
- Former une équipe-produit réduite pour prototyper, appuyée par une équipe plateforme dédiée — mesurer délai et qualité.
- Documenter et chiffrer les points d’intégration entre équipes pour identifier où la coordination pèse le plus.
- Mettre en place des « contrats de service » clairs entre équipes (SLA, ownership) plutôt que compter sur la seule confiance informelle.
- Expérimenter des pods temporaires pour projets IA afin d’éviter la multiplication permanente de petites équipes.
Perspectives : ni tout petit, ni indéfiniment grand
La leçon qui se dégage aujourd’hui est pragmatique : la rigidité d’une règle unique cède la place à une approche contextuelle. Les petites équipes restent puissantes pour l’innovation rapide, mais elles ont besoin d’un écosystème — plateformes, gouvernance, processus — pour évoluer à l’échelle. À mesure que les projets se complexifient, la question n’est plus seulement « combien de personnes ? » mais « quelles interactions et quels services partagés garantissent rapidité et fiabilité ? ».
Pour les dirigeants, la priorité immédiate est claire : revoir la cartographie des dépendances et tester des configurations hybrides avant d’imposer une nouvelle norme organisationnelle.