Programme

Bienvenue à l'AFUP Day 2026 Lyon

Si vous demandez aux devs PHP s'ils ont déjà créé ou utilisé des API renvoyant des données au format JSON, c'est un euphémisme de dire que la majorité répondra par l'affirmative.

Dans cet océan (voire univers !) d'API utilisant le format JSON pour communiquer, il peut parfois être difficile de garantir la robustesse des réponses que nous envoyons en tant que créateurs de ces API. C'est là que JSON Path entre en jeu.

Après 4 ans de développement, une spécification officielle décrivant un « langage de requête pour JSON » a été publiée en février 2024. Symfony vous permet d'utiliser ce langage grâce au nouveau composant JsonPath de la version 7.3, qui fournit toute une série d'outils pour booster vos tests d'intégration et vérifier avec précision les retours de vos API JSON. Symfony va encore plus loin en 7.4 pour vous permettre d'étendre cette nouvelle syntaxe, avec comme toujours, un DX examplaire.

Vous ne pourrez bientôt plus jamais casser votre API en production !

Lorsque j’intègre un nouveau projet ou une nouvelle équipe, les défis sont nombreux. Mais un problème persiste presque toujours : la gestion des branches.

Rapidement, les mêmes questions reviennent dès que le projet démarre :

• Faut-il partir de main, de release ou de develop ?
• Est-ce acceptable de supprimer ma branche après ma MR vers develop ?
• Que faire si plusieurs tickets ont besoin du code présent sur une autre branche ?
• Est-ce que tout le monde connaît le workflow choisi et en comprend le fonctionnement ?

Beaucoup de nouveaux devs se retrouvent perdus, sans savoir comment agir. Ce désordre impacte directement le projet : prise en charge compliquée des MR par le responsable technique, retards de livraison, bugs en production… voire perte pure et simple de commits.

Fort d’expériences variées dans des équipes aux profils et projets très différents, j’ai participé chez ACSEO à la mise en place d’une véritable culture Git pour harmoniser la gestion des branches. Ceci permet notamment que peu importe le projet, une nouvelle personne puisse facilement intégrer l'équipe, et ne découvre pas un workflow fondamentalement différent des autres projets de l'entreprise.

Dans cette conférence, je vous propose :

• D’identifier les problèmes courants et de mettre en lumière les situations désagréables causées par l’absence, ou l’imprécision, d’un workflow.
• De passer en revue les points qui font qu'un workflow est considéré comme bon.
• De découvrir comment passer du chaos à la clarté grâce à des exemples de workflow simples, lisibles et adaptables à différents types de projets.
• De partager des bonnes pratiques appliquées au quotidien chez ACSEO, avec des exemples concrets de configuration (GitLab notamment).

Après 20 ans de développement d’applications sur mesure, nous venons de vivre notre plus grand virage : traiter la documentation comme un langage de programmation. La documentation, technique et fonctionnelle, versionnée en Markdown, devient la source de vérité qui guide la génération de code et sa mise à jour continue, en interaction et sous le contrôle des développeurs (CI, revues, règles). Avec des assistants IA, orchestrés avec Claude Code, nous avons avant tout gagné en qualité : ambiguïtés réduites, meilleure cohérence doc/code, traçabilité claire. Surtout, nous gardons le plaisir et la maîtrise de livrer des fonctionnalités, même si nous écrivons moins de code nous-mêmes.

Vous connaissez les attributs "aria" et vous savez qu'il faut mettre des "alt" sur vos images ? Vous avez un score de 100 sur Lighthouse ? Vous avez passé un audit RGAA et avez eu le score honorable de 95 % au RGAA ?

Mais comment savoir si votre site est VRAIMENT accessible ?

Pourquoi, en 2026, tant de sites et d’applications restent-ils encore largement inaccessibles, malgré le cadre légal, les standards et les bonnes intentions affichées ?

Et pourtant, l'accessibilité numérique est une démarche de qualité qui profite à tout le monde : personnes porteuses d'un handicap, utilisatrices et utilisateurs valides, et même votre business !

Dans cette conférence ouverte à toutes et tous, nous montrerons comment faire votre maximum et comment valider concrètement l'accessibilité de votre site internet. Après un rappel sur les besoins des différents handicaps, nous explorerons une démarche qualité à appliquer tout au long du cycle de développement. En insistant sur l'essentiel : savoir tester tout comme vos utilisateurs réels, en maîtrisant leurs outils, comme les lecteurs d’écran.

