AFUP Day Paris 2026

PHP continue de vivre avec son temps

Le 22 mai 2026, nous étions à l’AFUP Day Paris, à l’ESGI. Dix conférences en une journée, un programme qui brassait large : FrankenPHP, Symfony AI, qualité logicielle, passkeys, task runners, APIs, tests, exceptions, gotchas PHP. Dense, parfois inégal, mais avec de vraies bonnes surprises.

Ce qu’on retient de cette édition chez Globalis, c’est que PHP bouge. Pas de révolution, pas de grand virage marketing. Plutôt un écosystème qui digère les sujets du moment — IA, workers long-running, authentification sans mot de passe — à sa manière, c’est-à-dire progressivement et sans esbroufe.

Quatre fils rouges traversaient la journée. On les a regroupés ici plutôt que de dérouler les talks un par un.

Le runtime PHP se transforme

C’est Nicolas Grekas qui a ouvert la journée, et c’était probablement le talk le plus ambitieux du programme. Son sujet : les « sidekicks applicatifs » dans FrankenPHP, et ce que ça change pour les applications Symfony.

Pour comprendre, il faut revenir au modèle PHP classique. Une requête arrive, l’application démarre, traite la demande, répond, puis oublie tout. Grekas l’a dit lui-même : PHP est excellent justement parce qu’il oublie tout entre deux requêtes. Pas de mémoire persistante, pas de fuites, des applications robustes.

Sauf que ce modèle coince dès qu’une application doit écouter son environnement en continu. Détecter le master Redis via Sentinel, récupérer des feature flags, réagir à une rotation de secrets, invalider un cache sans redéployer. En PHP classique, ça veut dire du polling, des appels réseau à chaque requête, des composants externes.

Les sidekicks répondent à ça. Ce sont des workers PHP lancés en arrière-plan, qui ne traitent pas les requêtes HTTP. Leur boulot : écouter le monde extérieur et maintenir un état local que les workers HTTP viennent lire. L’image du whiteboard est parlante — les sidekicks écrivent l’état du monde, les workers HTTP le consultent. On passe de « je redemande à chaque requête » à « on me prévient quand ça change ».

Ce qui rend cette conf marquante, c’est qu’elle dépasse la question de la perf. FrankenPHP n’est pas juste « PHP-FPM mais plus rapide ». C’est un runtime qui ouvre de nouveaux patterns : workers long-running, supervision intégrée, infrastructure simplifiée. On commence à voir ce que pourrait être le prochain socle d’exécution pour PHP, et franchement, ça donne envie de mettre les mains dedans.

Dans un registre très différent mais complémentaire, le format court sur Castor — le task runner de JoliCode — rappelait que la modernisation de PHP passe aussi par les petits outils du quotidien. Castor remplace make avec du PHP natif, et derrière sa simplicité apparente, il y a des choix intéressants : les exemples servent à la fois de documentation et de tests automatisés, la doc reste en sync avec le code, les releases sont packagées en phars et binaires. Ce n’est pas le genre de talk dont on parle à la machine à café, mais ce sont ces outils-là qu’on utilise dix fois par jour.

Construire des applications qui tiennent la route

Plusieurs conférences de la journée tournaient autour d’une même question : comment rendre nos applications plus solides, plus testables, plus prévisibles ? C’est peut-être le sujet le moins sexy sur le papier, mais c’est celui qui a produit les échanges les plus concrets.

Le retour d’expérience de Weglot (« De la rentabilité à la durabilité ») racontait un scénario que beaucoup de startups connaissent. Au début, on construit vite. On livre, on itère, on cherche son marché. Et puis un jour, la base de code devient un frein. Il faut consolider. Chez Weglot, la démarche qualité s’est mise en place progressivement : linters, PHP CS Fixer, Twig CS Fixer, PHPStan, PHPUnit, Paratest. Pas tout d’un coup. Le curseur a monté petit à petit, avec des règles renforcées au fil du temps. Le chiffre qui a retenu notre attention : la baisse du taux de hotfix, corrélée avec la montée en couverture des outils qualité. Pas un discours, un graphe. On a rarement vu une équipe regretter d’avoir mis PHPStan en place six mois plus tôt.

La conf sur les tests sans mocks (« Comment tester une API externe en ayant 0 Mocks ? ») complétait bien ce tableau. Le problème est connu : on dépend d’APIs tierces — paiement, CRM, emailing, auth —, on mock ces services, et au bout d’un moment les mocks divergent de la réalité. Le contrat externe évolue, le mock reste figé, et on se retrouve avec des tests verts et une intégration cassée en prod. L’approche présentée forçait à réfléchir à la frontière entre tests unitaires, tests d’intégration et contrats externes. Plus de travail en amont, mais on détecte les ruptures avant la prod, pas après.

Et puis il y a eu « L’exception qui confirme la règle », en fin de journée. « Everything fails all the time. » Le propos : les exceptions ne sont pas un mal nécessaire qu’on attrape et qu’on enterre. Ce sont des signaux. Une exception bien pensée qualifie le problème, le logge correctement, le transforme en réponse adaptée, remonte une info utile aux équipes techniques. Une application mature n’est pas une application qui n’échoue jamais. C’est une application dont les erreurs sont lisibles.

