Le modèle Spotify : Squads, Tribes et Guilds expliqués

En 2012, deux coachs agiles de Spotify ont publié un court livre blanc décrivant la façon dont l’entreprise organisait ses équipes d’ingénierie. Ce n’était pas un manifeste. Ce n’était pas une méthodologie. C’était un instantané, la description de la manière dont une entreprise se trouvait fonctionner à un moment précis. Les auteurs le disaient explicitement.

En quelques années, des milliers d’organisations l’avaient adopté comme un cadre prescriptif. Elles ont rebaptisé leurs équipes « squads », les ont regroupées en « tribes », ont créé des « chapters » et des « guilds », et ont attendu que les résultats suivent. Beaucoup ont découvert que copier une structure organisationnelle sans comprendre la culture qui la porte ne produit guère plus qu’un vocabulaire neuf pour de vieux problèmes.

L’ironie va plus loin : Spotify est passé à autre chose. Ses propres ingénieur·es ont reconnu publiquement que le modèle décrit dans le livre blanc ne correspond plus à la façon dont l’entreprise travaille. Le « modèle Spotify » n’en reste pas moins l’une des approches les plus discutées du passage à l’échelle des organisations agiles, précisément parce que les idées qui le fondent répondent à des problèmes réels que rencontre toute entreprise en croissance.

Ce guide explique ce que le modèle Spotify décrivait réellement, comment fonctionnent ses quatre briques de base, pourquoi il s’est autant répandu, où il se fissure et comment en adapter les principes sans tomber dans les pièges les plus courants.

Qu’est-ce que le modèle Spotify ?

Le modèle Spotify trouve son origine dans un livre blanc de 2012 intitulé « Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds », signé Henrik Kniberg et Anders Ivarsson. Kniberg était coach agile auprès de Spotify ; Ivarsson était le coach organisationnel de l’entreprise. Le document, accompagné d’une série vidéo en deux parties, décrivait la manière dont Spotify organisait alors sa trentaine d’équipes d’ingénierie, soit environ 250 personnes réparties sur trois villes.

L’essentiel, à propos de ce livre blanc, tient à ce qu’il n’était pas. Ce n’était pas un cadre à adopter. Ce n’était pas un ensemble de pratiques à suivre. Ses auteurs ont pris soin de décrire ce que Spotify faisait à ce moment précis, et non ce que les autres entreprises devraient faire. Kniberg lui-même a maintes fois insisté sur cette distinction : ce qu’ils décrivaient, c’était la façon de travailler de Spotify, pas un modèle universel.

Le livre blanc décrivait un ensemble de structures organisationnelles (squads, tribes, chapters et guilds) conçues pour résoudre un problème précis : comment conserver la vitesse et l’autonomie des petites équipes tout en passant à des centaines d’ingénieur·es travaillant sur un même produit. C’était la tension entre autonomie et alignement traduite en structure.

La suite était prévisible. Le livre blanc était clair, bien illustré, et traitait d’un problème que rencontraient des centaines d’entreprises tech en croissance. Il s’est diffusé à toute vitesse dans la communauté agile. Les conférences y faisaient référence. Les articles de blog l’expliquaient. Les cabinets de conseil l’ont mis en boîte. En quelques années, « le modèle Spotify » était devenu un patron organisationnel reconnu, adopté, adapté et parfois imposé tel quel à des organisations dont la culture, la taille et les défis n’avaient rien à voir.

L’écart entre ce que Kniberg et Ivarsson décrivaient et ce que le secteur en a retenu constitue la tension centrale de l’histoire du modèle Spotify : un instantané descriptif traité comme un plan prescriptif.

Les quatre briques de base

Le modèle Spotify répartit les personnes entre quatre structures qui se chevauchent, chacune conçue pour résoudre un problème de coordination différent. Comprendre comment ces quatre pièces s’articulent est essentiel : ce ne sont pas des départements indépendants, mais des strates entrecroisées d’une même matrice.

Squads

La squad est l’unité fondamentale. C’est une petite équipe pluridisciplinaire de 6 à 12 personnes, responsable de bout en bout d’un périmètre fonctionnel, d’un composant produit ou d’un parcours utilisateur·rice. Chaque squad fonctionne comme une mini-start-up : elle a sa propre mission, décide de sa façon de travailler et pilote son propre backlog.

Une squad réunit en principe toutes les compétences nécessaires pour concevoir, développer, tester et livrer son travail : des développeur·euses, une personne au design, un·e product owner et un·e spécialiste QA. Elle n’a pas besoin de passer le relais à une autre équipe pour aboutir. C’est voulu : la composition pluridisciplinaire supprime les passages de relais, réduit les dépendances et donne à la squad la maîtrise de sa livraison.

Le Product Owner définit ce que la squad construit et dans quel ordre. La squad, elle, décide comment le construire. Le modèle Spotify ne prescrit aucun rôle formel de Scrum Master, même si beaucoup de squads en désignent un. Chaque squad choisit sa méthodologie agile : Scrum, Kanban, un hybride ou tout autre chose.

L’autonomie est le trait déterminant. On fait confiance aux squads pour prendre leurs décisions techniques, gérer leur travail et livrer de façon indépendante. Cette confiance n’est pas inconditionnelle (elle suppose un alignement avec la direction produit d’ensemble), mais le réglage par défaut reste l’autonomie, la coordination émergeant de la culture et d’objectifs partagés plutôt que d’un contrôle descendant.

Tribes

