Ce qu’il fallait voir au Forum PHP 2026

Comme chaque année, nous nous sommes rendus à la conférence phare de l’écosystème PHP en France : le Forum PHP de l’AFUP. En plus d’être sur scène pour parler de lucidité, de headers HTTP ou encore d’embbeding et de régression, nous étions aussi dans le public pour assister à de nombreux talks de qualité !

À travers cet article, nous allons passer en revue les plus grands enseignements de ces deux journées à Disneyland Paris.

Section intitulée les-nouveautes-de-symfony-8–2Les nouveautés de Symfony 8.2

Impossible de passer à côté : le backlog de Symfony a changé de tête ces trois derniers mois :

Avoir plus de 300 pull requests ouvertes, en attente de review, était un état normal et sain dans la vie du projet – mais depuis que Nicolas GREKAS a adopté le développement et la review agentique, c’est du passé ! Il n’y a plus que 19 PR ouvertes à l’heure actuelle. Toutes les autres n’ont pas simplement été fermées 👋 – mais précieusement relues, testées et enfin mergées ; pour certaines, des années après leur ouverture 🎉

Ce préambule annonce donc du lourd pour la version à venir de Symfony (8.2), qui va bénéficier de plus de 375 features (contre ~180 d’habitude). En termes de sécurité aussi, les choses ont pris de l’ampleur, avec plus de 200 rapports de sécurité traités (un mélange de vraies failles et de hardening : des améliorations de robustesse).

Nicolas utilisait déjà l’IA depuis 2025, mais juste en babysitting. Depuis août, il a crafté des skills très précis basés sur tout son historique de code review, de contribution et de traitement des sujets. Aujourd’hui, rien n’est fait sans intervention humaine, mais l’agent s’occupe de tout ce qui est évident : les rebases, les checks basiques, et une review profonde en se réappropriant tout le sujet de A à Z.

Section intitulée quelques-fonctionnalites-que-nous-avons-hate-d-utiliserQuelques fonctionnalités que nous avons hâte d’utiliser

• Demandé depuis 2019, l’attribut #[SerializedName()] prend maintenant en charge un nom différent en fonction du groupe de sérialisation !
• Un mode « sudo » pour forcer une re-saisie du mot de passe (ou autre) dans certains endroits très sensibles de votre application ;
• Le support natif d’OpenID Connect pour gérer la connexion des utilisateurs via des providers d’authentification (Google, Apple…) ;
• Le composant KeyManagement pour parler avec HashiCorp Vault, Azure Key Vault ou AWS KMS, et chiffrer les données de façon sécurisée !
• Consommer des messages en parallèle avec un seul worker Messenger via amphp/parallel. Une seule connexion backend et N threads de traitement 💪
• Le BatchDispatcher dans Messenger, capable d’envoyer plusieurs messages d’un coup dans la queue, plus rapidement que des ajouts unitaires (à l’exception d’AMQP) ;
• Le ChainStamp pour créer des enchaînements de messages qui se traitent les uns après les autres ;
• L’unique APP_SECRET, utilisé pour tout ce qui concerne les signatures, les cookies, les jetons… est désormais séparé par fonctionnalité, et il devient possible de le faire tourner (donc d’utiliser plusieurs secrets en même temps : le premier configuré signe, et tous valident) ;
• Le RecorderHttpClient est enfin mergé. Nous l’avions déjà vu à l’Afup Day Paris et nous avions hâte de pouvoir l’utiliser. Un attribut #[UseRecord] permet d’enregistrer le HAR du trafic réel, qui est ensuite rejoué dans nos tests ;
• L’attribut #[AsFormType] sur un DTO qui crée le formulaire correspondant pour nous 🤯
• Pareil avec #[AsWorkflow] : les transitions sont directement définies sur nos constantes. Bravo à Grégoire, qui avait commencé cette feature en 2024, et l’a terminée avec Claude !

Enfin, une nouvelle page d’exception a été intégrée, mais tout va bien, notre GifExceptionBundle supporte déjà le nouveau design, merci Loïck.

Section intitulée exposer-son-metier-aux-agents-ia-avec-api-platformExposer son métier aux agents IA avec API Platform

