Le platform engineering est la pratique qui consiste à concevoir et à fournir une plateforme interne aux équipes de développement : un ensemble intégré de capacités (environnements, pipelines, bases de données, observabilité, gestion des secrets) exposées selon les besoins de ses utilisateurs 1. Pour construire une plateforme utile, la règle est simple à énoncer et difficile à tenir : la traiter comme un produit, partir des irritants réels des équipes, livrer la couche la plus fine possible, puis mesurer son adoption et son effet sur la livraison logicielle.
Le sujet n'est plus marginal. Le rapport DORA 2025 indique que 90 % des organisations interrogées ont adopté au moins une plateforme interne et relève une corrélation directe entre la qualité de cette plateforme et la capacité à tirer de la valeur de l'IA 3. Mais l'édition 2024 du même programme de recherche rappelait qu'une plateforme améliore la productivité individuelle et la performance des équipes tout en pouvant dégrader le débit et la stabilité des changements si elle est mal conçue 4.
Autrement dit, le platform engineering n'est pas un achat d'outil. C'est une décision d'organisation, avec une équipe dédiée, une feuille de route et des utilisateurs à convaincre. Cet article propose une démarche concrète, appuyée sur les travaux du groupe de travail Platforms de la CNCF.
Platform engineering : de quoi parle-t-on exactement ?
La CNCF définit une plateforme comme une collection intégrée de capacités, définies et présentées en fonction des besoins de ses utilisateurs internes, qui offre une expérience cohérente pour obtenir et intégrer des services communs 1. Le platform engineering couvre l'ensemble de ce qui permet de la planifier et de la fournir : personnes, processus, politiques, technologies et objectifs métier 2.
Deux précisions évitent bien des malentendus. D'abord, l'équipe plateforme n'a pas vocation à tout construire : le livre blanc de la CNCF recommande de s'appuyer sur des fournisseurs externes ou d'autres équipes internes chaque fois que c'est possible, et de ne développer une capacité que lorsqu'aucune n'existe 1. Ensuite, une plateforme peut être très mince. Le même document admet qu'un simple wiki décrivant les procédures de provisionnement peut constituer une première plateforme 1.
Une plateforme interne se juge à ce qu'elle retire de la charge cognitive des équipes, pas au nombre d'outils qu'elle agrège.
Le platform engineering n'est donc ni un renommage de l'équipe d'exploitation, ni un projet Kubernetes. C'est une interface négociée entre ceux qui opèrent les capacités communes et ceux qui livrent les applications métier.
Les attributs d'une plateforme interne réussie
Le livre blanc Platforms de la CNCF identifie sept attributs qui distinguent une plateforme adoptée d'une plateforme imposée 1. Ils servent de grille de revue de conception :
- Plateforme comme produit : elle est conçue à partir des besoins de ses utilisateurs et priorise les cas d'usage les plus fréquents.
- Expérience utilisateur : des interfaces cohérentes (portail, API, CLI, intégration IDE) adaptées à chaque profil.
- Documentation et prise en main : exemples, modèles et chemins balisés (golden paths) permettant de démarrer vite.
- Libre-service : les capacités s'obtiennent à la demande, avec un minimum d'intervention manuelle.
- Réduction de la charge cognitive : les détails d'implémentation sont masqués et les équipes n'opèrent pas elles-mêmes les services.
- Optionnelle et composable : chaque équipe utilise ce dont elle a besoin et peut apporter ses propres briques.
- Sécurisée par défaut : la conformité et les contrôles sont intégrés au chemin standard, pas ajoutés après coup.
L'attribut le plus souvent négligé est le caractère optionnel. Une plateforme rendue obligatoire par décision hiérarchique obtient une adoption de façade, puis des contournements. Le livre blanc insiste sur ce point : la plateforme se développe avec ses utilisateurs, pas par mandat descendant 1.
Choisir les premières capacités de la plateforme
Le livre blanc recense treize domaines de capacités, des portails web au stockage d'artefacts en passant par l'automatisation du build, la livraison, les environnements de développement, l'observabilité, les services d'infrastructure et de données, la messagerie, l'identité et les secrets 1. Vouloir tous les couvrir dès le départ est la meilleure façon d'échouer.
La recommandation de la CNCF est de choisir soigneusement les premières capacités (les pipelines, les bases de données et l'observabilité sont des points de départ fréquents) et de commencer avec quelques équipes applicatives volontaires 1. En pratique, le bon critère de sélection est le temps perdu : quelles demandes reviennent sans cesse dans les tickets, quelles étapes bloquent une mise en production, quels contrôles de sécurité sont refaits à la main à chaque projet ?
Le portail développeur : une interface, pas la plateforme
Le portail développeur concentre souvent l'attention. Backstage, présenté par la CNCF comme une plateforme ouverte pour construire des portails développeurs, y est entré en 2020 et a atteint le niveau Incubating en mars 2022 5. Un portail apporte un catalogue de services, des modèles de création de projet et une documentation centralisée. Mais il n'est qu'une des interfaces possibles : sans capacités en libre-service derrière lui, il devient une vitrine de liens. Il est souvent plus rentable de commencer par un modèle de projet et un pipeline standardisés, puis d'ajouter le portail lorsque le catalogue a atteint une taille qui le justifie.
Organiser l'équipe plateforme et piloter la maturité
Le modèle de maturité publié par le groupe de travail Platforms de la CNCF en novembre 2023 décrit cinq aspects (investissement, adoption, interfaces, opérations, mesure) et quatre niveaux pour chacun 6. L'investissement passe d'un effort provisoire à une équipe dédiée, puis à une gestion en produit ; l'adoption va d'un usage erratique à une adhésion volontaire, puis participative ; les interfaces évoluent de processus sur mesure vers des services en libre-service intégrés 2.
Les auteurs mettent en garde contre la tentation de viser le niveau le plus élevé partout : cela peut être coûteux, voire contre-productif. Le modèle sert à situer l'état actuel, à définir l'état souhaité aspect par aspect et à concentrer l'investissement là où il aura le plus d'effet 6.
Côté organisation, les responsabilités d'une équipe plateforme dépassent l'ingénierie : recherche utilisateur, feuille de route, promotion de la plateforme auprès des équipes, gestion des interfaces et de la documentation 1. Un rôle de product owner plateforme, explicitement nommé, est un bon indicateur de sérieux.
Mesurer la valeur du platform engineering
Sans mesure, une plateforme se défend mal en comité budgétaire. Le livre blanc de la CNCF propose trois familles d'indicateurs 1 :
- Satisfaction et productivité des utilisateurs : nombre d'utilisateurs actifs et rétention, enquêtes de type NPS, indicateurs de productivité (par exemple le cadre SPACE).
- Efficacité organisationnelle : délai entre une demande et sa satisfaction, temps de mise en service d'un nouveau service, temps nécessaire à un nouvel arrivant pour soumettre sa première modification.
- Livraison logicielle : les quatre indicateurs DORA, soit fréquence de déploiement, délai de mise en production des changements, temps de rétablissement et taux d'échec des changements.
Le dernier groupe est indispensable pour détecter l'effet pervers documenté par DORA en 2024 : une plateforme qui centralise trop peut ralentir les équipes et dégrader la stabilité 4. Mesurer avant le lancement, puis à chaque incrément, permet de corriger la trajectoire avant que la plateforme ne devienne un goulet d'étranglement.
Checklist pour lancer une plateforme interne
- Interviewer cinq à dix équipes applicatives et lister les irritants qui coûtent le plus de temps.
- Nommer une équipe plateforme dédiée et un responsable produit, avec un budget pluriannuel.
- Choisir deux ou trois capacités initiales et un premier golden path de bout en bout (création de projet, pipeline, déploiement, supervision).
- Recruter deux équipes pilotes volontaires et co-construire avec elles.
- Intégrer les contrôles de sécurité et de conformité dans le chemin standard plutôt que dans des revues manuelles.
- Mesurer la situation de départ (indicateurs DORA, délais de provisionnement) avant toute mise en service.
- Auto-évaluer la maturité avec le modèle CNCF tous les six mois et ajuster la feuille de route.
Conclusion
Une plateforme interne réussie ne se voit presque pas : elle rend le bon chemin plus simple que le contournement. Elle exige une posture produit, des choix de capacités modestes au départ et une mesure honnête de son effet sur la livraison. DATASWING accompagne ce type de démarche en partant des équipes et de leur existant, avant tout choix d'outillage.
— Questions fréquentes
Ce qu'on nous demande souvent
Quelle différence entre platform engineering et DevOps ?+
DevOps est une culture et un ensemble de pratiques qui rapprochent développement et exploitation. Le platform engineering en est une mise en œuvre organisationnelle : une équipe dédiée fournit, sous forme de produit interne, les capacités communes en libre-service (pipelines, environnements, observabilité). Les équipes applicatives gardent leur autonomie sans devoir maîtriser chaque outil sous-jacent, ce qui réduit leur charge cognitive.
Faut-il obligatoirement Backstage pour faire du platform engineering ?+
Non. Backstage est un projet CNCF de niveau Incubating qui sert à construire des portails développeurs, mais le portail n'est qu'une interface de la plateforme. Une plateforme peut démarrer avec des modèles de projet, un pipeline standard et une documentation claire. Le portail devient pertinent lorsque le nombre de services et d'équipes rend un catalogue centralisé réellement utile.
Comment mesurer le retour sur investissement d'une plateforme interne ?+
Combinez trois familles d'indicateurs : adoption et satisfaction des développeurs, efficacité (délai de provisionnement, temps de mise en service d'un nouveau service, temps avant la première contribution d'un nouvel arrivant) et indicateurs DORA de livraison logicielle. Mesurez la situation de départ avant le lancement pour pouvoir démontrer l'écart, et surveillez la stabilité des changements.
Quelle taille doit avoir une équipe plateforme ?+
Il n'existe pas de ratio de référence fiable. Le modèle de maturité CNCF montre plutôt une progression : effort provisoire, puis équipe dédiée, puis gestion en produit. L'essentiel est de dimensionner l'équipe sur un périmètre de capacités limité, avec un responsable produit identifié, plutôt que de couvrir trop de domaines avec trop peu de personnes.
— Sources
Références citées
Les textes réglementaires et documentations évoluent : vérifiez la version en vigueur avant toute décision. Cet article n'est pas un avis juridique.
-
[1]
CNCF Platforms White Paper ↗CNCF TAG App Delivery · 2023-04
-
[2]
Platform Engineering Maturity Model ↗CNCF TAG App Delivery · 2023-11
-
[3]
Announcing the 2025 DORA Report ↗Google Cloud · 2025-09
-
[4]
Accelerate State of DevOps Report 2024 ↗DORA · 2024
-
[5]
Backstage – project page ↗CNCF · 2022
-
[6]
Announcing the Platform Engineering Maturity Model ↗CNCF TAG App Delivery · 2023-11