Une tribe rassemble des squads qui travaillent sur un même domaine produit. Si les squads sont les mini-start-up, la tribe est l’incubateur. Une tribe compte généralement entre 40 et 150 personnes. La borne haute n’a rien d’arbitraire : elle s’appuie sur les travaux de Robin Dunbar, selon lesquels un être humain peut entretenir des relations sociales stables avec environ 150 individus. Au-delà, la coordination fondée sur la confiance commence à se déliter et des processus formalisés deviennent nécessaires.

Chaque tribe a un Tribe Lead, chargé de créer un environnement productif pour les squads. Le Tribe Lead ne dirige pas les squads une à une et ne décide pas à leur place. Son travail consiste à lever les obstacles, à faciliter la coordination entre squads et à assurer l’alignement avec la direction générale de l’organisation.

Les tribes créent une proximité physique et sociale. Dans le modèle Spotify d’origine, les squads d’une même tribe étaient installées ensemble, partageaient des espaces communs et se retrouvaient régulièrement au grand complet. Cette proximité n’a rien de fortuit : c’est un mécanisme délibéré de coordination informelle. Quand les gens travaillent au même endroit, ils surprennent des conversations, se croisent à la machine à café et partagent du contexte sans avoir besoin de réunions formelles.

La frontière de la tribe délimite un espace de coordination. Les squads d’une même tribe se coordonnent souvent et de façon informelle. Celles de tribes différentes se coordonnent plus rarement et plus délibérément. D’où une tension naturelle : des frontières de tribe bien tracées réduisent les frictions internes ; mal tracées, elles fabriquent des silos.

Chapters

Les chapters règlent le problème de compétence que créent les squads. Dès lors qu’on organise les personnes en squads pluridisciplinaires, les spécialistes se dispersent. Vos développeur·euses iOS se retrouvent éparpillé·es dans dix squads différentes, chacune sur une fonctionnalité différente. Qui veille à ce qu’ils et elles appliquent des standards techniques cohérents ? Qui les accompagne dans leur métier ? Qui s’occupe de l’évolution de carrière et des discussions salariales ?

Un chapter réunit des personnes de même spécialité, appartenant à la même tribe mais à des squads différentes. Tous les développeur·euses backend d’une tribe forment un chapter. Toutes les personnes au design en forment un autre. Toutes celles qui travaillent aux tests, un troisième. Chaque chapter a un Chapter Lead, et c’est là que le modèle introduit sa tension structurelle la plus lourde.

Le Chapter Lead est le supérieur hiérarchique formel des membres du chapter. Il ou elle mène les entretiens d’évaluation, suit l’évolution des carrières et conduit les discussions salariales. Mais le Chapter Lead est aussi membre actif d’une squad, où il ou elle met les mains dans le cambouis en parallèle de ses responsabilités managériales. Ce double rôle est délibéré : il maintient le Chapter Lead au contact de la réalité quotidienne du travail. Il signifie aussi qu’il ou elle assume deux métiers.

Les chapters se réunissent régulièrement pour partager des savoirs, s’accorder sur les pratiques techniques, discuter des choix d’outillage et traiter les sujets qui dépassent une seule squad. C’est par eux que passent la cohérence technique et le développement professionnel par-delà les frontières des squads.

Guilds

Les guilds étendent la notion de communauté de pratique au-delà des frontières des tribes. Une guild est un groupe volontaire, transverse aux tribes, réuni autour d’un intérêt, d’une compétence ou d’un domaine de connaissance. Contrairement aux chapters, les guilds sont ouvertes à tout le monde. Nul besoin d’être développeur·euse backend pour rejoindre la guild backend : il suffit d’être intéressé·e.

Chaque guild a un Guild Coordinator, qui anime les activités (rencontres, ateliers, canaux partagés, travaux de documentation) sans détenir aucune autorité formelle. L’appartenance est volontaire, la participation libre, et la guild n’existe qu’aussi longtemps qu’elle crée de la valeur pour ses membres.

Les guilds sont l’antidote aux silos tribaux. Quand les tribes sont vastes et refermées sur elles-mêmes, la connaissance risque de rester prisonnière de leurs frontières. Les guilds ouvrent des canaux de pollinisation croisée : une guild dédiée aux tests diffuse les pratiques d’automatisation dans toutes les tribes ; une guild développement web harmonise les standards frontend à l’échelle de l’entreprise ; une guild leadership fait circuler les pratiques managériales dans toute l’organisation.

Comment les quatre structures s’entrecroisent

Les quatre structures forment une matrice, mais une matrice dotée d’un axe principal clairement identifié. La squad est l’unité organisationnelle première. C’est là que le travail se fait, là que les personnes passent l’essentiel de leur temps, là que se prennent les décisions du quotidien.

Les tribes regroupent les squads pour la coordination. Les chapters regroupent les spécialistes pour la compétence. Les guilds regroupent les passionné·es pour le partage de connaissance.

Chaque ingénieur·e appartient à exactement une squad et un chapter, et peut appartenir à une ou plusieurs guilds. Autrement dit, chaque personne relève de deux lignes de rattachement : sa squad (pour la livraison produit) et son chapter (pour le management des personnes et les standards techniques). C’est la version Spotify de l’organisation matricielle, pensée pour capter simultanément les bénéfices de l’expertise fonctionnelle et ceux de la livraison pluridisciplinaire.

Tribe A
├── Squad 1: [Designer, iOS Dev, Backend Dev, Tester, Product Owner]
├── Squad 2: [Designer, iOS Dev, Backend Dev, Android Dev, Product Owner]
├── Squad 3: [Designer, Backend Dev, Backend Dev, Tester, Product Owner]
│
├── Chapter: iOS Developers (couvre Squad 1 + Squad 2)
├── Chapter: Backend Developers (couvre toutes les squads)
├── Chapter: Designers (couvre toutes les squads)
└── Chapter: Testers (couvre Squad 1 + Squad 3)

