Platform engineering : définition et guide pour équipes

Qu'est-ce que le platform engineering ?

Il est 22h10 et une nouvelle embauche essaie d'obtenir un environnement de staging depuis deux jours. Elle a ouvert trois tickets, collé deux fois la même erreur Terraform dans Slack, et elle ne sait toujours pas lequel des quatre templates CI est le bon. Voilà ce qui coince en pratique : le platform engineering, c'est le travail qu'on fait pour construire la route interne pavée, celle où personne ne doit se frayer un chemin seul à travers la jungle, et traiter cette route comme un produit avec des utilisateurs.

Concrètement, une équipe platform construit une internal developer platform (IDP) : des outils en libre-service qui permettent aux autres devs de créer des services, déployer, et vérifier ce qui tourne sans attendre qu'on les aide. Voici ce qui dégénère en pratique quand on saute cette étape : chaque équipe réinvente son déploiement, et le savoir vit dans la tête de trois personnes seules.

Qu'est-ce que le platform engineering, vraiment ?

La définition la plus claire que je connaisse vient de la communauté platformengineering.org : concevoir et construire des platforms qui donnent aux équipes des capacités en libre-service pour les tâches récurrentes de leur travail. Décortiquez le vocabulaire et vous trouvez trois briques.

D'abord, une internal developer platform : ce n'est pas un produit unique qu'on achète. C'est une fine couche de templates, de pipelines, d'APIs et de docs qui s'asseoit sur top des outils que vous tournez déjà (compte cloud, Kubernetes, CI, secrets, monitoring) et qui cache les arêtes vives.

Ensuite, une équipe platform : un petit groupe d'ingénieurs dont les clients sont d'autres ingénieurs. Leur livrable, ce n'est pas des features pour les utilisateurs finaux. C'est la vitesse à laquelle tout le monde peut deployer.

Enfin, une mentalité produit : la platform a des utilisateurs, un backlog, des chiffres d'adoption et une rotation d'astreinte. Si personne ne l'utilise, elle a échoué, peu importe l'élégance de l'architecture.

Gartner prédisait qu'en 2026, 80% des grandes organisations d'engineering logiciel auraient des équipes platform, contre 45% en 2022. Traiter ça comme un marqueur de tendance, pas comme une promesse. La conversation du secteur dit qu'une part importante de ces équipes luttent pour montrer de l'impact, c'est exactement pourquoi le reste de cet article s'attarde sur ce qui déraille.

Platform engineering vs DevOps et SRE ?

Courte version : DevOps c'est une culture, SRE c'est une discipline de fiabilité, et le platform engineering c'est une forme d'équipe qui productize les deux.

DevOps disait que les devs et les ops devraient partager la responsabilité de faire tourner les logiciels. Bonne idée. Dans une startup de 15 personnes ça marche parce que tout le monde voit tout. Dans une boîte de 300 personnes ça se transforme silencieusement en « chaque squad doit aussi devenir expert Kubernetes », ce que personne n'avait signé pour.

SRE, ça se focalise sur les cibles de fiabilité : error budgets, incident response, capacity. Une équipe platform se soucie aussi de la fiabilité, mais sa métrique principale est différente. Elle mesure combien de temps s'écoule entre « j'ai une idée pour un service » et « il tourne en production avec des logs et des alertes ».

Le platform engineering c'est la réponse à la charge cognitive que DevOps a laissée en arrière. Au lieu de demander à chaque dev d'apprendre toute la toolchain, vous lui donnez une default supportée et vous gardez l'expertise à l'intérieur de la platform. Trois raisons de le faire, une de ne pas le faire : ça ne paie que si le nombre d'équipes ou de services est assez grand pour que la duplication blesse. On y revient plus bas.

Qu'est-ce qu'une équipe platform livre réellement ?

Oubliez les diagrams d'architecture. Voici ce que le backlog d'une vraie équipe platform ressemble un mardi ordinaire.

Un template de service : une commande, ou un bouton dans un portail, qui crée un repo avec un pipeline qui marche, un Dockerfile, des health checks, une stack de logs et un dashboard basique. Le dev change la logique business, pas la plomberie.

