Platform Engineering : pourquoi votre équipe DevOps doit évoluer

Le constat : le DevOps ne passe pas à l’échelle

Le mouvement DevOps a profondément transformé la manière dont nous concevons, déployons et opérons les logiciels. La collaboration entre développeurs et opérationnels, l’automatisation des pipelines CI/CD, l’infrastructure as code : ces pratiques sont aujourd’hui largement adoptées et ont permis des gains considérables en vélocité et en fiabilité

Pourtant, un malaise croissant émerge dans les organisations qui ont atteint une certaine taille. Le modèle “You build it, you run it”, poussé à l’extrême, a transféré une charge cognitive écrasante sur les développeurs. Là où un développeur devait maîtriser son langage, son framework et ses tests, il doit désormais comprendre Kubernetes, Terraform, Helm, ArgoCD, Prometheus, Grafana, les politiques réseau, la gestion des secrets, les stratégies de déploiement, la conformité sécurité…

Le résultat est paradoxal. Le DevOps promettait d’accélérer la livraison de valeur. Mais dans une organisation de 200 développeurs, l’équipe DevOps/SRE de 8 personnes devient un goulot d’étranglement. Elle est sollicitée en permanence pour des demandes de support, des revues de configuration, des créations d’environnements. Les développeurs, eux, passent 30 à 40% de leur temps sur des tâches d’infrastructure plutôt que sur le code métier (source : DORA State of DevOps Report 2024)

C’est le problème que le Platform Engineering se propose de résoudre

Qu’est-ce que le Platform Engineering ?

Le Platform Engineering est la discipline qui consiste à concevoir et à construire des plateformes internes en self-service qui abstraient la complexité de l’infrastructure et des toolchains pour les équipes de développement. L’objectif n’est pas de supprimer le DevOps, mais de l’industrialiser

L’analogie la plus parlante est celle du cloud public. AWS ne met pas un ingénieur à disposition de chaque client pour provisionner ses ressources. AWS fournit une plateforme en self-service (console, CLI, API, CDK) avec des garde-fous intégrés (IAM, quotas, Service Control Policies). Le Platform Engineering applique le même principe à l’échelle de l’entreprise

Concrètement, une équipe de Platform Engineering construit et maintient une Internal Developer Platform (IDP) qui expose aux développeurs un ensemble de services standardisés : création de projets, provisioning d’environnements, déploiement d’applications, observation, gestion des secrets, bases de données as a service, etc

Les développeurs consomment ces services en self-service, via un portail web ou des fichiers de configuration déclaratifs, sans avoir besoin de comprendre les détails de l’implémentation sous-jacente (Kubernetes, Terraform, les spécificités du cloud provider)

Les Golden Paths : guider sans contraindre

Un concept central du Platform Engineering est celui de Golden Path (ou Paved Road). Il s’agit d’un chemin balisé et pré-optimisé pour les cas d’usage les plus courants. Un Golden Path n’est pas une contrainte rigide, mais une recommandation forte assortie d’un outillage complet

Exemple de Golden Path pour un microservice Java :

1. Le développeur crée un nouveau projet via le portail développeur
2. Un repository Git est automatiquement créé à partir d’un template standardisé (structure de projet, Dockerfile optimisé, pipeline CI/CD, configuration Kubernetes, dashboards Grafana)
3. L’application est déployable en un commit sur un environnement de développement
4. La promotion vers staging puis production suit un workflow standardisé avec gates de qualité (tests, scan de sécurité, review)
5. L’observabilité (logs, métriques, traces) est configurée automatiquement

En théorie, les Golden Paths réduisent l’onboarding de 2-3 semaines à quelques heures. En pratique, notre cas client a atteint 2 jours, un gain de 80% qui reste significatif

Ceux qui ont des besoins spécifiques peuvent s’écarter du Golden Path, mais ils assument alors la complexité supplémentaire. L’objectif est que 80% des cas d’usage soient couverts par les Golden Paths, et que les 20% restants soient gérés au cas par cas avec l’équipe plateforme

L’Internal Developer Platform (IDP) : architecture et composants

Une IDP mature repose sur plusieurs couches, chacune adressant un besoin spécifique

