Tout sur le platform engineering : pourquoi c’est nécessaire, comment le construire et à quoi ressemble le succès

• En tant que discipline organisationnelle qui construit et exploite des produits internes avec les ingénieurs internes comme utilisateurs, c’est un domaine fondamentalement différent d’un simple rebranding de DevOps ou de l’administration de clusters Kubernetes
• Selon le rapport DORA 2025, 90 % des organisations ont adopté au moins une plateforme interne, et la qualité de la plateforme s’impose comme un indicateur qui prédit directement la capacité des outils d’IA à créer de la valeur
• Alors que le cloud et l’open source fournissent une infinité de primitives, sa raison d’être centrale est de résoudre le problème du « marécage de la surgénéralisation (over-general swamp) », où chaque équipe construit ses propres pipelines de son côté
• Traiter la plateforme comme un véritable produit, et la doter d’abstractions logicielles, d’un registre de métadonnées et de SLO opérationnels pour le développeur médian, constitue la condition structurelle du succès
• Une bonne plateforme fonctionne de façon si naturelle que les développeurs en oublient son existence, et une mauvaise plateforme amplifie la confusion des outils d’IA, tandis qu’une bonne plateforme amplifie le débit

---

Pourquoi le platform engineering existe

• Le marécage de la surgénéralisation (Over-General Swamp)

  • Le cloud et l’OSS fournissent une infinité de primitives — queues, object stores, bases de données, runners CI, service mesh, etc. — ce qui pousse chaque équipe applicative à faire des choix différents
  • Un an plus tard, tous les services dérivent vers un marécage de glue code où chacun possède son propre pipeline de déploiement, sa logique de retry, ses conventions de monitoring et des bindings IAM subtilement incorrects
  • Deux causes sont à l’origine de ce marécage : l’explosion du nombre d’options et des exigences opérationnelles plus élevées (disponibilité 24/7, sécurité, conformité, maîtrise des coûts)
  • Dans un projet réel de landing zone, on a vu 20 équipes réinventer séparément des modules Terraform presque identiques pour le VPC, l’IAM et les alertes budgétaires, chacun avec des bugs différents

• Les quatre choses que fait réellement le platform engineering

  • Limiter les primitives visibles par les développeurs pour les orienter vers un usage maîtrisé et curé
  • Absorber les travaux répétitifs de plomberie dans des services partagés afin de réduire le glue code spécifique à chaque application
  • Lorsqu’une primitive sous-jacente change, faire en sorte que l’équipe plateforme ne le traite qu’une seule fois, afin de centraliser le coût des migrations
  • Permettre aux développeurs d’exploiter eux-mêmes ce qu’ils construisent sans devoir devenir experts du noyau Linux
  • DevOps disait : « les développeurs doivent posséder l’exploitation » ; le platform engineering dit : « nous allons fournir comme un vrai produit de bons outils pour cette exploitation »
  • La page des capacités DORA 2025 le définit elle aussi comme une discipline sociotechnique, et non comme une catégorie d’outils

Les cinq piliers (Pillars)

• Approche produit curée (Curated Product Approach)

  • Déterminer intentionnellement ce que la plateforme prend en charge et ce qu’elle ne prend pas en charge
  • Quand une équipe veut Kafka plutôt que Pub/Sub, ne pas répondre « voici le lien vers la documentation », mais indiquer le périmètre supporté, la raison de ce choix et la voie de sortie si cela ne convient pas
  • Dire non fait aussi partie du travail

• Abstractions fondées sur le logiciel (Software-Based Abstractions)

  • Une plateforme n’est pas un wiki mais un logiciel, dont les interfaces sont des API, CLI et SDK
  • Un développeur doit pouvoir provisionner un service de niveau production en n’écrivant qu’un petit fichier déclaratif
  • Le projet Score de la CNCF en est un exemple représentatif : avec une seule spécification de workload, il provisionne automatiquement base de données, topic, compte de service et déploiement
    • Le développeur n’a pas besoin de savoir si, en interne, il s’agit de Cloud SQL, Pub/Sub ou Cloud Run

• Personnalisation OSS et registre de métadonnées

  • Au lieu d’utiliser Argo CD ou Backstage bruts, il faut les exploiter avec des plugins, des politiques par défaut et des intégrations adaptés à l’organisation
  • Sans registre de métadonnées (catalogue de services), il est impossible de savoir qui possède quoi, quelles sont les dépendances et ce qui s’exécute réellement
  • Backstage est le framework OSS standard de fait de cette couche, utilisé en production dans plus de 270 organisations
    • La CNCF a lancé les certifications Certified Backstage Associate et Certified Cloud Native Platform Engineering Associate
    • Qu’on utilise Backstage, Port, Cortex ou autre, il faut une source unique de vérité (single source of truth) sur « quels services existent, qui en est propriétaire et quelles sont les dépendances »

