Depuis une quinzaine d’années, les pratiques organisationnelles des grandes entreprises technologiques exercent une fascination considérable sur le monde de la gestion de projet. Google, Amazon, Spotify et Netflix sont régulièrement cités comme des modèles à suivre dans les conférences, les formations et les articles spécialisés. Le problème est que la plupart des organisations qui tentent de reproduire ces pratiques n’obtiennent pas les résultats escomptés, et ce pour des raisons qui méritent d’être examinées.
Le syndrome du cargo cult organisationnel
Le terme “cargo cult” (culte du cargo) désigne un phénomène observé dans le Pacifique Sud après la Seconde Guerre mondiale: des populations locales construisaient des pistes d’atterrissage en bambou et des tours de contrôle en paille, espérant que ces imitations feraient revenir les avions chargés de marchandises. En gestion de projet, le parallèle est saisissant: adopter les formes visibles d’une pratique sans en comprendre les conditions de fonctionnement.
Le cas le plus emblématique est celui du “modèle Spotify”. En 2012, Henrik Kniberg a publié un document décrivant comment Spotify organisait ses équipes en “squads” (équipes autonomes de six à douze personnes), regroupées en “tribus”, avec des “chapitres” (communautés de pratique par discipline) et des “guildes” (groupes d’intérêt transversaux). Ce document décrivait une photo à un instant donné d’une organisation en évolution constante. Pourtant, des centaines d’entreprises l’ont adopté comme un organigramme figé, renommant leurs départements en “tribus” et leurs équipes en “squads” sans modifier les structures de pouvoir, les processus de décision ni la culture managériale. Spotify lui-même a reconnu ne plus appliquer ce modèle tel qu’il avait été décrit.
Le résultat est typique du cargo cult: on a les étiquettes mais pas les effets. Les équipes portent de nouveaux noms sans gagner en autonomie, et les managers ont de nouveaux titres sans changer leur manière de piloter.
Pourquoi la transplantation directe échoue
La raison pour laquelle copier une pratique du Big Tech produit rarement les mêmes résultats tient à trois facteurs que l’on sous-estime systématiquement.
Le contexte culturel est invisible
Quand Amazon applique sa règle des “deux pizzas” (aucune équipe ne doit être si grande que deux pizzas ne suffiraient pas à la nourrir, soit cinq à huit personnes), cette règle s’inscrit dans une culture de “single-threaded ownership” (propriété exclusive d’un périmètre) où chaque équipe dispose d’une autorité réelle sur ses décisions techniques et produit. Dans une organisation où les décisions remontent systématiquement à la hiérarchie, réduire la taille des équipes ne change rien si le pouvoir de décision reste centralisé.
La maturité organisationnelle diffère
Comme le souligne Gergely Orosz dans son analyse des pratiques de gestion de projet dans le Big Tech, les géants du web n’utilisent généralement pas Scrum. Leurs équipes fonctionnent avec des approches légères et adaptées, fondées sur la confiance et l’autonomie. Ce n’est pas que Scrum soit inadapté en soi: c’est qu’à leur niveau de maturité, les cérémonies formelles répondent à des problèmes qu’ils ont déjà résolus autrement. Pour une organisation en phase d’apprentissage, les frameworks structurés comme HERMES, PRINCE2 ou Scrum apportent un cadre nécessaire. Supprimer ce cadre en imitant le Big Tech revient à retirer l’échafaudage avant que la structure ne tienne seule.
Les conditions préalables sont ignorées
Le “Project Aristotle” de Google a identifié la sécurité psychologique (la conviction que l’on peut prendre des risques interpersonnels sans être puni) comme premier facteur de performance des équipes. La documentation re:Work de Google détaille ce résultat. Mais instaurer cette sécurité psychologique suppose un engagement managérial réel et durable. Si un dirigeant décrète que “l’erreur est autorisée” tout en sanctionnant le premier collaborateur qui signale un problème, la pratique est morte avant d’avoir commencé.
Ce qui est réellement transférable
Si la copie directe échoue, certains principes sous-jacents aux pratiques du Big Tech restent universels. Ce ne sont pas des méthodes à appliquer mais des questions à se poser.
La clarté des responsabilités
Le principe d’Amazon n’est pas “faites des petites équipes”, c’est “assurez-vous que chaque périmètre a un propriétaire identifié qui a le pouvoir de décider”. Un chef de projet peut appliquer cette logique dès à présent en vérifiant que chaque lot de travail, chaque livrable et chaque décision clé a un responsable unique et nommé, pas un comité ni un “groupe de travail”.
L’apprentissage structuré après les échecs
Le “blameless postmortem” (retour d’expérience sans recherche de faute), formalisé par les équipes SRE de Google et décrit en détail dans le livre SRE, repose sur un principe qui vient de l’aviation: on apprend davantage d’un système qui présume la bonne foi que d’un système qui cherche des coupables. La mécanique est simple: après un incident, documenter la chronologie, les causes et les actions correctives en excluant explicitement toute attribution de faute individuelle. Ce format peut être introduit dans n’importe quel projet, quel que soit le secteur.
La remise en question des rituels
La question la plus utile que pose l’exemple des géants du web n’est pas “quels rituels adopter?” mais “quels rituels ai-je conservés par habitude plutôt que par nécessité?”. Un comité de pilotage mensuel qui ne produit aucune décision, un rapport d’avancement que personne ne lit, une réunion de synchronisation où chacun récite un statut sans que personne n’interagisse: autant de pratiques qui persistent par inertie. Les identifier et les remettre en question est un exercice qui ne coûte rien et qui libère du temps pour ce qui compte.
L’erreur serait de tout rejeter
La tentation inverse du cargo cult est le rejet complet: décréter que les pratiques du Big Tech ne s’appliquent pas “chez nous” parce que le contexte est différent, une attitude tout aussi improductive que la copie aveugle. Le contexte est effectivement différent, mais les problèmes humains que ces pratiques adressent, comme la dilution de la responsabilité, la peur de l’erreur ou l’accumulation de processus inutiles, sont universels. La question pertinente n’est pas “comment faire comme Google?” mais “quel problème Google a-t-il résolu, et ai-je le même problème?”.