Antoine BLUCHET nous a fait une démo sympa d’un agent IA vocal qu’il a développé en side project pour son garage : gestion documentaire, wireframes 3D des voitures, estimation de devis auto, le tout semblait très complet !

Sous le capot, on retrouve évidemment plusieurs APIs comme l’accès au SIV pour récupérer les infos via la plaque d’immatriculation, mais aussi le vecteur principal de son assistant : le MCP.

Antoine nous explique que pour faire du MCP en PHP aujourd’hui, on a des librairies bien pratiques :

• le SDK PHP de bas niveau qui permet de lancer un serveur avec transport, chaque outil mis en avant est une méthode en PHP ;
• l’abstraction Symfony, qui permet, entre autres, d’utiliser des attributs sur les méthodes et de configurer le transport (HTTP, stdio) ;
• une abstraction API Platform avec des attributs au niveau des classes et une exposition plus simple des APIs sur le MCP.

Nous nous sommes donc attardés sur ce que propose l’abstraction d’API Platform :

• de la validation avec des Asserts et des Constraints ;
• du typage, y compris avec des choices ;
• la réutilisation des processors existants ;
• de la sécurité, avec le support des isGranted ;
• du retour en markdown et le branchement de providers.

La liste est longue, et l’idée derrière est simple : exposer un métier à un agent, ce n’est pas réécrire une API, c’est la rendre lisible pour lui.

Vient alors la vraie question, celle que nous retenons : comment parler à un agent sans lui noyer le contexte ? Antoine écarte les appels HTTP à l’API en direct. Faire des allers-retours avec l’API est assez bavard et gourmand en tokens. Il propose à la place d’exposer la documentation de l’API sur sa racine /, au format hypermédia, pour que l’agent s’y renseigne seul et aille droit au but, en un seul appel.

Reste le flux : PHP synchrone n’aime pas rester ouvert, ce qui tombe mal pour tenir une connexion avec un agent. La réponse avancée est Mercure.

En pratique, Antoine fait cohabiter plusieurs modèles selon les besoins. Avec Symfony AI, on peut limiter certains tools à un modèle précis, par exemple limiter la recherche web à Gemini 2.5 qui le fait très bien et propose un free tier.

Un mot pour finir sur le testing, où rien n’est vraiment sûr. Tester les choix d’un agent est difficile et coûteux, et si les LLM Judges existent, Antoine les trouve fragiles : on ajoute du déterminisme sur du non-déterminisme. Bref, pas encore de solution solide.

Est-ce que le futur sera fait de pleins de « Jarvis » ? Pas forcément, mais quoi qu’il en soit, c’est autour des APIs qu’il sera construit !

Section intitulée php-defensif-arretez-de-faire-confiance-defendez-votre-codePHP Défensif : Arrêtez de faire confiance, défendez votre code !

Thomas DUTRION nous ouvre son talk avec une citation de Léonard de Vinci :

L’expérience prouve que celui qui n’a jamais confiance en personne ne sera jamais déçu.

Le code défensif, ce n’est pas une question de compétence, mais de posture : ne faire confiance à personne, même pas à soi-même. L’idée directrice du code défensif, comme nous le présente Thomas, c’est de déplacer la responsabilité de l’humain vers la machine. On ne compte plus sur la discipline et la mémoire de chacun ; on écrit les règles noir sur blanc dans le projet pour que l’outillage les fasse respecter à notre place. Ce qui n’est pas explicite n’existe pas.

Côté pratique, on retient plusieurs vraies actions :

• Poka-yoke : rendre l’erreur humaine impossible et très facilement détectable si elle arrive (typage, readonly, logging). Préférer la prévention, prévoir la détection ;
• un type par concept : unions, intersections, DNF, tant qu’à faire. Si une union dépasse deux types, c’est sûrement qu’il manque un Enum ou un DTO ;
• des types dédiés plutôt que des primitifs : on type les IDs, on passe par brick/money pour les prix au lieu de floats, par une classe Uri au lieu de concaténer des strings ;
• on bannit les @, on passe aux comparaisons strictes, en gardant en tête que, dans le legacy, les loose comparisons sont parfois des features ;
• on ne fait jamais confiance aux valeurs externes : une couche de sécurité et de cohérence, on vérifie puis on valide ;
• et les petits réflexes qui comptent : des enums plutôt que des constantes, la config injectée plutôt qu’un fichier .env lu directement, des classes complètes dès leur création (logique dans le constructeur) et final pour éviter les changements de comportement abusifs, des conventions d’équipe sur le nommage (get ou find ?).