• Service pour une large base d’utilisateurs

  • Les plateformes internes ont souvent un petit nombre de clients très bruyants, mais leur objectif est surtout de bien servir les tâches médianes du développeur médian
  • Si l’on construit seulement pour les utilisateurs d’élite, le reste des équipes contournera la plateforme, faisant émerger des plateformes de l’ombre

• Exploitation comme une fondation

  • Si la plateforme tombe, l’entreprise tombe avec elle ; cela implique donc astreinte 24/7, vrais SLO, vraie gestion du changement et charge de support
  • Elle ne joue pas le rôle d’un « outil », mais celui du « sol », sur lequel tout ce qui est construit suppose que ce sol tiendra

Quand et comment commencer

• Ne pas créer une équipe plateforme trop tôt

  • À l’échelle de 10 ingénieurs, il faut de la coopération, pas une équipe plateforme
    • Qu’une personne gère les scripts de déploiement, une autre Terraform, et qu’on s’accorde sur des conventions suffit
  • Si l’on forme une équipe trop tôt avec 1 ou 2 personnes, elles deviennent une file de tickets, et le reste de l’organisation devient passif
  • En général, au-delà de 50 ingénieurs, quand les cibles de déploiement se multiplient et que plus personne ne connaît la bonne réponse à « comment déployer un nouveau service », la création d’une équipe devient pertinente

• Transformer une organisation infra existante

  • Lorsqu’on transforme une équipe infrastructure/SRE en organisation plateforme, la partie la plus difficile n’est pas la technique mais la culture
  • Les responsables infra sont habitués au rôle de gardiens du « non », alors que les responsables plateforme doivent devenir ceux qui rendent le “oui” facile
    • Parler souvent avec les clients
    • Recruter et faire grandir des ingénieurs logiciels qui aiment aussi construire des outils, et pas seulement des opérateurs
    • Mettre à jour le système de récompense pour que « rendre 200 équipes 5 % plus rapides » soit davantage reconnu que « déployer un nouveau cluster »
  • Le mode d’échec le plus fréquent consiste à saupoudrer un PM par-dessus et s’arrêter là : cela produit non pas une plateforme, mais du théâtre

Construire une équipe plateforme

• Quatre rôles

  • Software Engineer : construit la surface produit de la plateforme — API, SDK, portail, etc.
  • Systems Engineer : maîtrise les primitives sous-jacentes comme Kubernetes, Linux, le réseau et les control planes cloud
  • Reliability Engineer : se concentre sur la qualité opérationnelle, l’astreinte, les SLO et l’observabilité
  • Systems Specialist : expert de domaine approfondi sur les bases de données, la sécurité, le réseau, etc.
  • Si l’accent est trop mis sur le logiciel, on obtient un beau portail qui s’effondre sous une charge réelle ; s’il est trop mis sur les systèmes, on obtient un cluster solide que personne ne peut utiliser sans ticket

• Recrutement

  • Il faut recruter en donnant la priorité absolue à l’empathie client (customer empathy)
  • Un ingénieur incapable, après un échange avec un développeur applicatif frustré, d’en ressortir avec une compréhension claire du problème n’est pas adapté
  • L’excellence technique sans empathie produit une plateforme exacte mais que personne n’utilise
  • Pour les rôles logiciels, on peut utiliser la même matrice de niveaux, mais pour les spécialistes systèmes, comme la valeur marché et les compétences se mappent mal sur la grille des software engineers, il faut autoriser des intitulés flexibles

• Managers et autres rôles

  • Trois caractéristiques communes d’un excellent manager en platform engineering : une expérience réelle d’exploitation de plateforme, une expérience de livraison de projets longs sur plusieurs trimestres, et une obsession du détail
    • La plateforme récompense le détail : les cas à 1 % qui paraissent rares mais qu’on a sautés finissent par représenter 80 % du temps de support
  • PM, technical writer, developer advocate et support engineer sont tous importants, mais il faut les recruter une fois que l’équipe d’ingénierie est suffisamment mûre
  • Un PM injecté trop tôt dans une équipe plateforme de 4 personnes ne sera qu’une chaise en forme de roadmap