Un chemin de déploiement : push sur main, les tests tournent, l'artifact est built et promu à travers les envs avec exactement les mêmes steps à chaque fois. Pas de snowflakes par équipe.

Environnement à la demande : un environnement de preview par pull request, détruit automatiquement. C'est la feature pour laquelle les devs vous remercient vraiment.

Secrets et accès : credentials qui expirent vite, un endroit pour les demander, une piste d'audit. C'est ennuyeux, et c'est ce qui vous sauve à un security review.

Observabilité par défaut : chaque service créé depuis le template embarque des métriques, des logs et des traces sans que personne ne les câble. Une stack comme Grafana s'asseoit généralement derrière cette couche, et son free tier et son option open-source conviennent à une petite équipe.

Notez ce qui manque à cette liste : un portail custom-built avec une roadmap de trois mois. Le portail c'est la dernière chose qu'on ajoute, pas la première.

Golden paths : l'idée qui rend le reste possible

Une golden path c'est le moyen supporté, opiné, de faire une tâche fréquente. C'est plus vite que de le faire à la main et plus sûr que d'improviser, et crucialement ça reste optionnel. Les devs peuvent quitter la path quand ils ont une vraie raison. Ils prennent juste la responsabilité qui vient avec.

Il y a une distinction utile dans le write-up d'Octopus sur les paved versus golden paths : une paved road c'est la surface large et bien entretenue, tandis qu'une golden path c'est la route recommandée pour un job spécifique. De mon expérience la différence importe moins que le principe en dessous. On gagne en rendant le bon chemin le chemin facile, pas en bannissant les autres.

Voici à quoi ressemble la plus petite golden path possible. C'est une command de scaffold unique qu'un dev lance une fois :

platform new service payments-api \
  --template node-api \
  --env preview,staging,prod \
  --owner team-checkout

Derrière cette ligne s'asseoit un repo, un pipeline, du DNS, un stub de database, des alertes et un enregistrement d'ownership. La command est triviale. Le dur c'est les six mois à s'accorder sur ce que « node-api » veut dire, et à la tenir à jour quand Node, votre image de base ou votre cloud provider change.

Testée. Pas optimale. Voici pourquoi on la fait quand même : une golden path médiocre utilisée par 80% des équipes bat une parfaite utilisée par 10%, parce que la première vous donne le levier pour améliorer tout à la fois.

Quand ça vaut le coup, quand c'est une distraction ?

C'est la section que la plupart des posts passent sous silence. Le platform engineering n'est pas gratuit, et pour beaucoup d'équipes c'est la mauvaise décision.

Le overview de platformengineering.org suggère que les organisations commencent généralement à en tirer bénéfice une fois passées environ 20 à 30 users platform. Je lirais ça comme un plancher rude, pas une règle. En-dessous, un bon README partagé, un template CI solide et une personne qui s'en soucie vont faire plus qu'une équipe platform formelle.

Ça vaut le coup quand :

• Vous avez plus qu'une poignée d'équipes, et chacune a construit son propre pipeline de déploiement.

• Les nouveaux devs prennent des semaines, pas des jours, pour shipper leur premier changement.

• Le même type d'incident se répète parce que chaque service a câblé ses propres alertes.

• La sécurité ou la compliance demande une cohérence que vous ne pouvez pas livrer juste en demandant poliment.

À laisser de côté quand :

• Vous êtes une équipe de cinq. Écrivez un script, pas une platform.

• Vous ne savez pas encore à quoi ressemblent vos services. Standardiser trop tôt gèle les mauvaises décisions.

• La proposition c'est « construire un portail » sans liste des douleurs qu'il enlève.

Pour les builders solo et les petites crews de side projects, la réalité honnête est plus simple. Vous n'avez pas besoin d'une équipe platform, mais vous avez besoin des habitudes : un script de deploy reproductible, un template pour les nouveaux projets, un dashboard qu'on regarde. C'est une platform d'une personne, et ça vous sauve un weekend par mois.

