Des prompts plutôt que des templates : le Platform Engineering à l'ère des agents

Donner davantage de latitude aux builders. Leur permettre de faire. Le cloud, l’infrastructure as code, le Platform as a Service ont tous poussé le curseur dans la même direction — réduire la distance entre une intention et sa mise en production. À l’échelle d’une entreprise, le Platform Engineering est l’aboutissement de ce mouvement : faire de l’infrastructure, longtemps réservée à une poignée d’experts, un bien commun en self-service : on industrialise l’autonomie. Les équipes déploient, supervisent et créent sans attendre un Ops.

Malgré tout, limitée par la technologie elle s’est jusqu’alors enfermée dans des workflows rigides : un bouton pour créer un repo, une action prédéfinie pour restaurer un backup, un template pour créer un projet type. Ces workflows sont sûrs par conception — on ne peut faire que ce qui a été prévu, ce qui limite par nature le risque. Malheureusement, ils sont aussi bêtes par conception. Le jour où le besoin ne ressemble à aucun template, la plateforme ne sert plus à rien, et tout retombe, comme avant, sur la personne “capable de”.

L’IA a, ici encore, changé la donne, cette fois-ci en remplaçant le workflow figé par un agent capable de raisonner sur un problème qu’on n’avait pas anticipé. La bonne question n’est plus « quels workflows outiller », mais « jusqu’où on laisse un agent agir ». C’est une révolution conceptuelle du platform engineering qui est en cours et comme nous allons le voir, elle a un potentiel énorme qui pose aussi de nouveaux défis.

Le Platform Engineering en quelques mots

Le platform engineering, c’est standardiser et simplifier les process internes tels que la configuration d’environnements, les outils, l’hébergement — pour les sécuriser autant que les rendre accessibles aux équipes non-Ops.

Le mot qui porte tout est « de manière sécurisée » : exposer l’usage en masquant la mécanique. Facile à tenir tant qu’on se contente de lire, beaucoup moins lorsqu’il s’agit d’opérations en écriture. Par exemple : permettre via le Platform Engineering de restaurer un backup de base de données dans un environnement de production : le workflow doit être extrêmement fiable car les enjeux sont énormes !

Le plafond de verre des templates : rigidité et maintenabilité

Jusqu’alors, le Platform Engineering consistait donc en la standardisation des process ops internes communs en automatisations cadrées et pensées de façon exhaustive : les template. C’était d’une part laborieux à produire mais aussi pénible à maintenir.

On l’a vécu chez Dernier Cri avec une idée qui revient sans cesse : le boilerplate de projets. En tant qu’agence nous passons une part non négligeable de notre temps à démarrer des nouveaux projets. C’est une source de coûts à faible valeur ajoutée pour nous et pour nos clients. Les boilerplates de projets, c’est l’idée de pouvoir démarrer un projet dans la technologie souhaitée avec tout ce qu’il faut pour commencer à builder le produit : monitoring, authentification, logging etc.

L’intention est bonne mais en pratique, ça n’a jamais fonctionné. Il faut maintenir un boilerplate par combinaison de technologies, c’est déjà un travail titanesque. Chaque projet a aussi ses spécificités : ici Sentry, là Datadog, ailleurs encore autre chose. Le squelette qui devait faire gagner du temps devient une collection à entretenir. Et puis, pour qu’il soit utile et sécurisé, à chaque nouvelle version importante de l’une des technologies le constituant, il fallait être capable de vérifier que le template fonctionnait toujours. Un template assez exhaustif pour faire gagner du temps et assez flexible pour absorber chaque cas particulier, c’était au final assez illusoire.

Même histoire avec les procédures de déploiement. On a tenté plusieurs fois d’écrire une documentation exhaustive pour guider les équipes. Jamais exempte d’erreur, et toujours rattrapée par un cas particulier qui force à solliciter nos chers et tendres Ops.