Couche portail développeur

C’est le point d’entrée unique pour les développeurs. Un catalogue de services (créer un microservice, provisionner une base de données, demander un certificat TLS), un catalogue logiciel (inventaire de tous les services, leurs propriétaires, leur documentation, leur état de santé), et un système de templates pour bootstrapper de nouveaux projets

Couche orchestration

Le moteur qui traduit les intentions des développeurs en actions concrètes sur l’infrastructure. Lorsqu’un développeur demande “un nouveau microservice en Java avec une base PostgreSQL”, l’orchestrateur déclenche la création du repository Git, le provisioning de la base de données via Terraform, la configuration du pipeline CI/CD, et l’enregistrement dans le catalogue

Couche infrastructure

Les briques techniques sous-jacentes : Kubernetes pour l’orchestration de conteneurs, Terraform ou Crossplane pour l’infrastructure as code, ArgoCD ou Flux pour le GitOps, Vault pour les secrets, Prometheus et Grafana pour l’observabilité. Cette couche est invisible pour les développeurs, et c’est précisément l’objectif

Couche gouvernance

Les politiques de conformité, de sécurité et de coûts intégrées dans la plateforme. Les développeurs ne peuvent pas déployer une image Docker avec des vulnérabilités critiques, provisionner une base de données sans chiffrement, ou exposer un service sans authentification – non pas parce qu’on leur interdit, mais parce que la plateforme l’empêche by design

Backstage : le portail développeur open-source de référence

Backstage, créé par Spotify et donné à la CNCF, est devenu le standard de fait pour le portail développeur. Il repose sur trois piliers

Le Software Catalog : un inventaire centralisé de tous les composants logiciels de l’organisation (services, bibliothèques, pipelines, documentation). Chaque composant est décrit par un fichier catalog-info.yaml versionné avec le code, ce qui garantit que le catalogue est toujours à jour

Les Software Templates : des workflows paramétrés qui permettent de créer de nouveaux composants en quelques clics. Un template “nouveau microservice Spring Boot” peut, par exemple, créer le repository, configurer le pipeline, provisionner la base de données et enregistrer le service dans le catalogue – le tout en 5 minutes

Les Plugins : l’écosystème de plugins Backstage est riche et en croissance constante. Kubernetes, ArgoCD, Grafana, PagerDuty, SonarQube, Snyk, Cost Insights… Chaque plugin ajoute une vue ou une fonctionnalité au portail, créant un single pane of glass pour les développeurs

Fonctionnalité	Backstage	Port (ex-Portainer)	Kratix	Humanitec
Open-source	Oui (CNCF)	Partiellement	Oui	Non
Software Catalog	Natif	Limité	Non	Oui
Templates	Natif	Non	Via Promises	Oui
Plugins	200+	Limité	Extensible	Intégrations
Communauté	Très large	Modérée	En croissance	Support éditeur
Complexité de mise en œuvre	Moyenne à élevée	Faible	Moyenne	Faible (SaaS)

Chez Nobori, nous avons implémenté Backstage pour plusieurs clients et constatons que la valeur se matérialise dès les premiers mois, à condition de commencer par le Software Catalog avant de déployer les templates et les workflows

Retour d’expérience : transformation Platform Engineering pour un acteur de la grande distribution

Pour l’un de nos clients dans le secteur de la grande distribution, nous avons accompagné la transformation d’une équipe DevOps classique vers un modèle Platform Engineering sur 9 mois. Coût indicatif : 4 ETP plateforme pendant 9 mois + licences outillage, soit environ 350-450K€ tout compris. ROI atteint en 14-18 mois

Contexte initial : 180 développeurs répartis en 22 squads, une équipe DevOps de 6 personnes submergée par les tickets de support (120 tickets/semaine en moyenne), un délai moyen de 18 jours pour mettre un nouveau service en production, et un taux de satisfaction développeur de 2.8/5 concernant l’expérience de déploiement

