Comment nous avons créé un assistant IA pour l’API Platform Conference 2026

Trouver le talk qui correspond à vos objectifs, savoir qui va briller sur la scène FrankenPHP, caler votre agenda… La billetterie de l’API Platform Conference 2026 ferme dans quelques jours, et on a voulu vous accompagner jusqu’au bout avec un nouvel outil : un assistant IA avec qui échanger directement sur la conférence. On vous raconte ce projet en trois articles : celui-ci pose le contexte général, le second détaille l’architecture, et le troisième revient sur notre choix d’outils souverains. Prêt·es à tester ?

Les prémices du projet

Chaque année, l’API Platform Conference propose à Lille deux jours de programme chargé : des dizaines de conférences sur plusieurs tracks, des intervenant·es venu·es du monde entier, des ateliers, et toute la logistique qui va avec un événement en pleine croissance. Et chaque année, les mêmes questions reviennent côté participant·es : qu’est-ce qui se passe en ce moment, c’est quoi la prochaine conférence en salle 2, qui parle de tel sujet, où sont les stands des partenaires… On a voulu y répondre avec un assistant conversationnel.

La façon évidente de faire, c’est un chatbot classique : une interface, un LLM, un prompt, un accès aux données câblé derrière. C’est d’ailleurs par là qu’on a commencé. Mais en cours de route, une question de conception a fait bifurquer tout le projet, et la réponse s’est révélée beaucoup plus réutilisable qu’une simple fenêtre de chat. C’est ce recadrage qu’on raconte dans cet article, parce que c’est la leçon la plus transposable qu’on en a tirée, et elle ne doit presque rien à la technique.

L’idée de départ vient de techready.live, qui a montré tout ce qu’un bon compagnon d’événement peut apporter aux participant·es. Notre question a été : à quoi ça ressemble, cette expérience, à l’heure des agents IA ?

Une question qui a changé la conception

La question qu’on s’est posée : quand l’assistant doit savoir « quelle est la prochaine conférence en salle 2 », où vit cette connaissance ?

Si la réponse est « dans le chatbot », alors le chatbot, c’est le produit. Et toute autre façon d’accéder à la même info (Claude Desktop, un assistant d’IDE comme Cursor, le bot Slack d’une équipe, le script perso d’un·e collègue) devrait être reconstruite de zéro, avec sa propre copie de l’accès aux données, des règles métier et du prompt. La fenêtre de chat deviendrait à la fois l’interface et le plafond de verre.

On a donc inversé la logique. On a d’abord construit la connaissance de la conférence et les actions possibles pour un·e participant·e comme un service autonome, et traité l’interface de chat comme son premier client et pas comme le produit lui-même. Ce service s’appuie sur le Model Context Protocol (MCP), le standard ouvert pour exposer des outils à des agents IA. Le chat en est un consommateur parmi d’autres ; n’importe quel agent compatible MCP peut en être un autre.

Des capacités, pas des endpoints

Concevoir un serveur MCP, ça change subtilement la manière de penser par rapport à une API REST classique. Au lieu de raisonner en ressources et en endpoints, on raisonne en capacités et en verbes les actions concrètes qu’un·e utilisateur·ice fait vraiment.

Notre serveur s’organise autour des besoins réels d’un·e participant·e pendant l’événement :

• Explorer le programme : lister et rechercher des conférences, récupérer les détails d’une session ou d’un·e intervenant·e, parcourir l’historique d’un·e speaker, lister les catégories et les partenaires, lire les infos générales de l’événement.
• Se repérer dans le temps : savoir ce qui se passe maintenant et ce qui vient ensuite.
• Participer : noter une conférence, laisser un commentaire, lire les retours de la communauté.
• Planifier : ajouter une conférence à son agenda personnel, la retirer, le consulter.

Le projet compte vingt outils au total. Ce qui compte, c’est qu’ils portent des noms d’actions humaines, pas des noms de tables SQL. « Les prochaines conférences », c’est une capacité que n’importe quel·le participant·e comprend ; une query string avec un offset et une limite, c’est de la tuyauterie. Et quand celui qui consomme l’API est un modèle de langage qui doit décider quel outil appeler, c’est ce cadrage sémantique qui l’aide à choisir le bon outil et à lui passer les bons arguments.

La description de l’outil est l’interface

