Duck Conf 2026 – CR – À l'épreuve de l'échelle - surmonter la dette technique et les défis d'une plateforme DevOps

À l’épreuve de l’échelle — surmonter la dette technique et les défis d’une plateforme DevOps

Lors de la Duck Conf 2026, Adrien Gooris, architecte IT chez Michelin depuis une dizaine d’années, et Lucas Drago, tech lead sur l’équipe Factory, sont venus nous raconter comment ils ont fait grandir un GitLab self-hosted de quelques centaines à plusieurs milliers d’utilisateurs en accumulant, puis en soldant, une dette technique qui a failli les dépasser. Un retour d’expérience honnête sur ce que « scaler » veut vraiment dire dans une grande entreprise industrielle.

Michelin, une software company qui s’assume

Difficile de parler de cette expérience sans poser le contexte. Michelin, ce n’est pas seulement des pneus : c’est 120 marques réparties sur trois cercles d’activité, environ 3 000 applications, 500 sites web, et pas moins de 230 applications mises à jour chaque semaine. Un périmètre considérable, piloté par un seul GitLab self-hosted.

Ce choix d’internalisation n’est pas anodin. Il reflète une conviction forte portée au plus haut niveau du groupe : « l’IT, c’est vraiment un levier pour la performance », comme le dit le CEO dans un message public. Le CIO va même plus loin en parlant de Michelin comme d’une software company. Adrien insiste : « ce n’est pas juste un slogan marketing, c’est une vraie conviction stratégique », et elle oriente les investissements, les recrutements, les priorités. Pour l’équipe en charge de l’outillage, ça change tout.

GitLab Omnibus : ne vous fiez pas aux apparences

Quand on installe GitLab, on n’installe pas vraiment GitLab mais plutôt GitLab Omnibus. Lucas tient d’ailleurs à corriger l’idée reçue : « on voit souvent passer la définition de ‘gestionnaire de paquets’ et je ne suis pas tout à fait d’accord ». Omnibus est avant tout un contrôleur de services : il orchestre tous les composants nécessaires à la plateforme (Sidekiq, Redis, PostgreSQL, Gitaly…), dit à quels services tourner sur quelle machine, et gère comment ils communiquent entre eux.

Le fichier de configuration d’Omnibus compte à lui seul 3 599 lignes. L’architecture de base est conçue pour tenir jusqu’à 1 000 utilisateurs. Elle est simple, rapide à déployer, et masque une complexité qui se rappelle à vous dès que la charge augmente.

Scaler à marches forcées (2017 → 5 000 utilisateurs)

L’histoire commence en 2017. L’équipe Factory a besoin d’un outil de gestion de code : elle déploie GitLab sur une architecture simple, sans trop savoir si la technologie va durer. Le pragmatisme prime. Et ça tient jusqu’à ce que la taille de l’équipe commence à augmenter.

• 1 200 utilisateurs (2018) : les premières plaintes arrivent. La doc GitLab recommande d’éclater les services sur 9 VM distinctes mais c’est un projet trop ambitieux pour Michelin à ce moment-là. L’équipe opte donc pour une solution intermédiaire : externaliser PostgreSQL et Redis, ajouter un load balancer, et dupliquer les nœuds restants. Résultat : ça fonctionne, avec 2 VM au lieu de 9. La dette s’accumule, mais reste « sous contrôle ».
• 3 000 utilisateurs (2019) : nouveau palier, nouveau nœud. L’architecture tient. L’équipe est satisfaite et gagne, selon ses propres mots, « quasiment deux ans avec une architecture simple ».
• 5 000 utilisateurs : point de rupture. Les utilisateurs demandent l’activation de la recherche avancée, ce qui impose d’ajouter un cluster Elasticsearch. Mais ce n’est pas là que le problème se cache vraiment.

Le NFS, goulot d’étranglement fatal

