PlatformCon Paris 2026 : repenser le platform engineering pour les agents IA

La semaine dernière, le 24 septembre, j'ai eu l'opportunité d'assister à la PlatformCon Paris pour représenter Seven Mile. L'événement était organisé par WeScale et comptait une vingtaine de sessions. Forcément, le thème principal tournait autour de l'IA et de la gouvernance appliquées aux plateformes : les agents, la sécurité et l'automatisation.

En introduction, Luca Galante expliquait qu'une équipe sur dix identifie le modèle comme son principal problème, et qu'environ 30 % pointent l'infrastructure autour. Sachant que tout le monde a accès aux mêmes modèles, c'est aujourd'hui la plateforme qui va vraiment faire la différence.

D'ailleurs, dans une autre session, Alexandre Hugla (Broadcom) en tirait une conséquence : les agents doivent aujourd'hui être traités comme un type d'utilisateur à part entière, auquel on doit appliquer du tracking, de l'audit et du contrôle d'accès.

De cette journée, j'ai principalement retenu quatre talks, sur lesquels je vous propose de revenir avec mon avis.

Manuel Pais : un agent ne voit pas les frontières entre équipes

Manuel Pais, co-auteur du livre Team Topologies, a commencé son talk par une anecdote. Un agent chargé de débloquer le rapport d'un client se sert d'un point d'entrée de données d'une autre équipe, qui n'était pas prévu pour un utilisateur tiers. Derrière, personne ne vérifie, et trois semaines plus tard le problème revient avec encore plus de clients impactés.

Le truc, c'est que l'agent a fait son travail, mais il n'avait pas conscience de toutes les frontières organisationnelles qu'on trouve dans une entreprise. Ce qu'il postule, c'est qu'il faut aujourd'hui retravailler, au sein d'une organisation, des API lisibles par une machine, qui indiquent à l'agent ce qu'il peut faire et ce qu'il ne peut pas faire, pour éviter qu'il franchisse ces frontières. C'est aussi une manière d'optimiser la charge cognitive de l'agent, parce que la fenêtre de contexte équivaut en fait à sa mémoire de travail.

Il indique également que l'IA peut aider à réconcilier autonomie et responsabilité. Chez Seven Mile, on le rejoint en partie. On est totalement convaincus que l'IA peut produire les preuves, sous forme de traces, de contrôles de politiques et de conformité vérifiée en continu. La responsabilité, elle, doit toujours rester humaine.

Comme on peut le voir sur la slide juste en dessous, les agents ne connaissent pas l'intention métier : c'est aux personnes de rester dans la boucle. Ce qui permet au final de faire cohabiter les deux, c'est l'observabilité. On ne peut pas déléguer d'autonomie à un agent qu'on ne sait pas observer.

Pablo Lopez : chaque agent est une identité

Pablo Lopez, qui dirige les équipes Platform Engineering chez PayFit, a raconté deux incidents qu'il a vécus récemment :

1. la compromission du paquet npm axios fin mars 2026 ;
2. le vol d'un token GitHub, réexploité quelques mois plus tard en lien avec le ver Miasma.

Il explique notamment que chez PayFit, des commits signés ont été repérés à cause de leur horaire : 4 h du matin. Leur réponse se fait en trois temps :

1. Savoir, en mettant en place de la veille. Elle peut s'automatiser : des flux RSS de blogs sécurité passent par un LLM, qui indique quels paquets compromis concernent ce qui tourne sur la plateforme. Il faut aussi des SBOM qui remontent en 5 minutes au lieu de plusieurs heures.
2. Agir, avec des kill switches : des mécanismes d'urgence qui permettent de verrouiller immédiatement un poste compromis, de révoquer tous ses tokens ou de bloquer les merges. Lors du second incident, les merges ont ainsi été bloqués pendant 8 heures.
3. Prévenir, en appliquant le least privilege, en faisant du deny by default et en donnant une identité propre à chaque service, chaque agent et chaque sous-agent.