Le talk « PHP gotchas » s’inscrivait aussi dans cette lignée, avec un format plus léger. QCM en salle, participation du public, on teste ses intuitions sur des comportements surprenants de PHP. Le genre de quiz où même les gens expérimentés se font piéger, et c’est un peu le but. Le format fonctionnait bien : ça détendait l’atmosphère tout en rappelant que connaître un langage, ce n’est pas seulement maîtriser sa syntaxe, c’est aussi connaître les endroits où il peut vous mordre. Et c’est là que PHPStan fait office de filet de sécurité.

L’IA débarque en PHP (pour de vrai cette fois)

Deux talks abordaient l’IA. L’un nous a laissés un peu sur notre faim. L’autre était probablement la meilleure surprise de la journée.

« L’IA comme binôme de code » était annoncé comme grand public, et ça se sentait. GitHub Copilot dans les IDE, usage en ligne de commande, Claude, fichiers de contexte comme AGENTS.md. Pour ceux qui utilisent déjà ces outils au quotidien, honnêtement, il n’y avait pas grand-chose de neuf. Le talk avait le mérite de poser une base commune — tout le monde dans la salle n’en est pas au même stade — et d’insister sur un point qu’on ne répète jamais assez : l’IA accélère, elle ne remplace pas le jugement. Mais on serait repartis frustrés si la journée s’était arrêtée là côté IA.

Heureusement, le talk sur Symfony AI et les embeddings a relevé le niveau. Ici, l’IA n’était plus un assistant de développement. C’était une brique fonctionnelle intégrée dans l’application elle-même. Recherche sémantique, vectorisation de contenu, similarité de pages, rapprochement de textes, choix de modèles, stockage de vecteurs, mise à l’échelle. L’outillage défilait : Redis, ClickHouse, Postgres, Ollama, multi-GPU, RabbitMQ.

Ce qui nous a plu : l’approche est agnostique. Pas de verrouillage sur un fournisseur ou un modèle. Symfony AI est une couche d’abstraction, pas une cage dorée. Et c’est bienvenu, parce que beaucoup d’équipes ont déjà bricolé des fonctionnalités similaires en interne. Symfony AI vient structurer ça et le rendre maintenable.

Le contraste entre les deux talks était révélateur. L’IA comme assistant de dev, en 2026, c’est acquis. Le vrai sujet, c’est l’IA comme fonctionnalité produit : embeddings en prod, recherche sémantique, classification. Et là, l’écosystème PHP commence à proposer des outils sérieux.

Remettre en question les réflexes

Deux autres conférences de la journée avaient un point commun : elles invitaient à questionner des choix qu’on fait par habitude.

« Repenser les APIs » tapait sur un réflexe répandu : tout passer en REST, même quand ça ne colle pas. L’exemple qui a fait mouche : l’envoi d’email. POST /email/send est plus explicite que POST /email. Dans le second cas, l’intention reste floue — on crée une ressource ? on prépare un brouillon ? on déclenche l’envoi ? La conf comparait webhooks, formulaires, REST, RPC, JWT, endpoints dual-purpose. Pas pour dire que REST est mauvais, mais pour rappeler qu’une API doit coller au métier, pas au standard le plus populaire. On se force souvent à faire du REST par habitude. Parfois ça colle. Parfois on tord le besoin pour rentrer dans le moule, et cette conf donnait la permission de s’en affranchir.

Côté authentification, « Mots de passe, SSO et Passkeys » posait une question du même ordre. Les mots de passe, tout le monde sait que c’est fragile — phishing, réutilisation, fuites, règles de complexité contre-productives — mais on continue de les utiliser par défaut. La conf montrait que les passkeys et WebAuthn ne sont plus expérimentaux. Les navigateurs supportent bien le standard, les appareils aussi, et l’écosystème PHP dispose de packages pour l’intégration. Ce qui a changé, c’est la maturité de l’ensemble. Reste le vrai travail : le parcours UX. Le standard est prêt, les outils sont là, mais si le flow d’inscription perd les utilisateurs, on n’aura rien gagné.

Ce qu’on retient

PHP ne fait pas de bruit, mais il avance. C’est le sentiment avec lequel on est repartis.

FrankenPHP esquisse un nouveau runtime, et c’est le sujet qu’on a le plus envie de suivre dans les mois qui viennent. Symfony AI rend les embeddings accessibles sans bricolage. Les retours d’expérience sur la qualité prouvent leur valeur en chiffres, pas en discours. Les passkeys arrivent pour de bon.

On n’a pas eu l’impression d’un écosystème en crise d’identité. Plutôt d’une communauté qui sait ce qu’elle fait bien, qui ne cherche pas à impressionner, et qui avance à son rythme. C’est peut-être moins excitant qu’un keynote avec des promesses grandioses, mais c’est nettement plus crédible.

Mehdi Zaïdi, Akram Kies et Suleyman Kaplan.