Combien de temps a pris le déploiement de la plateforme sur les 40+ équipes ?

La construction de la plateforme elle-même a pris 5 mois, suivie d'un déploiement par phases démarrant avec deux équipes pilotes pour valider les golden paths en conditions réelles. L'adoption à l'échelle de toute l'organisation s'est ensuite faite en dix semaines, avec un référent de migration dédié affecté à chaque équipe.

Faut-il déjà utiliser Backstage ou Argo CD pour appliquer cette approche ?

Non. Cette organisation a choisi de standardiser sur Backstage, Argo CD et Crossplane dans le cadre de la mission, mais le principe sous-jacent — un catalogue en libre-service, un déploiement GitOps et un provisionnement encadré par des politiques — peut se construire sur l'outillage déjà en place. Le vrai prérequis, c'est la volonté de converger vers une seule route pavée plutôt que de maintenir indéfiniment les scripts de déploiement propres à chaque équipe.

Quel était le plus gros risque dans une migration touchant toutes les équipes produit ?

Le risque principal était de perturber la livraison en cours pour plus de 40 équipes simultanément. Ce risque a été maîtrisé en validant d'abord les golden paths avec deux équipes pilotes, puis en déployant sur dix semaines avec un référent de migration par équipe plutôt qu'une bascule brutale et unique.

Cette approche fonctionne-t-elle pour une organisation plus petite que 40 équipes ?

Oui — les mêmes modèles en libre-service, environnements de prévisualisation éphémères et scans de sécurité intégrés réduisent le toil dès quelques équipes, car le goulot d'étranglement lié aux tickets apparaît bien avant d'atteindre 40 équipes. Une organisation plus petite a généralement besoin d'une phase pilote plus courte et peut se passer du modèle à plusieurs référents de migration au profit d'un seul ingénieur plateforme coordonnant le déploiement.

Retour aux études de cas

TechnologieConseil DevOpsPlateforme Kubernetes

Plateforme développeur interne

Golden paths, environnements en libre-service et routes pavées vers la production pour une organisation d'ingénierie à forte croissance dépassant 40 équipes produit sans faire croître ses effectifs plateforme au même rythme.

Moins de toil pour la plateforme, onboarding plus rapide pour les produits

Client

Confidentiel — technologie à forte croissance

Secteur

Technologie

Calendrier

5 mois

Technologies

7+ outils

Le défi

!Chaque nouvel environnement, certificat ou namespace nécessitait un ticket auprès de l'équipe plateforme, avec un délai de traitement typique de trois à cinq jours ouvrés. Les équipes produit voyaient régulièrement des sprints entiers bloqués en attendant une infrastructure qui aurait dû prendre quelques minutes à provisionner.

!Chaque équipe avait développé sa propre méthode de déploiement des microservices, certaines avec des scripts shell maison, d'autres en connectant directement des jobs Jenkins à kubectl. Résultat, chaque incident, migration ou mise à jour de la plateforme exigeait de réapprendre un modèle de déploiement différent équipe par équipe.

!Les nouveaux embauchés passaient leurs deux à trois premières semaines à reconstituer une connaissance tacite à partir de fils Slack et de pages wiki inachevées laissées par des ingénieurs partis. Il n'existait aucune source de vérité unique sur la manière de construire, tester et livrer un service.

!Les scans de sécurité étaient ajoutés tout à la fin du cycle de release, souvent sous forme de contrôle manuel juste avant un déploiement en production. Les vulnérabilités étaient fréquemment découvertes des jours, voire des semaines après l'écriture du code, imposant un changement de contexte coûteux pour les corriger.

!L'observabilité était incohérente d'un service à l'autre: certains émettaient des traces et métriques riches, d'autres ne produisaient rien au-delà de logs stdout. Lorsqu'un incident traversait plusieurs services, les ingénieurs d'astreinte perdaient un temps précieux à simplement identifier quels tableaux de bord existaient, si tant est qu'ils existent.

!Le provisionnement des accès aux ressources cloud reposait sur un mélange de modifications IAM manuelles et de changements Terraform ad hoc, revus par un seul ingénieur plateforme déjà surchargé. Cela créait à la fois un point de défaillance unique et une piste d'audit quasiment impossible à reconstituer.

!Les environnements de préproduction et de prévisualisation étaient partagés et souvent contestés, si bien que tester un changement signifiait attendre qu'une autre équipe termine, ou pire, écraser silencieusement les données de test en cours d'une autre équipe.

!Les ingénieurs plateforme consacraient l'essentiel de leur semaine à des demandes répétitives à faible valeur ajoutée plutôt qu'à l'architecture ou aux outils, sans aucune capacité restante pour s'attaquer aux causes profondes alimentant la file de tickets.

!La réponse aux incidents souffrait de la même fragmentation que le déploiement : quand un problème de production touchait deux services possédés par des équipes différentes, les intervenants découvraient souvent en plein incident que les deux équipes utilisaient des formats de logs et des outils d'alerte différents, ajoutant de précieuses minutes au diagnostic précisément quand la vitesse comptait le plus.

