Qu'est-ce que l'ingénierie de plateforme ? Le guide
Résumé
L'ingénierie de plateforme consiste à construire une plateforme interne en libre-service qui donne aux développeurs accès à leurs environnements, pipelines, services et garde-fous sans passer par un ticket. Elle traite le chemin entre une idée et la production comme un produit. Elle est utile à partir d'une trentaine d'ingénieurs environ, et elle échoue quand elle devient un guichet ou une plateforme que personne n'utilise.
Qu'est-ce que l'ingénierie de plateforme, concrètement ? C'est la pratique qui consiste à construire et faire tourner une plateforme interne qui donne aux développeurs un accès en libre-service à ce dont ils ont besoin pour livrer du logiciel : environnements, pipelines, services, documentation et garde-fous. Une petite équipe traite le chemin entre « j'ai une idée » et « ça tourne en production » comme un produit, et les développeurs en sont les clients. L'objectif : moins d'attente, moins de tickets, moins d'outils à apprendre.
Vous avez probablement déjà vécu le problème. Un nouveau service demande un dépôt, un pipeline, une base de données, des secrets, des tableaux de bord et un tour de garde, et chacun de ces éléments se trouve derrière une page wiki différente ou une personne différente sur Slack.
Pourquoi l'ingénierie de plateforme est-elle apparue ?
« You build it, you run it » a bien fonctionné tant qu'une équipe possédait un service et une poignée d'outils. Le modèle a cessé de passer à l'échelle quand la chaîne d'outils s'est étoffée : Kubernetes, Terraform, trois systèmes de CI, un gestionnaire de secrets, un service mesh et une pile d'observabilité. Chaque développeur était désormais censé être, à temps partiel, un ingénieur infrastructure.
Le coût n'apparaît pas sur une ligne de budget. Il se voit dans la charge cognitive. Un développeur qui passe 90 minutes à trouver quel chart Helm est le « bon » n'a pas manqué de compétences. Il a manqué de valeurs par défaut.
L'ingénierie de plateforme est la correction de ce problème. Au lieu de demander à chaque équipe d'assembler la même pile à partir de zéro, une équipe dédiée l'assemble une fois, en fait l'option facile et la maintient en bon état. Les analystes observent la même tendance : Gartner prévoit que 80 % des grandes organisations de développement logiciel disposeront d'équipes d'ingénierie de plateforme d'ici 2026, contre 45 % en 2022.
Que construit vraiment une équipe plateforme ?
Oubliez un instant les schémas des éditeurs. Dans la plupart des entreprises, une équipe plateforme livre quatre choses.
Une plateforme de développement interne (IDP). L'ensemble des outils et workflows en libre-service posés sur votre cloud et votre CI. Ça peut être un portail Backstage, un produit d'éditeur ou un dépôt bien tenu de modèles, complété par une CLI.
Des chemins dorés (golden paths). Des parcours opiniâtres et supportés pour les tâches courantes, comme « créer un nouveau service API » ou « ajouter une file de messages ».
Des garde-fous. Politiques, analyse de sécurité et limites de coûts appliquées par défaut, pour que l'option sûre soit aussi la plus paresseuse.
La documentation et la découvrabilité. Un catalogue qui répond à « qui possède ce service, où est son runbook et de quoi dépend-il ? »
Rien de tout cela ne demande une nouvelle catégorie de produits. Beaucoup de bonnes plateformes ont commencé comme un template cookiecutter et un README que quelqu'un a pris soin de tenir à jour.
Qu'est-ce qu'un chemin doré, et pourquoi les équipes les ignorent-elles ?
La CNCF décrit un chemin doré comme une « composition templatisée de code et de capacités bien intégrés pour le développement rapide de projets », une définition que Google Cloud détaille à partir d'un exemple Spring Boot. Concrètement, c'est un template qui donne à un nouveau service un dépôt, un pipeline, de la journalisation et une configuration de déploiement dès le premier jour.
Le mode d'échec est tout aussi simple. Un chemin que personne n'a demandé, construit sans discuter avec les équipes qui vont l'emprunter, stagne à un taux d'adoption à un chiffre pendant que l'équipe plateforme se demande pourquoi les développeurs continuent d'ouvrir des tickets. Le chemin doit être plus court que le contournement, sinon les gens prendront le contournement.
Deux règles gardent les chemins dorés en vie :
Pavé, pas clôturé. Les développeurs peuvent quitter le chemin, mais ils assument la charge de support de ce qu'ils construisent en dehors.
Géré comme un produit. Quelqu'un lit les retours, suit l'adoption et supprime les chemins que personne n'utilise.
L'ingénierie de plateforme n'est-elle que du DevOps sous un autre nom ?
En partie, et la réponse honnête est plus utile que la réponse marketing. Le DevOps est une culture : responsabilité partagée entre développement et exploitation, boucles de retour courtes. L'ingénierie de plateforme est une manière de rendre cette culture soutenable à grande échelle, en transformant le travail opérationnel répétitif en produit.
Le SRE est encore une autre discipline. Les SRE définissent des objectifs de fiabilité, les mesurent et décident quand arrêter les livraisons pour les protéger. L'équipe plateforme fournit la route pavée. L'équipe SRE vous dit quel risque vous pouvez vous permettre de prendre dessus.
DevOps est une culture et un ensemble de pratiques. Il produit de la responsabilité partagée et de l'automatisation, et il échoue souvent en devenant un intitulé de poste et une file de tickets.
SRE est une discipline de fiabilité. Il produit des SLO, des budgets d'erreur et un processus d'incident, et il échoue souvent en devenant une astreinte sans autorité.
Ingénierie de plateforme est une équipe produit interne. Elle produit une plateforme en libre-service et des chemins dorés, et elle échoue souvent en devenant une plateforme que personne n'utilise.
Les modes d'échec sont la partie à lire deux fois. Une équipe plateforme qui prend des tickets et construit ce qu'on lui demande n'est qu'une équipe ops rebaptisée, et elle hérite de tous les vieux problèmes de file d'attente.
Quand une équipe plateforme vaut-elle son coût en effectifs ?
Passez votre tour si vous avez moins d'une trentaine d'ingénieurs et un ou deux services. À cette taille, un bon dépôt de modèles et un module Terraform partagé font le travail, et une équipe plateforme à temps plein serait du surcoût. Quelques personnes dans une équipe de dix finiront discrètement par devenir la plateforme, et c'est très bien.
Elle commence à se rentabiliser quand les mêmes signaux reviennent :
Les nouveaux services mettent des semaines à atteindre la production, surtout parce qu'ils attendent d'autres personnes.
Trois équipes ont résolu le même problème de déploiement de trois façons différentes.
Intégrer un nouvel ingénieur signifie une pile de savoir tacite et beaucoup de « demande à Priya, elle sait ».
Les revues de sécurité et de conformité arrivent en bout de course, par équipe, à la main.
La plus petite version utile est ce que Team Topologies appelle la plateforme minimale viable : juste assez pour supprimer la plus grosse douleur répétée, bien documentée, et rien de plus. Commencez par le workflow qui coûte le plus d'heures à travers les équipes, en général « créer un nouveau service » ou « obtenir un environnement de prévisualisation ».
La gestion des fonctionnalités (feature flags) en est un bon exemple. C'est moins cher en service partagé qu'en dix versions privées.
Un service de flags que toutes les équipes peuvent appeler, avec la même piste d'audit et les mêmes règles de nettoyage, évite à chaque équipe d'écrire son propre système de bascules à moitié fonctionnel. Que vous l'achetiez ou que vous le construisiez, il doit vivre sur la plateforme et non dans chaque dépôt.
Quel rapport entre une plateforme et la lecture du code ?
Plus qu'on ne le montre sur les schémas. Une plateforme n'est utile que si la connaissance qui l'entoure l'est aussi. Quand un développeur demande « comment le service A s'authentifie-t-il auprès du service B ? », la réponse se trouve dans le code, dans la configuration et dans un runbook qui a peut-être six mois.
C'est là que les équipes plateforme perdent discrètement du temps. Ce sont elles qui reçoivent la question Slack qui commence par « où est configuré X ? », et elles y répondent de mémoire, pour la cinquième fois de la semaine. L'effet est très net quand un dépôt dépasse 80 000 lignes de code et que l'équipe plateforme devient un index de recherche humain.
Quelques outils aident, et ils résolvent des moitiés différentes du problème. Les outils de documentation-as-code gardent la partie écrite au plus près de la source.
Les assistants qui comprennent le code répondent aux questions sur le code lui-même. L'assistant de Sourcegraph vise les grandes organisations multi-dépôts et se vend aux entreprises sur devis. Il convient donc mieux aux équipes plateforme de grands parcs qu'à une équipe de quinze personnes.
Pour le travail de tous les jours dans l'éditeur, un assistant généraliste couvre beaucoup de terrain, à condition de garder en tête qu'il ne connaît que le contexte que vous lui donnez.
Le schéma que nous copierions : mettre au même endroit les modèles de chemins dorés, le catalogue de propriété et un index de recherche du code, puis laisser les nouveaux ingénieurs poser leurs questions là avant de les poser à une personne. Mesurable en heures, aussi. Si votre équipe plateforme répond à moins de dix questions « où est-ce configuré » par semaine une fois le dispositif en place, c'est que ça a marché.
Que se passe-t-il mal, et comment le repérer tôt ?
Trois schémas d'échec reviennent sans cesse.
La plateforme guichet. Les demandes arrivent par ticket, l'équipe les traite à la main et appelle ça du libre-service. Test : un développeur peut-il finir la tâche courante sans parler à personne ?
La plateforme imposée. La direction oblige chaque équipe à rejoindre la plateforme avant qu'elle soit bonne. Les chiffres d'adoption ont fière allure, le moral s'effondre. Laissez l'usage se mériter pendant les six premiers mois.
La plateforme tout-en-un. Chaque demande devient une fonctionnalité, la surface grossit et la qualité baisse. Dites non, par écrit, avec les raisons.
Un signal d'alerte précoce : le ratio entre les questions Slack et les réponses documentées. Si la même question revient trois fois dans le mois, sans doc, sans modèle et sans automatisation, c'est votre prochain élément de backlog.
Comment démarrer sans construire une cathédrale, et que faire lundi ?
La plupart des efforts de plateforme qui échouent commencent par l'outil. Le meilleur ordre est : les personnes, puis les chemins, puis l'outillage.
Interrogez dix développeurs. Demandez-leur où ils perdent du temps entre une PR fusionnée et une fonctionnalité qui tourne. Vous entendrez les mêmes trois réponses.
Choisissez un chemin et livrez-le en un mois. Un seul modèle « nouveau service » qui fonctionne de bout en bout vaut mieux qu'un portail avec quarante tuiles vides.
Mesurez avant et après. Suivez le temps jusqu'au premier déploiement d'un nouveau service et le temps jusqu'à la première PR fusionnée d'une nouvelle recrue. Ces deux chiffres en disent plus que n'importe quelle enquête de satisfaction.
Publiez une feuille de route et un changelog. Le travail de plateforme est invisible tant qu'on ne le rend pas visible.
Supprimez des choses. Retirez les chemins et les outils que personne n'utilise. Une plateforme plus petite en qui les gens ont confiance vaut mieux qu'une plus grande qu'ils contournent.
Résistez à l'envie d'acheter un portail d'abord. Un portail posé sur des workflows désordonnés donne un désordre mieux présenté, et un catalogue de 247 entrées, dont la moitié sont périmées, est pire que pas de catalogue du tout.
Le lundi, choisissez la chose qui fait perdre le plus de temps à travers les équipes et rendez-la ennuyeuse. Pour la plupart des entreprises, c'est la création d'un nouveau service ou l'obtention d'un environnement de test. Écrivez le chemin, placez-le là où les gens le trouveront, comptez les heures qu'il fait gagner, et seulement ensuite décidez si vous avez besoin d'une équipe plus grande.
L'ingénierie de plateforme n'est pas une chaîne d'outils qu'on installe. C'est la décision de traiter les développeurs internes comme des clients, et la preuve que vous l'avez prise, c'est une distance plus courte entre le premier jour d'une recrue et sa première modification fusionnée.