Forum PHP 2026
8 - 9 Oct 2026 at Hôtel New York - The Art of Marvel

Le Model Context Protocol (MCP) est devenu en un an le standard pour donner des outils aux agents IA. Au Forum PHP 2025, Edouard Courty nous a montré comment l'intégrer dans une application Symfony via son bundle. Depuis, beaucoup a changé : ce bundle est officiellement déprécié, Symfony a publié son propre symfony/mcp-bundle, et un SDK PHP officiel mcp/sdk est en cours de stabilisation, fruit d'une collaboration entre la PHP Foundation et le projet Symfony. Dans cet écosystème en mouvement, maîtriser le protocole lui-même devient un avantage concret : pour choisir le bon outil, pour intégrer MCP à un projet existant qui n'est pas en Symfony, ou simplement pour ne pas dépendre d'une abstraction qui peut changer demain. Durant ce talk, nous construirons un serveur MCP en PHP pur, sans framework, en environ 300 lignes de code. Nous décortiquerons le protocole couche par couche : JSON-RPC 2.0, transport Streamable HTTP, cycle de vie (initialize, discovery, operation), et les trois primitives fondamentales (tools, resources, prompts). Pour rendre la démonstration concrète, le serveur sera branché sur une instance WordPress existante. Nous verrons l'IA explorer les articles publiés, terminer un brouillon en suivant le style de l'auteur, et réécrire un post dans le style d'un personnage de fiction, en direct. Tout cela sans ajouter une seule dépendance lourde au projet WordPress. À la sortie, vous saurez ce que les SDK et bundles font pour vous, ce que vous pouvez faire vous-mêmes, et comment ajouter une couche MCP à n'importe quelle application PHP existante, quel que soit son framework (ou son absence de framework).

Claude Code, Copilot, Cursor… les coding agents font partie de notre quotidien. Pourtant, sur le terrain, les retours sont contrastés : certaines équipes décuplent leur productivité, d'autres passent leur temps à corriger l'agent. Pourquoi ? Après deux ans à intégrer des agents dans nos projets clients chez Marmelab, nous avons identifié un facteur déterminant : l'Agent Experience (AX). À l'image de la Developer Experience, l'AX désigne la capacité d'un codebase à permettre à un agent de travailler de manière autonome et efficace. Dans ce talk, je présenterai un framework structuré autour de 10 dimensions concrètes et illustré par des exemples réels. Vous découvrirez pourquoi certaines pratiques classiques du Software Craftsmanship deviennent critiques avec les agents, pourquoi d'autres doivent être repensées, et comment investir dans l'AX peut transformer votre rapport au code. Spoiler : la bonne nouvelle, c'est qu'un codebase optimisé pour les agents est aussi plus agréable pour les humains.

Une architecture ne naît jamais parfaite. Elle évolue à mesure que les contraintes apparaissent. Pourquoi passer à l'asynchrone ? Pourquoi introduire une abstraction des fournisseurs ? Comment structurer un RAG multi-corpus ? Quand intégrer un MCP ? Comment gérer les limites des modèles sans réécrire toute l'application ? À travers deux années d'évolution d'un assistant IA métier développé en PHP/Symfony, cette conférence revient sur les décisions qui ont façonné l'architecture actuelle, en expliquant les motivations, les compromis et les enseignements tirés de chaque étape.

