Platform engineering : construire le moteur, pas la vitrine

On embauche un ingénieur logiciel pour fabriquer un produit. Dans beaucoup d’entreprises, il passe une bonne partie de sa semaine à ne pas le fabriquer. Le temps part dans tout ce qui entoure le code : comprendre comment lancer un nouveau service, savoir quels fichiers de configuration modifier, trouver quel tableau de bord indique si la mise en production de la veille a vraiment fonctionné, et deviner à qui s’adresser quand ce n’est pas le cas. Rien de tout cela ne livre une fonctionnalité, et c’est précisément ce qu’une plateforme interne de développement est censée régler.

Le terme paraît plus lourd que l’idée. Une plateforme interne de développement, c’est simplement un ensemble d’outils en libre-service qu’une entreprise construit pour ses propres ingénieurs, pour qu’ils passent du code écrit à un service qui tourne sans avoir à ouvrir un ticket et attendre plusieurs jours qu’une autre équipe le mette en place. Cette plateforme porte souvent un sigle, IDP pour internal developer platform. Et le travail de la construire et de la faire vivre a son propre nom, le platform engineering. La meilleure façon d’entrer dans le sujet, c’est de bien séparer les deux : le platform engineering, c’est le travail ; la plateforme, c’est ce que ce travail produit. Une équipe qui achète un outil et s’arrête là a sauté le travail.

C’est cette distinction qui est l’idée durable, parce qu’elle survit à toutes les modes d’outillage. La plateforme est un produit interne dont les utilisateurs sont vos propres développeurs, avec sa feuille de route et sa liste de tâches en attente. Ce n’est jamais un projet ponctuel qu’on termine pour passer à autre chose, et c’est en la traitant comme tel que la plupart de l’argent se gaspille.

La douzaine d’outils dans la tête d’un seul ingénieur

Pour voir contre quoi la plateforme se bat, regardez ce qu’on demande de porter à un seul ingénieur produit. En plus de la fonctionnalité pour laquelle on l’a recruté, il est censé savoir comment le code est empaqueté, comment il est déployé, où sont stockés les mots de passe et les clés, lequel des trois tableaux de bord de surveillance mérite qu’on s’y fie, et quoi faire à deux heures du matin quand une alerte se déclenche. Chacun de ces points est un outil distinct, avec ses propres bizarreries. Chacun est un détour qui ne produit aucune ligne de code utile au produit.

Cette charge est le vrai coût, et il n’est pas mince. Les enquêtes sur la façon dont les développeurs occupent leur temps tombent toujours sur la même fourchette inconfortable : entre un cinquième et deux cinquièmes de la semaine d’un ingénieur partent dans des frictions qui n’ont rien à voir avec le produit. Une plateforme justifie son budget en rendant ce temps. Elle ne rend pas les ingénieurs plus intelligents ; elle supprime l’impôt qu’ils paient pour le simple droit de livrer.

La vitrine, c’est la partie facile

C’est là que la plupart des projets de plateforme dérapent en silence. La partie visible d’une plateforme, c’est un portail : une seule page web où un développeur clique pour démarrer un nouveau service, en retrouver un existant, ou vérifier son état de santé.

L’exemple le plus connu est Backstage, le portail que Spotify a construit en interne avant de le confier à la communauté open source, et qui est depuis devenu le point de départ par défaut pour des milliers d’entreprises. Un portail est vraiment utile, et c’est aussi la partie facile du travail, à peu près le cinquième visible.

Le portail n’est qu’une porte d’entrée. La vraie valeur, c’est le moteur derrière, la machinerie qui prend la demande d’un développeur et la transforme en infrastructure réelle : une base de données, une file d’attente, un endroit où faire tourner le code, le tout correctement branché pour chaque environnement, sans qu’aucune main humaine ait à exécuter les étapes une par une. Ce moteur représente l’essentiel du travail et presque rien de la gloire, et c’est justement pour ça que les équipes le sautent. Elles achètent une belle porte d’entrée, la fixent sur du vide, et se retrouvent avec un catalogue qui liste tous les services sans laisser les développeurs faire autre chose que les consulter. Une porte d’entrée qui ouvre sur un mur est pire que pas de porte du tout, parce qu’elle a l’air terminée.

Les golden paths : la seule idée à voler

La meilleure idée sortie du platform engineering porte un nom limpide une fois traduit : le golden path, le chemin pavé et entièrement pris en charge qui mène de l’idée au service qui tourne. Imaginez un modèle de projet où la journalisation, la surveillance, les contrôles de sécurité et la chaîne de déploiement sont déjà branchés, de sorte qu’un développeur qui le reprend passe de rien à un service en ligne en quelques minutes plutôt qu’en quelques jours. Spotify, qui a forgé le terme, le décrivait comme la route si bien outillée que l’emprunter devient tout simplement la voie de moindre résistance.

