Retour sur l'API Platform Conference 2025

On se raconte une histoire à propos des conférences tech. On y va pour les annonces fracassantes, les keynotes qui changent la donne. Pour son dixième anniversaire, l'API Platform Conference a su combler nos attentes. Et cette histoire a deux chapitres qui semblent paradoxaux : d'un côté, une quête de performance brute, et de l'autre, une obsession pour l'expérience dev (DX). Le paradoxe, c'est que l'écosystème PHP a décidé de ne pas choisir. Il veut les deux, et les a.

Cette édition est la plus grande jamais organisée : sold-out pour un mélange de devs, de CTO et étudiant·es qui montrait que c’était un rendez-vous attendu par la communauté. Les annonces clés ont confirmé cette impression : des extensions PHP écrites en Go, un support natif pour gRPC, un API Platform plus mature que jamais, et des améliorations de la DX dans Symfony qui vont nous faire gagner un temps précieux.

La première journée, le message était clair : on renforce les fondations. Du serveur d'applications jusqu'à la base de données, l'objectif est d'atteindre une performance et une stabilité qui étaient, il y a peu, difficiles à imaginer en PHP.

Kévin Dunglas, le créateur d'API Platform et de FrankenPHP , a ouvert le bal. Il a rappelé la promesse d'API Platform : "Une seule structure pour de nombreuses architectures", définir une ressource une fois et la servir en Hydra, OpenAPI, GraphQL, etc. C'est la base.  

Mais la vraie annonce était tout autre : la possibilité d'écrire des extensions PHP... en Go. Ce n'est pas un gadget. C'est une chaîne d'outils complète pour faire le pont entre les deux mondes, avec des convertisseurs de types et des générateurs de code pour masquer la complexité du C et du Zend Engine. Kévin et Alexandre Daubois ont travaillé durant plusieurs semaines pour atteindre ce résultat.

L'application directe? Un serveur gRPC natif pour PHP, propulsé par FrankenPHP. Pour ceux qui ne connaissent pas, gRPC est ce protocole ultra-rapide basé sur HTTP/2 que le monde des microservices adore, mais qui était un cauchemar à implémenter correctement en PHP: il était jusqu’à alors possible de créer seulement des clients gRPC avec PHP, jamais le côté serveur. Le projet est encore expérimental, mais il est déjà sur GitHub.

Soyons clairs : il ne s'agit pas de remplacer les extensions C par Go. C'est plus malin que ça. On délègue les tâches ingrates et critiques en performance (comme la gestion réseau bas niveau) à un langage haut-niveau taillé pour ça (Go), et on garde C pour ce qu'il fait de mieux : les opérations bas-niveau ultra optimisées. On ne remplace pas non plus PHP et un de ses plus grandes forces: écrire la logique métier, rapide à développer et facile à maintenir. C'est le meilleur des deux mondes.

Ce genre d'annonce, c'est bien. Mais est-ce que ça tourne en production? Florian Beer, de l'équipe infrastructure de Laravel , est venu répondre à cette question. Et la réponse est oui. Il a déployé une application Laravel en direct, en moins d'une minute, et a montré comment un simple interrupteur dans l'interface de Laravel Cloud permet de basculer de PHP-FPM à Laravel Octane, qui utilise FrankenPHP.

Ce qui est intéressant ici, c'est la collaboration. Les équipes ont travaillé ensemble pour que ça marche, et ça marche bien. Historiquement, les mondes de Symfony et Laravel avançaient en parallèle. Voir un produit phare de l'écosystème Laravel adopter un outil issu de la communauté Symfony, c'est un signe de maturité incroyable pour tout l'écosystème PHP. On arrête les guerres de clochers, on fait avancer le langage, tous ensemble.

Antoine Bluchet, le release manager d'API Platform, a présenté la version 4.2. Son résumé? "Juste" 610 commits et des centaines de milliers de lignes de code changées.

Une des grosses nouveautés, c'est l'intégration du nouveau composant ObjectMapper de Symfony. Si vous avez déjà galéré à mapper manuellement un DTO vers une entité, vous savez de quoi nous parlons. C'est le genre de code répétitif et source d'erreurs qu'on déteste écrire. Maintenant, quelques attributs #[Map] suffisent. C'est un outil qui va devenir indispensable pour ceux qui veulent faire de la Clean Architecture ou du DDD sans s'infliger une complexité inutile.

Le reste est à l'avenant : des nouvelles façons plus simples de personnaliser les métadonnées avec AsResourceMutator et AsOperationMutator, des filtres refactorisés pour être plus logiques, et des gains de performance de 2x à 3x avec le mode worker de FrankenPHP.

La journée s'est poursuivie sur les fondamentaux. Nils Adermann, co-créateur de Composer , a présenté des options pour la commande update qui vont nous sauver la mise plus d'une fois : --minimal-changes pour éviter de tout casser en mettant à jour une seule dépendance, et --patch-only pour n'appliquer que les correctifs de sécurité.

