Jusqu’au Forum PHP 2026, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

Exposer son métier aux agents IA avec API Platform Vous avez forcément déjà demandé à un assistant IA d'aller faire quelque chose à votre place : réserver, commander, mettre à jour une fiche. Quand ça marche, plus personne ne clique sur une interface, et c'est bluffant. Mais une fois l'effet passé, une question bien plus intéressante demeure : qu'est-ce qui, dans nos applications, permet à un agent d'agir ? Après un rapide détour par le Model Context Protocol (MCP), soit la façon dont un agent découvre et appelle les opérations d'une application, nous étudierons le vrai besoin : exposer son métier sans en écrire une seconde description « pour l'IA ». Nous verrons pourquoi API Platform part déjà avec une longueur d'avance, en réutilisant ce qu'il décrit depuis toujours : vos ressources, leur validation, leur sérialisation et leur sécurité. De la ressource d'API aux outils MCP, il n'y a qu'un pas. En réutilisant la couche CQRS d'API Platform, nous verrons comment transformer nos ressources existantes en outils qu'un agent peut appeler, sans jamais dupliquer la description de notre domaine. Et puisque l'interface, elle, semble se dissoudre, nous terminerons sur la question qui nous attend toutes et tous : à quoi ressembleront nos logiciels quand l'API sera la porte d'entrée, et l'agent, son premier client ?

Joan Clarke - HJK 08/10/2026 10:00-10:40

Quelle est pour toi l'évolution la plus marquante sur API Plateform ces 12 derniers mois ?

Sans hésiter, l'arrivée du support de MCP dans la 4.3, en mars. Votre API devient un serveur MCP, côté Symfony comme côté Laravel, et vos ressources deviennent des outils qu'un agent peut appeler.

Ce qui est marquant pour moi, ce n'est pas tant le protocole que ce qu'il a révélé. Cela fait plus de dix ans que nous défendons la même architecture : le domaine se décrit une seule fois, dans des métadonnées, et tout le reste n'est qu'une vue sur cette description. C'est comme ça que nous produisons OpenAPI, JSON-LD et Hydra, GraphQL, JSON Schema, sans jamais redemander au développeur de réécrire son modèle. On nous a souvent dit que c'était trop abstrait, que c'était de la sur-ingénierie. Et puis un protocole complètement nouveau arrive, pensé par des gens qui n'avaient jamais entendu parler d'API Platform, et il se branche sur ces mêmes métadonnées. Il s'est passé trois mois entre la première expérimentation et un composant dédié. Nous n'avons rien eu à reconcevoir.

C'est une satisfaction rare en logiciel libre, parce que ce genre de pari se juge sur dix ans, pas sur une release. Les décisions d'architecture qu'on prend aujourd'hui, on ne sait pas encore si elles étaient bonnes, on le saura quand le prochain format ou le prochain protocole arrivera et qu'il faudra soit l'accueillir, soit tout casser.

Deux autres chantiers méritent d'être mentionnés : l'ObjectMapper de Symfony branché sur les stateOptions, et la refonte des filtres autour des paramètres. Ils enlèvent une couche d'indirection que nous traînions depuis la 2.x, avec toute la rétro-compatibilité à assurer derrière, ce qui reste la partie la plus longue et la plus délicate de notre travail.

L'IA a fait les gros titres cette année, mais ce sont les métadonnées qui ont fait le travail.

Tu as dernièrement publié avec Kévin Dunglas un article scientifique en prépublication à propos des APIs Hypermedia et des LLMs. Peux-tu nous parler de cette expérience ?

Au départ ce n'était pas un projet d'article, c'était une frustration. En implémentant MCP, nous sommes tombés sur une contradiction que nous n'arrivions pas à contourner proprement. MCP demande au modèle d'appeler des outils prédéfinis, il ne lit pas un contenu de lui-même. Une API HATEOAS fait exactement l'inverse : les actions sont dans la réponse, découvertes à l'exécution, dépendantes de l'état de la ressource et des droits de l'utilisateur. Une opération Hydra peut apparaître ou disparaître d'une réponse à l'autre. Les deux modèles se contredisent, et ce que nous cherchions, c'était le meilleur des deux mondes : la simplicité d'usage de MCP côté agent, sans renoncer à ce que l'hypermedia apporte côté serveur.

Ce que nous proposons est une passerelle dynamique. L'agent démarre avec un seul outil, une opération de lecture, et découvre les autres au fil de sa navigation : quand il visite une collection, la passerelle croise la réponse avec la documentation Hydra et enregistre à ce moment-là les outils correspondants. Autrement dit, les outils apparaissent au fur et à mesure, en fonction de là où l'agent se trouve, exactement comme un client hypermedia est censé fonctionner.

