La parole est aux speakers : François Zaninotto

Publié le

Jusqu’au Forum PHP 2026, retrouvez nos interviews de speakers pour mieux comprendre leur parcours et le sujet qu’ils ou elles aborderont lors de leur conférence !

La conférence

L'expérience agentique, ou comment tirer le maximum des IAs sur votre code

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.

Alice Recoque - ABCDEF
09/10/2026
12:25-12:45

Dans le grand débat actuel "est-ce que l'IA va remplacer les devs", as-tu un avis sur la question ?

C'est vrai, l'IA est aujourd'hui capable de faire une grosse partie du travail d'un·e dev. Mais pas tout. Il faut encore des devs pour juger de la pertinence d'une solution, de l'ergonomie, du respect des pratiques de l'équipe, pour penser à ne pas casser une feature qui a mis des mois à être calée, et pour discuter avec les utilisateurs... Et peu importent les progrès futurs de l'IA générative, il faudra toujours des humains pour prendre en charge ces tâches, qui nécessitent une capacité de jugement. Il faut aussi des devs pour garantir la qualité du résultat, qui est ce que les managers exigent de nous. Et ça, ça dépend directement de la compréhension du code.

Donc non, les devs ne vont pas disparaître. En revanche, le type de projet sur lequel on travaille est déjà en train de changer. Les projets faciles, on ne les voyait déjà pas - les utilisateurs s'en sortaient avec Excel ou du no-code. Les projets moyens, les utilisateurs vont les faire tous seuls avec l'IA. Il ne va nous rester que des projets gros et complexes. Et comme l'IA va permettre de lancer quantité de projets moyens qui vont naturellement évoluer vers plus de fonctionnalités et de complexité, l'IA générative pourrait tout-à-fait annoncer une explosion du besoin des devs. C'est en tout cas ce qui s'est passé chaque fois qu'on a inventé des outils pour faciliter la programmation par le passé.

Mais l'IA générative va nous forcer à étendre notre panel de compétences. Car le boost de productivité que permettent les assistants de codage révèle que là où on passe le plus de temps dans un projet, c'est à s'attendre les uns les autres. Il faudra donc plus de polyvalence et d'autonomie. On ne pourra plus se contenter d'être un "dev backend", il faudra aussi être capable de faire du front, de la QA, de l'analyse, de la supervision de la production, etc.

Reste-t-il un intérêt à rendre une codebase humainement lisible si le code est généré par des agents ?

Les humains doivent être capables de maintenir et de faire évoluer une application. Pour ça, il faut la comprendre. S'il existait un mécanisme sûr et reproductible pour transformer une spec en code, alors on pourrait se contenter de comprendre les specs et pas le code. Mais ce mécanisme n'existe pas (encore) - les LLMs sont très loin d'être des compilateurs de langage naturel en code. Donc en attendant, il faut comprendre le code, et donc qu'il soit lisible.

Il y a une autre raison : les assistants de codage ont été entraînés à partir de code écrit par des humains. Donc ils sont plus performants sur du code humainement lisible. Alors oui, ils peuvent écrire un programme entier en PHP encodé en base64, mais les bugs s'y glissent plus facilement, et ils peinent à le maintenir. Après, dans la base de code utilisée pour entraîner Claude Code, il y avait aussi des programmes en Brainfuck. Donc qui sait, l'IA est peut-être plus performante sur du code VRAIMENT pas lisible...

Quel est le premier signe qui montre qu'une codebase PHP a une AX (expérience agentique) de mauvaise qualité ?

Le signe le plus important à mon sens est l'absence de documentation décrivant l'intention d'un script. Je ne parle pas de phpDoc qui décrit la nature des paramètres à passer à une méthode, mais de l'explication du problème que la méthode est supposée résoudre. Car si les IAs savent lire du code, elles ne peuvent deviner le domaine qu'on y a encodé. Il faut donc le documenter, et le meilleur endroit pour ça, c'est directement dans le code, via un nommage efficace ou des commentaires orientés métier.

Mais l'AX, c'est bien plus que ça ! Il faudra venir voir mon talk pour en savoir plus 😉

Une conférence présentée par

François ZANINOTTO
François ZANINOTTO
Fondateur de marmelab, entrepreneur, développeur PHP & TypeScript, lead développeur de react-admin, GreenFrame et Atomic CRM, François est également contributeur open-source prolifique, coach agile, ex-core team Faker et Symfony.

Autres interviews