Guild: Web Development (couvre Tribe A + Tribe B + Tribe C)
Guild: Testing Practices (couvre toutes les tribes)

Les principes qui sous-tendent le modèle

Les composants structurels (squads, tribes, chapters, guilds) forment la partie visible du modèle Spotify. Mais ce n’est pas ce qui l’a fait fonctionner chez Spotify. Ce qui l’a fait fonctionner, c’est un ensemble de principes culturels que la structure était censée soutenir. Copiez la structure sans ces principes et vous obtiendrez une hiérarchie déguisée en Spotify.

L’autonomie avec l’alignement

C’est la tension centrale autour de laquelle tout le modèle est bâti. Les squads sont autonomes : elles choisissent leurs méthodes, gèrent leur travail et prennent leurs décisions techniques. Mais elles ne sont pas indépendantes. Elles sont alignées sur une vision produit partagée et sur un socle commun de priorités stratégiques.

Kniberg en a fait un spectre. À une extrémité, alignement fort et autonomie forte : les dirigeant·es énoncent le problème à résoudre et son importance, les squads trouvent comment le résoudre. À l’autre, alignement faible et autonomie forte : les squads font ce qu’elles veulent, et il en résulte une collection d’efforts sans lien entre eux. L’objectif est de rester dans le quadrant alignement fort et autonomie forte, où les squads décident librement de leur façon de travailler tout en sachant précisément ce que l’organisation cherche à accomplir.

Cela suppose des dirigeant·es capables de formuler une direction sans dicter les solutions. Cela suppose des squads qui cherchent à comprendre la vue d’ensemble au lieu d’optimiser localement. Et cela suppose une transparence organisationnelle telle que les squads puissent s’aligner d’elles-mêmes, au lieu d’avoir à être alignées par des managers.

La culture plutôt que le processus

Le modèle Spotify privilégiait explicitement les normes culturelles sur les processus formalisés. Les règles restaient minimales. La confiance était le réglage par défaut. Le pari était le suivant : recruter de bonnes personnes, leur donner du contexte et leur faire confiance pour prendre des décisions raisonnables donne de meilleurs résultats qu’une documentation de processus détaillée.

Cela a fonctionné chez Spotify parce que l’entreprise avait beaucoup investi dans sa culture d’ingénierie. La sécurité psychologique, la communication ouverte et la tolérance à l’expérimentation n’étaient pas des slogans : c’étaient des comportements réellement pratiqués. C’est cette culture qui a façonné le modèle, et non l’inverse.

La confiance par défaut

Les squads bénéficiaient de la confiance a priori. Elles n’avaient pas à mériter leur autonomie par un historique de résultats, ni à justifier leurs décisions auprès du management. Le postulat organisationnel était qu’elles prendraient de bonnes décisions et que des erreurs occasionnelles constituaient un coût acceptable de la vitesse que procure l’autonomie.

C’est plus difficile à instaurer qu’il n’y paraît. La plupart des organisations fonctionnent sur le postulat inverse : la confiance se mérite et l’autonomie s’accorde par paliers. Basculer vers la confiance a priori demande aux dirigeant·es d’accepter que certaines squads prennent des décisions avec lesquelles ils et elles ne sont pas d’accord, et de n’intervenir que lorsque les conséquences sont sérieuses, non simplement parce qu’ils ou elles auraient choisi autrement.

La pollinisation croisée plutôt que les silos

Les chapters et les guilds existaient précisément pour prévenir l’effet de silo que peuvent produire des équipes autonomes. Quand les squads sont pleinement autonomes, elles risquent de résoudre le même problème de trois façons différentes, d’adopter des technologies incompatibles ou de développer des savoirs qui ne sortent jamais de la squad.

Le modèle y répondait par des recoupements structurels : les chapters pour l’alignement technique au sein d’une tribe, les guilds pour le partage de connaissance entre tribes. L’accent portait sur l’échange organique (pratiques partagées, participation volontaire, apprentissage mutuel) plutôt que sur des standards décrétés d’en haut.

L’amélioration continue plutôt que le suivi d’un manuel

Le modèle Spotify n’a jamais été figé. Le livre blanc décrivait un moment précis de l’évolution de l’entreprise. Spotify a continué de faire évoluer sa structure organisationnelle après sa publication. Le modèle lui-même devait être pris comme un point de départ pour une expérimentation continue, non comme une destination.

Ce principe est à la fois la plus grande force du modèle et la source de son détournement le plus fréquent. Si le modèle est une invitation à expérimenter, le copier à l’identique trahit déjà sa philosophie fondamentale.

Le modèle Spotify face aux autres cadres organisationnels

Le modèle Spotify s’inscrit dans un paysage plus large d’approches de la conception organisationnelle. Chacune traite des problèmes différents, joue sur un niveau de formalisme différent et convient à des contextes différents. La comparaison ci-dessous éclaire ce que le modèle Spotify offre, et n’offre pas, par rapport aux autres.