Les outils que les gens combinent vraiment

Il n'y a pas un seul produit « platform engineering ». Les équipes assemblent une stack, et les pièces se rangent dans quelques buckets.

Pour le portail et le catalogue, beaucoup d'équipes utilisent Backstage ou une alternative hébergée, qui donne une liste searchable de services, d'owners et de docs. Pour le provisioning, Terraform ou OpenTofu plus un outil GitOps comme Argo CD ou Flux. Pour le CI et la delivery, ce que vous tournez déjà, wrapped dans des templates partagés.

Deux buckets méritent un regard de plus, parce qu'ils décident si la platform paraît trustworthy.

L'observabilité : si les devs ne peuvent pas voir ce que leur service fait, ils ne vont pas trust la platform qui l'a déployé. Datadog vous donne une interface polie et uniforme sur l'infra, l'APM et les logs, à un coût par host qui grimpe vite. Grafana's open-source stack vous coûte du temps en opérations au lieu des frais de license. Choisissez selon votre ressource scarce : l'argent ou l'attention.

Les docs et la qualité : une platform sans bonnes docs c'est une ticket queue déguisée. Les tools docs-as-code gardent les guides à côté du repo qu'ils décrivent, et les gates de code quality en CI gardent les templates honnêtes.

Aucun de ces trucs n'est requis. C'est des exemples de la couche où une équipe platform dépense son temps : choisir un default, le câbler dans le template, et own le chemin de mise à jour.

Comment commencer sans construire le mauvais truc

La plupart des efforts platform qui échouent partagent le même pattern. Ils démarrent trop gros, buildent pendant des mois avant qu'une seule équipe les touche, et optimisent pour la slide de roadmap au lieu de l'adoption. La réponse est peu glamour.

Choisissez une tâche douloureuse et fréquente. « Créer un nouveau service » et « obtenir un environnement de preview » sont les gagnants habituels. Interviewez trois devs et regardez-les la faire. Comptez les steps et les minutes.

Construisez la version la plus fine qui enlève la plupart de la douleur. Un template repo et un fichier de pipeline partagé ça compte. Donnez-la à une équipe sympa et asseyez-vous à côté tandis qu'ils l'utilisent. Réparez ce qui dégénère, puis proposez-la à une deuxième équipe.

Trackez deux chiffres : combien de temps de « nouveau service » à « tournant en production ». Et combien d'équipes utilisent le chemin volontairement. Si le deuxième chiffre stagne, c'est un mandat, et les mandats pourrissent.

Staffez-la comme une équipe produit. Les platform engineers ne sont pas des DevOps avec un nouveau titre. La matière platformengineering.org note que les platform engineers gagnent autour de 27% de plus que les pros DevOps, ce qui vous dit que le marché voit le mix produit-et-engineering comme un job distinct et plus dur.

Une raison de plus de faire ça maintenant : le nouveau twist c'est que l'« utilisateur » d'une platform n'est plus seulement humain. Des agents de code ouvrent des pull requests, tournent des tests et demandent des environments. Une platform avec des templates clairs, des permissions claires et des docs machine-readable c'est beaucoup plus sûr pour un agent que un tas de repos snowflakes.

Des credentials qui expirent, des environnements de preview et un pipeline cohérent c'est ce qui garde les erreurs d'un agent cantonnées à une branche à jeter. Si votre platform ne peut pas différencier un déploiement humain d'un automatisé, ajoutez ça avant d'ajouter n'importe quoi d'autre.

Qu'est-ce que vous buildez ensuite ?

Si vous leadez une équipe de 30 devs et chaque squad a son propre pipeline, une petite équipe platform avec une golden path c'est probablement votre hire la plus leverage. Si vous êtes un dev solo avec trois side projects, copiez le pipeline de votre meilleur projet dans un template repo ce weekend et appelez ça fini.

De toute façon, la question qui vaut la peine de porter à votre prochaine session de planning c'est concrète : quelle tâche unique vos devs répètent le plus, et qu'est-ce qu'il faudrait pour la rendre une commande à une ligne ?