Le schéma tient sur une diapositive. Des équipes appelées « squads », regroupées en « tribus », traversées par des « chapitres » et des « guildes ». Depuis 2012, il circule dans les directions sous le nom de modèle Spotify, avec la promesse d'équipes autonomes qui restent alignées.
Une organisation peut en reprendre tout le vocabulaire en quelques semaines. Elle renomme ses équipes, dessine ses tribus, désigne des responsables de chapitre. Rien n'oblige pour autant les décisions à changer de mains, ni les critères d'évaluation à bouger.
Cet écart entre ce que l'on copie et ce qui commande le comportement fait le sujet de cet article. Il prolonge une question plus large, celle du choix d'une méthode dans la conduite du changement en entreprise.
Que décrit réellement le modèle Spotify ?
Il décrit une entreprise à un moment précis de sa croissance. En octobre 2012, Henrik Kniberg, coach agile, publie avec Anders Ivarsson un document de quatorze pages intitulé Scaling Agile @ Spotify with Tribes, Squads, Chapters & Guilds. Spotify compte alors plus de trente équipes réparties dans trois villes. Ses effectifs techniques sont passés de 30 à 250 personnes en trois ans.
Une matrice tournée vers la livraison
L'unité de base est la squad, une équipe stable et pluridisciplinaire pensée comme une mini-start-up. Elle n'a pas de chef désigné. Un product owner priorise son travail et laisse à l'équipe la manière de le faire. Les squads d'un même domaine forment une tribu, conçue pour rester sous la centaine de personnes en référence au nombre de Dunbar.
Les chapitres réunissent, à l'intérieur d'une tribu, les personnes d'un même métier. Leur responsable est le manager hiérarchique de ses membres, chargé de leur développement comme de leur salaire, tout en travaillant lui-même dans une squad. Les guildes sont des communautés d'intérêt ouvertes à tous, à l'échelle de l'entreprise. Les auteurs reconnaissent une organisation matricielle d'un genre particulier. Son axe principal reste la livraison du produit.
Ce que le schéma ne montre pas
Le document décrit aussi ce sur quoi ces équipes s'appuient. L'architecture technique compte plus de cent systèmes que l'on peut modifier et déployer séparément. Une équipe d'exploitation construit ce que les auteurs appellent la route vers la production, pour que chaque squad mette elle-même son code en ligne. Chaque squad a accès à un coach agile. Une enquête trimestrielle mesure, squad par squad, la facilité de mise en production, l'adéquation du processus ou la clarté de la mission.
| Élément | Ce que dit le document de 2012 |
|---|---|
| Taille | Plus de 30 équipes dans 3 villes, effectifs techniques passés de 30 à 250 personnes en 3 ans. |
| Tribu | Conçue pour compter moins d'une centaine de personnes environ. |
| Temps d'exploration | Environ 10 % du temps de chaque squad consacré à des « hack days ». |
| Architecture | Plus de 100 systèmes distincts, chacun maintenu et déployé séparément. |
| Décision de conception | L'architecte en chef donne des suggestions, la décision finale revient à la squad qui construit le système. |
| Mesure | Enquête trimestrielle par squad, satisfaction des salariés déclarée à 4,4 sur 5 en avril 2012. |
| Statut du texte | Un instantané d'un travail en cours, présenté comme déjà dépassé au moment de la lecture. |
Les auteurs préviennent dès la première page que leur texte capture une étape. Ils ajoutent cette phrase.
« By the time you read this, things have already changed. »Henrik Kniberg et Anders Ivarsson, Scaling Agile @ Spotify, octobre 2012
Ce qu'en dit Kniberg trois ans plus tard
En juin 2015, Kniberg revient sur ce document dans un billet de son blog. Ce que l'on appelle désormais le modèle Spotify n'a jamais été pensé comme un cadre générique, écrit-il, « it’s just an example of how one company works ». Il raconte avoir d'abord trouvé inquiétant que tant d'entreprises le copient. Il dit ensuite n'avoir encore rencontré aucune d'entre elles qui ait fini dans une situation pire qu'avant, certaines ayant même beaucoup progressé.
Il en donne une raison. Copier oblige à regarder sa propre organisation d'un œil critique et à s'inspirer des autres, à condition d'adapter ce que l'on prend au contexte local. Ce témoignage déplace la question vers ce que l'on croit emprunter quand on copie.
Pourquoi copier une organisation laisse-t-il souvent ses comportements en place ?
L'organigramme montre la couche la plus visible d'une organisation, celle qui commande le moins la façon dont on y décide. Les noms d'équipes se copient en une réunion. Les règles de décision, les critères d'évaluation et les parcours de carrière restent en place tant que personne ne les touche.
La structure selon Senge
Peter Senge, professeur de management à la MIT Sloan School of Management, tire de la simulation du jeu de la bière un premier enseignement dans La cinquième discipline. « Des personnes différentes placées dans une même structure tendent à produire des résultats similaires. » Sous sa plume, la structure ne se résume pas aux boîtes d'un schéma. Elle comprend les « politiques opérationnelles » de ceux qui décident. Senge en conclut que « redéfinir notre propre mode de prise de décision revient à redéfinir la structure du système ».
Lu ainsi, un modèle d'organisation copié modifie la structure seulement s'il change la manière dont les décideurs tranchent. Renommer un service en tribu laisse ses politiques de décision intactes.
La structure selon Larman
Craig Larman, consultant en organisation, arrive au même endroit par l'observation. Sa cinquième loi pose que, dans les grandes organisations établies, la culture suit la structure. Il précise ce qu'il range sous ce mot, les groupes, les équipes, les rôles et les responsabilités, la hiérarchie, les parcours de carrière, les politiques, les mécanismes de mesure et de récompense. Un modèle copié touche volontiers le début de cette liste. La fin demande d'autres décisions.
Sa deuxième loi décrit la suite probable quand la fin de la liste reste intacte. Toute initiative de changement finit par redéfinir son vocabulaire nouveau jusqu'à lui faire désigner, pour l'essentiel, la situation antérieure. Une squad devient le nouveau nom du service, le responsable de chapitre celui du chef de service. Les cinq lois sont présentées en détail dans l'article sur ce que Kotter décrit et ce que Larman prédit en conduite du changement.
| Couche | Dans le document de 2012 | Question à poser avant de copier |
|---|---|---|
| Vocabulaire et schéma | Squads, tribus, chapitres, guildes. | Quel problème ces noms nouveaux doivent-ils résoudre chez nous ? |
| Rôles | Pas de chef de squad, un product owner qui priorise sans dire comment faire. | Qui perd ou gagne une décision avec ces rôles ? |
| Droits de décision | La squad choisit sa façon de travailler et tranche la conception de ses systèmes. | Quelle décision une équipe prendra-t-elle demain sans validation ? |
| Conditions techniques | Systèmes déployables séparément, route vers la production. | Une équipe peut-elle livrer sans attendre une autre équipe ? |
| Mesure | Enquête trimestrielle par squad sur ses conditions de travail. | Que mesure-t-on des équipes et qui lit la mesure ? |
| Carrière et rémunération | Le responsable de chapitre développe ses membres et fixe leur salaire. | Sur quels critères évalue-t-on et fait-on progresser les personnes ? |
L'effet de halo du modèle qui a réussi
Phil Rosenzweig, professeur de stratégie et de management international, décrit en 2007 neuf illusions qui faussent la lecture de la performance des entreprises. La première est l'effet de halo, l'un des biais cognitifs qui faussent les décisions. On regarde la réussite d'une entreprise, puis on en déduit la qualité de sa culture, de son leadership ou de ses valeurs. Une autre consiste à chercher ce que des entreprises gagnantes ont en commun sans jamais les comparer à des entreprises moins brillantes.
Un schéma d'organisation venu d'une entreprise admirée arrive chargé de ce halo. Rien ne permet de savoir quelle part de sa réussite il explique. Les rituels agiles subissent le même sort quand les méthodes agiles reproduisent la forme des pratiques sans leur cause.
Adopter des pratiques ou transformer la culture, quelle différence ?
L'adoption change ce que l'on fait, la transformation change ce que l'on est. Jurgen Appelo, auteur et conférencier en management, le formule avec une image de café dans sa préface au guide de Michael Sahota, coach agile et consultant. Apprendre à faire un bon café relève de l'adoption, devenir barista relève de la transformation. « Une adoption ne modifie que ce que vous faites. Une transformation modifie ce que vous êtes. »
Un choix à nommer
Sahota fait de cette distinction l'axe de son Guide de survie à l'adoption ou transformation agile, publié en 2012. Il la reprend de Mike Cottmeyer, consultant en transformation agile. Celui-ci oppose le changement par le « faire agile » au changement par le « être agile ». Sahota recommande d'écarter le mot « transition », assez vague pour désigner l'un comme l'autre. Le mot masque le choix au lieu de l'éclairer.
Son constat sur les organisations est net. Il juge « absolument essentiel » de rappeler que « la vaste majorité des organisations ne veulent pas de transformation ». Il l'explique sans reproche. Les dirigeants cherchent à résoudre leurs problèmes avec le moins de risque et d'effort possible, alors qu'une transformation demande un effort considérable et fait courir un risque réel.
L'adoption est un choix légitime
Dans ce cadre, l'adoption n'a rien d'un échec. Elle introduit des pratiques en s'appuyant sur la culture en place plutôt qu'en la combattant. Le risque se loge dans ce que Sahota appelle la transformation par accident, engagée sans que personne l'ait décidée ni mesuré ce qu'elle implique. Il estime qu'elle abîme les entreprises.
Copier un modèle d'organisation brouille cet arbitrage. Le schéma a l'allure d'une transformation alors qu'il peut être conduit comme une adoption, en laissant intacts les règles de décision et les parcours. La distinction rejoint celle qui sépare le changement 1 du changement 2, selon que l'on modifie les éléments d'un système ou ses règles.
Avant de présenter un nouveau schéma, un comité peut écrire sur une ligne ce qu'il attend de changer dans la façon de décider. Si la ligne reste vide, il prépare une adoption. Le choix est légitime dès lors qu'il est nommé et annoncé comme tel aux équipes.
Que se passe-t-il quand une équipe change plus vite que son organisation ?
L'organisation se défend. Sahota décrit une équipe enthousiaste qui commence à repousser les exigences des autres services et les demandes qui n'apportent rien à ses clients. Il compare la suite à un film de série B, « Attaque des anticorps de l'organisation ! ». Dans le corps humain, les cellules T éliminent les éléments étrangers. Une organisation réagit de la même façon à une culture qui lui est étrangère. Ses anticorps désignent les éléments qui travaillent dur à préserver le statu quo.
Les adaptateurs, une taxe acceptée
La réponse de Sahota est pragmatique. Plutôt que d'attaquer, l'équipe construit des adaptateurs qui traduisent sa façon de travailler dans la langue de l'organisation. Il cite un planning sous Microsoft Project inutile au client comme à l'équipe, exigé pourtant par l'organisation. Leur entretien consomme une partie du gain. « Les adaptateurs font partie du coût de l'activité économique. Comme les taxes. »
Il raconte lui-même l'avoir appris à ses dépens. Il avait refusé de fournir au bureau des projets un plan qu'il jugeait inutile. Il y a gagné un peu de travail en moins et, à long terme, des adversaires de la démarche au sein même de l'entreprise.
Frédéric Laloux, consultant et coach de dirigeants, décrit une tension voisine à propos des cultures non hiérarchiques logées dans des structures hiérarchiques. Il en tire le prix d'un emprunt de pratiques opales sans le modèle qui les porte, un prix qui se paie en attention continue, sur la durée.
Comment s'inspirer d'un modèle sans le plaquer ?
En l'adaptant avant de l'adopter. Appelo consacre à ce piège une section de Management 3.0 (2010). Il y tient le transfert d'idées entre organisations pour une très bonne stratégie, à condition de vérifier que ces innovations ont du sens dans sa propre situation. Il nomme copy-paste improvement l'amélioration par copier-coller, le fait de reprendre les idées des autres sans les adapter au contexte local. Cette exigence d'adaptation traverse les outils de Management 3.0, pensés pour manager le système.
Les cinq temps qui suivent en tirent une trame de travail pour un comité de direction ou une équipe de transformation.
1. Nommer le problème à résoudre
Un modèle répond au problème de l'entreprise qui l'a conçu. Celui de Spotify en 2012 tenait à une croissance rapide, avec la volonté de garder des équipes autonomes malgré leur nombre. Avant de regarder un schéma, le comité écrit le problème qu'il cherche à résoudre chez lui, avec ses propres mots.
2. Trancher entre adoption et transformation
Le comité décide s'il veut changer ce que les équipes font ou ce que l'organisation est. Il le dit aux équipes. Une adoption annoncée comme telle protège mieux la confiance qu'une transformation annoncée puis conduite à moitié.
3. Relever les conditions invisibles du modèle source
Chaque modèle repose sur des conditions que son schéma ne montre pas. Pour le document de 2012, elles figurent dans le texte même, avec une architecture découpée en systèmes déployables séparément, une route vers la production, l'accès de chaque squad à un coach agile et une enquête trimestrielle. Le comité vérifie lesquelles existent chez lui et lesquelles manquent.
4. Choisir la règle que l'on change
Une copie utile touche au moins une règle, qu'il s'agisse de qui décide, de ce que l'on mesure ou de la façon dont on évalue. Donella Meadows, scientifique spécialiste de la dynamique des systèmes, place les règles et les flux d'information bien au-dessus des chiffres dans son échelle des douze points de levier d'un système. Une règle changée et tenue pèse davantage qu'un organigramme redessiné.
5. Prévoir les adaptateurs et un rendez-vous de révision
Les équipes qui changent auront besoin d'adaptateurs vers le reste de l'organisation. Mieux vaut les prévoir et en accepter le coût. Le comité fixe aussi une date pour revoir ce qui a été emprunté, le modèle d'origine ayant lui-même changé avant que son texte soit lu.
D'où je parle
J'accompagne des équipes, des managers et des CODIR depuis 2012, dans une carrière commencée en 1998 dont quatorze ans à manager des équipes. Mes certifications couvrent SAFe, Scrum (CSM, CSPO) et Management 3.0. Bon nombre de mes accompagnements s'appuient sur certains outils de Management 3.0, le modèle que je trouve le plus utile et le plus engageant.
Quelles questions poser avant de lancer la copie d'un modèle ?
Celles qui obligent à expliciter le contrat du changement. Sahota termine son guide par une liste de contrôle en neuf points destinée aux agents du changement, internes ou externes. Plusieurs se posent telles quelles à un comité qui envisage de reprendre un modèle d'organisation.
- Le problème. Celui qui accompagne connaît-il le problème qu'on lui demande de résoudre ?
- L'objectif. Le comité et lui sont-ils d'accord sur l'approche, « simplement adopter les pratiques ou bien aussi transformer la culture » ?
- Les implications. Le commanditaire comprend-il ce que l'approche choisie implique ?
- Le périmètre. Sait-on quelles personnes sont incluses et lesquelles seront touchées ?
- L'influence. Le commanditaire a-t-il assez d'influence et de contrôle pour rendre le succès possible ?
- Le chemin. Accepte-t-il que, dans un système complexe, « le chemin à emprunter est émergent et ne peut pas être défini à l'avance » ?
La dernière question contredit la forme même d'un modèle prêt à copier. Un schéma promet un point d'arrivée connu. Le guide de Sahota comme le document de Kniberg et Ivarsson décrivent un chemin dont personne ne connaît la fin.
Questions fréquentes
Ses auteurs ne l'ont pas conçu ainsi. En 2015, Henrik Kniberg écrit que ce que l'on appelle le modèle Spotify n'a jamais été pensé comme un cadre générique et qu'il décrit la façon de travailler d'une entreprise. Le document de 2012 se présente lui-même comme un instantané d'un travail en cours.
Le document de 2012 prévenait que les choses auraient déjà changé au moment de sa lecture. Les sources réunies pour cet article ne décrivent pas l'organisation actuelle de Spotify. Mieux vaut lire ce texte comme le portrait de l'organisation technique de Spotify, alors forte de 250 personnes, à l'automne 2012.
Michael Sahota y voit un choix légitime, à condition qu'il soit fait en conscience. L'adoption s'appuie sur la culture en place. Le risque tient à la transformation par accident, engagée sans que personne en ait mesuré les implications.
Craig Larman observe que dans les très petites organisations jeunes l'ordre s'inverse et la structure suit la culture de ceux qui la composent. Une petite entreprise peut donc façonner sa structure à partir de sa culture. Cette fenêtre se referme en général avec la croissance.
Non. Jurgen Appelo tient le transfert d'idées pour une très bonne stratégie, à condition de vérifier qu'elles ont du sens dans sa propre situation. Henrik Kniberg dit n'avoir encore vu aucune entreprise finir plus mal après avoir copié le modèle Spotify. Il ajoute que la copie peut aider à condition d'adapter ce que l'on prend au contexte local.
Par la liste de ses conditions invisibles. Relevez dans le texte d'origine ce sur quoi le modèle s'appuie (architecture, droits de décision, mesure, carrières) puis vérifiez ce qui existe chez vous. Décidez ensuite quelle règle vous changez. Pour poser ce relevé sur votre contexte, réservons un échange de 30 minutes.
Votre organisation s'apprête à reprendre un modèle ?
Que vous soyez dirigeant, manager ou DRH, un premier échange permet de préciser ce que vous attendez de ce modèle et la part de vos règles de décision qu'il devrait toucher.
Réserver un échange découverte (30 min)Allez plus loin
- La cinquième discipline Les cinq disciplines de l'organisation apprenante, le jeu de la bière et l'idée que la structure influence le comportement. Voir le livre →
- Management 3.0 Une refondation du management sur la théorie de la complexité. L'organisation y devient un système adaptatif, loin de la machine hiérarchique. Voir le livre →
- The Halo Effect Neuf illusions qui faussent la lecture de la performance des entreprises, à commencer par l'effet de halo. Voir le livre →
Liens affiliés
