Lors du rebranding 2024 et de la refonte de ses sites e‑commerce, Decathlon a dû repenser sa stratégie de déploiement pour éviter qu’un incident ne touche l’ensemble de la production. Le groupe est passé à une architecture multi‑tenant sur Kubernetes (une instance par pays), ce qui a accru les risques liés aux changements. Tester « hors production » ne suffit pas toujours — notamment pour les charges réelles — d’où le recours aux déploiements progressifs en production.
Solution retenue
Decathlon a intégré Flagger (outil open source, licence Apache 2.0) à sa chaîne GitOps basée sur Flux CD. Flagger est un opérateur Kubernetes permettant d’automatiser des stratégies canary : il dérive une partie du trafic vers la nouvelle version, surveille les métriques et promeut ou annule le déploiement selon les résultats. Flagger peut effectuer :
- duplication de trafic (shadowing)
- A/B testing
- rollouts progressifs par paliers (ex. démarrer à 5 % du trafic, augmenter par pas de 5 % toutes les 5 minutes).
Décisions assistées et sécurité opérationnelle
Flagger automatise mais conserve des points de contrôle : notifications aux équipes et possibilité de demander des confirmations humaines avant chaque palier. Decathlon a aussi limité certains automatismes pour garder un « bouton d’urgence » manuel, en particulier parce que certaines dégradations peuvent apparaître avec retard et que les métriques ne sont jamais exhaustives à 100 %.
Problèmes rencontrés et solutions
- Pollution des métriques : l’intégration avec Datadog créait des biais pouvant entraîner des rollback injustifiés. Decathlon a soumis une contribution à la communauté open source pour corriger cela.
- Base statistique : la fiabilité des décisions dépend de la taille et du comportement du trafic. Sur des parties à fort volume (catalogue), on peut analyser sur des intervalles courts ; sur des parcours moins fréquentés (tunnel de commande), il faut des fenêtres d’observation plus longues.
- Adoption par les développeurs : le défi majeur n’a pas été technique mais humain. Les équipes regrettent de ne pas avoir davantage co‑construit la solution avec les développeurs dès le départ.
Bonnes pratiques recommandées (synthèse opérationnelle)
- Choisir des métriques pertinentes : erreurs 5xx, latence p50/p95, taux de réussite des transactions critiques.
- Adapter la durée des tests et la granularité des paliers selon le volume de trafic par endpoint.
- Conserver une option de rollback manuel et des procédures d’escalade.
- Impliquer les développeurs tôt (coconstruction des pipelines et des règles de promotion).
- Surveiller la qualité des intégrations monitoring (éviter les « faux positifs »).
- Documenter et automatiser via GitOps pour traçabilité et reproductibilité.
Alternatives et compléments
Flagger + Flux est une option GitOps native adaptée à Kubernetes. D’autres approches existent : Argo Rollouts, des service meshes comme Istio ou Linkerd pour le traffic shifting/mirroring, ou des solutions commerciales ; le bon choix dépendra de l’écosystème monitoring, des exigences de sécurité et de la maturité des équipes.
Conclusion
Le cas Decathlon illustre l’intérêt des déploiements canary intégrés à une chaîne GitOps pour tester en production sans exposer l’ensemble des utilisateurs à un risque. La réussite repose autant sur les choix techniques (outil, métriques, fenêtres statistiques) que sur l’adoption par les équipes et la qualité des intégrations observability.
Source : Article LeMondeInformatique — « Comment Decathlon assure son développement continu dans Kubernetes », Reynald Fléchaux, publié le 10 février 2026. https://www.lemondeinformatique.fr/actualites/lire-comment-decathtlon-assure-son-developpement-continu-dans-kubernetes-99298.html