Phase 1 – Cadrage et MVP (mois 1-3) : nous avons commencé par cartographier les parcours développeurs les plus douloureux. Trois Golden Paths prioritaires ont été identifiés : création d’un microservice (Java/Spring Boot ou Node.js), provisioning d’une base de données (PostgreSQL, Redis), et configuration de l’observabilité (Datadog). Un Backstage minimal a été déployé avec le Software Catalog alimenté par les repositories existants

Phase 2 – Construction (mois 4-7) : les trois Golden Paths ont été implémentés comme des Software Templates Backstage, connectés à Terraform Cloud pour le provisioning et ArgoCD pour le déploiement GitOps. Un système de scoring a été mis en place pour mesurer la conformité de chaque service aux standards de la plateforme (tests, documentation, observabilité, sécurité)

Phase 3 – Adoption et itération (mois 8-9) : l’adoption a été progressive, commençant par 3 squads pilotes avant un déploiement généralisé. Des “Platform Champions” ont été nommés dans chaque squad pour faciliter l’adoption et remonter les feedbacks

Résultats à 9 mois :

• Délai de mise en production d’un nouveau service : de 18 jours à 2 jours
• Tickets de support DevOps : de 120/semaine à 35/semaine (-70%)
• Satisfaction développeur : de 2.8/5 à 4.3/5 (enquête interne, n=45 développeurs, questionnaire Developer Expérience trimestriel)
• Temps passé par les développeurs sur l’infrastructure : de 35% à 12%
• Couverture des services par l’observabilité standard : de 45% à 92%

Disclaimer méthodologique sur les 23 points libérés (35% → 12%) : ils ne se traduisent pas intégralement en code métier livré. Une partie est réabsorbée par des réunions, du refactoring, du mentoring junior, ou du training sur la nouvelle plateforme. Sur cette mission et 2 missions similaires, nous observons que 50 à 70% du gain brut se traduit en vélocité mesurable (story points livrés / sprint). C’est ce gain net qu’il faut utiliser pour le calcul ROI.

Les détails complets de cette transformation sont disponibles sur notre page cas clients

Le ROI du Platform Engineering

Le ROI du Platform Engineering se mesure sur plusieurs axes

Productivité développeur : chaque développeur récupère en moyenne 8 à 12 heures par semaine précédemment consacrées aux tâches d’infrastructure. Pour une organisation de 100 développeurs à un coût chargé de 600 euros/jour, cela représente 1,2 à 1,8 million d’euros par an de capacité de développement récupérée en valeur brute. Attention au calcul net : les heures libérées ne se réaffectent pas intégralement au code métier (cf. cas client ci-dessus, ~50-70% du gain brut se traduit en vélocité mesurable). Le ROI net réaliste est plus proche de 600K€ à 1,2M€/an pour 100 devs. Nous préférons annoncer ce gain net réaliste qu’un gain brut spectaculaire qui serait démonté par le directeur financier au premier trimestre, c’est toujours un ROI très significatif, mais c’est le bon ordre de grandeur à porter au COMEX

Réduction du time-to-market : la diminution du délai entre l’idée et la mise en production permet de livrer plus de valeur, plus vite. Dans un marché compétitif, cette vélocité est un avantage stratégique mesurable

Standardisation et sécurité : la plateforme encode les bonnes pratiques de sécurité, d’observabilité et de résilience. Le nombre d’incidents liés à des erreurs de configuration diminue significativement, typiquement de 40 à 60% sur la première année

Attractivité talent : l’expérience développeur (DevEx) devient un facteur différenciant dans le recrutement. Les développeurs préfèrent travailler dans des organisations où ils peuvent se concentrer sur le code métier plutôt que de lutter avec l’infrastructure

Les écueils à éviter

Écueils spécifiques au Platform Engineering (souvent oubliés au cadrage)

Sous-estimer le coût de la migration de données et configurations existantes : un Backstage Software Catalog vide n’a pas de valeur. Le remplir avec les centaines de services existants (description, owners, lineage, dépendances, criticité) demande typiquement 2 à 4 mois de travail en parallèle du build de la plateforme. Ce poste est souvent oublié au cadrage et apparaît au mois 4 quand l’équipe se rend compte qu’on ne peut pas demander aux 22 squads de remplir manuellement leurs catalog-info.yaml sans accompagnement. Budget réaliste : 0,5 à 1 ETP dédié sur 3 mois, soit 30 à 60K€