C’est là où l’IA a changé la donne. Ce qui avait été jusqu’alors régi par un workflow rigide peut aujourd’hui être délégué à un agent capable de s’exprimer dans un cadre. Si l’on reprend l’exemple du boilerplate de projet, le paradigme change : on n’écrit plus un template de projet rigide mais on définit un ensemble de règles propres à notre organisation pour démarrer un projet, on récolte les besoins dudit projet et on laisse l’agent générer le code de départ.

Tout le Platform Engineering peut être revisité de la sorte et c’est la transformation que nous avons entamée en interne. Pour ce faire, nous avons décidé de nous structurer autour de Backstage, le portail développeur open source, créé par les équipes de Spotify.

Backstage : la fondation de notre démarche Platform Engineering

Le Platform Engineering touche par nature à tout ce qui structure l’usine logicielle : projets, dépôts, hébergement, applications, documentation, process — avec évidemment des droits d’accès distincts selon le profil de l’utilisateur. Le périmètre est large, et le risque de s’éparpiller l’est tout autant.

On ne voulait donc ni démarrer de zéro, ni réinventer les notions de catalogue, d’authentification et de système de plugins. On cherchait surtout une architecture robuste et maintenable et notre choix s’est rapidement fixé sur Backstage, le portail développeur open source de Spotify. L’enjeu n’était pas le framework, mais ce qu’on allait y brancher, et dans quel ordre :

1. L’authentification : OIDC via Google, la sécurité étant le maître mot de la démarche.
2. Le catalogue : pour référencer nos applications et nos dépôts Github. La source de vérité : ce qui existe, qui en est responsable, sur quelle stack ça tourne.
3. Les plugins : pour ajouter des fonctionnalités spécifiques, sur étagère, ou développées par nos soins pour les besoins spécifiques à notre organisation.

Enfin, pour aller dans le sens de la démarche agentique, Backstage propose comme plugin officiel le Model Context Protocol pour permettre à un agent de découvrir et d’appeler les fonctionnalités exposées par Backstage et ce qui en découle est une architecture qui permet de faire passer le self-service à un niveau de service sans précédent.

Le MCP dans le cas du Platform Engineering et Backstage

Le Model Context Protocol est souvent réduit à « le truc qui branche un LLM sur des outils ». Pour un platform engineer il va avoir deux usages :

• La porte ouverte : Backstage cesse d’être un portail qu’on consulte pour devenir une plateforme qu’on actionne. Le point d’entrée n’est plus le backoffice mais là où l’on interagit avec l’agent.
  • Au lieu de cliquer, on demande : « quels services tournent encore sur une version de Node en fin de vie ? », « crée-moi le squelette d’un outil interne ». Le self-service ne passe plus par des écrans figés, mais par une conversation.
• Le protocole d’interopérabilité pour les workflows se reposant sur l’IA. Le MCP va permettre à tous les workflows augmentés par l’IA de pouvoir non seulement interagir avec Backstage mais aussi avec tous nos services externes et internes. Par exemple : créer un repository sur Github, déclarer le projet correspondant sur Sentry pour le monitoring d’erreur et envoyer un message sur Slack pour informer l’équipe.

Le protocole MCP étant central, c’est sur lui que nous nous appuyons pour décider qui va pouvoir appeler quelles fonctionnalités. On y a posé deux régimes :

• Jeton API, en lecture seule, pour les systèmes automatisés.
• ‍OAuth, pour les actions humaines qui engagent des droits. Ici, on veut toujours savoir qui agit vraiment.

Ce que nous avons déjà concrètement mis en place

Tout ce qui est décrit depuis le début de cet article est déjà concrètement mis en place chez Dernier Cri.

