Du DevOps au platform engineering : industrialiser l'expérience développeur

Un développeur productif est un développeur qui consacre l'essentiel de son attention au domaine métier et au code, pas à la plomberie. Or l'empilement des responsabilités — conteneurisation, orchestration, infrastructure as code, chaînes de livraison, observabilité, sécurité, conformité — dépasse ce qu'une équipe produit peut raisonnablement maîtriser en profondeur. Le résultat se lit partout où ce modèle a été poussé trop loin : des dizaines de variantes de pipelines, des configurations Kubernetes copiées-collées sans être comprises, et des experts d'infrastructure recrutés dans chaque équipe pour faire le même travail en parallèle. Centraliser cette complexité n'est pas un retour en arrière : c'est une division du travail raisonnée.

Une plateforme de développement interne (IDP) regroupe en libre-service ce dont les équipes ont besoin pour livrer : création d'un nouveau service à partir de modèles approuvés, chaînes de livraison standardisées, environnements à la demande, observabilité et gestion des secrets intégrées d'office. Le point décisif n'est pas l'outillage — Backstage et ses équivalents ne sont que des supports — mais la posture : la plateforme est un produit, avec des utilisateurs (les équipes de développement), une feuille de route pilotée par leurs besoins réels, et des indicateurs d'adoption. Une plateforme construite en chambre, imposée d'en haut et déconnectée des irritants quotidiens, rejoint invariablement la liste des grands projets d'outillage abandonnés.

Le concept opérant est celui du golden path : pour chaque besoin courant — créer un service, déployer, exposer une API, provisionner une base — un chemin balisé, documenté et maintenu, qui intègre d'office les exigences de sécurité et de conformité. L'équipe qui suit le chemin balisé bénéficie du support de la plateforme ; celle qui a un besoin légitime de s'en écarter le peut, en assumant la charge correspondante. Cet équilibre est essentiel : une plateforme obligatoire et rigide pousse les équipes au contournement, une plateforme purement optionnelle ne standardise rien. La qualité du chemin par défaut — sa simplicité, sa rapidité, sa documentation — est ce qui rend la standardisation désirable plutôt que subie.

La démarche raisonnable ne commence pas par un portail : elle commence par une enquête. Quels sont les trois irritants qui coûtent le plus de temps aux équipes ? Le plus souvent : créer un nouveau projet conforme, obtenir un environnement de test, comprendre pourquoi un déploiement a échoué. Traiter ces trois irritants de bout en bout apporte plus de valeur qu'un catalogue exhaustif à moitié fonctionnel. Côté pilotage, les indicateurs utiles sont ceux de l'expérience développeur : délai entre l'idée et la mise en production, temps d'intégration d'un nouvel arrivant, part du temps passée sur l'infrastructure plutôt que sur le produit.

Le platform engineering n'enterre pas le DevOps : il en est la forme industrialisée. La culture de responsabilité demeure ; ce qui change, c'est que l'organisation cesse de demander à chaque équipe de réinventer le socle, pour lui offrir un point de départ éprouvé sur lequel concentrer son talent.