Dimension	Hiérarchie traditionnelle	Modèle Spotify	Holacratie	Sociocratie	RenDanHeYi	Beta Codex / Peach	DSO (Bayer)	SAFe	Buurtzorg
Structure d’autorité	Chaîne de commandement descendante	Autonomie de la squad dans l’alignement de la tribe	Rôles et cercles régis par une constitution	Cercles par consentement, avec double lien	Distribuée aux micro-entreprises	Décentralisée entre centre et périphérie	Distribuée à des équipes autonomes	Hiérarchique, avec des strates agiles	Équipes de quartier autogérées
Unité de base	Département ou division	Squad (6 à 12 personnes, pluridisciplinaire)	Cercle doté de rôles définis	Cercle avec double lien	Micro-entreprise (10 à 15 personnes)	Cellule autonome en périphérie	Équipe client ou produit (6 à 10 personnes)	Agile Release Train	Équipe autogérée (10 à 12 infirmier·ères)
Prise de décision	Validation par le manager	Autonomie au niveau de la squad	Processus de décision intégrative	Consentement (aucune objection argumentée)	Pilotée par le marché, autonomie de la ME	Fondée sur la maîtrise, en périphérie	95 % au niveau de l’équipe	PI Planning et décisions d’équipe	Consensus au niveau de l’équipe
Mécanisme de passage à l’échelle	Ajout de strates managériales	Tribes (150 personnes maximum environ), chapters, guilds	Cercles imbriqués	Cercles imbriqués avec double lien	Écosystèmes de micro-communautés	Cellules fédérées	Cycles de 90 jours, coaching VACC	ART, Solution Trains, portefeuille	Coaching régional et back-office
Modèle de leadership	Managers hiérarchiques	Tribe leads, chapter leads	Lead Links et Rep Links	Facilitateur·trices et délégué·es	« Chacun est son propre PDG »	Distribué, fondé sur la maîtrise	VACC (visionnaires, architectes, catalyseurs, coachs)	RTE, System Architect, Product Management	Coach (et non manager)
Formalisme	Élevé (politiques et procédures)	Faible à modéré (porté par la culture)	Très élevé (constitution écrite)	Modéré (fondé sur des principes)	Modéré (discipline de marché)	Faible (principes de réseau)	Modéré (VACC et cycles de 90 jours)	Très élevé (cadre SAFe)	Faible (fondé sur des principes)
Idéal pour	Environnements stables, forte conformité	Entreprises tech orientées produit, de 50 à 500 ingénieur·es	Les organisations qui veulent une gouvernance explicite	Les organisations qui privilégient des décisions inclusives	Les grands groupes en quête de vitesse entrepreneuriale	Les organisations tournées vers le marché qui veulent se décentraliser	Les grands groupes qui allègent leur bureaucratie	Les grands groupes qui passent la livraison agile à l’échelle	Les organisations de soin et de service
Échelle éprouvée	Toute échelle	De quelques centaines à quelques milliers	De quelques centaines à quelques milliers	De quelques centaines à quelques milliers	Plus de 80 000 personnes	Variable	Plus de 100 000 personnes (en cours)	Des dizaines de milliers	Plus de 15 000 professionnel·les

Les distinctions clés

Modèle Spotify et SAFe : SAFe (Scaled Agile Framework) est prescriptif là où le modèle Spotify est descriptif. SAFe fournit des cérémonies, des rôles et des événements de planification détaillés à chaque niveau de l’organisation. Le modèle Spotify fournit des concepts structurels et fait confiance aux équipes pour combler les détails. SAFe convient bien aux organisations qui ont besoin de rigueur procédurale et de traçabilité réglementaire. Le modèle Spotify convient mieux à celles qui ont une forte culture d’ingénierie et rejettent les processus lourds. Beaucoup d’organisations empruntent aux deux.

Modèle Spotify et holacratie : l’holacratie fournit une constitution de gouvernance formelle, avec des règles explicites sur la création des rôles, la prise de décision et le déroulement des réunions. Le modèle Spotify n’a pas de constitution : sa gouvernance est culturelle, pas procédurale. Les organisations qui veulent des processus de gouvernance clairs et documentés trouveront l’holacratie plus structurante. Celles qui préfèrent les normes culturelles aux règles formelles trouveront le modèle Spotify plus naturel.

Modèle Spotify et sociocratie : la sociocratie repose sur la décision par consentement et sur le double lien entre les niveaux de gouvernance. Le modèle Spotify ne prescrit aucun processus de décision : les squads décident de la façon dont elles décident. La sociocratie convient mieux aux organisations qui veulent une gouvernance structurée à tous les niveaux. Le modèle Spotify convient mieux aux contextes d’ingénierie produit, où la vitesse de livraison compte davantage que le formalisme de la gouvernance.

Modèle Spotify et RenDanHeYi : le RenDanHeYi de Haier pousse l’autonomie plus loin que le modèle Spotify. Chaque micro-entreprise assume l’intégralité de son compte de résultat et recrute sa propre équipe. Les squads de Spotify sont autonomes dans leur façon de travailler, mais pas dans la composition de leurs effectifs ni dans leur financement. Le RenDanHeYi est conçu pour des entreprises pilotées par le marché, où chaque unité est en lien direct avec les clients. Le modèle Spotify est conçu pour des organisations d’ingénierie produit, où les squads contribuent à un produit commun.

Modèle Spotify et Beta Codex : le Beta Codex se situe à un niveau d’abstraction plus élevé. Il énonce 12 lois sur la manière dont les organisations devraient être structurées, performer et s’adapter, sans prescrire de forme d’équipe particulière. Le modèle Spotify est plus concret : il définit des unités structurelles précises (squads, tribes, chapters, guilds), avec des tailles et des relations précises. Le Beta Codex peut englober une structure de type Spotify dans ses cellules périphériques, mais il traite du modèle organisationnel dans son ensemble, et pas seulement de la fonction d’ingénierie produit.