Le plus surprenant dans ce développement, c’est la documentation. Sur une API classique, la doc de référence s’adresse aux développeur·euses et reste, dans les faits, optionnelle : le code marche, que la doc soit bonne ou non. API Platform fait déjà mieux avec une doc OpenAPI générée automatiquement à partir du code, toujours à jour. Mais sur un serveur MCP, la description de chaque outil est lue par le modèle à chaque décision qu’il prend. Ce n’est plus de la documentation sur l’interface, c’est l’interface. Elle décide si l’agent appelle l’outil, et s’il l’appelle correctement.

Une description du genre « Voter pour une conférence » n’apprend quasiment rien au modèle. Voici celle qu’on a fini par écrire pour l’outil de notation :

Rate an API Platform Conference 2026 talk (1–5). Requires a GitHub access token (sent as a Bearer token); one vote per talk per user — voting again updates your rating. Returns the updated feedback.

En trois phrases, le modèle sait quelle plage de notes est valide, qu’une authentification est requise, que revoter met à jour la note au lieu de la dupliquer, et à quoi ressemble la réponse. On a passé plus de temps à écrire et réécrire ces descriptions que sur n’importe quel handler. Sur un projet MCP, ce sont elles qui font la différence entre un projet qui marche et un qui ne marche pas, ça vaut le coup de les traiter comme du vrai prompt engineering.

L’authentification comme frontière produit

L’essentiel du serveur est accessible sans création de compte : lire le programme ne demande rien. Écrire, en revanche : noter une conférence, laisser un commentaire ou se construire un agenda  demande une connexion GitHub. C’est un choix assumé, pas un détail technique : il définit qui a le droit de modifier les données et garde une trace des contributions.

Cette règle est portée par l’outil lui-même, pas par un client en particulier. Un agent qui essaie de voter sans token reçoit une réponse en langage clair lui expliquant qu’une connexion est nécessaire. Notre interface de chat traduit ça par un bouton « Se connecter avec GitHub » ; un autre client le présenterait autrement. Mais la règle vit à un seul endroit, sur le serveur, donc chaque client l’applique sans avoir à la réécrire.

Bring your own agent

Quand le produit est un service et non une appli figée, la distribution change de nature : ce n’est plus un app store, mais un petit bout de configuration. Un·e développeur·euse ajoute quelques lignes à son client IA préféré, et son assistant sait répondre aux questions sur la conférence et enregistrer ses votes. Pareil pour un assistant d’IDE ou un script écrit pour un besoin précis : chaque client accède aux mêmes vingt outils et au même comportement, sans qu’on ait à redévelopper quoi que ce soit de notre côté.

Pour que ce soit concret, on publie une page statique avec des instructions d’installation copier-coller pour les clients les plus courants. Le « bring your own agent », ça ne marche que si ça prend deux minutes à mettre en place.

Notre interface de chat garde toute son utilité : c’est le point d’entrée que la plupart des participant·es utiliseront, et on détaille sa construction dans la Partie 2. Mais ce n’est qu’une porte d’entrée parmi d’autres, pas là où se concentre la valeur du projet.

Retours d’expérience et bonnes pratiques

Quelques principes qui ont tenu la route, et qu’on appliquerait à n’importe quel projet MCP :

• Modéliser le domaine par des verbes. Quand les capacités portent le nom des actions de l’utilisateur·ice, les frontières entre outils se dessinent toutes seules, et le modèle choisit plus fiablement quel outil appeler.
• Traiter les descriptions comme de l’UX. Ça prend du temps à écrire et à tester contre le comportement réel du modèle.
• Préférer la sortie structurée à la prose formatée. Du contenu typé laisse chaque client (bulle de chat, panneau d’IDE, interface vocale) libre de le présenter comme il veut.
• Mettre la logique de contrôle côté serveur. Un client peut oublier l’authentification, les rate limits ou la validation ; le serveur, lui, doit les appliquer systématiquement.
• Voir l’interface comme un client, pas comme le produit. Ça reste utile d’en soigner une, mais ça ne doit pas devenir le seul moyen d’interagir.

Au final, ce qui compte dans ce projet, ce n’est pas tellement la fenêtre de chat qu’on a construite, mais le socle technique sur lequel n’importe quel futur client IA peut venir s’appuyer..

La suite du cheminement

Dans la Partie 2, on rentre dans le détail technique : comment API Platform transforme une ressource en outil MCP avec un seul attribut, comment le mode worker de FrankenPHP garde le serveur actif, et comment les réponses sont streamées jusqu’au navigateur avec Mercure. La Partie 3 montre que toute cette infrastructure peut tourner sur une stack entièrement européenne et open source, inférence comprise.