Imaginez la scène : une salle de réunion, seize chaises, seize personnes, et un projet qui n'avance pas. Chacun a un avis, personne n'a la main. À la fin de l'heure, on a décidé de se redonner rendez-vous. C'est exactement le type de réunion que Jeff Bezos aurait voulu rendre impossible. Sa parade tient dans une image de cantine : si deux pizzas ne suffisent pas à nourrir une équipe, c'est que cette équipe est trop grande.

Ce que dit vraiment la règle

La règle des deux pizzas énonce un principe volontairement trivial : aucune équipe de travail ne devrait compter plus de membres que ce que deux pizzas peuvent rassasier. En pratique, cela plafonne les équipes autour de cinq à huit personnes.

Le nombre de pizzas est une astuce mnémotechnique, pas une science. Ce qui compte, c'est ce que la contrainte force : une équipe petite est une équipe où tout le monde tient dans une même conversation, où l'on sait qui fait quoi sans organigramme, et où la responsabilité ne peut pas se diluer. Chez Amazon, cette petite cellule est devenue le grain élémentaire de l'organisation — pas un cas particulier, mais l'unité de base.

Le contresens classique consiste à croire qu'il s'agit d'économiser du personnel. Ce n'est pas une règle d'austérité, c'est une règle de bande passante. On ne cherche pas à faire plus avec moins de gens ; on cherche à ce que les gens qui travaillent ensemble puissent réellement penser ensemble.

D'où ça vient : l'obsession de l'autonomie

L'anecdote fondatrice est restée célèbre parce qu'elle prend le mythe managérial à rebrousse-poil. Dans une entreprise qui grossissait à toute vitesse, l'instinct collectif poussait à faire communiquer davantage les équipes : plus de réunions transverses, plus de synchronisation, plus de « alignement ». Bezos aurait soutenu l'inverse. Le problème d'Amazon, selon lui, n'était pas un déficit de communication interne — c'était son excès. Il fallait moins de coordination, pas plus.

D'où deux idées jumelles. La première : des équipes assez petites pour rester agiles. La seconde, moins connue mais décisive : chaque équipe doit être autonome, capable de livrer sa partie sans quémander l'accord de dix autres services. Une petite équipe qui doit demander la permission à tout le monde n'est pas petite, elle est simplement à l'étroit.

Cette exigence d'autonomie a une conséquence architecturale directe. Pour que des cellules indépendantes cohabitent, il faut que leurs briques logicielles se parlent par des interfaces propres plutôt que de partager un magma commun où chacun marche sur les pieds de l'autre. La règle des deux pizzas n'est pas qu'un principe RH : c'est aussi, en filigrane, l'origine culturelle de la manière dont Amazon a découplé ses systèmes.

Pourquoi ça compte : la tyrannie des canaux

Derrière l'image conviviale se cache une loi mathématique implacable. Dans un groupe de n personnes, le nombre de liens possibles entre deux membres est de n(n−1)/2. Traduction : quand vous ajoutez des gens à une équipe, le travail utile croît au mieux linéairement, mais le nombre de connexions à entretenir explose de façon quadratique.

• Une équipe de 5 personnes : dix relations à tenir.
• Une équipe de 10 personnes : quarante-cinq relations.
• Une équipe de 20 personnes : cent quatre-vingt-dix relations.

On double l'effectif, on quadruple la friction. Chaque nouvelle recrue passée un certain seuil ne fait plus avancer le projet : elle passe son temps à se tenir informée. C'est le cousin organisationnel de la fameuse loi de Brooks — ajouter des gens à un projet en retard le retarde encore davantage, parce que le coût d'intégration dépasse l'apport.

La petite équipe échappe à cette malédiction pour une raison simple : à cinq, tout le monde peut tenir à jour un modèle mental partagé du projet sans réunion formelle. À vingt, c'est physiquement impossible, alors on invente des rituels — points de synchronisation, comptes rendus, chefs de projet — dont la seule fonction est de compenser une taille que l'on aurait dû éviter.

Il y a aussi un effet psychologique, cousin de la paresse sociale : dans un grand groupe, chacun se sent moins indispensable et fournit inconsciemment moins d'effort. Dans une équipe de six, si vous ne faites pas votre part, tout le monde le voit. La petite taille rend la responsabilité visible.

Comment l'appliquer sans la trahir

Réduire ses équipes à six personnes ne suffit pas ; on peut très bien créer six mini-équipes qui restent totalement dépendantes les unes des autres, et n'avoir gagné que du morcellement. La règle ne vaut que couplée à son revers de médaille : l'autonomie réelle. Quelques garde-fous concrets.

• Un périmètre qui se possède. Chaque équipe doit être « propriétaire » d'un morceau clair du produit, du début à la fin, pas d'une tranche horizontale qui dépend de dix autres pour exister.
• Un responsable unique. Amazon a formalisé plus tard la figure du single-threaded leader — une personne dont c'est le seul et unique sujet. Quand un dossier est le douzième de quelqu'un, il n'avance pas.
• Le test de la réunion. Si votre équipe ne peut pas prendre une décision importante sans convoquer trois autres services, elle n'est pas autonome — elle est juste petite.
• Des interfaces, pas des tunnels. Ce que l'équipe livre aux autres doit être défini par un contrat clair, pour qu'elle puisse travailler sans négocier en permanence.

Appliquée hors de la tech, la règle éclaire beaucoup de dysfonctionnements ordinaires. Le comité de pilotage à quatorze, la « task force » transverse où personne ne décide, le groupe de travail qui accouche d'un énième compte rendu : tous violent la même loi. À chaque fois, la question à poser n'est pas « qui manque-t-il autour de la table ? » mais « qui est en trop ? ».

Ses limites et son revers

La règle n'est pas un dogme universel. Certaines tâches sont irréductiblement grosses et demandent des dizaines de mains coordonnées — construire un avion ne se découpe pas en cellules de six qui s'ignorent. La bonne lecture n'est pas « toute équipe doit faire six personnes », mais « les unités de décision et de livraison doivent rester petites », quitte à en empiler beaucoup.

Le vrai danger de la petite équipe, c'est la fragmentation en silos. Multipliez les cellules autonomes sans vision d'ensemble, et vous obtenez une entreprise où trois équipes construisent trois fois le même outil sans le savoir. L'autonomie sans architecture commune produit de la redondance et de l'incohérence. La règle des deux pizzas doit donc toujours s'accompagner de sa contrepartie : des standards partagés, des interfaces communes, une direction qui tient le cap au-dessus des cellules.

Reste que, comme heuristique, elle est d'une redoutable efficacité. Face à un projet qui patine, avant de recruter, de réunir ou de « mieux coordonner », commencez par la question de Bezos. Combien de pizzas pour nourrir tout ce monde ? Si la réponse dépasse deux, vous avez probablement identifié le problème — et il ne se réglera pas en ajoutant une troisième pizza.

À retenir

• Le travail utile d'une équipe croît linéairement, mais la friction de coordination croît au carré : doubler l'effectif quadruple les canaux à entretenir.
• La règle n'est pas une consigne d'austérité mais une exigence d'autonomie : une petite équipe qui doit tout faire valider n'est pas petite, elle est à l'étroit.
• Face à un projet qui patine, la bonne question n'est jamais qui manque autour de la table, mais qui est en trop.