Le modèle hub-and-spoke data : pourquoi il déçoit presque toujours

Depuis quatre ou cinq ans, le modèle hub-and-spoke domine les débats sur l'organisation des équipes data. Les grandes entreprises ont abandonné leurs cellules data centralisées jugées trop lentes, refusé les modèles décentralisés jugés trop fragmentés, et opté pour ce que beaucoup présentent comme le meilleur des deux mondes : un centre d'excellence qui fixe les standards, entouré d'équipes satellites intégrées dans les métiers. McKinsey, Gartner et la plupart des cabinets de conseil ont relayé cette architecture avec enthousiasme. Dans les conférences CDO de 2025 et 2026, elle est présentée comme le modèle mature, celui que les organisations "avancées" ont adopté. Le problème, c'est que les chiffres d'adoption ne disent rien sur les résultats.

Ce que défend le consensus, et pas sans raison

L'argument central du hub-and-spoke est cohérent. Un hub central garantit la gouvernance, la qualité des données, les standards techniques et la formation. Les spokes, intégrés dans les équipes produit, finance ou marketing, assurent la proximité avec les décisions opérationnelles et réduisent le délai entre l'analyse et l'action.

D'après une étude MIT Sloan Management Review publiée en 2023, les équipes data trop centralisées échouent fréquemment à produire de la valeur opérationnelle parce qu'elles ne comprennent pas suffisamment les processus métiers. À l'inverse, les équipes purement décentralisées génèrent de la dette technique, de la duplication des outils et des définitions contradictoires des indicateurs clés. Le hub-and-spoke tente de corriger ces deux défauts simultanément. Sur le papier, c'est une réponse raisonnable à un problème réel. L'intention organisationnelle est saine.

Des entreprises comme ING ou Zalando ont rendu publics certains éléments de leurs architectures data organisationnelles, qui ressemblent à des variantes de ce modèle. Chez Spotify, le modèle "squad" avec des fonctions data intégrées a été largement documenté et repris comme référence. Ce n'est pas une mode sans fondement.

Où le modèle décroche, et pour quelles raisons concrètes

Le premier problème est structurel : les data analysts et data scientists placés dans les spokes finissent systématiquement par répondre aux priorités immédiates du métier, au détriment de tout ce qui relève du hub. Les revues de gouvernance, la documentation, la mise à jour des pipelines selon les standards communs, la remontée des anomalies de qualité : tout cela est perçu comme du travail "pour le centre", sans bénéfice direct pour l'équipe métier qui évalue et promeut le spoke analyst.

Ce n'est pas une question de volonté individuelle. C'est une conséquence mécanique du double rattachement hiérarchique, souvent mal résolu. Dans la majorité des déploiements hub-and-spoke observés dans des grandes entreprises françaises du CACCACCustomer Acquisition Cost (CAC) is the total sales and marketing spend divided by the number of new customers gained in a period. It measures how efficiently you grow.Voir la définition complète → 40, le rattachement fonctionnel au hub existe sur l'organigramme mais le rattachement opérationnel au métier dicte les vraies priorités de la journée. Le hub devient progressivement un comité de normes sans pouvoir réel.

Le deuxième problème concerne la gouvernance des données elle-même. Quand une définition du "client actif" diverge entre le spoke marketing et le spoke finance, qui tranche ? En théorie, le hub. En pratique, les deux équipes vivent avec leurs propres définitions parce que l'arbitrage prend trop de temps et que les deadlines métiers n'attendent pas. Gartner estimait en 2022 que les conflits de définitions entre équipes data coûtaient en moyenne plusieurs semaines de travail analytique par trimestre dans les grandes organisations. Ces conflits sont aggravés, et non résolus, par le hub-and-spoke quand les lignes d'autorité sont floues.

Le troisième problème est le plus difficile à admettre : le modèle crcrThe percentage of visitors or prospects who complete a desired action (purchase, sign-up, contact form), calculated as conversions divided by total opportunities.Voir la définition complète →ée une illusion de décentralisation. Les métiers ont un data analyst attitré, ce qui les satisfait. Mais les décisions sur les outils, les accès, les priorités de pipelinepipelineAll active sales opportunities across the stages of the sales process, together with their combined potential value and probability of closing.Voir la définition complète → restent concentrées dans le hub. Le spoke ne peut rien faire d'autonome sur l'infrastructure. Résultat : le spoke est au contact du métier mais dépend du hub pour agir. Il attend. Le métier s'impatiente. Le hub est accusé d'être un goulot d'étranglement, exactement comme l'ancienne équipe centralisée qu'on avait voulu remplacer.

Le cas particulier des entreprises en transformation

Dans les organisations qui traversent une transformation digitale rapide, le hub-and-spoke supporte encore moins bien la charge. Les spokes sont sollicités sur des cas d'usage IA générativement complexes, des projets de personnalisation temps réel, des modèles de prédiction. Ces sujets nécessitent une coordination étroite avec l'ingénierie data et les équipes MLOpsMLOpsMachine Learning Operations: combining ML and DevOps practices to industrialise, deploy, monitor, and retrain models reliably in production.Voir la définition complète →, qui vivent dans le hub ou dans une fonction encore différente. La multiplication des interfaces organisationnelles ralentit précisément les initiatives qui justifiaient d'investir dans la data.

Ce qu'un CDO lucide devrait faire à la place

Le modèle hub-and-spoke n'est pas à rejeter en bloc. Mais il faut l'aborder comme un compromis coûteux plutôt que comme une architecture idéale, et construire explicitement les mécanismes qui compensent ses défauts.

Premier point concret : clarifier le rattachement hiérarchique sans ambiguïté. Si le spoke analyst est évalué et promu par le métier, il travaille pour le métier. Si le hub veut une influence réelle sur ses pratiques, il faut soit un rattachement hiérarchique direct, soit un système d'objectifs partagés avec une partie de la rémunération variable liée aux indicateurs de gouvernance. Chez ABN AMRO, par exemple, des mécanismes de ce type ont été documentés publiquement pour maintenir la cohérence entre spokes.

Deuxième point : investir dans des "data contracts" formalisés entre spokes et hub, c'est-à-dire des engagements mutuels sur la qualité des données produites, les délais de mise à jour et les définitions partagées. Ce n'est pas un concept nouveau, mais il reste sous-utilisé dans les déploiements hub-and-spoke réels, souvent parce que le hub manque de ressources pour les négocier et les maintenir.

Troisième point : accepter que certains domaines métiers ne bénéficient pas du hub-and-spoke et fonctionnent mieux avec une cellule data autonome et complète, ingénierie incluse. La supply chain dans un groupe industriel, le trading dans une banque : ces domaines ont des besoins techniques et des temporalités si spécifiques qu'un spoke sans capacité d'infrastructure est une gêne plus qu'un atout.

Le vrai risque du hub-and-spoke mal exécuté n'est pas l'échec visible. C'est la médiocrité stable : des équipes data actives partout, des résultats insuffisants nulle part, et un CDO qui explique