Votre équipe dev perd 30% de son temps à ne pas coder : l'Internal Developer Platform comme solution

Où part le temps de vos développeurs ?

Si vous avez lu notre article sur l’évolution du DevOps vers le Platform Engineering, vous connaissez le diagnostic. Cet article ne le répète pas. Il passe directement au comment : construire un MVP d’Internal Developer Platform en 6 semaines

Mais d’abord, un rappel chiffré. Selon les études DORA/SPACE 2024-2025, les développeurs passent en moyenne 25 à 35% de leur temps sur du glue work (CI, configuration, tickets infra), avec une fourchette qui va de 15-20% dans les organisations matures à 40-50% dans les organisations en transition DevOps. La fourchette “30 à 40%” souvent citée correspond à la médiane des organisations en milieu de transition, pas un plancher universel. Le détail typique :

Activité	% du temps	Valeur ajoutée
Écrire du code métier	30-35%	Élevée
Code review et tests	15-20%	Élevée
Attendre la CI/CD	10-15%	Nulle
Configurer des environnements	8-12%	Nulle
Tickets infra / Ops	5-8%	Nulle
Onboarding / documentation	5-10%	Faible
Réunions et coordination	10-15%	Variable

Les lignes “attendre la CI”, “configurer des environnements” et “tickets infra” totalisent 25 à 35% du temps (source : DORA State of DevOps Report 2024). Sur une équipe de 20 développeurs à 70K€/an de coût complet, c’est 350 à 490K€/an de temps perdu. C’est ici qu’un IDP intervient

Les prérequis techniques minimums

Avant même de parler organisationnel, un IDP automatise un socle technique. Si ce socle n’existe pas, l’IDP n’a rien à abstraire. Vérifiez que vous avez :

• Infrastructure-as-Code en place (Terraform, Pulumi, ou Crossplane) : un IDP qui provisionne via SSH ou scripts bash artisanaux est une fausse plateforme.
• Pipelines CI/CD standardisees (GitHub Actions, GitLab CI, Jenkins) : pas nécessairement uniformes entre équipes, mais reposant sur la même techno.
• Gestionnaire de secrets centralisé (Vault, AWS Secrets Manager, GCP Secret Manager) : pour éviter que les Golden Paths leakent des credentials.
• Monitoring basique (Prometheus / CloudWatch / Datadog ou équivalent) : pour mesurer l’impact et intégrer l’observabilité dans le portail.

Si plusieurs de ces briques manquent, l’IDP n’est pas votre prochaine étape : c’est un projet de standardisation IaC + CI qu’il faut mener en amont (3 à 6 mois). Sauter cette étape produit des Golden Paths instables qui détruisent la confiance des développeurs dès le mois 2

Les prérequis organisationnels

Un IDP n’est pas pertinent pour toutes les organisations. Avant de construire, vérifiez ces conditions :

Vous avez au moins 15-20 développeurs. En dessous, les problèmes se résolvent par la communication directe. Un IDP pour 5 devs est de l’over-engineering

La douleur est ressentie et mesurée. Si les développeurs ne se plaignent pas du temps perdu en config et tickets, soit votre DevOps actuel fonctionne bien, soit les devs ne savent pas que c’est anormal. Mesurez avant de construire

Vous avez un socle cloud raisonnable. Un IDP automatise le provisioning. S’il n’y a pas de cloud (même basique), il n’y a rien à automatiser. Kubernetes n’est pas un prérequis, Terraform + un cloud provider suffit

Vous avez 2-3 personnes dédiées pendant 6 semaines. Un IDP ne se construit pas “en plus du reste” par un SRE débordé. C’est un projet avec des livrables et un calendrier

Si ces conditions sont réunies, passons au concret

Semaine 1 : Cadrage et sponsorship

Avant de choisir un outil, cadrez avec un sponsor executif (VP Engineering ou CTO) les 3 métriques de succès de l’IDP et obtenez un engagement de communication interne. Sans ce sponsorship, l’adoption sera un combat permanent. Le sponsor doit communiquer publiquement que l’IDP est la voie officielle, pas une option parmi d’autres

Semaine 1-2 : Choisir le socle

Backstage vs Port vs Humanitec

Le choix du socle est la première décision. Elle conditionne le reste

Critère	Backstage (Spotify)	Port	Humanitec
Type	Open-source (React + Node)	SaaS	SaaS
Flexibilité	Maximale (plugins custom)	Bonne (API extensible)	Limitée (opinions fortes)
Time-to-value	3-4 semaines	1-2 semaines	1-2 semaines
Coût	Gratuit + hébergement + dev	~500-2000$/mois	~1000-3000$/mois
Compétences requises	React + TypeScript	Configuration YAML	Configuration UI
Catalogue de services	Natif (YAML descriptors)	Natif (blueprints)	Via intégrations
Communauté	Large (CNCF, 2000+ plugins)	Croissante	Plus petite