La plateforme comme produit

• Les clients internes sont plus difficiles

  • Les clients internes sont des utilisateurs captifs qui ont du mal à partir, avec des opinions tranchées et un faible sens du produit
  • Ils expriment ce qu’ils veulent (want), mais cela diffère souvent de ce dont ils ont réellement besoin (need)
  • Ils demandent que la plateforme fasse leur travail à leur place, plutôt que des outils leur permettant de mieux faire leur travail
  • Le vrai backlog consiste à s’asseoir à côté d’eux et à observer combien de changements de contexte ils effectuent pour déployer une seule modification

• Discovery, roadmap et modes d’échec

  • La discovery d’une plateforme se fait via des pilotes, pas avec des tests A/B, en travaillant avec des équipes réceptives et en mesurant la réduction du lead time après un vrai déploiement
  • Les quatre horizons temporels d’une roadmap
    • Vision (pluriannuel) : la direction de la plateforme
    • Strategy (annuel) : les paris de l’année
    • Goals and Metrics (trimestriel à annuel) : la définition du succès
    • Milestones (trimestriel) : ce qui sera effectivement livré
  • Les modes d’échec qui font souvent dérailler les équipes
    • Sous-estimer le coût des migrations (toujours 2 à 3 fois plus élevé que prévu)
    • Surestimer le budget de changement des utilisateurs pour les nouvelles fonctionnalités
    • Se concentrer sur l’ajout de fonctionnalités alors que le vrai problème est la stabilité
    • Avoir trop de PM par rapport à la taille de l’équipe d’ingénierie (2 PM pour 5 ingénieurs, c’est un problème)

Exploitation de la plateforme

• L’astreinte n’est pas optionnelle

  • Puisqu’on opère une fondation, la couverture 24/7 est non négociable
  • Le principe "you build it, you run it" s’applique aussi ici, non comme une punition mais comme une boucle de feedback
  • Si un seul ingénieur reçoit des pages plusieurs fois par semaine, il faut corriger le système, pas le planning
  • Un ingénieur plateforme en burn-out déploie une mauvaise plateforme

• Support : la moitié cachée du travail

  • C’est un sujet rarement abordé en conférence, mais il représente la moitié essentielle du platform engineering
  • Un framework en quatre étapes
    • Étape 1 : formaliser les niveaux de support (P0 vs P3, temps de réponse, etc.)
    • Étape 2 : séparer le support non critique de l’astreinte pour qu’une question comme « comment ajouter un CronJob » ne réveille personne
    • Étape 3 : quand le volume le justifie, recruter un spécialiste support dédié
    • Étape 4 : construire une organisation de support engineering adaptée à l’échelle
  • Si l’étape 1 est sautée, les ingénieurs passent la moitié de leur temps à répondre à des DM Slack et l’autre moitié à se plaindre

• Feedback opérationnel

  • Les SLO et SLA sont indispensables ; les error budgets sont utiles mais facultatifs
  • Le monitoring synthétique capte les modes d’échec avant que les utilisateurs n’ouvrent un ticket
  • Les revues opérationnelles ne consistent pas à jeter un œil à un dashboard au vert, mais à imposer l’examen de données réelles
  • Dans les données DORA 2025, la capacité plateforme la plus corrélée à l’expérience utilisateur était un feedback clair sur le résultat du travail — en cas d’échec, l’utilisateur doit savoir exactement ce qui a échoué et quoi faire

Planification et delivery

• Les projets de long terme ont besoin d’un document de proposition

  • Les projets plateforme comme les migrations, les réarchitectures ou un nouveau control plane prennent des trimestres entiers
  • Les éléments indispensables d’une bonne proposition : le problème à résoudre, les bénéficiaires, le périmètre, ce qui est explicitement hors périmètre, et la définition du succès
  • Écrire d’abord le document, le faire relire, puis le transformer en plan d’exécution avec des jalons concrets avant d’écrire du code
  • Le mode d’échec du « long slog » — un projet qui traîne pendant des années et dont plus personne ne se souvient de la raison d’être — est presque toujours le résultat d’avoir sauté cette étape

• Planification bottom-up de la roadmap

  • Les quatre types de travail dans une roadmap plateforme : KTLO (keep-the-lights-on), injonctions de la direction, améliorations système décidées en interne, demandes directes des clients
  • On ne peut pas prioriser uniquement selon la demande client ; KTLO est prioritaire, les injonctions viennent en second, et le reste exige une discussion honnête avec les parties prenantes