Pour appliquer toutes ces règles, ce sont finalement des outils que nous connaissons déjà qui entrent en jeu : PHP CS Fixer pour le style, PHPStan pour le typage, Deptrac pour les frontières d’architecture, Valinor pour valider les valeurs externes et les collections, et d’autres encore. Le tout est de les mettre en place sur nos projets et de les y tenir dans la durée.

Le fil rouge, en soi, c’est que moins on s’appuie sur l’humain, plus on s’appuie sur la machine. À l’ère des agents qui produisent du code en volume, les bonnes pratiques deviennent une nécessité et la machine devient essentielle pour ne pas faillir là où la discipline et la mémoire humaines fatiguent.

Section intitulée vos-coding-agents-en-mode-yolo-mais-en-toute-securiteVos coding agents en mode YOLO… mais en toute sécurité

Le mode YOLO, c’est ce qui permet à vos agents de pouvoir lancer toutes les commandes sans vous demander la permission. C’est donc… un peu dangereux 😜 Cependant, il a pour gros avantage de laisser l’agent travailler sans avoir à valider chacune de ses opérations. L’agent va plus vite, mais nous sommes moins en sécurité !

Guillaume LOURS travaille chez Docker et il nous a présenté leur solution : Docker Sandboxes, avec une démo basé sur Symfony Demo.

L’idée est de pouvoir laisser votre agent faire ce qu’il veut mais dans une sandbox où :

• il n’aura pas accès à tout Internet, configurable locale ou par l’organisation ;
• il ne verra pas vos secrets applicatifs, vos jetons, etc. ;
• il n’aura accès qu’aux fichiers de votre projet.

En interne, c’est comme du Docker-in-Docker : nos projets qui tournent actuellement déjà avec Docker sont cette fois démarrés dans le Docker Sandboxe, avec l’agent et tous les outils dont nous avons besoin.

Nous pouvons noter que Guillaume n’a pas parlé du mode « auto » de Claude. Ce mode se situe entre le mode « manual » et le mode « yolo ». Il classifie chaque opération, et ne demande pas de validation tant que l’opération est jugée non dangereuse. Est-ce que ce mode permet d’éviter la complexité de faire tourner son agent et sa stack dans une micro VM ?

C’est plutôt un outil à destination des grands groupes qui ont besoin de contrôler ou limiter les capacités des agents de leurs collaborateurs – à retenir !

Section intitulée la-lucidite-comme-architectureLa lucidité comme architecture

Bastien JAILLOT a présenté un retour d’expérience à deux voix avec Joël GOMEZ CABALLE, lead dev chez Aropixel. Le point de départ est une billetterie en ligne lancée en 2014 par un développeur seul, qui apprend Symfony 2 en même temps. Le succès arrive vite : rachat, 150 sites en production, plusieurs millions d’euros par mois.

Avec le succès, Joël a voulu une architecture « sérieuse » : microservices, DDD, interfaces partout. Chaque choix avait une bonne raison. Mais ajouter un champ téléphone imposait de traverser un DTO, un transformer, un handler, un repository et un event listener. Le code était réparti sur quatre dépôts. Une développeuse junior devait publier une version de la librairie front, sans tests ni review, juste pour pouvoir avancer. Et on ne déployait qu’une fois tous les quinze jours : le lundi après-midi, plus personne ne committait.

Le talk prend le temps de nommer ce qui bloquait vraiment, et ce n’est pas la technique. À l’écran, les affects s’affichent comme des lignes de log : la confusion et le déni en [WARN], la honte en [ERROR], la peur en [FATAL].