Pour une ETI avec 20-50 devs et peu de compétences React : Port. Déploiement rapide, self-service immédiat, et l’API permet d’étendre quand les besoins évoluent

Pour une organisation 50+ devs avec une équipe plateforme dédiée : Backstage. La flexibilité des plugins justifie l’investissement en développement. Mais soyez lucides : Backstage est puissant et exigeant. La communauté CNCF est large, mais les plugins tiers sont de qualité inégale (certains cassent à chaque mise à jour). Prévoyez 20 à 30% du temps de votre équipe plateforme en maintenance de Backstage lui-même. Ce coût est souvent sous-estimé. Concrètement, sur une équipe plateforme de 3 personnes, 1 ETP est absorbé par la maintenance Backstage (plugins, mises à jour, support interne). C’est le prix de la flexibilité open-source. Si vous n’avez pas une équipe de 2+ personnes dédiées à la plateforme, Port est un choix plus réaliste

Pour un focus infrastructure/cloud sans catalogue de services : Humanitec. Mais c’est plus un orchestrateur d’infra qu’un IDP complet

Ce qu’on fait en semaine 1-2

• Jour 1-2 : POC sur l’outil choisi (installer, configurer, créer un premier service)
• Jour 3-5 : Inventorier les services existants et les importer dans le catalogue
• Jour 6-8 : Connecter le SSO et les permissions de base
• Jour 9-10 : Démo à l’équipe dev, recueillir le feedback

Le piège : passer 4 semaines à évaluer les 3 outils. En 2 jours de POC sur chacun, vous avez assez d’information pour décider. Le meilleur outil est celui que votre équipe adopte, pas celui qui gagne le benchmark

Semaine 3-4 : Les 3 Golden Paths prioritaires

Un Golden Path est un workflow standardisé et self-service pour une tâche fréquente. Pas besoin de 20 Golden Paths au lancement. Trois suffisent pour couvrir 80% des besoins quotidiens

Golden Path 1 : Créer un nouveau service

Avant : un développeur qui veut créer un nouveau microservice passe 2 à 3 jours à configurer manuellement le repo Git, le CI/CD, le Dockerfile, le Helm chart, les variables d’environnement, les secrets, et le monitoring. Il oublie toujours quelque chose (le health check, le label de coût, le scan de sécurité)

Après : le développeur va sur le portail IDP, sélectionne “Nouveau service”, choisit le langage (Python/Java/Node), et clique. En 5 minutes, il a un repo avec le code skeleton, la CI/CD configurée, le déploiement automatique en dev, et le monitoring intégré. Tout conforme aux standards de l’organisation.

Implémentation : un template (Backstage Software Template, Port Blueprint, ou simplement un script Terraform + Cookiecutter) qui provisionne le repo, configuré la CI, et déploie le scaffold. 3-5 jours de développement. Ce temps couvre le scaffold du template, le pipeline CI/CD associé, et la documentation. Il n’inclut pas les tests d’adoption (compter 2-3 jours supplémentaires de feedback et itérations avec les premiers utilisateurs)

Golden Path 2 : Déployer en production

Avant : pousser du code en production implique 5 à 8 étapes manuelles (merge, attendre la CI, vérifier les tests, checker les approbations, déclencher le déploiement, vérifier le rollback, mettre à jour le changelog). Chaque équipe fait différemment

Après : une pipeline standardisée. Merge sur main → CI automatique → tests → scan sécurité → déploiement canary → promotion progressive → rollback automatique si les métriques dégradent. Le développeur voit l’état du déploiement en temps réel dans le portail

Implémentation : standardiser la pipeline CI/CD (GitHub Actions, GitLab CI, ou ArgoCD pour les plus matures). 5-8 jours si vous partez de pipelines disparates, 2-3 jours si vous avez déjà une base commune

Golden Path 3 : Provisionner une base de données

Avant : un ticket Jira au DBA, 3 à 5 jours d’attente, des allers-retours sur la configuration (taille, backup, retention), et un script SQL envoyé par email

Après : le développeur sélectionne “Nouvelle BDD” dans le portail, choisit le type (PostgreSQL/MySQL/Redis), la taille (S/M/L, avec les coûts affichés), et valide. La base est provisionnée en 10 minutes avec backup automatique, monitoring intégré, et les credentials dans le gestionnaire de secrets

