Quand j’ai rejoint l’équipe produit de METRO France en tant que consultant via Wemanity Group, l’organisation d’ingénierie avait un problème qui n’était pas évident de l’extérieur : chaque produit était construit en silo.
Les différentes équipes avaient fait des choix technologiques différents. Certains produits utilisaient un framework, d’autres un autre. Pas de librairie de composants partagée, pas de conventions API communes, pas de stratégie de déploiement unifiée. Un ingénieur qui passait d’un produit à l’autre devait repartir de zéro. Chaque nouvelle fonctionnalité impliquait de réinventer des décisions déjà prises ailleurs.
Le résultat était prévisible : onboarding lent, effort dupliqué, déploiements fragiles, et un sentiment croissant que l’organisation d’ingénierie ne pouvait pas suivre le rythme du business.
Voici comment nous avons résolu le problème, et ce que j’ai appris sur le vrai coût de la fragmentation technique.
Le problème avec la diversité “suffisante”
Il existe un argument séduisant pour laisser les équipes choisir leurs outils : l’autonomie stimule la créativité, et chaque équipe connaît mieux son problème. Ce n’est pas entièrement faux. Mais à une certaine échelle, cette autonomie devient une taxe.
Chez METRO France, la taxe se manifestait de trois façons :
Latence à l’onboarding. Un nouvel ingénieur rejoignant une équipe ne pouvait pas contribuer pendant des semaines, car il devait apprendre une stack propre au produit depuis zéro. Il n’existait aucune connaissance fondamentale transférable.
Pas de réutilisation. Un composant construit par une équipe pour résoudre un problème UX ne pouvait pas être utilisé par une autre, même quand le problème était identique. Chaque équipe réinventait les mêmes solutions.
Fragilité des déploiements. Sans patterns d’infrastructure partagés, chaque produit avait ses propres particularités de déploiement. Un correctif dans un pipeline n’aidait pas les autres. Les incidents étaient isolés mais fréquents.
L’impact business était clair : construire un nouveau produit prenait des mois. Itérer sur un produit existant prenait plus de temps que nécessaire. La dette technique s’accumulait silencieusement dans chaque codebase.
Choisir un standard qui tient dans le temps
La première décision, et la plus politiquement délicate, était de choisir la stack.
Nous avons retenu TypeScript, React, Node.js, TypeORM et GraphQL pour le développement applicatif, GCP et Kubernetes pour l’infrastructure, et GitHub Actions pour la CI/CD.
Ce n’était pas un choix arbitraire. Chaque technologie a été sélectionnée pour une raison précise :
- TypeScript plutôt que JavaScript seul : typage fort, meilleur support IDE, et un contrat partagé entre les équipes front-end et back-end.
- React pour le front-end : écosystème large, réutilisation de composants, et un vivier de talents suffisamment profond pour recruter.
- Node.js + GraphQL pour la couche API : interface de requête unifiée, typage fort avec génération de code, et capacité à agréger des sources de données sans sur-récupération.
- GCP + Kubernetes : déjà partiellement en place, bien documenté, et scalable jusqu’aux 93 entrepôts.
L’insight clé : un standard ne tient que s’il est réellement meilleur pour les équipes, pas seulement sur le papier. Nous avons choisi des technologies avec lesquelles il était genuinement productif de travailler, pas les plus à la mode ni les plus théoriquement correctes.
Implémentation : adoption avant obligation
La plus grande erreur des organisations qui standardisent est de rendre la conformité obligatoire avant de démontrer la valeur.
Nous avons fait l’inverse. Avant de demander à quelque équipe que ce soit de changer sa stack, nous avons construit une implémentation de référence : un vrai petit produit avec le nouveau standard, déployé en production. Il fallait que ça marche, pas juste que ça soit beau en démo.
Une fois cette référence existante, l’adoption s’est propagée plus vite que prévu. Les ingénieurs pouvaient voir les patterns en action. Ils pouvaient poser des questions avec de vrais exemples en main. Le nouveau standard n’était pas un document de politique. C’était du code fonctionnel.
À partir de là, nous avons introduit des outils partagés : un design system avec des composants React réutilisables, des configs TypeScript communes, des règles ESLint encodant les décisions architecturales, et un template de pipeline CI/CD que les équipes pouvaient copier et adapter.
Les nouveaux produits démarraient sur la nouvelle stack par défaut. Les produits existants migraient progressivement, pas d’un coup pour éviter les perturbations, mais module par module, au fil des nouvelles fonctionnalités ou des refactorisations.
Le produit de gestion des primes : une étude de cas dans l’étude de cas
L’exemple le plus concret de ce qu’a permis cette standardisation est le produit de gestion des primes employés.
Les 93 entrepôts de METRO France géraient les primes via des tableurs. Les responsables de rayons saisaient les données manuellement, les RH consolidaient avec un décalage significatif, et les erreurs étaient fréquentes. Le processus était chronophage, non auditable, et une source récurrente d’insatisfaction des employés.
Construire ce produit dans l’ancien monde aurait nécessité des mois de mise en place, des outils custom, et une équipe qui n’aurait pas pu être réutilisée ailleurs ensuite.
Dans le nouveau monde, nous l’avons construit sur la stack standardisée dès le départ. Nous avons réutilisé des composants partagés pour l’UI. L’API GraphQL suivait les patterns établis. Le pipeline de déploiement était templaté. L’équipe qui l’a construit avait déjà travaillé sur d’autres produits dans la nouvelle stack et a été opérationnelle immédiatement.
Le produit a été déployé sur les 93 entrepôts à l’échelle nationale. Le calcul des primes est passé des tableurs à un système digital auditable. Les responsables ont signalé un traitement plus rapide. Les RH ont libéré du temps significatif. Les scores de satisfaction employé dans les entrepôts se sont améliorés de façon mesurable.
Mais au-delà du produit lui-même, le résultat le plus significatif était ce qu’il démontrait : la stack standardisée était devenue un multiplicateur. Construire ce produit avait pris une fraction du temps qu’il aurait fallu avant.
Les 80%
L’accélération de 80% des cycles de création de produits que nous avons mesurée n’était pas de la magie : c’était la somme de plusieurs effets qui se composent :
- Pas de délibération sur le choix de stack. Les équipes commençaient à construire immédiatement, sans débat sur les technologies.
- Les composants partagés réduisaient le travail UI de 40 à 60% sur les nouveaux produits.
- Les pipelines CI/CD templatés éliminaient des semaines de mise en place d’infrastructure par projet.
- Le transfert de connaissance inter-équipes signifiait que les ingénieurs pouvaient contribuer à n’importe quel produit dès le premier jour.
- Moins d’incidents grâce à des patterns d’infrastructure mieux compris et mieux documentés.
Chacun de ces effets seul aurait été significatif. Ensemble, ils ont transformé la capacité de l’organisation à livrer.
Ce que les leaders techniques devraient savoir
Si vous envisagez un effort de standardisation dans votre organisation, voici ce que je retiens de cette expérience :
Partez de la douleur. L’argument pour la standardisation doit être ancré dans des problèmes réels, pas dans l’élégance théorique. Montrez le coût de l’onboarding. Montrez l’effort dupliqué. Montrez les incidents de déploiement. Rendez visible le coût de l’état actuel.
Construisez avant d’imposer. Une implémentation de référence vaut dix documents de stratégie. Livrez quelque chose de réel en production, puis montrez pourquoi la nouvelle façon est meilleure.
Standardisez les décisions, pas les outils. L’objectif n’est pas l’uniformité pour elle-même : c’est réduire la fatigue décisionnelle et permettre la réutilisation. Une config TypeScript partagée est plus précieuse qu’un framework imposé, parce qu’elle supprime une décision de bas niveau sans contraindre l’architecture de plus haut niveau.
Attendez-vous à une migration progressive. Tout réécrire d’un coup casse les choses et épuise les ingénieurs. Migrez incrémentalement, produit par produit, module par module. Les nouveaux projets adoptent le standard par défaut ; les existants migrent au fil de leur évolution.
Mesurez le résultat, pas le processus. La métrique qui compte est la vélocité de livraison, pas le “pourcentage de produits sur la nouvelle stack”. Suivez ce qui vous importe vraiment.
Standardiser une stack technique est, dans le fond, un pari que l’infrastructure partagée crée plus de valeur que l’autonomie individuelle. Chez METRO France, ce pari a clairement payé : livraison plus rapide, meilleurs produits, et une équipe d’ingénierie capable de travailler ensemble plutôt qu’en silos parallèles.
Les 80% sont réels, mais ce qu’ils représentent est plus important : quand les ingénieurs arrêtent de réinventer les mêmes décisions encore et encore, ils peuvent passer ce temps à construire des choses qui comptent vraiment pour les utilisateurs.
C’est ça, le vrai point.