Le piège, c’est l’arbitrage entre standardisation et liberté. La route pavée est rapide précisément parce qu’elle est étroite : elle prend en charge un langage principal, un schéma de base de données, une façon de déployer, et en sortir signifie que la plateforme cesse de vous porter. Pavez trop peu de routes, et vos meilleurs ingénieurs laissent la plateforme de côté ; essayez de paver toutes les routes et vous construisez un truc qui prend tout en charge mal et ne livre rien bien. La discipline consiste à paver les deux ou trois routes qui couvrent l’essentiel du travail, et à dire non, à voix haute, à la longue traîne du reste.

La route ne marche que si elle est vraiment la plus rapide. Dès l’instant où elle est imposée mais plus lente que le contournement, les ingénieurs la contournent, et l’équipe plateforme passe ses trimestres à faire la police de la conformité au lieu d’améliorer la route. Chaque choix par défaut inscrit dans ce chemin, jusqu’à une décision aussi élémentaire que la façon dont les conteneurs (la manière standard d’empaqueter un logiciel pour qu’il tourne pareil partout) sont construits et exécutés, devient un choix dont chaque équipe hérite. Même cette seule décision est plus lourde qu’elle n’en a l’air, comme l’explique notre comparaison entre Docker et Podman pour les équipes qui livrent.

Quand ça vaut vraiment le coup de construire

Rien de tout cela n’est gratuit, ce qui pose la seule question à se poser avant de commencer : l’entreprise est-elle assez grande pour que la plateforme se rembourse toute seule ? Un chiffre qu’on cite beaucoup tourne autour de cinquante ingénieurs, mais ce nombre est le repère d’autre chose de réel, pas une ligne rouge. Le vrai déclencheur, c’est le moment où plusieurs équipes cessent de partager le même contexte et où chacune se met à réinventer la même tuyauterie. En dessous de ce point, une petite équipe a en général assez de savoir commun pour qu’une poignée de scripts bien tenus et un bon fichier README suffisent, et construire une plateforme ne fait que taxer le petit groupe qu’elle était censée soulager.

Il y a un piège honnête que ceux qui sont passés par là rapportent sans cesse : une nouvelle plateforme tend à ralentir les équipes avant de les accélérer. La plateforme est elle-même une chose que les ingénieurs doivent apprendre avant qu’elle ne paie, donc la courbe de productivité plonge avant de remonter. Faire comme si ce creux n’existait pas, c’est ainsi que les équipes plateforme grillent leur crédibilité dès le premier trimestre ; le nommer d’emblée, c’est ainsi qu’elles survivent jusqu’au moment où ça marche.

À quoi ressemble ce « ça marche » a son étalon. Le secteur mesure la livraison de logiciel avec une série d’indicateurs connue sous le nom de DORA, assise sur une tension simple : la vitesse à laquelle une équipe livre, contre la sûreté avec laquelle elle livre. Une plateforme mérite son budget en rendant la livraison plus rapide sans la rendre plus fragile, en transformant deux semaines d’attente pour un nouveau service en un clic en libre-service, le jour même. Ce seul changement, des semaines ramenées à des heures, c’est en général ce qui fait financer une plateforme au départ.

Là où ces projets vont mourir

Les deux façons courantes dont une plateforme meurt sont repérables tôt, si on en connaît la forme.

La première est la porte d’entrée qui ouvre sur le vide : un portail qui catalogue tous les services et ne déclenche aucune action réelle, si bien qu’en quelques mois le catalogue se périme parce que personne n’a la moindre raison de le tenir à jour. La seconde est le sur-équipement avant que quiconque en ait besoin, l’empilement de couches d’abstraction pour une équipe qui déploie une appli, à un seul endroit, deux fois par semaine. La plateforme devient son propre produit, détaché de ce que les développeurs demandaient vraiment, ajoutant un délai à chaque changement tout en supprimant une douleur que personne ne ressentait.

Le signal est le même dans les deux cas, et il est simple : aucune mesure de l’usage réel de la plateforme. Une équipe incapable de dire quelle part des déploiements passe par le golden path, ou combien de services ont été créés à partir d’un modèle le mois dernier, navigue à l’aveugle. Traitez la plateforme comme un produit et mesurez si quelqu’un s’en sert, sinon vous ne remarquerez sa mort que le jour où le catalogue aura un an de retard.

La partie IA, gardée honnête