Appelé pour un classique « le site est lent » (nous intervenons régulièrement dans ce genre de contexte), Bastien commence par un constat sans affect : un wrapper d’API n’a aucune raison de tomber avant l’API qu’il enveloppe. Varnish et le user context hash absorbent le trafic qui ne rapporte rien. Mais le vrai chantier est ailleurs : rendre les petits changements faciles avant de simplifier toute l’architecture.

• un monorepo, fait en une heure ;
• un environnement Docker lancé avec Castor ;
• Datadog, que Joël a rebaptisé « Data-drogue » 😂 ;
• du trunk-based development, avec dix déploiements par jour pour une équipe de trois devs ;
• des feature flags activés sur un shop, puis dix, puis tous.

C’est seulement ensuite que Mercure, Memcache, Elasticsearch et toute une API intermédiaire ont pu disparaître, sans feature freeze.

Le dernier chapitre parle des agents IA. Tout ce qui avait été mis en place leur profite à plein. Mais l’enthousiasme de ceux qui s’éclatent avec eux peut, une seconde fois, empêcher de voir ceux qu’on laisse sur le bord du chemin. La conclusion : la lucidité ne se décrète pas, elle se construit, comme une architecture. Le talk se termine sur une question à la salle : et chez vous, qui donne l’alerte ?

Les slides et leurs notes sont en ligne.

Section intitulée avant-que-php-n-execute-ton-premier-echo-ce-que-la-couche-reseau-coute-vraimentAvant que PHP n’exécute ton premier echo : ce que la couche réseau coûte vraiment

Dans son talk, Nicolas PERUSSEL est parti d’un constat. FrankenPHP est arrivé en prod chez beaucoup de monde, et il active par défaut HTTP/3, 0-RTT, Early Hints et les certificats automatiques. Or on ne sait pas toujours ce que ces fonctionnalités font vraiment. L’idée est de suivre ce qui se passe quand un client se connecte, avant même que PHP n’entre en jeu. Ça vaut aussi pour Nginx et Apache.

Le talk commence par un rappel des bases en présentant le modèle OSI (Open Systems Interconnection) pour aider à situer chaque couche du réseau. Vient ensuite le three-way handshake TCP : avant d’échanger la moindre donnée, client et serveur font un aller-retour complet pour établir la connexion.

Nicolas a ensuite évoqué la fameuse notion de RTT (Round Trip Time), rien à voir avec vos congés 🙂. Elle exprime combien coûte un dialogue avec une autre machine sur le réseau. Chaque étape de la connexion se compte en RTT, et c’est ce qu’on cherche à réduire.

Le chiffrement TLS ajoute ses propres RTT par-dessus TCP. TLS 1.2 en coûte 2, TLS 1.3 n’en coûte plus qu’1. Passer en 1.3 est donc déjà un gain direct sur chaque nouvelle connexion. Le RTT est généralement très variable sur mobile comparé à la fibre. Économiser quelques RTT a donc un impact bien plus visible pour les utilisateurs mobiles que pour ceux sur une connexion fixe.

Nous avons ensuite parlé de HTTP/3 et QUIC qui remplace TCP par UDP et englobe TLS 1.3. La connexion et le chiffrement se font en 1 seul RTT au total, contre 2 avec TCP + TLS 1.3. QUIC est implémenté en userspace et non dans le noyau. C’est donc souvent un peu plus gourmand en CPU, avec un p90 légèrement plus élevé. En contrepartie, une perte de paquet n’immobilise plus tous les flux. Avec TCP, un seul paquet perdu bloquait tout le monde. C’est aussi très pratique pour la reprise de connexion lors des changements d’antenne 5G : la connexion survit au changement de réseau au lieu de devoir tout renégocier.

Grâce au 0-RTT, si un client se reconnecte à un serveur déjà connu, il peut envoyer sa requête dès le premier paquet, sans attendre la fin du handshake. Cependant, le 0-RTT expose aux replay attacks : une requête peut être rejouée par un attaquant. Il faut donc le limiter aux routes idempotentes (GET) et ne pas l’accepter sur un POST qui modifie des données.