Vous avez forcément déjà demandé à un assistant IA d'aller faire quelque chose à votre place : réserver, commander, mettre à jour une fiche. Quand ça marche, plus personne ne clique sur une interface, et c'est bluffant. Mais une fois l'effet passé, une question bien plus intéressante demeure : qu'est-ce qui, dans nos applications, permet à un agent d'agir ? Après un rapide détour par le Model Context Protocol (MCP), soit la façon dont un agent découvre et appelle les opérations d'une application, nous étudierons le vrai besoin : exposer son métier sans en écrire une seconde description « pour l'IA ». Nous verrons pourquoi API Platform part déjà avec une longueur d'avance, en réutilisant ce qu'il décrit depuis toujours : vos ressources, leur validation, leur sérialisation et leur sécurité. De la ressource d'API aux outils MCP, il n'y a qu'un pas. En réutilisant la couche CQRS d'API Platform, nous verrons comment transformer nos ressources existantes en outils qu'un agent peut appeler, sans jamais dupliquer la description de notre domaine. Et puisque l'interface, elle, semble se dissoudre, nous terminerons sur la question qui nous attend toutes et tous : à quoi ressembleront nos logiciels quand l'API sera la porte d'entrée, et l'agent, son premier client ?

AI-assisted development tools promise unprecedented speed. But without proper foundations, velocity becomes recklessness: technical debt accumulates faster, architectural boundaries erode quicker, and defects ship sooner. The opposite failure mode is just as real: teams that insist on control without speed cannot meet modern market demands. This session distills the essential lessons of a full-day workshop into 40 minutes: how to establish automated safety nets that let teams move faster precisely because they can trust their quality controls. Using PHP and industry-standard tooling as the running example, we trace how traditional quality practices such as automated testing, static analysis, and architectural boundary enforcement evolve in AI-assisted workflows, culminating in a test-driven pattern where humans write specifications as tests and AI agents generate implementations. You will leave with clear criteria for evaluating your own quality infrastructure and a prioritized list of practices to adopt first. The central insight: the practices that make AI collaboration safe are the same practices that make human development fast. That convergence is the path to sustainable speed.

Il existe ce que l’on appelle la permission fatigue : à force de valider des demandes, on finit par accepter sans vraiment regarder ce que notre coding agent s’apprête à exécuter. Pour contourner cela, les outils proposent aujourd’hui des modes YOLO (trust-all-tools, bypass permissions…), donnant aux agents une autonomie totale. Mais cette autonomie a un coût : ces modes permettent aux agents d’effectuer n’importe quelle opération sur la machine du développeur·euse. Les retours de devs ayant perdu du travail ou vu leur environnement local altéré se multiplient . La question devient : comment offrir un maximum d’autonomie aux agents sans mettre en danger la machine hôte ? En combinant VMs et conteneurs, Docker Sandboxes permet d’exécuter des agents IA dans des environnements réellement isolés. Les agents peuvent installer des outils, modifier leur environnement et lancer des workloads complexes en s’appuyant sur un engine Docker isolé, sans accès direct au host. Le trafic réseau sortant est contrôlé via les règles d’entreprise, et les agents n’ont accès ni aux clés d’API ni aux credentials, offrant une solution pour exécuter des coding agents en mode YOLO, mais en toute sécurité.

Left without guardrails, AI assisted software development can quickly spiral out of control: buggy, hard to maintain, inconsistent and slow code is the result. Only when you introduce quality assurance tools on all levels will you get reliable results. In this talk I show how you can use static analysis, testing tools and production runtime data to ship code with AI assistance. Benjamin EBERLEI

