DevOps à l'échelle d'une infrastructure critique — Forge GitLab CI pour 450+ apps & GameDays de Chaos Engineering chez Enedis (via Klanik)

TL;DR

Chez Enedis, principal distributeur d’électricité en France, j’ai contribué à construire from scratch une forge GitLab CI sur Kubernetes pour 450+ applications, puis co-construit une plateforme de Chaos Engineering pour des GameDays à 100+ participants. Objectif commun : apprendre aux équipes à anticiper les pannes plutôt que les subir.

Contexte

Enedis opère ~95 % du réseau de distribution électrique français. On parle ici d’infrastructure critique nationale — la fiabilité, la traçabilité et la sécurité ne sont pas des « best practices », ce sont des exigences opérationnelles.

À mon arrivée (mission via Klanik, janvier 2022), il n’existait aucune forge CI/CD centralisée. Les équipes avaient des pipelines hétérogènes, des outils éparpillés, et des pratiques de sécurité inégales. Certains projets avaient une automatisation correcte, d’autres ressemblaient plus à du scripting maison. Pas de point d’entrée unique, pas de templates standards, pas de gestion centralisée des secrets, des artefacts, des scans ou des runners.

Et derrière, plusieurs centaines d’applications (~450 projets GitLab) et une très grosse population de développeurs avaient besoin de CI/CD au quotidien.

Notre équipe DevOps (5 personnes) avait un objectif clair :

Industrialiser une forge CI/CD unique pour toute l’entreprise, sur Kubernetes, capable de scaler de haut en bas automatiquement, et faire du « bon DevOps » le default pour tout le monde.

Plus tard dans la mission, j’ai aussi co-construit une plateforme de Chaos Engineering utilisée pour des GameDays massifs (100+ participants), pas pour « casser des trucs pour le fun » mais pour éduquer les équipes à l’observabilité, au monitoring, et à l’anticipation des défaillances en production.

Les deux fils suivent la même philosophie : les plateformes et les exercices sont des outils pour changer les comportements d’ingénierie à l’échelle.

Contraintes

• Contexte d’infrastructure critique. On ne pouvait pas se permettre d’instabilité dans la forge elle-même.
• Exigences de sécurité élevées. Gestion stricte des secrets, auditabilité, traçabilité.
• 450+ applications, beaucoup d’équipes, beaucoup de langages et de stacks.
• Runners auto-scalés. Maîtrise des coûts ET performance.
• Intégrer l’existant plutôt que tout remplacer.
• GameDays. 100+ participants, coordination multi-équipes, scénarios réalistes sur de vrais clusters.

Décision — Industrialiser la forge GitLab CI

On a fait de GitLab l’unique point d’entrée CI/CD de l’entreprise, adossé à une plateforme Kubernetes faisant tourner :

• Runners GitLab auto-scalés (HPA)
• Secrets centralisés avec HashiCorp Vault
• Repository d’artefacts avec Sonatype Nexus
• Qualité de code et scans de sécurité via SonarQube
• Déploiements Infrastructure as Code avec Terraform

La clé n’était pas d’héberger les runners. La clé, c’étaient les templates.

On a construit 40+ templates CI/CD modulaires qui couvraient :

• Plusieurs langages et frameworks
• Build, test, Docker build, push, release
• Scans de sécurité par défaut
• Pipelines Terraform plan/apply
• Patterns de déploiement standardisés

N’importe quel nouveau projet pouvait s’onboarder et obtenir instantanément un cycle de vie DevOps complet en incluant quelques lignes dans son .gitlab-ci.yml.

Concrètement, ça a fait basculer la CI/CD d’une responsabilité par équipe à une capability de plateforme partagée.

Architecture des templates (l’idée centrale)

• Usage massif de include
• Templates versionnés
• Blocs composables (build, test, scan, docker, deploy)
• Defaults opinionés, overridables quand nécessaire

Les équipes n’avaient pas à réinventer leurs pipelines. Elles consommaient des building blocks.

Décision — Le Chaos Engineering comme pédagogie

En parallèle, une entité interne (NIDC) voulait organiser de gros GameDays.

Avec un autre ingénieur DevOps, j’ai construit une plateforme de chaos entièrement automatisée et reproductible :

• Vrais clusters Kubernetes créés pour l’événement
• Infra entière provisionnée via Terraform
• Scénarios de catastrophe automatisés :
  • DDoS
  • Corruption de base de données
  • Fuite de secrets
• Espaces d’observabilité par équipe avec dashboards Grafana Labs
• Automatisation Discord : un canal par équipe, orchestration de l’événement, instructions, monitoring

L’objectif était à la fois compétitif et éducatif : les équipes devaient détecter, comprendre et corriger les incidents le plus vite possible.

Il ne s’agissait pas de casser de l’infra.

Il s’agissait d’apprendre aux équipes :

Logs, métriques, monitoring et tests en production ne sont pas optionnels.

Ce que j’ai construit

La forge (vue haut niveau)

Développeurs → GitLab CI → Runners K8s (HPA)
                            ↓
                    Vault / Nexus / Sonar
                            ↓
                  Docker registry / Terraform / Deploy

• Runners qui scalent automatiquement selon la charge
• Secrets injectés dynamiquement via Vault
• Artefacts stockés dans Nexus
• Scans de sécurité partout par défaut
• Forge elle-même conçue pour scaler down quand inactive

On a même conçu un PRA automatisé pour la forge elle-même.

La plateforme GameDay

Terraform → Clusters EKS → Pannes injectées
                            ↓
                       Dashboards Grafana
                            ↓
                       Discord par équipe

Tout était prêt avant l’événement. Le jour J, on n’avait plus qu’à appuyer sur « start ».

Résultat

Forge

• 450+ applications onboardées
• CI/CD standardisée à l’échelle de l’entreprise
• Scans de sécurité par défaut partout
• Forte amélioration de l’onboarding développeur
• Plateforme de runners fiable et auto-scalée
• Une forge que les équipes ont adoptée et dans laquelle elles avaient confiance

GameDays Chaos

• 100+ participants
• Des équipes qui découvrent des trous dans leur monitoring et leur alerting qu’elles ne soupçonnaient pas
• Changement de comportement net entre les premières et les dernières sessions :
  • Les équipes arrivaient mieux préparées
  • Le monitoring était pris au sérieux par la suite
• Impact pédagogique qui dépassait largement l’événement lui-même

Ce que je ferais différemment

• Investir plus tôt dans la documentation des templates. L’adoption aurait été encore plus rapide.
• Industrialiser la plateforme GameDay comme un produit interne réutilisable, plutôt que comme une infra dédiée à un événement.
• Mesurer plus formellement les gains de DX. On avait du qualitatif fort, on aurait pu poser des métriques propres derrière.

---

← Toutes les études de cas