Avec sa conférence, Nicolas nous a non seulement permis de comprendre ce qu’il se passait dans le réseau lorsque l’on se connecte à un serveur, mais aussi nous a donné plusieurs pistes pour optimiser nos infrastructures. Car même si les réglages par défaut des logiciels aident beaucoup, certains paramètres doivent tout de même être faits à la main : restreindre le 0-RTT, s’assurer que l’infra laisse passer QUIC, activer l’OCSP stapling, etc.

Section intitulée l-ecosystem-security-team-de-la-php-foundation-de-l-interieurL’Ecosystem Security Team de la PHP Foundation de l’intérieur

Alexandre DAUBOIS est Core Security Engineer à la PHP Foundation. Son rôle est de relire, de tester et de vérifier les différentes failles qui sont découvertes et signalées à la fondation.

Le monde de la sécurité a beaucoup changé cette année. L’avènement des agents a provoqué un afflux massif de rapports, à tel point que les programmes de bug bounty s’arrêtent : ils ne peuvent plus suivre ! Curl, Google, Internet Bug Bounty (IBB)… sont suspendus sous le poids des propositions.

Le goulot d’étranglement, c’est l’humain, car chaque notification doit être vérifiée. Beaucoup de mainteneurs font des burnouts ou n’arrivent pas à suivre. La solution pour ces mainteneurs qui n’ont pas toute une core team, c’est l’Ecosystem Security Team de la fondation, dont Alexandre fait partie.

Un des outils qu’ils utilisent est scrutineer d’Alpha-Omega. C’est un outil pour scanner les projets open source à la recherche de failles, via des agents LLM et des skills, et gérer le processus de divulgation proprement, sans doublons et sans les tartines de texte que les LLM adorent nous faire lire.

Leur premier job avec l’outil a été de scanner les 300 projets les mieux classés en nombre de téléchargements sur Packagist. En un mois, ils ont contacté 35 mainteneurs avec des rapports bien structurés, prouvés et qualitatifs, provoquant plus de 100 corrections !

Lors du scan d’API Platform, une faille a été trouvée. Il a fallu vérifier humainement, car c’est une lourde responsabilité de déclarer une faille : on demande un ID unique mondial, c’est propagé partout, les distributions Linux doivent se mettre à jour, les scanners de dépendances signalent la version concernée… CVE-2026–54164 est né, validé par des humains. On ne peut pas tout automatiser. L’humain voit tout : les conditions que le LLM n’a pas vues, le contexte, la véracité. Merci Alexandre 💪

Section intitulée les-lighting-talksLes lighting-talks ⚡ !

Bravo à Baptiste LEDUC, qui a présenté PABLO, son orchestrateur maison d’agents et de tâches (vous pouvez en lire plus dans sa série d’articles ici-même).

Xavier LACOT a présenté, pour sa part, une petite liste d’en-têtes HTTP méconnus. Nous y avons, par exemple, découvert les User-Agent Client Hints, avec Sec-CH-UA, ou Sec-GPC, qui remplace le Do Not Track. Et un clin d’œil à redirection.io avec le bien ancien en-tête Refresh: <time>; url=<url>, qu’on vous recommande de ne jamais utiliser 😀

Nous avons aussi découvert nektos/act par l’intermédiaire d’Estelle GAITS, pour exécuter nos GitHub Actions en local 🙏 Outil particulièrement pertinent à mettre en place à un moment où ce sont les agents qui écrivent nos actions !

Enfin, citons Grégoire PINEAU, qui a expliqué son clone du site bien connu « De Gauche ou de Droite ? », mais qui tourne à 100 % dans le navigateur avec un petit modèle d’IA embarqué. Les slides expliquent la démarche, ce qui a fonctionné et ce qui a raté – à lire !

Section intitulée souverainete-numerique-a-l-ere-de-l-iaSouveraineté numérique à l’ére de l’IA