Le véritable problème, c’est le NFS (Network File System) utilisé comme stockage partagé. Git génère des millions de petits fichiers, et chaque commit déclenche des opérations de verrouillage que NFS gère très mal à grande échelle. Ajoutez l’Elasticsearch qui indexe le code à chaque push, et c’est l’écroulement. « C’est le NFS au milieu qui vient écrouler les performances de la plateforme », confirme Lucas.

La solution préconisée par GitLab : abandonner le NFS pour les repositories et adopter Gitaly Cluster. Mais cela implique de revoir entièrement la stratégie de backup, qui était jusqu’alors un simple snapshot du NFS, et de déployer une architecture bien plus ambitieuse : 31 VM, 15 services distincts, dont seulement 11 gérés par Omnibus.

Le backup devient alors un sujet à part entière. Avec 4 à 6 To de données de repository, la commande de backup native de GitLab peut prendre plus de 24 heures, ce qui rend de fait impossible de tenir un RPO inférieur à 12 heures. Une contrainte que l’équipe découvre malheureusement tardivement, et sur laquelle Lucas insiste qu’ils ont “vraiment galéré”.

GitLab Environment Toolkit : la sortie par le haut

En discutant avec d’autres grands groupes confrontés aux mêmes problématiques, Adrien et Lucas découvrent GitLab Environment Toolkit (GET) : un ensemble de playbooks Ansible et de modules Terraform maintenus par GitLab pour déployer des architectures de référence à grande échelle, de 1 000 à 50 000 utilisateurs.

Ce que GET change concrètement :

• Monitoring clé en main : exporteurs Prometheus et dashboards Grafana prêts à l’emploi. Chez Michelin, il a suffi de démarrer un Grafana à côté, d’importer les dashboards officiels et ça a marché immédiatement.
• Extensible sans fork : les « custom tasks » permettent de personnaliser le comportement (forcer les projets en visibilité interne, renforcer la sécurité…) sans modifier le code source du projet. Crucial pour pouvoir suivre les mises à jour de l’outil sans douleur.
• Reproductible : l’infrastructure peut être détruite et reconstruite à l’identique, ce qui simplifie considérablement les scénarios de reprise après sinistre.
• Multi-cloud : compatible AWS, Azure, GCP. Chez Michelin, c’est Azure pour l’instant mais changer de provider reste envisageable sans tout réécrire.

Une nuance importante cependant : « GET n’est pas magique », prévient Lucas. L’outil exige des compétences sérieuses en Terraform, Ansible et en administration GitLab. Sans cela, impossible de le configurer correctement pour son contexte d’entreprise.

Take aways

• Respectez les architectures de référence dès le départ. Même si on ne sait pas encore si on va garder l’outil, partir sur une archi scalable évite des migrations douloureuses.
• GET est solide, mais pas magique. Investissez dans la montée en compétence Terraform, Ansible et administration GitLab.
• Ne forkez pas GET. C’est, selon les speakers, « vraiment une mauvaise idée ». Utilisez les mécanismes d’extension prévus à cet effet.
• Désignez la stratégie de backup avec l’architecture, pas après. Le backup natif GitLab devient un problème de taille sur les grandes instances.
• Restez sur du self-hosted si vos contraintes l’exigent. Les outils existent pour le faire proprement. Et comme le résume Lucas : « si vous pouvez garder votre code chez vous, c’est vraiment quelque chose d’indispensable ».

Conclusion

Adrien nous laisse avec un enseignement qui dépasse le cas GitLab : dans son équipe, on évalue les produits du marché à l’aune de leur fonctionnel. Mais à l’avenir, il sera « plus observateur sur ce qui est fourni à côté du produit » notamment les outils pour le déployer, le monitorer, le sauvegarder. C’est souvent là que se cachent les vraies difficultés.

Une plateforme de code, c’est le carrefour de toute la stratégie IT : CI, containers, contrôle des accès, sécurité. Garder la main dessus vaut vraiment l’investissement.