Sous-estimer la complexité de la migration progressive : pendant 6 à 12 mois, deux mondes coexistent : l’ancien DevOps “ticket-based” et la nouvelle plateforme self-service. Les développeurs doivent comprendre quels services utilisent quel circuit. Les équipes DevOps doivent maintenir les deux. C’est une période de surcharge cognitive et opérationnelle qu’il faut anticiper et budgeter explicitement, sinon les tickets de support augmentent au lieu de diminuer pendant les premiers mois, ce qui démoralise l’équipe et fragilise le sponsorship COMEX

Verrouillage via les Software Templates Backstage : un template “microservice Java” qui contient un choix d’observabilité (Datadog), de framework (Spring Boot 3), de pipeline (GitLab CI) verrouille toute l’organisation sur ces choix. Si vous voulez changer Datadog pour un concurrent dans 2 ans, vous devrez modifier des centaines de services. Anticipez en gardant les templates aussi modulaires que possible (séparer les briques observabilité / framework / pipeline) et en versionnant les templates pour permettre une migration progressive

Écueils génériques de transformation à ne pas oublier non plus

Construire une plateforme sans utilisateurs : la plateforme doit être conçue avec les développeurs, pas pour eux. Les plateformes construites en chambre par l’équipe DevOps sans implication des utilisateurs finissent comme des projets fantômes. Traitez votre plateforme comme un produit, avec des utilisateurs, des feedbacks et des itérations

Vouloir tout automatiser dès le départ : commencez par les parcours les plus douloureux et les plus fréquents. Un Golden Path qui couvre 3 cas d’usage avec une excellente expérience vaut mieux qu’une plateforme qui couvre 20 cas d’usage avec une expérience médiocre

Sous-dimensionner l’équipe plateforme : une équipe de Platform Engineering viable nécessite un minimum de 4 à 6 personnes (product owner, développeurs backend, spécialiste infrastructure). En dessous, la plateforme ne peut pas évoluer assez vite pour rester pertinente

Oublier le change management : la transformation Platform Engineering est autant culturelle que technique. Les développeurs habitués à “faire à leur manière” doivent être convaincus, pas contraints. La formation, la documentation et les champions internes sont essentiels

Conclusion

Le Platform Engineering n’est pas un remplacement du DevOps, c’est son évolution naturelle pour les organisations qui grandissent. Là où le DevOps a cassé les silos entre Dev et Ops, le Platform Engineering structure et industrialise cette collaboration pour qu’elle passe à l’échelle

La mise en œuvre est un investissement significatif, mais le retour est mesurable et rapide. Les organisations qui l’adoptent ne reviennent pas en arrière : l’expérience développeur, la vélocité de livraison et la fiabilité opérationnelle atteignent un niveau que le modèle DevOps artisanal ne peut tout simplement pas égaler

Nobori construit des Internal Developer Platforms pour les organisations de 50 à 500 développeurs. Découvrir notre offre Platform Engineering

Sources et méthodologie

• DORA State of DevOps Report 2024 : données sur le temps passé par les développeurs sur l’infrastructure et les métriques de performance (deployment frequency, lead time, MTTR, change failure rate)
• CNCF Platform Engineering Maturity Model : cadre de référence pour évaluer la maturité des plateformes internes
• Backstage.io / CNCF : documentation officielle et benchmarks communautaires
• Retours d’expérience Nobori : données issues de nos missions d’accompagnement Platform Engineering (métriques avant/après anonymisées, enquêtes internes de satisfaction développeur)

Les métriques du cas client (grande distribution, 180 devs) sont issues de mesures réelles effectuées pendant la mission. Les chiffres de ROI et de coûts sont des ordres de grandeur qui varient selon le contexte organisationnel et technique

Pour aller plus loin

• Découvrez notre expertise Platform Engineering et nos approches de transformation des pratiques d’ingénierie
• Consultez nos cas clients pour des retours d’expérience complets
• Explorez notre expertise Platform Engineering pour comprendre comment l’infrastructure cloud s’intègre dans une stratégie de plateforme interne