Nous l'avons comparée à une baseline OpenAPI statique, avec deux modèles et un protocole reproductible que tout le monde peut rejouer. Les deux approches accomplissent les mêmes tâches, la différence se joue sur le contexte : l'agent n'a jamais en tête que les outils dont il a besoin, là où la baseline lui réinjecte la totalité des schémas de l'API à chaque tour. En échange il doit naviguer un peu avant d'agir, ce qui coûte quelques appels supplémentaires. Sur une petite API ce coût domine, sur une grosse le rapport s'inverse et on consomme nettement moins de tokens en entrée. Les chiffres exacts sont dans l'article pour celles et ceux que ça intéresse.

Ce qui me plaît le plus dans cette histoire, c'est qu'on ne fait que reprendre le fil. Quand Tim Berners-Lee, James Hendler et Ora Lassila décrivent le web sémantique dans Scientific American en 2001, ils ne parlent pas de moteurs de recherche, ils parlent d'agents logiciels qui vont lire du RDF et agir à notre place. Le RDF est une recommandation du W3C depuis 1999. Autrement dit, les formats que nous utilisons dans API Platform ont été conçus pour des machines, bien avant que les LLM n'existent, par des gens qui venaient justement des systèmes multi-agents. La technologie qui manquait à l'époque est arrivée entre temps, et on redécouvre que la couche d'interopérabilité était déjà là. Je le disais l'an dernier, je ne serais rien sans les standards. Cet article, c'est simplement la continuité de ces recherches.

Avec ton rôle de contributeur sur le SDK PHP pour le MCP et API Platform, penses-tu qu'on bascule vers un modèle où le MCP devient la priorité absolue devant les API traditionnelles ?

Non. MCP ne remplace pas votre API, il la consomme.

Un serveur MCP ne sait rien de votre métier. Il ne sait pas qu'une commande payée ne s'annule plus, que ce champ est réservé aux administrateurs, que cette valeur doit être validée. Tout ça vit dans l'API et doit y rester. On ajoute un maillon à la chaîne, on n'en retire aucun.

Par contre, il faut être lucide sur la maturité. Je fais partie depuis mars de l'équipe qui maintient le SDK PHP officiel, et je contribue au bundle MCP de Symfony AI, donc je vois le rythme de près : le protocole et le SDK évoluent très vite, avec des révisions de la spécification en parallèle. Le contenu de mes contributions dit bien où nous en sommes : durcir l'analyse des messages JSON-RPC malformés, corriger OAuth pour qu'un serveur MCP se comporte en serveur de ressources et pas en serveur d'autorisation, faire tourner les tests de conformité chaque semaine contre la dernière version de la spécification. C'est jeune et c'est sain, mais poser son système d'information là-dessus en priorité, c'est viser une cible mobile. C'est d'ailleurs pour cette raison que notre composant est marqué expérimental.

Il y a aussi un point de sécurité qu'on sous-estime beaucoup : exposer un serveur MCP, c'est autoriser un client non déterministe à appeler des opérations qui écrivent. Ce qui vous protège, ce n'est pas MCP, c'est la sécurité de votre API.

Selon moi, le meilleur investissement « IA » qu'une équipe PHP puisse faire aujourd'hui, c'est simplement de bien modéliser son API. Si le domaine est correctement décrit, exposer du MCP n'est plus qu'une dépendance à installer, et c'est ce que je montrerai pendant la conférence : passer de ressources existantes à des outils qu'un agent peut appeler, sans jamais écrire une seconde description de son métier « pour l'IA ».

L'agent, c'est le nouveau client. L'API, elle, n'a pas bougé.

Une conférence présentée par

Antoine BLUCHET

Antoine est un développeur full-stack, il contribue aux logiciels open-source depuis plus de 10 ans. Auteur et mainteneur de modules JavaScript, il contribue également à Symfony et API Platform. Quand il ne répare pas ou ne conduit pas sa moto, ou qu'il ne jongle pas sur un monocycle, il est probablement en train de coder, d'écrire ou de préparer une nouvelle conférence impliquant de la programmation innovante !

Autres interviews

• La parole est aux speakers : Mathias Arlaud
• La parole est aux speakers : Gaël CRISPYN
• La parole est aux speakers : Guillaume Lours
• La parole est aux speakers : Kévin Martins
• La parole est aux speakers : Pierre Tondereau
• La parole est aux speakers : Kévin Dunglas
• La parole est aux speakers : Jori STEIN
• La parole est aux speakers : Thomas Dutrion
• La parole est aux speakers : Charlotte Chaumet
• La parole est aux speakers : Benjamin Eberlei
• La parole est aux speakers : Alexandre Daubois
• La parole est aux speakers : Michaël Benhaïm
• La parole est aux speakers : Sebastian Bergmann
• La parole est aux speakers : Yoann Blot
• La parole est aux speakers : Niels Ackermann
• La parole est aux speakers : Jean-François Lépine