Modèle Spotify et DSO : le Dynamic Shared Ownership de Bayer partage avec le modèle Spotify l’accent mis sur les équipes autonomes, mais il y ajoute une cadence de planification structurée (les cycles de 90 jours) et un cadre de leadership explicite (VACC). Le DSO a été conçu dès l’origine pour l’échelle des grands groupes ; le modèle Spotify, lui, est né dans une organisation d’ingénierie de taille moyenne et rencontre des difficultés à plus grande échelle.

Pourquoi Spotify est passé à autre chose

Comprendre pourquoi Spotify a dépassé son propre modèle est un contexte indispensable à quiconque envisage de l’adopter. Le modèle était un instantané, et l’organisation qu’il décrivait a continué de changer.

La critique de Jeremiah Lee

En 2020, Jeremiah Lee, ancien salarié de Spotify, a publié une critique très relayée intitulée « Spotify’s Failed Squad Goals ». Il y soutenait que le modèle décrit dans le livre blanc n’avait pas fonctionné comme prévu, y compris chez Spotify. Ses observations principales :

• Des squads autonomes ont créé des problèmes de coordination. Quand chaque squad choisissait ses outils, ses architectures et ses approches de son côté, le résultat était la fragmentation : bases de code hétérogènes, efforts dupliqués et casse-tête d’intégration.
• La structure en chapters n’a pas tenu sa promesse. Les Chapter Leads étaient écartelés entre leurs responsabilités dans la squad et leur rôle de manager, et les réunions de chapter passaient souvent pour une formalité.
• Les frontières des tribes sont devenues des silos. Pensées pour concentrer la coordination, les tribes ont aussi dressé des murs. La collaboration entre tribes s’est révélée plus difficile que le modèle ne le prévoyait.
• La culture qui faisait tenir l’ensemble n’était pas transférable. Spotify avait une culture d’ingénierie particulière (confiance élevée, normes d’autonomie fortes, tolérance au désordre) qui avait façonné le modèle. D’autres entreprises ont adopté la structure sans cette culture et ont obtenu d’autres résultats.

La critique de Lee a fait mouche parce qu’elle mettait des mots sur ce que beaucoup d’entreprises avaient vécu : le modèle Spotify sonnait juste, mais ne sonnait plus pareil une fois transposé dans un autre contexte.

Le piège matriciel

Le rôle de Chapter Lead est l’élément structurellement le plus fragile du modèle. Un Chapter Lead est à la fois membre actif d’une squad, où il ou elle contribue à la livraison produit, et responsable hiérarchique de membres du chapter répartis dans plusieurs squads, chargé à ce titre de l’évolution de carrière, des retours sur la performance et des décisions salariales.

C’est un mi-temps dans chacune des deux directions, et la tension est prévisible. En période de rush avant la fin d’un sprint, le travail de la squad l’emporte et les obligations de chapter sont repoussées. En période d’entretiens annuels, les responsabilités managériales dévorent le temps promis à la squad. Les Chapter Leads qui penchent vers le management se coupent du code. Celles et ceux qui penchent vers la technique deviennent de piètres managers.

Résultat : bien souvent, un Chapter Lead qui ne fait bien ni l’un ni l’autre, non par manque de capacité, mais parce que le montage structurel exige deux usages contradictoires du temps d’une même personne.

Les silos tribaux

Si les tribes ont été dimensionnées autour de 150 personnes, c’est pour une raison ancrée dans la psychologie sociale. Mais la cohésion sociale que favorise le nombre de Dunbar à l’intérieur d’une tribe peut aussi installer une dynamique de « nous contre eux » entre tribes. Quand une tribe se suffit à elle-même, avec ses squads, ses priorités et son Tribe Lead, l’intérêt de collaborer avec les autres s’émousse.

Les guilds étaient censées combler cet écart, mais la participation y est volontaire. Dès que les échéances se resserrent, les activités de guild sont les premières sacrifiées. Sans investissement soutenu dans la coordination entre tribes, la frontière de la tribe devient un mur d’information.

Ce que fait Spotify aujourd’hui

Spotify n’a publié aucun modèle successeur avec la clarté du livre blanc de 2012. Ce que l’on sait, c’est que l’entreprise s’est orientée vers une structure plus souple et moins étiquetée. Le vocabulaire des squads et des tribes subsiste par endroits, mais il ne définit plus le cadre organisationnel. L’entreprise continue d’expérimenter sa façon d’organiser le travail, ce qui, ironie de l’histoire, est exactement ce que recommandait le livre blanc d’origine.

Où le modèle Spotify fonctionne (et où il échoue)

Là où il fonctionne

Les entreprises technologiques orientées produit, de 50 à 500 ingénieur·es. C’est son point d’équilibre idéal. Le modèle a été conçu pour une organisation d’ingénierie produit à peu près de cette taille, et ses mécanismes (autonomie de la squad, coordination au niveau de la tribe, alignement technique porté par les chapters) s’y transposent bien. Les entreprises qui construisent des produits logiciels comportant plusieurs domaines fonctionnels et des équipes pluridisciplinaires trouveront le modèle intuitif.

Les organisations à forte culture d’ingénierie. Le modèle repose sur des normes culturelles qui ne se décrètent pas : confiance, autonomie, sécurité psychologique et acceptation du droit à l’erreur. Les organisations où les ingénieur·es ont l’habitude de s’autodiriger et où l’encadrement pratique un leadership au service des équipes adopteront le modèle plus facilement.

