Les 17 et 18 septembre 2026, deux membres de l’équipe TechMyTeam étaient présents à l’API Platform Conference à Lille. Pendant deux jours, développeurs, architectes, CTO et contributeurs de l’écosystème se sont réunis autour de plusieurs sujets qui façonnent aujourd’hui le développement PHP : APIs, intelligence artificielle, architecture, performance, sécurité et évolution du runtime PHP.
Au-delà des nouveautés présentées pendant la conférence, cette édition 2026 permet surtout de prendre du recul sur une évolution de fond : les applications modernes deviennent plus distribuées, plus asynchrones et de plus en plus intégrées à des systèmes externes, notamment à l’IA.
Cette participation avait un objectif concret : comprendre les évolutions de l’écosystème, confronter nos pratiques à celles d’autres équipes et identifier les sujets qui méritent d’être approfondis dans nos projets.
Des APIs aux agents IA : de nouveaux consommateurs à prendre en compte
Pendant longtemps, une API avait principalement deux types de consommateurs : les applications clientes et les développeurs qui les intégraient.
L’essor des agents IA introduit aujourd’hui un nouveau type de consommateur : un système capable de découvrir des outils, de choisir une action et de l’exécuter de manière autonome.
Le rôle du Model Context Protocol
Le Model Context Protocol (MCP) permet notamment d’exposer des ressources et des actions à des agents IA sous la forme d’outils qu’ils peuvent découvrir et utiliser.
Plusieurs approches ont été présentées autour de l’intégration entre APIs et agents : génération d’outils à partir d’OpenAPI, utilisation d’une approche hypermédia ou encore définition manuelle d’outils orientés vers des tâches métier.
Un point est particulièrement intéressant : exposer directement une API complète à un agent peut rapidement conduire à un nombre important d’outils et de tokens nécessaires à leur description.
Le sujet n’est donc pas simplement de rendre une API « compatible avec l’IA ». Il faut également réfléchir à la manière dont elle sera utilisée par un agent.
Les actions doivent être clairement définies, les descriptions suffisamment précises pour permettre au modèle de comprendre leur rôle et les permissions doivent être maîtrisées. Les opérations doivent également être pensées autour des besoins métier plutôt que d’une simple exposition technique des données.
L’arrivée des agents IA ne rend donc pas les APIs obsolètes. Au contraire, elle renforce l’importance d’une API bien conçue, capable de porter les règles métier, les permissions et les données.
À ce stade, l’intégration MCP d’API Platform reste toutefois expérimentale.
FrankenPHP : PHP change progressivement de modèle d’exécution
Autre sujet important abordé lors de la conférence : l’évolution du modèle d’exécution de PHP.
Le fonctionnement traditionnel de PHP est relativement simple : une requête arrive, l’application est exécutée, puis son état est généralement détruit à la fin de la requête. Ce modèle reste efficace dans de nombreux cas, mais de nouveaux usages poussent progressivement l’écosystème vers d’autres modèles d’exécution.
Le worker mode
Plusieurs présentations ont exploré FrankenPHP et son worker mode, notamment à travers des migrations de systèmes existants et des comparaisons avec différents modes d’exécution.
Le principe est différent : l’application peut rester chargée en mémoire et traiter plusieurs requêtes successivement.
Cette approche peut réduire certains coûts d’initialisation et ouvrir la porte à de nouveaux modèles d’exécution. Mais elle apporte également de nouvelles contraintes.
Une application conçue pour un modèle traditionnel doit alors prendre en compte la gestion de l’état, les éventuelles fuites mémoire, le cycle de vie des services, le comportement des workers, l’observabilité ou encore les mécanismes de redémarrage et de récupération après erreur.
Le worker mode n’est donc pas simplement une optimisation de performance. Il représente un changement de paradigme dans la manière d’exécuter une application PHP.
La maturité croissante de FrankenPHP rend ces modèles de plus en plus intéressants, mais leur adoption doit être accompagnée de benchmarks, d’observabilité et d’une bonne compréhension du comportement de l’application dans la durée.
API Platform 4.4 et 5.0 : les migrations deviennent un processus continu
Avec une version majeure d’API Platform désormais prévue chaque année, la gestion des migrations devient un sujet récurrent pour les équipes.
API Platform 4.4 introduit notamment plusieurs évolutions autour des filtres, avec une transition vers les QueryParameter et une commande permettant d’accompagner la migration. La version 5.0 poursuit cette évolution.
Ce rythme de versions peut sembler contraignant, mais il présente également un intérêt : éviter de devoir gérer des migrations massives après plusieurs années sans évolution.
La stratégie consiste alors à ne plus considérer une migration majeure comme un projet exceptionnel, mais comme un processus à anticiper dans le quotidien des équipes.
Cela implique notamment de :
- surveiller les dépréciations ;
- les traiter régulièrement ;
- maintenir les dépendances à jour ;
- automatiser autant que possible les vérifications ;
- préparer progressivement les migrations.
La meilleure migration est celle que l’on prépare avant d’en avoir besoin.
Pour une équipe qui maintient plusieurs applications, traiter les dépréciations au fil de l’eau peut permettre de réduire le coût et le risque des futures montées de version.
Quand API Platform rencontre le Domain-Driven Design
API Platform permet de construire rapidement des APIs en s’appuyant sur de nombreuses conventions. Mais lorsque la complexité métier augmente, ces conventions peuvent nécessiter une architecture plus structurée.
Une présentation consacrée au Domain-Driven Design avec API Platform a notamment abordé l’architecture hexagonale, la séparation du domaine et de l’infrastructure, le design orienté messages, la gestion de domaines métier complexes ainsi que le streaming de gros volumes avec JsonStreamer.
L’enseignement est finalement assez simple : un framework doit accélérer le développement, mais il ne doit pas dicter toute l’architecture d’un système.
Lorsque les contraintes métier deviennent importantes, il devient nécessaire de conserver une séparation claire entre :
Domaine → Application → Infrastructure → Exposition API
L’objectif n’est pas d’ajouter de la complexité pour le plaisir, mais de préserver la capacité du système à évoluer lorsque les besoins métier deviennent plus importants.
Concevoir des systèmes capables d’échouer
L’un des retours d’expérience présentés pendant la conférence concernait une architecture event-driven construite autour de Symfony, API Platform, Messenger et Redis.
Le problème est classique dans les systèmes d’entreprise : une API dépend souvent de services qu’elle ne contrôle pas entièrement.
Un ERP peut ralentir.
Un service externe peut devenir indisponible.
Une opération peut prendre plusieurs secondes.
Un pic de trafic peut provoquer une saturation.
La question n’est donc plus uniquement :
« Comment faire fonctionner le système ? »
Mais plutôt :
« Comment faire fonctionner le système lorsque quelque chose échoue ? »
Répondre maintenant, traiter ensuite
Une approche consiste à accepter rapidement la demande côté API puis à déléguer le traitement lourd à des workers Messenger.
L’utilisateur n’a alors plus besoin d’attendre la réponse d’un système externe pour obtenir une première réponse de l’API.
Redis peut également jouer plusieurs rôles dans cette architecture, notamment comme cache et comme transport de messages. Le cache permet notamment de protéger les systèmes en aval et d’éviter certaines situations dans lesquelles de nombreuses requêtes tentent simultanément de recalculer une donnée expirée.
Mais concevoir une architecture résiliente implique aussi de penser les échecs dès le départ : retries, gestion des erreurs définitives, isolation des traitements, observabilité et contrôle du nombre de tentatives.
La fiabilité ne vient donc pas simplement du framework utilisé. Elle repose sur des décisions d’architecture explicites :
- qu’est-ce qui doit rester synchrone ?
- qu’est-ce qui peut être asynchrone ?
- que faire lorsqu’un service externe ne répond pas ?
- combien de fois faut-il réessayer ?
- quand considérer une opération comme définitivement échouée ?
Dans un système distribué, la fiabilité est souvent plus importante que l’ingéniosité.
Sécuriser ses APIs sans réinventer les protocoles
La sécurité des APIs couvre de nombreux sujets : OAuth2, OpenID Connect, JWT, rate limiting, CORS, en-têtes HTTP et contrôle des accès.
La conférence a rappelé un principe essentiel : lorsqu’un standard et des outils éprouvés existent, il est généralement préférable de les utiliser plutôt que de réimplémenter soi-même des mécanismes complexes.
Des solutions comme Keycloak et les fonctionnalités de sécurité de Symfony permettent notamment de déléguer une partie importante de ces responsabilités.
Les en-têtes HTTP jouent également un rôle important dans la protection des APIs et des applications web.
Mais au-delà des outils, le principal enseignement est architectural : la sécurité ne doit pas être ajoutée à la fin d’un projet. Elle doit être considérée dès le départ.
Et surtout, il est inutile de réinventer des protocoles de sécurité qui existent déjà et qui ont fait leurs preuves.
L’IA en production : passer du prototype à l’architecture
Construire une première fonctionnalité utilisant un LLM est aujourd’hui relativement simple. Le véritable défi apparaît lorsque cette fonctionnalité devient un composant critique d’un produit.
Une présentation retraçant plusieurs années d’évolution d’une stack LLM en Symfony/API Platform a notamment montré une progression typique :
Prompt → abstraction multi-provider → traitements asynchrones → agents
À mesure que les usages se développent, les problématiques deviennent rapidement des problématiques d’architecture.
Comment changer de fournisseur de modèle ?
Comment gérer les erreurs ?
Comment observer les traitements ?
Comment reprendre un traitement interrompu ?
Comment gérer les traitements asynchrones ?
Comment maîtriser les coûts ?
Comment tester un système dont les réponses peuvent être probabilistes ?
Ces questions montrent que l’IA ne supprime pas les fondamentaux de l’ingénierie logicielle. Elle les rend souvent encore plus importants.
Une fonctionnalité IA peut commencer par un prompt. Un produit IA nécessite une architecture.
Ce que ces tendances changent pour le développement PHP
Pris séparément, les sujets abordés lors de l’API Platform Conference peuvent sembler très différents : API Platform, MCP, FrankenPHP, Domain-Driven Design, Messenger, Redis, sécurité ou encore LLM.
Pourtant, ils répondent à une même évolution : les applications modernes deviennent plus distribuées, plus asynchrones et plus intégrées à des systèmes externes.
Dans ce contexte, plusieurs compétences deviennent particulièrement importantes.
1. Concevoir des APIs pour plusieurs types de consommateurs
Une API doit pouvoir servir des applications classiques, des services internes et, de plus en plus, des agents logiciels.
2. Concevoir pour l’échec
Les systèmes distribués doivent intégrer les retries, les timeouts, les files de messages, les caches et les mécanismes de récupération.
3. Observer avant d’optimiser
Performance et résilience nécessitent des métriques, des traces et une bonne visibilité sur le comportement réel du système.
4. Garder une architecture évolutive
Les frameworks accélèrent le développement, mais les frontières entre domaine, application et infrastructure restent essentielles lorsque la complexité augmente.
5. Traiter l’IA comme un composant logiciel
Un LLM ne doit pas être considéré comme une simple API externe. Dès qu’il devient critique dans un produit, il faut penser abstraction, observabilité, résilience, asynchronisme et sécurité.
Et maintenant, que va explorer TechMyTeam ?
La conférence constitue surtout un point de départ pour approfondir plusieurs sujets et les confronter à des expérimentations concrètes.
Plusieurs axes vont ainsi être explorés dans les prochains travaux :
API Platform 5
Anticiper les évolutions et simplifier les migrations, notamment en traitant progressivement les dépréciations.
MCP
Mieux comprendre comment exposer des APIs à des agents IA, avec l’idée de réaliser un POC sur un périmètre réduit.
FrankenPHP
Évaluer le worker mode et ses bénéfices à travers des benchmarks et une approche basée sur l’observabilité.
La participation à l’API Platform Conference 2026 aura ainsi permis de confronter les pratiques, d’identifier les évolutions de l’écosystème PHP et de faire émerger des pistes concrètes d’expérimentation.
Car au-delà des nouvelles technologies et des nouvelles versions, une question reste centrale : comment construire des applications capables d’évoluer avec les usages, les architectures et les nouveaux types de consommateurs qui apparaissent ?