Pendant ce temps, Florian Engelhardt démystifiait la contribution au cœur de PHP, en montrant qu'écrire un test pour le langage lui-même n'est pas plus compliqué qu'un fichier .phpt avec quelques sections. C'est une invitation claire : le cœur de PHP n'est pas une forteresse inaccessible. Un site dédié indique le code coverage actuel du moteur PHP, permettant de voir en un coup d’oeil les partis du code qui auraient bien besoin de test. Une excellente source d’inspiration pour toute personne souhaitant se lancer dans la contribution du langage !

Pour finir la journée, deux conférences sur la performance pure. Xavier Leune a détaillé, étape par étape, comment il a atteint 196 000 requêtes par seconde avec cURL depuis un simple ordinateur portable, en optimisant chaque couche : réutilisation des connexions, parallélisation, multiplexage HTTP/2 et pcntl_fork().

Juste après, Tobias Petry a offert une masterclass sur la mise à l'échelle des bases de données. Son conseil : commencez simple (montez en charge verticalement), puis ajoutez des réplicas en lecture, et ne passez au sharding que si vous n'avez VRAIMENT pas le choix. Et si vous y allez, ne le faites pas à la main. Utilisez des outils comme Vitess pour MySQL ou Citusdata pour PostgreSQL.

Le message de ces deux conférences est le même : la haute performance n'est pas magique. C'est une discipline d'ingénierie qui demande de comprendre toute la pile, du réseau à la base de données.

Si le premier jour était consacré à la machine, le second était pour l'humain derrière le clavier. Comment nous rendre plus productifs, plus sereins, et rendre notre travail plus agréable.

Nicolas Grekas, de la core team de Symfony, a résumé la philosophie de Symfony en une phrase : "être agressif dans la simplification pour les débutants". Il en a profité pour tordre le cou à une rumeur : non, le YAML n'est pas déprécié.

Mais l'annonce la plus marquante est sans doute c'est l'arrivée de schémas JSON pour la configuration YAML de Symfony. Concrètement, ça veut dire que notre IDE peut enfin nous offrir l'autocomplétion et la validation en temps réel sur nos fichiers services.yaml. C'est le genre de détail qui ne fait pas les gros titres, mais qui élimine une source constante de petites erreurs et de frustration.

Un nouveau format de configuration basé sur les tableaux et les array shapes a aussi été annoncé. Cette fonctionnalité, dont le crédit de l’idée revient à Nicolas Grekas, Kevin Dunglas et Ryan Weaver, est développée par Alexandre Daubois et nécessite une collaboration étroite avec PHPStan et JetBrains pour améliorer significativement le support des array shapes dans l’intégralité de l’écosystème PHP. On peut désormais ajouter des commentaires dans les commentaires pour ajouter des informations à nos array shapes !

Alexandre Daubois a présenté PIE (PHP Installer for Extension), le successeur tant attendu de PECL. PECL, c'est un peu l'ancêtre qu'on garde par habitude mais qui n'est plus adapté. PIE, c'est l'expérience Composer pour les extensions PHP : une commande simple (pie install une/extension) qui s'occupe de tout. Ca a été annoncé pendant la conférence : il s’agissait du dernier jour pour voter sur la RFC indiquant officiellement que PIE est le remplacement officiel de PECL. Et effectivement, le lendemain, cela s’est confirmé : la RFC a été approuvée et c'est maintenant officiel : l'avenir, c'est PIE.

Hubert Lenoir a ensuite fait une présentation très pragmatique sur les feature flags, en recommandant l'outil open-source Unleash et en mentionnant sa propre pull request pour mieux intégrer ce concept dans Symfony. En effet, il propose l’intégration d’un nouveau composant FeatureFlags au sein du framework. Cette PR étant en review depuis un moment, nous espérons la voir arriver sous peu !

Fabien Potencier, le créateur de Symfony , a partagé sa vision sur l'impact des LLM. Son idée la plus intéressante? Créer un fichier llms.txt à la racine de nos bibliothèques. Ce fichier contiendrait une version de la documentation spécialement formatée pour être ingérée par les modèles d'IA.

C'est une idée brillante. Au lieu de laisser passivement les IA deviner comment fonctionne notre code, on leur donne un mode d'emploi. C'est une nouvelle façon de penser la documentation : elle n'est plus seulement pour les humains, mais aussi pour les machines qui nous assistent.

Fabien indique aussi qu’une bonne pratique à mettre en place est la disponibilité des documentations au format Markdown plutôt qu’HTML : les LLMs sont excellents pour comprendre le Markdown, et le coût en token chute drastiquement dans ce format.

Finalement, il nous invite à réfléchir de plus en plus à ce qu’il nomme l’AX : l’Agent Experience. Les agents faisant de plus en plus parti de notre vie quotidienne de développeurs, il ne faut pas les négliger et il est temps de les prendre en compte pleinement lors de nos développements.

Après tout ça, la conférence de Laura Durieux sur l'histoire des femmes dans la tech était une vraie bouffée d'air frais. Un rappel nécessaire que derrière le code, il y a des gens, une histoire, et une culture à construire.

Nous repartons de cette conférence avec quelques certitudes.

Alors, concrètement, qu'est-ce qu'on fait ?

Le message de cette conférence est clair : PHP n'est pas en train de rattraper son retard. Il est en train de définir son propre avenir, un avenir pragmatique, performant et centré sur le développeur. Et c'est sacrément enthousiasmant.