n le sait tous : une bonne code review, ce n'est pas traquer une indentation ou un nom de variable. C'est challenger l'intention, le design, les invariants métier, ce qui n'apparaît pas dans le diff. Sauf qu'en pratique, on review surtout la surface parce qu'on est fatigué, pressé, ou que la PR fait 600 lignes. Depuis quelques mois, je me fais assister par des agents IA pour faire une première passe de review sur mes projets. L'agent ne décide pas, il défriche : il signale, il questionne, il prépare le terrain. Et il s'est passé un truc inattendu : en m'appuyant sur cette première passe pour la surface, j'ai été obligé de redéfinir ce que je fais, moi, en tant que reviewer humain. Spoiler : c'est ce que j'aurais dû faire depuis le début. Je m'en sers aussi autrement : quand je tombe sur une classe ou une méthode dont le but n'est pas évident, je demande à l'agent de m'expliquer ce qu'il en comprend. Si sa lecture diverge de la mienne, ou si elle a du mal à émerger, c'est qu'il manque un commentaire, un nom plus clair, ou que le design est à revoir. L'agent devient un révélateur de zones floues. Autre découverte : bien paramétrés, ces agents peuvent rendre les PRs et les commentaires de review nettement plus lisibles : structure claire, contexte explicite, intention résumée. Un confort pour tout le monde, et un vrai levier d'inclusion pour les profils neuro-atypiques (dont je fais partie). Mais ça ne tombe pas du ciel : c'est à nous, humains, de paramétrer nos agents pour qu'ils délivrent ce niveau de clarté. Dans ce talk : les bonnes pratiques de review qu'on connaît et qu'on néglige, ce que l'assistance d'un agent apporte vraiment (et ses angles morts), comment s'en servir comme révélateur de zones floues, comment se positionner avec la décision finale, et comment configurer ses agents pour livrer des PRs vraiment lisibles. Échecs réels inclus. Vous repartez avec une vision claire de votre rôle de reviewer quand un agent vous a assisté, et avec l'envie de mieux reviewer, agent ou pas.

Le Cyber Resilience Act arrive, et avec lui une avalanche de nouvelles notions : fabricant, steward, gestion des vulnérabilités, obligations de sécurité... Faut-il arrêter de publier sur GitHub ? Les mainteneurs open source vont-ils finir en prison ? Une agence PHP peut-elle devenir « fabricant » sans le savoir ? Et pourquoi des devs se retrouvent-ils soudain à lire des règlements européens ? À travers des exemples concrets issus du monde PHP et de l'open source, cette conférence propose un décryptage accessible, pragmatique et sans jargon juridique du CRA. L'objectif : comprendre qui est réellement concerné, ce qui change vraiment, et comment se préparer sans céder à la panique. Une session pensée pour celles et ceux qui, à la base, n'avaient rien demandé !

L'IA a déboulé dans nos équipes sans mode d'emploi. On découvre les skills, les hooks, les claude.md, on bidouille nos configs — et très vite, chacun avance dans son coin : on ne sait plus ce qui existe, ni où ranger quoi. Comment passer de cette effervescence à quelque chose de partagé, réutilisable, sans étouffer l'initiative individuelle ? Je vous partage notre démarche, encore en chantier. Tout est parti d'un atelier où chacun a présenté ses tips. Ensuite, on s'est posé les vraies questions : Ce qu'on partage, ce qu'on garde : trier ensemble avec des niveaux clairs (🌍 global, 🤝 équipe, 💻 perso) — sachant qu'un tip perso peut tout à fait finir partagé. Le catalogue partagé : un repo commun pour ranger nos agents, nos skills, nos hooks du quotidien. L'orga humaine : on s'organise en squad autour d'un même besoin, par exemple un skill git. On pose la première pierre, pas la maison. Je vous partage nos arbitrages, nos doutes, nos petits réflexes d'atelier (« je le mets en global, ok ? ») et les premiers pièges qu'on repère : de quoi lancer la même dynamique chez vous.

