La puissance des Squads Spotify
.svg)
- Le modèle Spotify vient d’un article d’octobre 2012, « Scaling Agile @ Spotify », signé Henrik Kniberg et Anders Ivarsson, et non d’un cadre méthodologique officiel.
- Il repose sur quatre unités : la squad (l’équipe), la tribe (le regroupement de squads), le chapter (le métier) et la guild (la communauté d’intérêt).
- Aucune taille de squad ne figure dans le texte d’origine ; seule la tribe est bornée, sous la barre des 100 personnes, d’après le nombre de Dunbar.
- Le document lui-même prévient qu’il n’est qu’un instantané ; en 2016, un chapter lead de Spotify demandait publiquement de ne pas le copier.
- Jeremiah Lee, ancien product manager de Spotify, documente trois faiblesses : responsabilités brouillées, autonomie sans coordination, compétences agiles insuffisantes.
- La structure reste reproductible dans Talkspirit en cercles et sous-cercles, à condition de l’adapter plutôt que de la décalquer.
Parmi les nombreuses raisons qui ont fait sa renommée mondiale, Spotify est devenu une référence dans la communauté Teal après avoir publié une série de deux vidéos sur leur façon unique d’organiser leurs équipes d’ingénierie.
Elle reposait sur trois piliers : l’autonomie, la confiance et la rapidité.
Les Corporate Rebels ont également rédigé un article détaillant chaque composante clé de cette structure.
Avant les vidéos, il y a un texte fondateur : « Scaling Agile @ Spotify », publié en octobre 2012 par Henrik Kniberg et Anders Ivarsson. Il décrit une entreprise passée en trois ans de 30 à 250 personnes dans la tech, et qui cherchait à grandir sans perdre sa façon de travailler.
Si les organisations ont toujours intérêt à réfléchir à leurs propres besoins et préférences au moment de décider comment s’organiser, observer ce que font d’autres entreprises peut être source d’inspiration et constituer un bon point de départ.
Voici donc ce que contient réellement ce modèle, ce que Spotify lui-même en dit, et comment reproduire cette structure dans Talkspirit si elle vous sert de point de départ.
La structure Spotify
Pour commencer, il faut comprendre les composants de base de cette structure. Plutôt que des rôles et des cercles, tels qu’on les trouve dans l’Holacratie, le département ingénierie de Spotify s’articule autour des éléments suivants :
- Squad : Un petit groupe de personnes réunissant toutes les compétences nécessaires pour prendre en charge intégralement un aspect précis du travail. L’équivalent d’une équipe.
- Tribe : Un ensemble de plusieurs squads travaillant tous sur un même segment de l’organisation. L’équivalent d’un département.
- Chapters : Tous les membres d’une tribe, répartis dans différentes squads, qui exercent la même fonction. Par exemple, les testeurs produit de chaque squad d’une tribe partagent un même chapter. Chaque chapter est dirigé par un line manager.
- Guild : Un groupe de personnes, issu de n’importe quelle tribe, partageant un intérêt commun (loisirs, domaine d’expertise, etc.). Tout le monde peut rejoindre une guild.
Un point mérite d’être relevé, parce qu’il circule partout sous une forme approximative : le document de 2012 ne donne aucune taille de squad. Les effectifs repris de guide en guide, six à douze personnes le plus souvent, ne viennent pas de la source. La seule taille que le texte fixe concerne la tribe : elle est dimensionnée d’après le nombre de Dunbar, soit moins de 100 personnes environ, au motif qu’au-delà apparaissent les règles restrictives, la bureaucratie et les couches de management supplémentaires.
Le texte pose aussi lui-même la question que tout le monde finit par poser : n’est-ce pas simplement une organisation matricielle ? La réponse de ses auteurs est oui, en quelque sorte, avec une nuance. La dimension verticale, celle des squads et des tribes, porte le « quoi » et prime, parce que c’est ainsi que les personnes sont regroupées au quotidien. La dimension horizontale, celle des chapters et des guilds, porte le « comment » : le partage des savoirs, des outils et du code. Une squad n’a d’ailleurs pas de responsable désigné, seulement un product owner qui priorise le travail sans décider de la manière de le faire.
| Unité | Ce que le document de 2012 en dit | Qui la dirige | Dimension |
|---|---|---|---|
| UnitéSquad | Ce que le document de 2012 en ditL’unité de base, comparable à une équipe Scrum, colocalisée, réunissant toutes les compétences pour concevoir, développer, tester et livrer, sur une mission de long terme | Qui la dirigePas de responsable désigné, un product owner priorise le travail sans dire comment le faire | DimensionVerticale, le « quoi » |
| UnitéTribe | Ce que le document de 2012 en ditUn ensemble de squads travaillant sur un même segment du produit, dimensionné sous la barre des 100 personnes (nombre de Dunbar) | Qui la dirigeUn tribe lead, chargé d’offrir aux squads le meilleur cadre de travail possible | DimensionVerticale, le « quoi » |
| UnitéChapter | Ce que le document de 2012 en ditLes membres d’une même tribe qui exercent le même métier, réunis régulièrement autour de leurs sujets techniques | Qui la dirigeUn chapter lead, manager hiérarchique, qui reste par ailleurs membre d’une squad | DimensionHorizontale, le « comment » |
| UnitéGuild | Ce que le document de 2012 en ditUne communauté d’intérêt ouverte, qui traverse toute l’organisation et que chacun rejoint s’il le souhaite | Qui la dirigeUn coordinateur de guild | DimensionHorizontale, le « comment » |
Ce que Spotify dit du modèle Spotify
Le document fondateur s’ouvre sur un avertissement, souvent sauté par ceux qui le citent : « Nous n’avons pas inventé ce modèle. Spotify évolue vite, comme toute bonne entreprise agile. Cet article n’est qu’un instantané de notre façon de travailler actuelle, un chemin en cours, pas un chemin achevé. Au moment où vous lirez ceci, les choses ont déjà changé. » (traduit de l’anglais, Kniberg et Ivarsson, octobre 2012.)
En 2015, Henrik Kniberg a précisé sur son blog qu’il n’avait pas inventé ce modèle et que celui-ci n’était « pas censé être un framework générique ni un modèle, juste un exemple de la façon dont une entreprise travaille » (traduit de l’anglais).
Un an plus tard, Marcin Floryan, chapter lead chez Spotify, allait plus loin devant la conférence Spark the Change à Londres, rapporté par InfoQ : le modèle « peut aider à comprendre la manière dont les choses sont faites chez Spotify, mais ce n’est pas une chose que vous devriez copier dans votre organisation ». Sa raison tient en une phrase : le modèle change en même temps que les équipes qui le pratiquent.
La critique la plus documentée vient de Jeremiah Lee, ancien product manager chez Spotify, dans un texte intitulé « Failed #SquadGoals ». Il y décrit trois points d’achoppement observés de l’intérieur : des ingénieurs managés par un chapter lead extérieur à leur équipe, ce qui crée des trous de responsabilité et des chemins d’escalade compliqués ; une autonomie accordée sans processus de coordination entre équipes, chacune inventant sa propre façon de travailler ; et des compétences agiles de base qui manquaient, faute d’accompagnement suffisant. Il décrit une transition progressive vers des structures de management plus classiques, sans en donner la date.
Rien de tout cela n’invalide l’intention de départ. Cela déplace ce qu’il y a à en retirer : le vocabulaire, squad, tribe, chapter, guild, se copie en une après-midi, tandis que la clarté des responsabilités et les règles de prise de décision qui rendent cette autonomie tenable demandent nettement plus de travail.
Comment le construire dans Talkspirit
Cette structure a beau paraître complexe, sa reproduction dans Talkspirit est relativement simple, à condition de l’adapter à vos propres besoins plutôt que de la décalquer. Il suffit de suivre ces étapes :
- Créer 2 cercles : Tribes et Guilds
- Sous Tribes, créer un sous-cercle distinct pour chaque tribe
- Dans chaque sous-cercle tribe, créer deux sous-cercles supplémentaires : Squads et Chapters
- Dans chaque sous-cercle squads, créer un sous-cercle supplémentaire pour chaque squad. Ajouter tous les membres concernés à chacun de ces cercles.
- Dans chaque sous-cercle chapters, créer un sous-cercle supplémentaire pour chaque chapter
- Dans chaque chapter, désigner le rôle qui porte le management hiérarchique, le line manager, puis ajouter tous les membres du chapter concerné à ce cercle.
- Sous Guilds, créer un rôle ou sous-cercle distinct (selon les besoins) pour chaque guild
C’est tout. La restructuration initiale demandera du temps, et elle ira d’autant plus vite que les rôles essentiels de chaque cercle auront été arrêtés en amont, avant d’ajouter les rôles particuliers comme le line manager de chaque chapter.
Vous souhaitez voir ce que cela donne sur votre propre organigramme ? Demandez une démo à notre équipe.
D’autres modèles qui pourraient vous intéresser
Si la structure Spotify vous attire, vous serez peut-être tenté d’explorer des modèles organisationnels innovants tels que l’Holacratie, la Sociocratie, Agile ou le Lean. Tous ces modèles ont un point commun : ils visent à renforcer l’autonomie, la confiance et l’agilité des équipes. Pour commencer par un cas concret, lisez les avantages de l’holacratie et la façon de l’adopter. Envie d’en savoir plus ? Téléchargez notre livre blanc sur les modèles organisationnels 👇
Accéder au livre blanc
Dans notre livre blanc « Le Guide Ultime des Modèles Organisationnels », vous trouverez : un panorama complet des modèles organisationnels innovants (Agile, Teal, Holacratie, Management Constitutionnel, etc.), des témoignages d’organisations pionnières qui les ont adoptés avec succès, des bonnes pratiques pour choisir, mettre en œuvre et évaluer l’efficacité de votre modèle, ainsi que des outils numériques pour faciliter la transition.
FAQ
Une squad est une petite équipe autonome qui réunit toutes les compétences nécessaires pour concevoir, développer, tester et livrer une partie du produit. Le document de 2012 la compare à une équipe Scrum : elle choisit sa propre façon de travailler, n’a pas de responsable désigné, et suit une mission de long terme avec un product owner qui priorise le travail sans décider de la manière de le faire.
La squad est l’équipe. La tribe regroupe plusieurs squads travaillant sur un même segment du produit, sous la barre des 100 personnes. Le chapter réunit, à l’intérieur d’une tribe, les personnes qui exercent le même métier, et son chapter lead est leur manager hiérarchique. La guild est une communauté d’intérêt ouverte, qui traverse toute l’organisation et que chacun rejoint librement.
Le document d’origine ne donne aucun chiffre. Les tailles qui circulent, six à douze personnes le plus souvent, viennent de reprises ultérieures et non de la source. La seule taille fixée par le texte concerne la tribe, dimensionnée sous la barre des 100 personnes d’après le nombre de Dunbar.
Pas sous la forme publiée en 2012, et ses auteurs le disaient déjà à l’époque : l’article se présente comme un instantané, avec la mention « au moment où vous lirez ceci, les choses ont déjà changé ». En 2016, Marcin Floryan, chapter lead chez Spotify, demandait publiquement de ne pas le copier. Jeremiah Lee, ancien product manager de l’entreprise, décrit une transition progressive vers des structures de management plus classiques, sans en donner la date.
Trois limites sont documentées par Jeremiah Lee, qui les a observées de l’intérieur : des ingénieurs managés par un chapter lead extérieur à leur équipe, ce qui brouille les responsabilités et complique les arbitrages ; une autonomie accordée sans processus de coordination entre équipes ; et des compétences agiles de base qui manquaient, faute d’accompagnement. Le vocabulaire se copie vite, les règles de décision qui le rendent tenable beaucoup moins.
En deux cercles racines, Tribes et Guilds. Sous Tribes, un sous-cercle par tribe, contenant lui-même deux sous-cercles, Squads et Chapters, puis un sous-cercle par squad et par chapter. Dans chaque chapter, un rôle porte le management hiérarchique, le line manager. Sous Guilds, un rôle ou un sous-cercle par guild. Arrêter d’abord les rôles essentiels de chaque cercle fait gagner beaucoup de temps.