!La direction avait également perdu la capacité de répondre à une question simple — combien de services existent, qui possède chacun d'eux, et quel est son état de santé actuel — car le catalogue de services, quand il existait, était une page wiki mise à jour de façon inégale, voire jamais, par les équipes individuelles.

Notre solution

Nous avons mis en place un catalogue de services dans Backstage avec des modèles validés pour API REST, workers et jobs batch, permettant à n'importe quel ingénieur de générer un service prêt pour la production en quelques minutes, avec logging, health checks et CI déjà câblés par défaut.

Nous avons standardisé la structure des repos GitOps pour toutes les équipes via Argo CD, donnant à chacune un modèle mental identique pour les manifests, les overlays et les promotions, quel que soit le service concerné.

Chaque pull request reçoit automatiquement son propre environnement de prévisualisation éphémère, provisionné via Crossplane et détruit à la fusion, éliminant la contention des environnements partagés qui corrompait silencieusement les résultats de test.

Nous avons intégré SAST, analyse des vulnérabilités des dépendances et signature d'images de conteneurs directement dans les modèles de pipeline GitHub Actions par défaut, afin que chaque commit soit vérifié automatiquement plutôt que de dépendre d'un contrôle manuel tardif.

Le provisionnement des ressources cloud est passé à des compositions gérées par Crossplane avec des garde-fous de politique, remplaçant les modifications IAM manuelles par des demandes déclaratives, vérifiables et auditables, accessibles en libre-service dans des limites préapprouvées.

Nous avons publié une documentation golden path directement dans le catalogue Backstage à côté de chaque modèle, complétée par une permanence hebdomadaire, afin que l'adoption ne dépende pas de la connaissance tacite ni de la disponibilité d'un ingénieur plateforme.

L'instrumentation OpenTelemetry a été intégrée par défaut dans chaque modèle de service, connectant automatiquement les nouveaux services aux tableaux de bord et vues de traces existants, les rendant observables dès leur premier déploiement plutôt qu'après qu'un incident force la question.

Nous avons mené une migration par phases, en commençant par deux équipes pilotes pour valider les golden paths en conditions réelles, puis un déploiement à l'échelle de la plateforme sur dix semaines avec un référent de migration dédié à chaque équipe.

Standardisation de l'outillage d'incident et du routage d'alertes pour toutes les équipes sur la même couche d'observabilité que celle du monitoring quotidien, de sorte qu'un incident inter-services fait désormais apparaître une chronologie unique et corrélée, quelles que soient les équipes propriétaires des services touchés.

Le catalogue de services Backstage est devenu la source faisant autorité, auto-alimentée, de la propriété et de l'état de santé des services, puisant directement dans les données de déploiement et d'observabilité plutôt que de dépendre des équipes pour maintenir manuellement une page wiki à jour.

Impact mesurable

Lead time

Réduction de 40 à 50 %

Les services types atteignent la préproduction avec beaucoup moins de relais et de corrections, divisant quasiment par deux le lead time par rapport à avant les routes pavées.

Onboarding

Production dès la première semaine

Les nouveaux ingénieurs livrent un vrai changement en production dès leur première semaine grâce aux modèles en libre-service, contre deux à trois semaines de collecte de connaissance tacite auparavant.

Charge plateforme

60 à 70 % de tickets en moins

Le provisionnement en libre-service a éliminé l'essentiel des tickets répétitifs pour certificats, namespaces et accès IAM, libérant les ingénieurs plateforme pour des travaux d'architecture.

Qualité

100 % des commits scannés avant fusion

Les contrôles de sécurité et de dépendances s'exécutent désormais automatiquement sur chaque changement, remplaçant un unique contrôle manuel tardif qui détectait les problèmes des jours, voire des semaines trop tard.

Contention d'environnements

Zéro conflit d'environnement partagé

Les environnements éphémères par PR ont supprimé les conflits de préproduction partagée qui corrompaient les tests.

Couverture observabilité

100 % des nouveaux services instrumentés par défaut

Chaque nouveau service embarque traces, métriques et tableaux de bord dès le premier jour, contre une couverture inégale où de nombreux services ne produisaient que des logs stdout.

Adoption

40+ équipes en 10 semaines

Toutes les équipes ont migré vers les golden paths dans la fenêtre de déploiement de dix semaines, soutenues par des référents de migration dédiés.

Diagnostic d'incident inter-services

Quelques minutes au lieu de dix ou plus

Les intervenants travaillent désormais à partir d'une chronologie unique et corrélée, au lieu de perdre les dix premières minutes ou plus à réconcilier des formats de logs entre équipes en plein incident.

“Nos ingénieurs plateforme ne sont plus le goulot d'étranglement. Les équipes avancent toujours vite, mais avec des rails qui rendent le bon choix le choix facile. Nous avons enfin le temps d'investir dans la plateforme elle-même au lieu de simplement empêcher la file de tickets de nous submerger. Même nos appels d'incident ont changé — plus personne ne passe les dix premières minutes à chercher quel tableau de bord regarder.”
D
Directeur ingénierie
Directeur plateforme, entreprise technologique (NDA)

Stack technologique

BackstageArgo CDCrossplaneGitHub ActionsKubernetesHelmOpenTelemetry