Avec Quentin ADAM, CEO de Clever Cloud, pas de langue de bois. Dès les premières minutes, on comprend que le propos sera tranché, et il l’assume pleinement. Il commence par la révolution industrielle : le moteur a remplacé les muscles. Avec un tracteur de 400 chevaux, ce sont 400 chevaux et une centaine de personnes pour s’en occuper qui sont remplacés par seulement une personne pour conduire et une personne pour l’entretien. Puis l’ordinateur a commencé à remplacer les cerveaux.

Selon lui, l’Europe est en train de rater cette nouvelle révolution. Il en donne plusieurs raisons : une gouvernance trop centralisée, une politique qui préserve les emplois des vieilles entreprises au lieu de laisser émerger les jeunes, et une fiscalité qui marche sur la tête (8 % pour les GAFAM, 18 % pour nos grands groupes, 23 % pour nos PME). Les chiffres font mal : sur 100 € dépensés en informatique en Europe, 83 € partent aux États-Unis. Et le Cloud Act donne en prime aux autorités américaines un accès permanent à nos données.

Son message tient en une phrase, qu’il répète sans détour : diversifiez vos achats, achetez local, et écrivez à vos député·es, parce qu’à Bruxelles, en face d’un lobbyiste comme Clever Cloud, il y en a cent payés par les géants américains. Il pousse la logique jusqu’à sa « clause de souveraineté finale » : si Clever Cloud est racheté par un acteur étranger, ses clients obtiennent une licence perpétuelle, ce qui enlève tout intérêt au rachat.

Le seul adversaire qu’il n’a pas réussi à faire plier ce matin-là, c’est le vidéoprojecteur. À chaque GIF, l’écran se figeait et il devait débrancher puis rebrancher le câble HDMI. Cloud souverain ou GAFAM, tout le monde a ses limites, surtout face à la connectique 🔌.

Section intitulée speed-is-a-byproduct-of-trustSpeed is a byproduct of trust

D’après Sebastian BERGMANN, travailler avec un agent, c’est un peu comme jouer à un jeu d’aventure textuel, sauf que la grande majorité des commandes se résume à « Accept all ». Nous finissons par nous y perdre, jusqu’à devoir repartir de la base. Ce talk parle justement des filets de sécurité qui nous permettent de faire confiance à la vitesse des agents qui produisent du code en masse.

La vraie question d’ailleurs, n’est pas de savoir si nous faisons confiance à l’agent, mais si nous faisons confiance à notre pipeline pour garantir que ce qu’il génère est valide.

Sebastian nous présente deux façons de se planter :

• Recklessness (témérité) : de la vitesse sans contrôle. La dette s’accumule plus vite, les erreurs sont les mêmes qu’à la main, elles arrivent simplement plus vite ;
• Stagnation : du contrôle sans vitesse. Le marché nous largue, et la review devient un goulot d’étranglement.

Les deux mènent dans le mur, mais le message central est ailleurs : les équipes ne vont pas plus vite malgré leur quality control, elles vont plus vite parce qu’elles ont confiance en leur quality control. La confiance n’est pas un sentiment, c’est un track record, une suite de résultats observés et reconnus.

Dans un exemple concret, voici ce que nous pouvons mettre en place :

Un domaine isolé dans quelques fichiers PHP qui ne dépendent de rien + un dossier « Application » où l’agent travaille en le respectant sans jamais y toucher.

L’idée : isoler le métier dans quelques fichiers PHP qui ne dépendent de rien, pour que le cœur reste stable et lisible, et laisser l’agent travailler dans un dossier dédié en le respectant sans jamais y toucher. Il gagne un terrain de jeu où produire vite, et une frontière qu’il ne franchit pas.

Le filet tient dans des outils connus (PHP CS Fixer, PHPStan niveau 10, Deptrac, PHPUnit, mutation testing, une CI qui bloque le merge), avec quatre réflexes :

1. Observer le filet attraper des choses ;
2. Transformer les tests en specs ;
3. Inverser le rapport : c’est nous qui spécifions, et c’est l’agent qui implémente ;
4. Puis durcir notre gate.

Et évidemment, écrire les règles en dur dans l’outillage, sinon nous ne les rattrapons jamais.