Un exemple concret de ce que nous avons mis en place est la cartographie de notre parc applicatif : être capable de lister tous nos projets, technologies utilisées, quelles versions, quels composants d’infrastructure utilisés. Avant, cette information vivait dans un tableur que personne ne tenait à jour. Aujourd’hui, des agents scannent à intervalle régulier chacun de nos repos. Indépendamment de la technologie ils sont capables de recenser ce que nous utilisons. Le cas d’usage ? Un exemple : une faille critique vient de sortir sur Next.js, nous pouvons immédiatement interroger Backstage -> quels sont nos projets Next.js concernés par la faille XYZ ? L’agent utilise le MCP Backstage pour récolter tous les projets utilisant Next.js, leurs versions, compare avec. Et ce scan de code source fonctionne avec un prompt simple : on demande à l’agent d’inspecter le dépôt et de renvoyer un JSON décrivant la stack — langage, framework, services externes, runtimes de déploiement.

La vraie rupture est là : avant, il fallait que les workflows décrivent précisément comment faire chaque action (laborieux et fastidieux), maintenant, on donne des instructions, des règles et on laisse l’agent trouver le comment.

Le Platform Engineering comme manière de favoriser un « vibe coding » interne professionnel

Si l’on reprend l’exemple du boilerplate. Au lieu de maintenir un squelette par techno nous maintenons maintenant un seul générateur de projet. On définit les bonnes pratiques de Dernier Cri — ce qu’on instrumente, les contraintes à respecter, ce qu’on veut superviser — et l’agent les applique selon le contexte : PHP ou Node, Sentry ou Datadog, en s’appuyant sur les MCP des outils ou, à défaut, sur leur documentation. On passe de N boilerplates impossibles à maintenir à un générateur unique capable de tout porter.

Si l’on pousse l’idée de générateur jusqu’au bout, c’est la capacité de permettre le « vibe coding » interne à une organisation de sorte à respecter les bonnes pratiques de l’entreprise. Un membre de l’équipe demande à l’IA, via le MCP de Backstage, un outil interne complet. En dix minutes, le système enchaîne création du dépôt Git, supervision, authentification avec SSO, déploiement sur l’hébergeur, nom de domaine. Au bout : un squelette d’application prêt à l’emploi, sécurisé par défaut.

Le Platform Engineering comme manière de gérer les incidents

Le Platform Engineering permet aussi la gestion des incidents : l’IA ajoute une couche de diagnostic. Une montée d’erreurs 500 invisible dans les logs du routeur : un template n’a rien à proposer ; un agent corrèle métriques, logs et traces, distingue une erreur applicative d’un problème réseau, et pointe la cause — une requête qui référence une colonne supprimée par une migration. Le gain ne vient pas de l’exécution, déjà rapide, mais de la compréhension, qui était lente. Même logique en prévention : un magic link envoyé en boucle appelle un rate limit ; des e-mails en clair dans les logs sont un sujet RGPD à signaler avant qu’il ne devienne un incident.

Même logique côté support. La prochaine étape de notre feuille de route est un assistant branché sur Jira Service Management : il analyse un ticket interne, raisonne sur la demande et propose immédiatement une première action — ajouter un membre dans un Vault 1Password, gérer une liste de diffusion — qu’un administrateur valide avant exécution. Chaque brique existe déjà séparément ; le travail consiste à les composer derrière une porte unique et contrôlée.

L’intelligence est une surface d’attaque

Les potentialités du Platform Engineering agentique sont immenses. Néanmoins il faut rester précautionneux : une IA cherche à résoudre le problème qu’on lui pose, souvent à tout prix, sans toujours mesurer les implications de ce qu’elle déclenche. Les anciens templates étaient restreints par conception : périmètre de risque connu et borné. Un agent intelligent ne l’est pas — c’est sa force et c’est précisément ce qui en fait une surface de risque voire d’attaque. Le Platform Engineering par essence est au coeur de l’entreprise, en prise sur vos systèmes critiques.

Ainsi, dès la création de nouveaux plugins pour Backstage, qu’on implémentera avec l’IA, il faudra relire les plans et le code généré. L’IA doit rester un accompagnant, il faudra relire chaque changement pour s’assurer qu’aucune faille ne s’y glisse.