Cette conférence part d'une question qu'on se pose trop rarement avant d'ajouter de l'IA (générative) dans un projet : est-ce qu'on résout un vrai problème ou est-ce qu'on prend l'option la plus à la mode parce qu'elle fait moderne ? Pensée pour des devs qui appellent un LLM presque par réflexe, elle propose de repartir du besoin plutôt que de l'outil, le tout dans une perspective de résilence et de frugalité. Les chiffres, sans dramatiser : de vrais ordres de grandeur sur l'empreinte de l'IA (énergie, eau, métaux), avec des comparaisons concrètes pour situer ce qui pèse vraiment. Un jeu de démystification : distinguer ce qui compte de ce qui ne change rien (fermer le robinet en se brossant les dents, contre prendre l'avion pour un week-end). L'idée centrale, l'IA n'est pas que le génératif : tout un spectre, du code déterministe et des expressions régulières (qui ne sont pas de l'IA), à l'IA symbolique, au machine learning classique, aux petits modèles, puis aux gros LLM. L'option la plus sobre qui fait le travail se situe presque toujours en dessous du LLM. Un cadre pour décider, inspiré de l'AFNOR Spec sur l'IA frugale et du Frugal AI Hub de Cambridge : l'IA a-t-elle sa place dans ce projet, et à quelle intensité ? Un cas d'étude en direct, trier une boîte mail : des règles déterministes d'abord, un petit modèle seulement pour le reste difficile, et compar:IA pour le choisir. Résultat, environ 100 fois moins d'émissions que la version tout-LLM, avec une meilleure précision. Quand le génératif est le bon choix, le faire plus léger : dimensionner le modèle au besoin, structurer les entrées pour ne pas gaspiller de tokens, le green prompting (32 à 48 % d'énergie en moins), les modèles locaux, l'hébergement bas carbone. Au passage, ce qui est plus frugal coûte aussi moins cher, ce qui compte quand les forfaits laissent place au paiement à l'usage. Chacun·e repart avec une checklist de décision pour son prochain projet, et une réponse claire à la question de départ : est-ce que j'ai vraiment besoin d'IA ici ?

TBA

Depuis des années, le développement mobile impose souvent aux devs PHP de sortir complètement de leur écosystème : Flutter, React Native, Kotlin, Swift… Et si PHP pouvait désormais trouver sa place jusque dans nos smartphones ? Avec NativePHP Mobile, l’écosystème Laravel s’ouvre au développement d’applications mobiles iOS et Android en capitalisant sur les compétences, outils et habitudes déjà maîtrisés par de nombreux devs PHP. Dans cette conférence, nous découvrirons ce qu’est NativePHP Mobile, comment il fonctionne, quels problèmes il cherche à résoudre, mais aussi ses limites actuelles. Nous verrons à quels types de projets cette approche convient réellement, comment elle se compare aux solutions mobiles plus traditionnelles, et pourquoi elle peut représenter une opportunité intéressante pour les équipes PHP souhaitant produire rapidement des applications métier mobiles. Au travers de démonstrations concrètes et d’un retour pragmatique, nous explorerons les possibilités offertes aujourd’hui par NativePHP Mobile : accès natif, stockage local, architecture applicative, partage de logique métier et expérience développeur.

Passer au Worker Mode avec FrankenPHP ou Swoole propulse les performances de nos applications Symfony. Mais attention, dans ce nouveau paradigme, PHP n'est plus 'stateless' ! Un simple état muté dans un service partagé, et c'est la fuite de données assurée pour vos utilisateurs. Découvrez à travers ce retour d'expérience l'anatomie des 'State Leaks', comment fonctionne l'analyse statique pour les détecter, et comment j'ai fini par créer Igor-PHP pour auditer vos projects.

À quoi ressemble le PHP qu'on écrit vraiment en 2026 ? Pour répondre, j'ai téléchargé l'intégralité de l'écosystème open source (236 Go de dépôts Git) et je l'ai passé à la moulinette de mes outils d'analyse. Les résultats sont parfois rassurants, parfois inquiétants. Adoption des features récentes, longueur moyenne des méthodes, dette typique, écarts entre frameworks, traces des vieux patterns qui ne meurent pas : autant de signaux pour comprendre où va, et où traîne, l'écosystème. Je partagerai la méthode (collecte, normalisation, métriques retenues), les chiffres qui surprennent, et les limites de l'exercice (biais de l'open source, distorsion par les gros projets, paquets fantômes). Vous repartirez avec une vision chiffrée du PHP d'aujourd'hui, des repères pour situer votre propre code, et probablement quelques convictions à réviser.

10 minutes pour faire tourner l'analyse statique sur 300 000 lignes de code. Vous connaissez le rituel : on lance, on va prendre un café, on revient, c'est encore en cours. Et en local, soyons honnêtes, on ne la lance plus du tout. Maintenant, imaginez la même analyse en 15 secondes. C'est ce qu'on a obtenu en passant à Mago, et ce n'est pas un prototype : un seul binaire, écrit en Rust, qui formate, lint, type et fait respecter votre architecture. La vague Rust qui a déjà transformé les écosystèmes JS et Python déferle enfin sur PHP, et elle est prête pour la production ! Cette vitesse n'est pas qu'un confort : quand un outil devient instantané, on l'utilise vraiment, à chaque sauvegarde, et le rapport à la qualité change complètement. J'en profiterai pour parler d'un effet de bord fascinant de ces projets nés à l'ère des agents IA : la façon dont une communauté construit aujourd'hui son outillage, à un rythme qu'on n'avait jamais vu. Venez voir à quoi ressemble une chaîne qualité PHP en 2026. Vous risquez de vouloir mettre à jour votre stack en rentrant.

La rétrocompatibilité, ou Backwards Compatibility (BC) en anglais, est le principe selon lequel les pratiques et les conceptions élaborées dans un contexte antérieur restent valables dans le contexte actuel. Rompre la rétrocompatibilité (BC break) correspond à faire des changements qui altèrent la conception sous-jacente, entraînant souvent des perturbations qui cascadent pour les utilisateurs. Les avantages de maintenir la compatibilité sont évidentes, alors quelles sont les raisons que divers secteurs la rompent régulièrement ? Dans cette conférence, nous examinerons des exemples issus de divers domaines afin de montrer pourquoi la rupture de la rétrocompatibilité est généralement le prix nécessaire et inévitable du progrès.

Laravel a une solution prête pour presque tout, et ça marche tout de suite : c'est la magie. Sans même vous en rendre compte, le framework vous tient la main, et vous apprend les bonnes pratiques en chemin. Puis vient le jour où le défaut ne suffit plus, où votre métier sort du cadre. Et là, Laravel ne vous enferme pas : derrière chaque raccourci, une porte de sortie. C'est ce qui rend l'approche aussi confortable pour un·e junior·e qui débute que pour un·e senior·e qui a besoin de tout contrôler. Deux temps, des cas concrets : ce que Laravel fait pour vous, et comment reprendre le contrôle quand il le faut.

I have learnt more from the failures of PHPUnit than its successes. Over the last 25 years, I have witnessed the evolution of testing philosophy from a marginal practice to the bedrock of modern software development. But has the PHP community learned the right lessons? In this presentation, I will share what I have learned from PHPUnit, how my approach has evolved (sometimes unexpectedly), and my thoughts on the future of software development in the age of AI.

Il y a huit ans naissait Mercure : un protocole et un serveur open source écrits en Go, conçus pour apporter la puissance du temps réel à n'importe quelle architecture web, et tout particulièrement aux écosystèmes comme PHP qui ne gèrent pas nativement les connexions persistantes. Aujourd'hui, Mercure est devenu un standard incontournable, propulsant des centaines de projets en production, de la startup au grand compte. Parfaitement intégré à Symfony (via Symfony UX) ainsi qu'à API Platform, et embarqué par défaut dans FrankenPHP, il simplifie radicalement l'expérience de développement. Que ce soit pour concevoir des éditeurs collaboratifs (à la Google Docs), synchroniser des tableaux de bord instantanés, notifier vos utilisateurs lorsqu’une tâche en arrière-plan se termine ou, plus récemment, streamer les tokens de vos LLM et suivre l'avancement d'agents IA, Mercure s'impose comme la solution idéale. Rejoignez-moi lors de cette conférence pour découvrir toutes les nombreuses nouveautés de Mercure 1.0, qui va sortir prochainement !

Biscuit, c'est un format de token d'autorisation pensé pour la délégation et la vérification offline. Atténuation sans clé privée, politiques exprimées en Datalog, cryptographie moderne. Une alternative sérieuse à JWT quand l'authz devient complexe. En 2021, je le découvre et je veux l'utiliser en PHP. Il existe déjà des implémentations en Rust, Go, Java, Haskell, WebAssembly, et même Python via PyO3. Mais rien côté PHP. Réécrire la spec à la main aurait pris des mois, alors que biscuit-rust est l'implémentation de référence. Je cherche l'équivalent du pont Python côté PHP et je tombe sur ext-php-rs. Le projet me plaît, je commence à contribuer, je finis comainteneur. J'en parle au Forum PHP 2022, persuadé que la suite ira vite. Octobre 2025. biscuit-php sort enfin. Cette conférence parle de Biscuit, de ce qu'il apporte à l'authz PHP, et du chemin qu'il a fallu pour l'y amener.

PHP fait tourner une part énorme du web : Symfony, Laravel, WordPress, Magento… et les dizaines de milliers de paquets que vous récupérez de Packagist sans même y penser. Pourtant, la sécurité de cet écosystème n’a jamais vraiment été le travail de personne. Et depuis que les LLMs savent dénicher des failles en série, l’enjeu change d’échelle : le même outil qui aide les défenseurs arme aussi les attaquants. C’est pour répondre à cette problématique que la PHP Foundation a créé une équipe dédiée : l’Ecosystem Security Team. Notre mission tient en trois mots : identifier, prioriser, informer. Tout ça avant que ça ne deviennent votre problème en production. Direction les coulisses : les outils qu’on utilise à la fondation, comment sont choisit les projets sur lesquels intervenir, ce qu’on y trouve vraiment, ce qu’on corrige, et là où l’humain reste irremplaçable derrière la machine… Pour l’instant.

Une semaine ne se passe pas sans qu’une nouvelle fuite de données massive ne fasse la une des médias. Face à des attaquants de plus en plus ingénieux et des infrastructures cloud mouvantes, une certitude s'impose : la question n'est plus de savoir si votre base de données sera compromise, mais quand. Et si la solution consistait tout simplement à ne plus faire confiance à votre propre SGBD ? C’est tout le paradigme du Client-Side Encryption (CSE). En chiffrant les données sensibles avant leur transfert, votre base de données ne stocke plus que des suites d'octets parfaitement inutilisables pour un intrus. Même avec un accès administrateur complet au SGBD ou une faille zero-day, vos données restent à l'abri. Derrière la promesse théorique, la réalité du terrain soulève de vrais défis d'implémentation. Durant ce talk, nous décortiquerons concrètement comment sauter le pas : Focus rapide sur les solutions intégrées des SGBD modernes (comme le Client-Side Field Level Encryption). Le dilemme de la recherche : Comment indexer, requêter ou trier des données dont le serveur ne comprend pas la substance ? Comment l'implémenter avec Postgres & Doctrine Que vous soyez dev ou architecte, vous repartirez de cette session avec les clés pour mettre en place une stratégie Zero Trust.

N'avez-vous jamais eu de difficulté à tester vos règles de sécurité dans Symfony ? Saviez-vous que la classe AbstractVoter cache certaines limites ? Et si la stratégie de décision "Affirmative" (définie par défaut) n'était pas toujours la plus performante ? Lors de cette présentation, nous plongerons dans les rouages méconnus du composant Security de Symfony. À travers des cas d'usage concrets nous découvrirons comment hiérarchiser vos règles de sécurité de manière élégante et performante. Limites de l'AbstractVoter, Stratégies d'accès et Performance, Débogage et Bonnes Pratiques, vous aurez toutes les clés pour transformer vos voteurs en un système d'autorisation robuste, découplé et optimisé !

En 2014, nous développons une billetterie en ligne sous Symfony 2. Le besoin paraît simple : connecter des flux de billetterie, afficher des événements, et vendre des billets. Quelques années plus tard, le projet équipe plus de 150 sites, gère un gros volume de transactions, traverse plusieurs versions majeures de Symfony, plusieurs architectures, plusieurs outils, et l'équipe grandit avec lui. Nous avons alors voulu bien faire : microservices, DDD, couches spécialisées, interfaces, abstractions. Mais à force de chercher "la bonne architecture", nous avons parfois oublié les fondations : qualité automatisée, observabilité, déploiements fiables, environnement reproductible, ... et surtout simplicité. Ce qui ressemblait d’abord à un problème de performance a révélé une dette plus large : technique, organisationnelle, et cognitive. Dans ce retour d’expérience à deux voix, nous raconterons comment nous avons repris le contrôle sans tout réécrire : audit de performance, cache HTTP, monitoring, monorepo, trunk-based development, feature flags, déploiement automatisé, simplification progressive de l’architecture. Mais cette conférence parle aussi de ce qu’on aborde rarement dans les talks techniques : l'expérience intime de la dette. Les ressorts psychologiques qu’il faut reconnaître pour l'affronter, demander de l’aide, et retrouver assez de lucidité pour agir. Une conférence technique, méthodologique et humaine sur un projet PHP devenu trop complexe, et sur ce qu’il faut parfois traverser pour revenir à la simplicité.

FrankenPHP est arrivé en prod chez beaucoup d'entre nous. Mode worker, performances inégalées, déploiement plus simple. Et accessoirement : HTTP/3 sur QUIC activé par défaut, 0-RTT disponible, Early Hints supportés, certificats automatiques. La plupart de ces fonctionnalités, on ne les a pas demandées; et la plupart, on ne sait pas ce qu'elles font vraiment... Je te propose de plonger dans ce que fait ton serveur PHP quand un client se connecte. On regarde, dans l'ordre où ça se passe : la résolution DNS, le handshake TCP (avec ou sans Fast Open), la négociation TLS 1.3, arbitrage entre HTTP/1.1, HTTP/2 et HTTP/3, l'éventuel 0-RTT. À chaque étape, deux questions : qu'est-ce que ça t'apporte mesurablement, et qu'est-ce que ça peut casser silencieusement ? Captures Wireshark, mesures sur Symfony Demo, et trois pièges concrets : le 0-RTT et les replay attacks sur tes routes non-idempotentes, HTTP/3 derrière un load balancer qui ne le supporte pas, l'OCSP stapling oublié qui ajoute 300 ms à chaque cold connection. Si tu te dis qu'on n'optimise pas ce qu'on ne mesure pas, ce talk est pour toi. Mon objectif : que tu sortes de la salle en sachant ce que FrankenPHP fait pour toi (et c'est valable aussi pour Nginx ou Apache), ce qu'il ne fait pas, et ce que tu dois encore configurer à la main pour ne pas avoir de surprise.

La plupart des applications Symfony bufferisent tout : résultats Doctrine, objets sérialisés, JSON, exports... Puis elles construisent une réponse complète avant de l'envoyer au client. Ça fonctionne. Jusqu'au jour où ça ne fonctionne plus : mémoire qui explose, time-to-first-byte qui grimpe, exports qui tombent en production. De plus, avec l'arrivée des LLM dans nos produits, cette approche montre encore plus ses limites. Quand un modèle met plusieurs secondes à générer sa réponse, attendre le return signifie afficher un spinner pendant tout ce temps. Le streaming n'est plus une optimisation back-end. C'est devenu le socle d'une expérience utilisateur moderne. Dans ce talk, nous allons démonter une idée profondément ancrée dans nos applications : celle qu'une réponse doit être entièrement construite avant d'être envoyée. Nous repenserons le flux de données d'une application Symfony de bout en bout : StreamedResponse, encodage JSON incrémental avec le composant JsonStreamer, sources de données itérables avec Doctrine, Server-Sent Events et EventStreamResponse pour le temps réel. Vous apprendrez à produire les données au fil de l'eau, alimenter des interfaces en direct, générer des exports de plusieurs millions de lignes et maintenir une consommation mémoire stable grâce aux outils déjà présents dans Symfony.

« L'expérience prouve que celui qui n'a jamais confiance en personne ne sera jamais déçu. » (Léonard de Vinci) Partant du postulat lucide que nous codons tous et toutes mal, ce talk explore les principes de la programmation défensive appliqués au PHP moderne. L'idée centrale ? Anticiper que tout ce qui peut mal tourner finira par exploser, et s'appuyer sur le compilateur plutôt que sur la vigilance humaine pour l'éviter. Fini le code silencieux qui masque les erreurs et coûte une fortune à débugger en production à 1h du matin : il est temps de refuser les états invalides par construction et d'échouer vite, fort, et au bon endroit (Fail fast, fail loud). À travers une approche très concrète (attention : il y aura beaucoup de code !), nous verrons comment utiliser votre meilleur allié - le langage lui-même - pour blinder vos applications : Le système de types comme contrat absolu : strict_types, Union/Intersection/DNF types, et l'usage radical du type never. Le verrouillage des états : Immutabilité (classes readonly), Value Objects, Enums, et encapsulation maîtrisée. La fiabilité par conception : Nullabilité stricte, collections typées hétérogènes, et gestion des exceptions qui ne laissent rien passer. Un talk avec quelques opinions tranchées pour apprendre à dire "non" poliment (mais fermement) aux appelants de vos fonctions, et faire de l'analyse statique votre filet de sécurité ultime.

Réunions, open space, notifications, pauses café, revue de code, incident de production à gérer en urgence, une librairie PHP critique à mettre à jour avant la MEP... Autant de situations considérées comme normales dans le quotidien des équipes tech. Pourtant, pour certaines personnes, elles représentent une charge physique, cognitive ou émotionnelle considérable. Le problème, c'est que ces difficultés ne se voient pas. Et lorsqu'une difficulté est invisible, elle est facilement minimisée. Pourtant, près de 80 % des handicaps sont invisibles, mais le monde du travail continue souvent à considérer que chacun vit les mêmes contraintes, avec les mêmes ressources et les mêmes capacités d'adaptation. À travers 10 situations concrètes du quotidien professionnel, découvrons ce que vivent les personnes concernées, et pourquoi ce qui paraît banal pour les un·e·s peut parfois représenter un véritable défi pour les autres.

« Tout est au vert, et pourtant nous n'avons jamais été aussi épuisé·e·s. » Depuis plus d'un an, notre code sort surtout d'agents IA. Les projets avancent, mais nos journées sont devenues une suite ininterrompue d'allers-retours à haute charge cognitive, sans les pauses que donnait le code, et sur fond de nouveautés qui tombent chaque semaine avant qu'on ait stabilisé les précédentes. Nous avons fini par faire un choix à contre-courant : ralentir pour tenir, et arrêter de courir après chaque nouveauté. Ce talk raconte ce qu'on a traversé et ce qu'on a mis en place, de la décision individuelle (dire la fatigue, protéger ses plages) à l'organisation collective (un workflow qui nous arrête volontairement aux bons moments). On partage des pistes concrètes, testées chez nous, pour vivre cette bascule sans y brûler l'équipe.

Trois ans après le boom des IA génératives dans le grand public, le photojournaliste suisse Niels Ackermann analyse l’impact réel de ces outils sur sa profession et sur notre rapport au “réel”. Est-ce que tout est perdu, ou ces évolutions sont-elles aussi l’occasion de réinventer son métier? Il présentera quelques résultats de ses recherches et expérimentations, et notamment Dalia, une échelle opensource permettant à n’importe qui de quantifier le rôle de l’IA dans son travail.