Côté tests, Sebastian conseille de nommer les tests comme des phrases de ce qui est attendu, et de préférer le TDD (un test venu du code n’est qu’un log). De plus, le coverage ne suffit pas : d’où le mutation testing, où nous cassons le code exprès pour voir si les tests réagissent.

Reste la « Definition of Done », qu’il faut définir, sinon l’agent s’en choisit une tout seul, avec assurance et souvent à tort : plutôt que de dire « écris une classe pour faire X », demandons « fais passer ce test sans le modifier », en lui interdisant de toucher aux tests.

L’humain spécifie le comportement et l’architecture une fois, l’agent implémente jusqu’au vert, l’humain relit.

En résumé, nous ne faisons pas confiance à l’agent, mais au filet construit autour de lui. Les tests sont nos specs, la CI est l’arbitre, l’agent est un outil et pas un collègue. C’est ce track record, et non un sentiment, qui rend la vitesse tenable et qui transforme la fameuse commande « Accept all » en décision.

La vitesse, au bout du compte, n’est qu’un sous-produit de la confiance. ⚡

Section intitulée l-experience-agentique-ou-comment-tirer-le-maximum-des-ias-sur-votre-codeL’expérience agentique, ou comment tirer le maximum des IAs sur votre code

François ZANINOTTO nous a présenté une série de bonnes pratiques pour coder avec des agents. En voici quelques-unes qui nous semblent intéressantes :

• Donner le contexte métier : le décrire dans AGENTS.md, dans les commentaires du code… Si la documentation est ailleurs, connecter un MCP (coucou Jira / Confluence / Notion…) ;
• Les agents ne peuvent pas mettre tout le code dans le contexte. Ils font des grep en permanence. Il faut donc rendre le code facile à trouver. Utiliser des DTO, du LSP, documenter les synonymes, éviter les noms dupliqués ;
• Il faut être concis, car le contexte de l’agent est limité. Des fichiers courts, des logs peu verbeux, pas de commentaires inutiles, pas de code mort, du Markdown plutôt que du HTML/PDF/DOCX…
• Les modèles ont été entraînés sur du vieux code. Il est donc préférable de choisir des boring tech !
• Aider l’agent à trouver la documentation de vos outils sans parser le Web : ajouter le MCP Context7 ou fournir la documentation directement dans les vendors ;
• Renforcer les garde-fous avant que le code arrive dans la CI ; la boucle agentique doit être capable de tout tester / valider avant d’envoyer le code ;
• Garder la revue de code 💯 ;
• Améliorer le monitoring de production et les procédures de rollback en cas de soucis ;
• Entretenir la mémoire : mettre à jour la documentation en fin de session, faire des skills, nettoyer le harnais agentique.

Pour finir, François confirme ce que nous avons aussi constaté : écrire des tonnes de skills n’est pas nécessaire quand le code de votre projet est déjà clair / bien fait 👍

Section intitulée la-review-qu-on-aurait-du-faire-depuis-toujours-reprendre-sa-place-de-reviewer-humain-a-l-ere-des-agents-iaLa review qu’on aurait dû faire depuis toujours : reprendre sa place de reviewer humain à l’ère des agents IA

Gaël CRISPYN délègue maintenant la première review à des agents et il a profité de ce talk pour nous présenter ses bonnes pratiques.

Bien sûr, cela passe par un Skill (de notre côté, nous voyons souvent passer celui-ci) et par des descriptions de PR complètes. Une information que nous trouvons très intéressante, c’est de forcer le développeur à préciser dans chaque PR deux choses :

• ce qu’il a vérifié ;
• ce qu’il n’a pas vérifié !

Ce deuxième point est critique et l’agent pourra focus son étude dessus.

Tout ce qui concerne les coding standards, l’indentation et la cosmétique doit être ignoré par l’agent. L’agent doit aider l’humain à faire sa review, en mettant le doigt sur les points faibles et en questionnant tout ce qui n’est pas carré. Pour que ça fonctionne, il faut donner à l’agent le contexte, les spécifications, l’intention et des PR de taille raisonnable.

Un dernier point d’attention : quand l’agent dit « C’est OK, tout va bien », ce n’est pas OK ! L’humain doit toujours valider.