Implémentation : un module Terraform paramétré exposé via le portail IDP. Inclure les guardrails (taille max, politique de backup, tagging de coût obligatoire). 3-5 jours de développement

Semaine 5-6 : Self-service, adoption et métriques

Onboarding automatisé

Le premier test d’un IDP, c’est le onboarding d’un nouveau développeur. Si un dev qui arrive le lundi peut faire son premier commit en production le mercredi, votre IDP fonctionne

Automatisez :

• Création des accès (SSO → permissions automatiques selon le rôle)
• Provisioning de l’environnement de développement (IDE cloud ou script de setup local)
• Documentation “Getting Started” intégrée au portail (pas dans un Confluence que personne ne trouve)
• Premier exercice : déployer un changement trivial via le Golden Path 2

Les métriques de succès

Mesurez avant de déployer l’IDP (baseline) et après (semaine 6, puis mensuellement) :

Métrique	Baseline typique	Objectif semaine 6	Objectif 3 mois
Onboarding time	2 semaines	3 jours	2 jours
Tickets infra/mois	40-60	20-30	< 15
Temps de création service	2-3 jours	30 min	10 min
DORA deploy frequency	1x/semaine	2x/semaine	1x/jour
DORA lead time	5-10 jours	2-3 jours	< 1 jour

Important : ces objectifs supposent que l’IDP est accompagné d’un changement organisationnel : suppression des demandes manuelles d’accès, self-service réel, décommissionnement des process Jira historiques. Sans ce volet orga, les gains sont plus modestes : onboarding 2 semaines -> 1 semaine, tickets infra divisés par 1.5 (pas par 3), deployment frequency multipliée par 2 (pas par 5). L’IDP technique livre 30 à 40% du gain ; les 60 à 70% restants viennent de l’adoption et de la suppression des contournements

Si les métriques ne bougent pas après 6 semaines, le problème n’est pas technique, c’est l’adoption

Les erreurs qu’on a faites

Trop d’ambition au départ. Un premier IDP a été conçu pour couvrir 12 workflows. À la semaine 8, rien n’était fini. La deuxième version s’est concentrée sur 3 Golden Paths. Elle était en production à la semaine 5

Pas assez de sponsorship management. Les développeurs n’adoptent un IDP que si leur tech lead l’utilise en premier. Si le management continue d’approuver les tickets Jira manuels “parce que c’est plus rapide pour cette fois”, l’IDP meurt. Le sponsorship CTO/VP Engineering est non négociable

Métriques oubliées. Sans baseline, impossible de prouver la valeur. Un DSI a demandé “quel est le ROI de l’IDP ?” et personne n’avait mesuré le temps avant/après. Mesurez toujours la baseline avant de commencer

Golden Paths trop rigides. Les développeurs contournent les Golden Paths si ceux-ci sont trop restrictifs. Un Golden Path qui interdit tout customisation est un mur, pas un chemin. Laissez une porte de sortie documentée (“si tu as besoin de faire X qui n’est pas dans le Golden Path, voici comment, mais attention à Y”)

L’IDP n’est pas un projet, c’est un produit

La plus grande erreur est de traiter l’IDP comme un projet avec une date de fin. Un IDP est un produit interne qui évolue avec les besoins des développeurs. Les 6 semaines ne sont que le MVP. Ensuite :

• Mois 2-3 : ajouter 2-3 Golden Paths supplémentaires basés sur le feedback
• Mois 4-6 : intégrer le monitoring et l’observabilité dans le portail
• Mois 6+ : self-service pour les secrets, les certificats, les environnements éphémères

Traitez votre équipe plateforme comme une équipe produit : backlog priorisé, feedback utilisateurs, itérations régulières, et un product owner identifié

Sources et méthodologie

• DORA State of DevOps Report 2024 : données sur le temps passé en glue work et les métriques de performance des équipes (deployment frequency, lead time, MTTR)
• SPACE Framework (2021) : modèle de mesure de la productivité développeur (Satisfaction, Performance, Activity, Communication, Efficiency)
• Backstage.io / CNCF : documentation officielle et retours communautaires sur les coûts de maintenance
• Retours d’expérience Nobori : données issues de nos missions de conseil en Platform Engineering auprès d’ETI et grands comptes (métriques avant/après anonymisées)

Les chiffres de coûts et de gains présentés dans cet article sont des ordres de grandeur issus de nos missions et de la littérature. Ils varient significativement selon la taille de l’organisation, sa maturité DevOps et son contexte technique

---

Vous voulez évaluer si un IDP est pertinent pour votre organisation ? Notre audit platform engineering analyse votre maturité DevOps, identifie les bottlenecks, et propose une roadmap IDP adaptée à votre contexte