La parole est aux speakers : Sébastien Rogier
Jusqu’au mois de mai 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
De GPT-3 aux agents : 4 ans d'évolution d'une stack LLM en PHPEn 2021, l'effet "magique" : nous intégrons GPT-3 à notre SaaS SEO (stack Symfony/API Platform). Un simple appel à une API, un prompt, et nous avons des suggestions de titres dans notre application. Deux ans plus tard, l'effet magique s'estompe. Nous maintenons des dizaines de "générateurs". L'architecture (1 classe = 1 prompt) est devenue une usine à gaz, difficile à maintenir ou à faire évoluer. 2024 : Le besoin d'intégrer Claude expose notre dépendance technique. Nous devons intégrer un second provider dans une architecture 100% OpenAI. Première refonte : une abstraction multi-provider avec fallback. Changer de LLM devient une ligne de config. Mais les nouvelles features exigent d'aller plus loin. Le besoin émerge de gérer le streaming, de maintenir des échanges LLM de plusieurs minutes, et d'orchestrer des prompts secondaires. Deuxième transformation : nous passons à un système d'agent asynchrone. L'agent peut utiliser des "tools" (connectés à notre stack ou des API tierces) pour exécuter ces workflows complexes, tout en gardant la performance comme priorité. Cette nouvelle stack a soulevé des défis majeurs en PHP : fiabilisation de l'exécution, observabilité de workflows complexes, et gestion de la parallélisation/asynchronisme des "tools" sans async/await natif. Aujourd'hui, notre système (templates versionnés, observabilité complète, error recovery) gère environ 40 000 requêtes/jour. Ce talk est le REX de 4 ans de choix d'archi, de patterns, et de belles problématiques pour faire tourner des LLMs en production... avec PHP. |
C.P.E. 22/05/2026 11:20-12:00 |
Sur la partie “agents”, quelle est la limite principale que tu as rencontrée (fiabilité, hallucinations, permissions, observabilité) ?
La limite principale qu’on a rencontrée, c’est la fiabilité en production.
Dès qu’un agent enchaîne plusieurs étapes (LLM, tools, appels d’API tierces) pendant plusieurs minutes, on va multiplier les points de rupture (une latence variable, des timeouts, des annulations utilisateurs).
On a donc cherché à apporter le plus de résilience possible autour de ces exécutions, monitorer au maximum les différents échanges LLMs pour comprendre ce qui se passe, tout en gardant une UX rapide pour que nos utilisateurs et utilisatrices aient la meilleure expérience.
La démarche initiale adoptée : le pattern “1 classe = 1 prompt” paraît correct au début. Qu’est-ce qui l’a rendu ingérable à l’échelle, et quels signaux auraient pu alerter plus tôt ?
Ça marchait très bien au début, on a commencé avec 5 types de variations, donc 5 classes. Le problème est arrivé dès qu’on a commencé à itérer : on a ajouté des petites variantes (settings, données en entrée, formats).
Et on a essayé d’absorber ces variations avec de l’héritage.
Mais les divergences se sont multipliées, les signaux d’alertes aussi (copier/coller, profondeur d’héritage) et la chaîne d’héritage est devenue difficile à maintenir. Donc on a appris, on a cherché à rationaliser ces petites différences en appliquant le principe de « composition over inheritance ».
Avec le caractère non prévisible de l’IA, quelles méthodes utilises-tu pour tester vos workflows en PHP (mocks, fixtures, golden records, tests d’intégration) ?
On ne fait pas de golden tests sur le texte généré, parce que ce n’est pas stable par nature.
On va privilégier les tests de l’architecture de notre stack d’agent et sécuriser ce qui est déterministe via des tests unitaires en mockant les appels aux LLM.
Et en plus de toutes cette couche de tests, la QA est une phase importante dans nos process avec une validation systématique avant release des modifications apportées à nos différents prompts.
Une conférence présentée par
 Sébastien ROGIER |
Sébastien est tech Lead Backend chez Semji. |