Section intitulée l-ia-dans-l-image-la-mort-du-reel-ou-le-moment-qu-on-attendait-toutes-et-tousL’IA dans l’image : La mort du réel ou le moment qu’on attendait toutes et tous ?

La conférence s’est terminée avec Niels ACKERMANN, photographe de presse depuis plus de 20 ans, qui nous a parlé de la transformation de son métier face à l’IA générative. Bien que les générateurs d’images intègrent des filigranes, ils ne sont pas fiables et détecter une vraie photo d’une fausse devient impossible avec les derniers modèles.

Pourtant aujourd’hui, les grandes entreprises de l’IA ne font pas leurs publicités avec l’IA. L’IA ne sait pas innover. Tout ce qu’elles montrent est basé sur des choses qui ont déjà été faites. Donc pour les photos les plus évidentes / consensuelles, les IA remplacent le photographe, et il ne reste que l’innovant et l’inattendu.

Là où la vérité est importante (les médias !), le vrai, le réel, restent aussi importants. Mais pour autant, utiliser l’IA générative pour corriger une photo, l’améliorer ou la recomposer ne devrait pas être un problème tant que c’est dit.

Il a donc créé DALIA Scale, un moyen simple de noter un travail, sans jugement, en fonction de l’utilisation de l’IA générative dans son processus de création. Avec des questions simples (« Qui a l’idée ? », « Qui exécute ? » et « Qui valide ? »), nous pouvons obtenir une note.

• D0 : tout est fait à la main ;
• D5 : l’IA est autonome, elle a tout fait.

Il pousse ses clients à l’utiliser dans leurs appels d’offres, pour demander un « maximum Dalia 2 », par exemple. Cet article est D1 (les agents ne vont pas encore en conférence à notre place !).

Section intitulée le-mot-du-president-de-l-afupLe mot du président de l’AFUP

Benjamin : pour cette année 2026, je suis président de l’AFUP, l’association organisatrice du Forum PHP.

L’évènement existe et rassemble la communauté depuis plus de 25 ans maintenant et est organisé en grande partie par des bénévoles sur leur temps libre : négociation avec la salle, le traiteur, rédaction du CFP et sélection des conférences, gestion du planning et des venues des conférenciers et conférencières, billetterie, beaucoup de coordination logistique, et vous l’avez sûrement vu, beaucoup de pas parcourus pendant un jour de préparation et deux jours de conférences.

Merci à tous les bénévoles et à Amélie pour tout ce travail 💪

À cause des budgets plus serrés que d’habitude ainsi que du profond changement que notre secteur connaît, cette année a été compliquée, et l’AFUP a publié une lettre ouverte pour en parler.

Cependant, cette édition a été une vraie réussite :

• les quelques conférences auxquelles j’ai pu assister m’ont appris des choses et m’ont donné envie de tester tout ça dès mon retour, d’autres m’ont aidé à prendre du recul sur différents sujets : des projets, du code, de l’organisation ;
• j’ai pu retrouver des bénévoles, mais aussi en croiser de nouveaux (qui eux, ont pu découvrir la quantité d’énergie nécessaire pour tenir 3 jours !) ;
• j’ai discuté avec des conférenciers et des conférencières, des responsables d’antennes de l’AFUP qui organisent des meetups régulièrement près de chez vous, des sponsors dont le soutien est indispensable au fonctionnement de l’association, des confrères et consœurs avec qui on a partagé des bières, et évidemment de nombreux visiteurs.

L’AFUP travaille maintenant pour s’adapter également, et nous nous revoyons aux prochains événements AFUP en 2027 🎉

Section intitulée en-conclusionEn conclusion 🐘

Merci à l’AFUP pour ces deux jours riches en échanges, en discussions et en IA ! C’était clairement le sujet de l’année, et peu de gens dans la salle lèvent encore la main quand on demande « qui code sans IA ». Notre métier change très vite et vivre de telles conférences nous aide à nous orienter dans ce paysage mouvant.

Comme dirait un bénévole à la fin d’un talk : On a plus le temps pour les questions ! Merci pour votre attention !

Et à l’année prochaine 🙏