Une fois les agents en place, nous avons aussi édicté 3 règles non négociables :

• Pas d’accès direct aux bases de production : c’est la première barrière contre une fuite
• L’IA est un acteur comme les autres du système de permissions. et il n’a jamais les droits super-admin : il a ses propres droits et ses propres restrictions. Comme on vise un Backstage utilisé majoritairement via son MCP, on contrôle strictement les actions qu’on y expose, avec des droits granulaires pour ne pas retomber dans le travers où tout le monde pouvait tout faire.
• Approbation humaine sur le critique : l’agent propose, un administrateur valide (via une approbation Slack par exemple) ce qui engage vraiment.

Ces règles sont la condition pour que l’autonomie des agents sur un système si important soit acceptable.

Changer de réflexe

Le futur du Platform Engineering ne consiste pas à remplacer les Ops par une IA, ni à tout automatiser : il consiste à faire sauter le plafond des workflows rigides en gardant la main sur les droits et tout en gagnant en productivité.

Ce point déborde largement du périmètre strict du Platform Engineering : permissions, validation humaine sur l’irréversible : ces principes sont ceux de tout système où l’on laisse un agent agir. C’est l’un des noeuds autour de la démocratisation du « vibe coding » : tous les produits qui ouvriront leurs capacités à des agents se heurteront à la même question — et ceux qui auront appris à évoluer dans ces environnements nouvelle génération sans perdre le contrôle auront une longueur d’avance.

Questions fréquentes

Qu'est-ce que le platform engineering ?

C'est la discipline qui consiste à standardiser et simplifier les process internes d'une organisation — configuration d'environnements, outils, hébergement, déploiement — pour les rendre accessibles en self-service aux équipes non-Ops, de manière sécurisée. L'objectif : permettre à chacun de déployer, superviser et créer sans dépendre en permanence d'un Ops, tout en gardant un cadre maîtrisé.

En quoi l'IA transforme-t-elle le platform engineering ?

Jusqu'ici, une plateforme outillait des workflows figés : un bouton, un template, une procédure prévue à l'avance. Tout ce qui n'avait pas été anticipé retombait sur les Ops. L'IA remplace ces workflows rigides par des agents capables de raisonner sur un problème qu'on n'avait pas prévu. La bonne question n'est plus « quels workflows outiller », mais « jusqu'où on laisse un agent agir » — et quelle source de vérité on lui donne.

À quoi servent Backstage et le MCP dans une plateforme interne ?

Backstage est un portail développeur open source qui fournit le catalogue, l'authentification et un système de plugins — un socle robuste pour ne pas repartir de zéro. Le Model Context Protocol (MCP) transforme ce catalogue consultable en plateforme actionnable par un agent : il découvre et appelle les capacités exposées, et c'est aussi le point où l'on contrôle qui a le droit de faire quoi.

Faut-il encore maintenir des boilerplates de projet ?

Maintenir un squelette de projet par combinaison de technologies est un travail titanesque, jamais assez flexible pour absorber les spécificités de chaque projet. À l'ère des agents, on ne maintient plus N boilerplates : on définit une fois les bonnes pratiques de l'organisation et un générateur unique les applique selon le contexte (PHP ou Node, Sentry ou Datadog), en s'appuyant sur les MCP des outils ou leur documentation.

Comment encadrer un agent IA qui agit sur l'infrastructure ?

L'intelligence d'un agent est aussi une surface d'attaque : il cherche à résoudre le problème, parfois sans mesurer les implications. Trois règles non négociables : pas d'accès direct aux bases de production, l'IA est un acteur du système de permissions avec ses propres droits (jamais super-admin), et approbation humaine systématique sur les actions critiques. Donner du pouvoir sans cette discipline ne fait pas gagner du temps, ça reporte le risque sur un incident plus grave.

‍