• Succès et défis bimensuels (Biweekly Wins and Challenges)

  • Toutes les deux semaines, rédiger un court document : ce qui a été livré (succès), ce qui bloque (défis), de façon brève, publique et sans exagération
  • Trois effets simultanés : l’équipe exprime clairement sa progression, les parties prenantes voient la réalité du terrain, et les défis sont exposés tôt pour susciter le soutien de la direction
  • Un document qui ne contient que des succès est un document auquel personne ne croit ; il ne faut donc pas omettre les défis

Réarchitecture et migrations

• Réarchitecturer plutôt que faire une v2

  • Quand une plateforme vieillit, le réflexe « faisons une v2 » est presque toujours la mauvaise réponse
  • Pourquoi les projets v2 échouent : gel des investissements sur la v1, durée plus longue que prévu, coût de migration vers la v2 supérieur au coût de réarchitecture qu’elle était censée éviter
  • Réarchitecturer au sein de la plateforme existante, en préservant autant que possible la compatibilité, et utiliser des environnements inférieurs, des rollouts lents et des migrations par tranches
  • Les quatre étapes de planification
    • Voir grand pour l’architecture cible finale
    • Intégrer le coût de migration (toujours multiplié par 2 ou 3)
    • Identifier des résultats majeurs sur 12 mois qui justifient la poursuite de l’investissement
    • Obtenir l’accord de la direction, et être prêt à attendre

• La sécurité est architecturale

  • Il est impossible d’ajouter la sécurité après coup ; l’architecture doit imposer le moindre privilège, l’isolation et la traçabilité dès la conception
  • Si la plateforme exige que chaque équipe se souvienne des bons IAM bindings, alors le problème ne vient pas des équipes, mais d’un bug dans la plateforme

• Migration : un problème difficile systématiquement sous-estimé

  • Les antipatterns les plus courants
    • Donner à toutes les équipes un presse-papiers et une deadline, puis leur demander de migrer par elles-mêmes
    • Donner des ordres sans on-ramp ni off-ramp clairs
    • Sous-estimer la long tail des cas d’usage atypiques
  • Les méthodes d’ingénierie qui facilitent les migrations
    • Suivre les métadonnées d’usage pour identifier précisément les utilisateurs de l’ancienne version
    • Si 200 équipes doivent migrer, c’est l’équipe plateforme qui écrit les scripts, pas les équipes applicatives
    • Concevoir une architecture de migration transparente où le nouveau système utilise l’ancienne API
    • Documenter clairement l’on-ramp pour qu’il soit assez self-service pour les nouvelles équipes
  • Les mandats ne fonctionnent qu’une ou deux fois ; ensuite, ils deviennent du bruit
  • Dans la plupart des cas, la meilleure approche consiste à rendre le nouveau chemin suffisamment bon pour que l’ancien se dessèche naturellement

• Mise hors service (Sunsetting)

  • Il ne faut pas avoir peur de supprimer des produits
  • Un système de déploiement robuste vaut mieux que sept systèmes de déploiement à moitié supportés, et la mise hors service est une caractéristique des équipes matures

Relations avec les parties prenantes

• Matrice pouvoir-intérêt (Power-Interest Grid)

  • Cartographier les parties prenantes selon deux axes : le pouvoir et le niveau d’intérêt
    • Pouvoir élevé, intérêt élevé : mises à jour régulières et concertation
    • Pouvoir faible, intérêt faible : une page de statut suffit
  • Ne perdez pas le temps de l’équipe à informer un VP peu intéressé des upgrades Kubernetes

• Communiquer sans surpartager

  • Soyez transparent, mais sans excès — les dirigeants seniors n’ont pas besoin des débats sur trois stratégies de retry gRPC ; ils doivent connaître l’état d’avancement des jalons et les risques
  • Utiliser les 1:1 avec discernement et suivre les attentes et les engagements de façon visible

• Dire non sans abîmer la relation

  • Rendre l’impact business explicite, par exemple : « si nous ajoutons cette fonctionnalité, la migration sera décalée d’un trimestre, ce qui coûtera $X à l’entreprise »
  • Dire oui avec compromis, refuser tout en proposant un chemin, et parfois tolérer une shadow platform peut coûter moins cher que d’entrer en conflit
  • Pendant la saison budgétaire, présentez les besoins par équipe et par capacité, pas par individu, et ayez un avis tranché sur ce qu’il faut réduire ou maintenir — sinon, la finance décidera à votre place, et se trompera