Les entreprises prêtes à adapter plutôt qu’à copier. Les organisations qui réussissent avec le modèle Spotify sont celles qui le prennent pour un vocabulaire de départ, non pour un plan rigide. Elles en adoptent les concepts structurels, ajustent les détails à leur contexte et font évoluer le modèle à mesure qu’elles apprennent. ING, le groupe bancaire néerlandais, a adopté un modèle inspiré de Spotify resté célèbre, mais en l’adaptant fortement aux contraintes d’un secteur financier régulé.

Là où il achoppe

Les contextes non technologiques. Le modèle a été conçu pour le génie logiciel. Ses présupposés (équipes de livraison pluridisciplinaires, développement itératif, mises en production fréquentes, autonomie technique) ne se transposent pas proprement à l’industrie, à la logistique, à la santé ou à d’autres domaines où le travail est séquentiel, physique ou très réglementé. Rebaptiser « squad » une unité de soins ne la rend autonome en aucun sens utile.

Les organisations sans culture de l’autonomie. Adopter le modèle Spotify là où les décisions se prennent aujourd’hui au niveau des managers et où l’exécution se pilote d’en haut suppose une transformation culturelle que le modèle lui-même n’apporte pas. La structure présuppose la culture. Si celle-ci n’existe pas, la structure devient une façade : des squads de nom, du commandement et du contrôle en pratique.

Les secteurs très réglementés. Les exigences de conformité de la pharmacie, de la finance et de l’aéronautique imposent souvent des chaînes de validation documentées, des pistes d’audit et des processus standardisés. L’autonomie des squads dans le choix des outils, des approches et des architectures peut entrer en conflit avec des obligations réglementaires qui exigent cohérence et traçabilité.

Les très grandes organisations (plus de 1 000 ingénieur·es). Le modèle passe à l’échelle par les tribes, mais au-delà de 5 à 10 tribes, la coordination entre elles devient un défi considérable. Le modèle ne prescrit aucune structure au-dessus de la tribe. À cette échelle, les organisations ont souvent besoin de couches de coordination supplémentaires, ce qui les pousse vers des cadres comme SAFe, LeSS ou des hybrides maison.

Le principe d’adaptation

L’enseignement le plus important est aussi le plus simple : prenez ce qui marche, laissez le reste. Le modèle Spotify n’est pas un forfait tout compris. Vous pouvez adopter les squads sans les tribes. Vous pouvez utiliser les chapters sans les guilds. Vous pouvez vous inspirer du principe d’autonomie avec alignement sans rien étiqueter du tout. La valeur est dans les idées, pas dans les étiquettes.

Les erreurs d’adoption les plus courantes

À observer l’adoption du modèle Spotify dans de nombreuses organisations, quelques schémas d’échec reviennent avec une régularité frappante.

Erreur 1 : prendre une description pour une prescription

Le livre blanc décrivait le fonctionnement de Spotify. Il ne recommandait pas aux autres entreprises de fonctionner de la même façon. Traiter un document descriptif comme un cadre prescriptif (« nous aurons désormais des squads, des tribes, des chapters et des guilds ») passe à côté de l’essentiel. Les choix structurels de Spotify étaient taillés pour le contexte, la taille, le produit et la culture de Spotify.

Le remède : servez-vous du modèle comme d’une inspiration et d’un vocabulaire. Demandez-vous à quels problèmes de votre organisation ses composants répondent. Adoptez les morceaux qui règlent vos problèmes. Laissez le reste.

Erreur 2 : copier la structure sans la culture

C’est l’erreur la plus fréquente et la plus dommageable. Des organisations rebaptisent leurs équipes en squads, les regroupent en tribes, nomment des Chapter Leads et des Tribe Leads, et rien ne change. On attend toujours l’aval du manager. Les squads font toujours remonter les décisions. Les réunions de chapter ont bien lieu, mais ne produisent aucune valeur.

La structure est un contenant. La culture est ce qu’on met dedans. L’autonomie, la confiance, la sécurité psychologique, la transparence et le goût de l’action ne sont pas des propriétés structurelles mais comportementales. On ne les installe pas en réorganisant l’organigramme.

Erreur 3 : ignorer la tension du rôle de Chapter Lead

Le double rôle de Chapter Lead, mi-membre de squad, mi-manager, est une faiblesse connue du modèle. Les organisations qui l’adoptent sans traiter explicitement cette tension produisent des Chapter Leads qui s’épuisent, sous-performent dans l’un des deux rôles ou dans les deux, ou abandonnent discrètement le travail de squad pour se consacrer au management.

Certaines organisations tranchent en faisant du Chapter Lead un poste de management à plein temps, au prix du lien avec le travail quotidien. D’autres séparent les responsabilités entre un·e référent·e technique et un·e manager. D’autres encore allègent la charge managériale en confiant les entretiens de carrière à des partenaires RH. Chaque approche a ses contreparties, mais ignorer la tension n’en est pas une.

Erreur 4 : l’imposer aux équipes hors produit

Les fonctions support (RH, finance, juridique, infrastructure) n’entrent pas naturellement dans le moule de la squad. Leur travail est souvent réactif, transversal et orienté processus plutôt que fonctionnalité. Les forcer en squads crée des frontières artificielles et une charge inutile.

Certaines organisations excluent purement et simplement les fonctions support du modèle Spotify et les conservent dans une structure plus classique. D’autres y créent des squads orientées service, organisées autour des types de demandes qu’elles traitent. Les deux approches se défendent. L’erreur consiste à exiger que chaque équipe soit une squad.