Le dernier argument ajouté à l’argumentaire, c’est l’IA, et la version réaliste est plus étroite que la version de keynote. Ce qui marche aujourd’hui, c’est se servir de l’IA pour adoucir les moments les plus fastidieux : générer le squelette d’un nouveau service, remplir la configuration répétitive, répondre en langage clair à « où est le truc qui fait X » au lieu d’une fouille dans le wiki. Ce qui reste surtout une démo, c’est la plateforme qui se déploie et se répare toute seule, sans humain dans la boucle. L’IA raccourcit l’entrée sur la route pavée ; elle ne conduit pas encore la voiture. Quiconque vous vend aujourd’hui la seconde chose vous vend la diapositive, pas le produit.

Foire aux questions

En quoi le platform engineering diffère-t-il du DevOps ?

Le DevOps est une culture : l’idée que les gens qui construisent le logiciel et ceux qui le font tourner ne devraient pas être séparés par un mur. Le platform engineering est une façon concrète de réaliser cette idée à grande échelle. Au lieu que chaque équipe gère ses propres opérations, un groupe dédié construit un produit interne dont toutes les équipes se servent pour s’aider elles-mêmes. Le DevOps dit que le dev et l’ops ne devraient pas être en silos ; le platform engineering est le modèle d’équipe et d’outillage qui rend ça vrai une fois qu’une entreprise est trop grosse pour que les seules habitudes partagées la tiennent ensemble.

Faut-il Kubernetes pour en construire une ?

Non, même si une bonne partie de l’outillage populaire le suppose. Kubernetes est le système devenu standard pour faire tourner du logiciel en conteneurs sur de nombreuses machines, et il est puissant autant que compliqué. Vous pouvez construire une plateforme interne parfaitement bonne sur des fondations plus simples, avec un portail et des modèles par-dessus. Si vous ne faites pas déjà tourner Kubernetes, l’adopter uniquement pour avoir une plateforme est précisément l’erreur de sur-équipement. Calez la plateforme sur la machinerie que vous opérez déjà, pas sur celle de la conférence.

Backstage est-il gratuit, et combien coûte-t-il vraiment ?

Le logiciel est open source et gratuit à télécharger. Le coût est opérationnel : Backstage est une application que votre équipe doit déployer, garder à jour et étendre, ce qui veut dire au moins une fraction du temps d’un ingénieur de façon continue. Les alternatives commerciales facturent un abonnement en échange du fait de ne pas faire tourner cette application vous-même. Le choix revient à une question familière : avez-vous des gens capables de posséder et d’entretenir une base de code sur le long terme, ou préférez-vous payer quelqu’un d’autre pour le faire ?

Pourquoi une chaîne de déploiement classique ne suffit-elle pas ?

Une chaîne de déploiement exécute une recette figée pour construire, tester et livrer du code. Le moteur à l’intérieur d’une plateforme se situe un cran au-dessus : il prend la demande d’un développeur (« ce service a besoin d’une base de données et d’une file d’attente ») et détermine les ressources concrètes pour chaque environnement avant de passer la main à la chaîne. La chaîne exécute une recette connue ; le moteur décide de ce que la recette doit contenir cette fois-ci. C’est cette étape de décision qui transforme un clic dans le portail en infrastructure réelle, correctement branchée.

À partir de quelle taille d’équipe une plateforme a-t-elle du sens ?

Le seuil le plus cité tourne autour de cinquante ingénieurs, mais le vrai déclencheur, c’est le coût de communication, pas un effectif exact. Dès que vous avez plusieurs équipes qui ne partagent plus un contexte quotidien et que chacune rebâtit dans son coin la même tuyauterie de mise en place et de déploiement, faire payer ce coût une seule fois pour tout le monde, par un seul groupe, commence à devenir rentable. En dessous, des scripts bien tenus et de la documentation l’emportent en général, parce que l’entretien de la plateforme retombe sur la même petite équipe qu’elle était censée libérer.

Construisez la couche qui fait mal

L’ordre dans lequel on construit, c’est toute la décision. Si vous êtes en dessous du point où plusieurs équipes réinventent sans cesse le même travail de mise en place, ne construisez pas de plateforme : écrivez les scripts, écrivez le README, et revenez-y quand vous aurez grandi jusqu’au problème. Si vous êtes au-delà, partez du seul flux de travail qui coûte le plus cher à vos ingénieurs ce trimestre-ci, les deux semaines d’attente pour un nouveau service ou le déploiement que personne ne sait lancer sans aide, et ne construisez que le moteur qui le règle. Pavez une bonne route, prouvez que les gens roulent dessus, et ne pavez la suivante que lorsque la première porte une charge. La plateforme de la diapositive de conférence est celle qui devient un cimetière ; celle qui dure est la couche qui faisait vraiment mal.

---

Photo : cottonbro studio / Pexels