À quoi ressemble le succès

• Une plateforme alignée (Aligned)

  • Il faut un alignement sur la finalité (pourquoi elle existe), sur la stratégie (des paris cohérents entre les équipes) et sur le plan (pas de conflit entre jalons)
  • Un désalignement apparaît quand toutes les équipes runtime veulent Kubernetes tandis que l’équipe observabilité essaie de supporter tous les frameworks
    • Cela se manifeste par des guides contradictoires pour les clients, du travail en double et des développeurs furieux coincés au milieu
    • La solution passe non par le consensus, mais par un leadership fondé sur des principes

• Une plateforme de confiance (Trusted)

  • La confiance se construit lentement et peut être perdue à cause d’une seule mauvaise migration
  • La confiance se crée dans la manière d’opérer (communication lors d’un incident, respect des engagements), la manière d’investir (déployer réellement les grands paris vendus) et les priorités de livraison
  • Exemple de "plateforme sur-couplée (overcoupled platform)" : trop de logique personnalisée a été ajoutée à la plateforme, si bien que chaque changement prend plusieurs mois — la solution n’est pas plus d’ingénierie, mais une remise en cause des hypothèses sur le périmètre
    • Parfois, un problème de confiance ne vient pas du fait d’en faire trop peu, mais d’en faire trop

• Une plateforme qui maîtrise la complexité

  • La complexité logicielle est inévitable, mais pas la complexité accidentelle (accidental complexity)
  • Il faut distinguer la complexité intrinsèque du problème, la mauvaise coordination humaine, les shadow platforms qui résolvent deux fois le même problème, et la complexité accidentelle créée par une croissance sans fin
  • Trois leviers pratiques
    • Contrôler la croissance : une plateforme qui veut tout supporter ne supporte bien rien du tout, il faut expliciter le périmètre
    • Utiliser la product discovery non seulement pour décider quoi ajouter, mais aussi quoi arrêter
    • Gérer les shadow platforms : quand des équipes créent des solutions parallèles, c’est le signal qu’il manque vraiment quelque chose à la plateforme ou que quelqu’un est en train d’étendre son territoire — dans les deux cas, il faut réagir

• Une plateforme appréciée (Loved)

  • Trois formes
    • L’appréciation "ça marche, tout simplement" : la plupart des utilisateurs ne remarquent même pas la plateforme, les déploiements se font, la CI passe — le côté ennuyeux est le plus beau compliment
    • L’appréciation "effet hack" : de petites joies comme une commande CLI qui fait de manière évidente ce qu’il faut, sans explication supplémentaire
    • L’appréciation "évidente" : scores d’enquête, rétention, adoption organique, recommandation de la plateforme à d’autres équipes
  • Quand une plateforme est appréciée, les gens se battent pour elle quand il faut demander du budget ; quand elle est simplement tolérée, un seul mauvais incident peut la mettre en danger de remplacement

Priorités de terrain

• Ordre approximatif quand on part de zéro ou qu’on reconstruit
  • Priorité n°1 : décider du périmètre de support, puis le documenter et le défendre
  • Priorité n°2 : investir dans des abstractions logicielles plutôt que dans un wiki (Score, Crossplane, SDK maison, bref un logiciel avec une vraie API)
  • Priorité n°3 : construire un registre de métadonnées (avec Backstage, par exemple, pour savoir quoi s’exécute où et à qui cela appartient)
  • Priorité n°4 : construire pour l’équipe médiane, pas pour l’équipe qui fait le plus de bruit
  • Priorité n°5 : traiter l’exploitation comme une fonctionnalité de premier ordre, avec SLO, astreinte, niveaux de support, etc.
  • Priorité n°6 : recruter autant sur la capacité d’empathie que sur les compétences systèmes
  • Priorité n°7 : pratiquer une communication sans concession sur les résultats et défis toutes les deux semaines, une roadmap transparente et une gestion franche des parties prenantes
  • Priorité n°8 : arrêter, consolider et refuser ce qui n’est pas nécessaire
• Comme le montrent régulièrement les données DORA, la qualité de la plateforme est un multiplicateur de tout le reste, y compris de l’adoption de l’IA — une mauvaise plateforme amplifie le chaos des outils d’IA, une bonne plateforme amplifie le débit
• Il faut d’abord construire le sol avant de construire la fusée

[kalista22]

Je pense que la communication interne est plus importante que tout.