Erreur 5 : ne pas faire évoluer le modèle

Le livre blanc d’origine était un instantané. Spotify a continué de changer. Les organisations qui adoptent le modèle puis le figent, en traitant la mise en place initiale comme définitive, violent le principe même d’amélioration continue que le modèle incarne.

Instaurez des rétrospectives régulières au niveau structurel. Posez les questions : les frontières des tribes sont-elles toujours les bonnes ? Les chapters apportent-ils de la valeur ? Les guilds sont-elles actives ou en sommeil ? Les squads sont-elles réellement autonomes ? Le modèle doit évoluer avec l’organisation.

Faire fonctionner le modèle Spotify dans votre organisation

Si vous décidez de vous inspirer du modèle Spotify, voici une démarche concrète qui évite les écueils les plus courants.

Commencez par les squads

La squad est la meilleure idée du modèle : une petite équipe pluridisciplinaire, avec une mission claire et l’autonomie de la mener à bien. Commencez par là. Identifiez un domaine produit, constituez une squad dotée des compétences nécessaires, donnez-lui une mission claire et le pouvoir de décider, puis observez ce qui se passe. Vous n’avez besoin ni de tribes, ni de chapters, ni de guilds pour tester le concept central.

Tracez les frontières des tribes par domaine produit

Au-delà de 3 ou 4 squads, les regrouper prend du sens. Tracez les frontières des tribes autour de domaines produit, de segments de clientèle ou de couches de plateforme, bref, autour de ce qui crée des besoins de coordination naturels entre les squads d’un même périmètre. Résistez à la tentation de dessiner des tribes en fonction des jeux politiques internes. La frontière doit refléter les dépendances de travail, pas les liens hiérarchiques.

Maintenez les tribes sous la barre des 150 personnes. Si l’une dépasse ce seuil, scindez-la. Les dynamiques sociales qui font tenir la coordination à l’échelle de la tribe reposent sur le fait que les gens se connaissent.

Réglez explicitement le dilemme du Chapter Lead

N’acceptez pas le rôle de Chapter Lead tel que le décrit le livre blanc sans l’adapter à votre contexte. Le partage mi-membre de squad, mi-manager fonctionne mal en pratique. Choisissez l’une de ces alternatives :

• Un Chapter Lead à plein temps : il ou elle se consacre entièrement au management des personnes et au leadership technique. Il ou elle assiste aux mêlées et aux revues de la squad, mais ne porte pas de charge de travail en son sein.
• Des rôles séparés : distinguez le leadership technique (un·e ingénieur·e senior dans chaque squad) du management des personnes (un·e manager d’ingénierie couvrant plusieurs squads).
• Un Chapter Lead tournant : le rôle circule entre les membres seniors, ce qui répartit la charge et développe les compétences de leadership.

Quel que soit votre choix, faites-en une décision consciente et explicite.

Servez-vous des guilds pour prévenir les silos tribaux

Investissez dans les guilds dès le départ. N’attendez pas que les silos se forment. Réservez du temps pour les activités de guild. Soutenez explicitement les Guild Coordinators. Rendez les productions des guilds (règles techniques, outils partagés, documentation) visibles et valorisées.

Les guilds ne fonctionnent que si l’organisation valorise réellement la participation, et pas seulement la tolère. Si les activités de guild sont les premières annulées à l’approche d’une échéance, le message est limpide : la pollinisation croisée est facultative. Elle ne devrait pas l’être.

Rendez la structure visible

Un modèle organisationnel ne fonctionne que si l’on peut le voir. Dès lors que vous vous organisez en squads, tribes, chapters et guilds, la structure obtenue est plus complexe qu’une hiérarchie classique. Chacun·e doit comprendre à quelle squad il ou elle appartient, de quelle tribe cette squad relève, qui est son Chapter Lead et quelles guilds existent.

C’est là que la cartographie organisationnelle devient indispensable. Une Carte vivante, et non un schéma figé au fond d’une présentation, qui montre l’état actuel des squads, des tribes, des chapters et des guilds donne à tout le monde un repère commun. Elle rend la structure navigable au lieu de la laisser abstraite. Des outils comme Peerdom sont faits exactement pour cela : rendre les structures organisationnelles visibles, cherchables et à jour, quel que soit le modèle que vous utilisez.

Faites-le évoluer

Fixez une cadence de rétrospectives structurelles. Le trimestre est un bon point de départ. Vérifiez si les frontières des tribes reflètent encore la circulation réelle du travail. Évaluez si les chapters ajoutent de la valeur ou seulement des réunions. Regardez si les guilds sont actives. Demandez aux squads si elles se sentent réellement autonomes.

Tout l’intérêt du modèle Spotify tient à ce qu’il n’a jamais été conçu pour durer tel quel. Sa meilleure version est celle que vous avez adaptée à votre contexte et que vous continuez d’affiner.

Questions fréquentes

Spotify utilise-t-il encore le modèle Spotify ?

Pas dans sa forme d’origine. Spotify a fait considérablement évoluer sa structure organisationnelle depuis le livre blanc de 2012. Une partie du vocabulaire subsiste, on parle encore de squads et de tribes, mais les structures et pratiques précises décrites dans le document ne définissent plus le fonctionnement de l’entreprise. La critique publiée par Jeremiah Lee en 2020 et les déclarations d’ingénieur·es de Spotify confirment que l’entreprise a dépassé le modèle tel qu’il avait été décrit à l’origine. Ce n’est pas un échec : c’est cohérent avec le principe d’évolution continue que le modèle lui-même défend.