Animée par Vanessa, consultante et formatrice en accessibilité, et Gabriel, développeur fullstack, cette session s’adresse aux curieuses et curieux comme à celles et ceux qui veulent enfin passer à l’action, pour participer à rendre le monde numérique plus inclusif.

Dans le développement web, on optimise souvent l’UI, les frameworks, ou l’infra… mais beaucoup moins les algorithmes. Résultat : des applis qui rament, des serveurs qui souffrent, et des factures cloud qui explosent. Dans ce talk, on explore avec humour et bons exemples ce qui se cache derrière ces ralentissements : la complexité algorithmique.

Nous verrons comment mesurer l’efficacité d’un code avec la notation Big-O, comment reconnaître un algorithme efficace (O(1), O(n)…) d’un autre qui va ruiner votre prod (O(n²), O(2ⁿ)…). Nous évoquerons aussi deux grandes familles de problèmes : ceux qui se résolvent vite (classe P) et ceux qui prennent une éternité à résoudre, même si on peut vérifier la solution rapidement (classe NP). Oui, c’est là qu’on croise le fameux « P vs NP » et son million de dollars à la clé !

L’objectif principal : choisir le bon algorithme, anticiper les volumes de données, éviter les pièges classiques, et satisfaire à la fois vos utilisateurs et votre serveur.

Foundry est un générateur de fixtures, principalement utilisé avec Symfony et Doctrine.

Nous verrons ensemble ses principales fonctionnalités, les erreurs à éviter, et comment Foundry peut simplifier nos tests au quotidien. Nous explorerons aussi certaines fonctionnalités méconnues, comme l’utilisation de factories et de repositories in-memory pour tester du code orienté DDD sans dépendre de la base de données.

La console est l'un des composants Symfony les plus utilisés et figure parmi les 5 paquets PHP les plus téléchargés au monde.

Utilisée par des outils essentiels tels que Composer, PHPStan, Psalm, ainsi que par la plupart des frameworks PHP, CMS, plateformes e-commerce et pour finir nos applications finales, la console est omniprésente.

Plus un package est utilisé, plus il est délicat de le faire évoluer : la moindre correction de bug sur la console peut perturber des millions d'utilisateurs. Néanmoins, le composant a été constamment amélioré grâce aux innombrables contributions qu'il reçoit depuis son introduction en 2010, tout en tenant sa promesse de rétrocompatibilité.

Mais il était grand temps de redonner un coup de jeune à ce composant, non seulement dans le but d'éliminer certaines limitations et autres problèmes d'usage, mais aussi pour l'ouvrir à de nouvelles possibilités. C'est chose faite ! Quelques contributeurs clés ont travaillé d'arrache-pied pour repenser la Console. Elle n'arrête pas de s'améliorer depuis Symfony 7.3 et atteindra son zénith dans la version 8.1 qui sortira quelques jours après l'AFUP Day 2026.

Rejoignez moi pour redécouvrir la Console en avant-première !

L’industrie du développement a tendance à vouloir mettre les développeur·euse·s dans des cases, à nous pousser à devenir expert·e·s dans un seul domaine, une seule stack, un seul langage. Nos carrières évoluent souvent soit vers du management soit de l’expertise.

À la suite de mes études, j’ai commencé ma carrière en Delphi en client lourd et je me suis spécialisée dans ce langage et cet environnement pendant 13 ans. J’étais bien partie pour continuer dans cette voie.

Jusqu’au jour où j’ai eu l’opportunité de sortir de ma zone de confort et de découvrir C# et l’environnement .NET. Une fois l’appréhension initiale passée, je me suis rendue compte que ma formation et mon expérience allaient m’être très utiles pour que la transition se passe sans accroc.

Alors comment ai-je fait pour appréhender cette nouvelle stack ? Quels outils m’ont aidée ? Quelles difficultés ai-je rencontrées ? En partageant mon expérience, j’aimerais vous montrer que grâce à notre métier, nous avons toutes les cartes en main pour nous réinventer si on le souhaite.

En 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'est la fin de l'AFUP Day 2026 : en route vers le Forum PHP 2026 !