On est d'accord sur le principe, mais l'outillage n'est pas encore mature. Pour l'inventaire des identités non humaines, on est déjà en retard sur les tokens que créent les humains. Pablo Lopez y ajoute les secrets créés par les agents eux-mêmes, et avec des sous-agents éphémères, ça ne peut pas être tenu à la main. Il faut des identités courtes, émises par la plateforme au moment où l'agent en a besoin. C'est vraiment une capacité qui doit être portée en service partagé, plutôt que de laisser chaque équipe gérer seule ses accès.

Michel Hubert : le control plane et la délégation graduée

Michel Hubert (Avanade) part dans son talk du constat suivant : un agent déclenche une chaîne d'exécutions dont la latence, le coût et les résultats varient. Le CPU d'un pod peut être à 5 % pendant que l'utilisateur se plaint, parce que le pod attend le modèle ou un outil. Le contrat de la plateforme évolue donc des ressources vers des résultats sous contraintes, et la plateforme devient un control plane qui décide quelles règles s'appliquent.

Il en conclut qu'il faut désormais mettre en place une délégation graduée, par exemple :

• redémarrer un pod : l'agent le fait seul ;
• basculer 5 % du trafic : avec vérification ;
• supprimer des données : avec validation humaine.

Cette délégation graduée, c'est également ce qu'on applique à nos agents. On distingue les actions qui peuvent être automatiques, laissées libres à l'agent, de celles, un peu plus critiques, qui nécessitent un human in the loop. Prenons un exemple simple : un agent qui trie une boîte mail peut appliquer les labels et archiver tout seul. En revanche, un agent qui prépare un mail doit s'arrêter au brouillon : l'envoi reste une décision humaine. Ces règles, on peut les inscrire dans les instructions que lisent les agents, par exemple dans les skills qu'ils utilisent.

À l'échelle d'une personne, ça paraît pratique et facile, mais à l'échelle d'une entreprise, c'est exactement le rôle de ce control plane.

Benjamin Ameztoy : ouvrir l'observabilité aux agents

Benjamin Ameztoy, Platform Tech Lead Observability chez Peaksys, la filiale tech de Cdiscount, a raconté cinq ans d'observabilité construite en interne : 5 000 machines majoritairement on-premise, environ 2 000 microservices, une livraison toutes les 7 minutes en moyenne. Métriques, logs et traces vivent sur trois plateformes séparées derrière Grafana, pour garder de la visibilité si l'une tombe. Le chantier en cours : ouvrir ces données aux agents IA via API et MCP, en surveillant la stabilité de la plateforme face aux requêtes non optimisées que génèrent les agents. Après cinq ans, le plus difficile reste selon lui de convaincre une centaine d'équipes de structurer leurs logs et d'instrumenter leurs applications.

Ouvrir l'observabilité aux agents via MCP est la bonne direction, et c'est là que s'applique la délégation graduée : l'agent lit, avec des quotas de requêtes, et n'agit pas sans validation. L'inquiétude de Benjamin Ameztoy sur les requêtes non optimisées montre que l'agent experience se conçoit aussi du côté de la plateforme qui encaisse ces requêtes.

Repenser le métier

Aujourd'hui, il faut repenser le métier de platform engineer. Les équipes plateforme doivent devenir capables de concevoir des plateformes et la gouvernance qui permettent d'héberger un nouveau type d'utilisateur : les agents IA.

En clôture, Luc Legardeur, CEO de WeScale, a souligné que le rôle des ingénieurs évolue de l'exécution vers la conception et la gouvernance, parce que l'écriture de code, le déploiement de clusters et la livraison d'environnements vont être largement automatisés par ces agents. Dans son talk, Michel Hubert proposait de passer de l'exploitation d'une infrastructure à la conception des règles selon lesquelles elle doit s'exploiter elle-même.

Pour une équipe plateforme, la première étape est assez concrète. Il faut reprendre chaque capacité de la plateforme et écrire :

• ce qu'un agent peut faire seul ;
• ce qu'il peut faire avec vérification ;
• ce qui demande toujours une validation humaine.