Quelle est la différence entre un chapter et une guild ?

Un chapter réunit des personnes de même spécialité au sein d’une même tribe (par exemple tous les développeur·euses backend de la tribe A). Il a un Chapter Lead formel, qui en est le supérieur hiérarchique. L’appartenance est obligatoire : si vous êtes développeur·euse backend dans la tribe A, vous êtes dans le chapter backend. Une guild, elle, est une communauté d’intérêt transverse aux tribes (par exemple toutes les personnes que les pratiques de test intéressent, dans toute l’entreprise). L’adhésion à une guild est volontaire, et son Guild Coordinator n’a aucune autorité hiérarchique. Les chapters servent à l’alignement technique et au management des personnes. Les guilds servent au partage de connaissance et à la pollinisation croisée.

Quelle taille doit avoir une squad ?

Le livre blanc suggérait 6 à 12 personnes. Cette fourchette suit la recherche générale sur la taille efficace des équipes : assez grande pour réunir les compétences nécessaires à une livraison de bout en bout, assez petite pour que tout le monde se connaisse, communique directement et partage le même contexte. En dessous de 6, des compétences risquent de manquer. Au-dessus de 12, le coût de coordination commence à ronger les bénéfices de la petite équipe.

Les entreprises non technologiques peuvent-elles utiliser le modèle Spotify ?

Les concepts structurels (équipes autonomes et pluridisciplinaires, regroupements de coordination, communautés de pratique pour le partage de connaissance) ont une portée générale. Mais la mise en œuvre décrite dans le livre blanc a été pensée pour le génie logiciel, où la livraison itérative, l’autonomie technique et les mises en production fréquentes sont la norme. Les entreprises hors tech peuvent s’inspirer des principes, en particulier l’autonomie avec alignement et la composition pluridisciplinaire des équipes, mais elles doivent s’attendre à devoir adapter beaucoup. Hors du secteur technologique, des modèles comme la sociocratie, le Beta Codex ou le modèle Buurtzorg conviendront peut-être mieux.

Comment le modèle Spotify se compare-t-il à SAFe ?

SAFe (Scaled Agile Framework) est un cadre complet et prescriptif, avec des rôles, des cérémonies et des événements de planification définis aux niveaux équipe, programme et portefeuille. Le modèle Spotify est un ensemble de concepts structurels assorti d’un minimum de processus prescrits. SAFe convient bien aux grandes organisations qui ont besoin de rigueur procédurale, de traçabilité réglementaire et de synchronisation entre équipes. Le modèle Spotify convient mieux aux organisations à forte culture d’ingénierie qui veulent des repères structurels sans processus lourds. Les deux ne s’excluent pas : certaines organisations combinent la cadence de planification de SAFe et des structures d’équipe de type Spotify.

Quel est le rôle d’un Tribe Lead ?

Le Tribe Lead crée l’environnement dans lequel les squads peuvent réussir. Il ou elle ne dirige pas les squads une à une et ne prend pas de décisions produit à leur place. Ses responsabilités : lever les obstacles que les squads ne peuvent pas résoudre elles-mêmes, faciliter la coordination entre les squads de la tribe, assurer l’alignement avec la direction générale de l’organisation et porter les besoins de la tribe auprès du reste de l’entreprise. Le Tribe Lead tient davantage du leader au service de son équipe que du manager traditionnel.

Comment les squads se coordonnent-elles entre tribes ?

La coordination entre tribes est l’un des points faibles du modèle. Les mécanismes principaux sont les guilds, communautés volontaires qui partagent des savoirs par-delà les frontières des tribes, et la communication informelle. Certaines organisations ajoutent des rôles de coordination inter-tribes explicites, des points de synchronisation réguliers ou des groupes d’orientation architecturale. D’autres s’appuient sur des équipes plateforme partagées, qui rendent des services à plusieurs tribes. La bonne approche dépend du degré de couplage réel entre les travaux des différentes tribes.

Comment le modèle Spotify gère-t-il la gouvernance par les rôles ?

Le modèle Spotify ne prescrit aucun processus de gouvernance formel. Les rôles au sein des squads (Product Owner, développeur·euse, designer·euse) sont définis par le modèle, mais la façon dont ces rôles sont créés, modifiés ou supprimés est laissée à chaque squad et à chaque tribe. Les organisations qui souhaitent une gouvernance par les rôles explicite peuvent la superposer au modèle Spotify, en appliquant des processus de gouvernance holacratiques ou sociocratiques à l’intérieur des structures de squad et de chapter.

Commencez à cartographier votre organisation

Que vous adoptiez le modèle Spotify, que vous en repreniez quelques idées ou que vous exploriez une tout autre approche, la première étape est la même : rendre votre structure actuelle visible. Cartographiez vos équipes, vos rôles et vos relations pour que tout le monde partage la même compréhension du fonctionnement réel de l’organisation.

• Commencez à cartographier gratuitement : Peerdom prend en charge le modèle Spotify, l’holacratie, la sociocratie, le RenDanHeYi, le Beta Codex, le DSO et tout modèle hybride. Cartographiez vos squads, tribes, chapters et guilds, ou vos cercles, cellules et équipes, sur une seule plateforme.
• Parcourez les modèles : explorez des structures prêtes à l’emploi pour différents modèles organisationnels.
• Lisez le guide des logiciels d’autogestion : comparez les outils destinés aux organisations qui pratiquent l’autorité distribuée.
• Vous ne savez pas par où commencer ? Réservez une démo et nous verrons ensemble comment la structure de votre organisation se traduit dans le modèle que vous explorez.