La parole est aux speakers : François Zaninotto

Jusqu’au Forum PHP 2025, 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

Tu es lead développeur sur plusieurs projets dont react-admin, GreenFrame et Atomic CRM. As-tu des conseils pour mener plusieurs projets de front ?

Je développe des projets open-source depuis bientôt 20 ans, et ça m’a pris du temps pour trouver la bonne façon de faire. Déjà, j’évite de travailler sur un projet open-source pendant mon temps perso. Mes journées de travail sont déjà bien assez longues pour ne pas ramener du travail facultatif à la maison. Et puis ça m’a presque poussé au burnout il y a une quinzaine d’années. Cela veut dire que je fais de l’open-source principalement sur mon temps pro, et donc que mon entreprise me paie pour ça. 
Ce n’est pas facile de trouver une société qui sponsorise un projet open-source, alors j’ai dû créer la mienne ! L’avantage, c’est que je peux aussi demander à mes employés de mettre la main à la pâte. Et en pratique, mon entreprise consacre environ 4 personnes à temps plein pour travailler sur des projets open-source. Ça coûte cher à l’entreprise, mais je vois ça comme un investissement : cela me permet de fidéliser des collaborateurs et collaboratrices, d’attirer des candidats et des candidates et de nouveaux clients. Et puis certains projets open-source rapportent de l’argent. React-admin, par exemple, a rapporté près de 2M€ depuis sa création au travers de notre offre Entreprise. 
Après, pour mener plusieurs projets en même temps, il faut faire des choix ! Et je n’affecte pas la même énergie à tous les projets en même temps. En fait, quand on planifie le travail sur un projet open-source comme un projet d’entreprise, ça donne le temps d’investir, de tester, de mesurer… et parfois de se tromper. 

Quels sont les meilleurs conseils que tu donnerais à un·e dev qui veut utiliser les agents pour l’aider à développer ?

Le paysage des agents de codage bouge trop vite pour que je puisse donner des conseils qui restent pertinents. Ce qui est sûr, c’est que le métier de développement est en train de changer de façon drastique. Avec Claude Code par exemple, j’ai développé une application mobile pour apprendre les accords de piano jazz en 6 heures, qui m’aurait pris une semaine à faire à la main. Ce gain de productivité spectaculaire ne s’est pas traduit par un code inmaintenable, au contraire. J’ai demandé à l’agent d’écrire des tests et de procéder à des refactorings une fois ou deux, et il s’en est très bien sorti. 
Mais cela a changé mon rythme de travail. Je pense davantage conception, architecture, expérience utilisateur et moins détails d’implémentation. C’est aussi plus intense cognitivement, et je pense que ce sera difficile de maintenir une telle productivité sur la durée sans se griller le cerveau. 
J’ai remarqué que j’avais tendance à ne pas beaucoup regarder le code : tant que la fonctionnalité correspondait à ma demande, je passais à la suivante. Je peux exprimer une fonctionnalité en langage naturel, et l’agent compile ces instructions en code machine (parce qu’il n’est plus destiné à être lu par un humain).
Je pense que ça ne change pas fondamentalement la nature de notre métier, qui est de traduire un besoin client en application fonctionnelle – pas d’écrire des lignes de code. Ça fait déjà pas mal d’années que les développeurs et les développeuses utilisent des annotations, de la configuration, ou des outils no code pour aller plus vite. Les agents de codage nous permettent de passer à la vitesse supérieure. Ils abaissent également la barrière pour devenir développeur ou développeuse, puisqu’il n’est plus nécessaire d’apprendre un langage de programmation pour le faire.

Que réponds-tu aux personnes qui sont effrayées par l’arrivée de l’IA, quand la possibilité que les agents soient mal entraînés n’est pas rassurante ?

Qu’ils ont raison ! Les limites inhérentes aux LLMs actuels (hallucinations, non-reproductibilité, biais systématique, empreinte environnementale) ont de quoi faire peur. Et beaucoup des annonces tonitruantes des géants de l’IA sont surtout destinées à leur faire gagner des parts de marché et à augmenter la valeur de leurs actions. 
Mais je ne pense pas que ces problèmes soient insolubles. D’ici 6 mois, 5 ans ou 20 ans, je suis persuadé qu’ils seront résolus. Il n’y a qu’à voir le chemin parcouru depuis le premier de ces assistants, Copilot, en 2021 ! Qu’on le veuille ou non, ils sont là pour durer.
Ce qui veut dire qu’on ne peut pas ne pas s’y mettre. Notre métier est en train de changer, et il ne sera plus jamais comme avant. Je pense qu’il ne serait pas prudent de faire l’impasse sur ces outils, parce que les attentes des clients vont aller de pair avec l’augmentation de la productivité généralisée. Et puis c’est dans la définition de poste des développeurs et développeuses d’apprendre de nouvelles technologies en permanence (sinon on ferait tous du Cobol). 
Une des frayeurs que j’entends beaucoup est que ces IAs vont nous remplacer. Je trouve que c’est une réaction un peu hypocrite. Le métier des informaticiens et informaticiennes, depuis toujours, est de remplacer le travail manuel par un automate. Pourquoi devrait-on être étonnés que ça nous arrive ? 
Je vois l’irruption de l’IA dans notre métier comme une opportunité. Si tout le monde peut devenir développeur ou développeuse, il y aura une quantité astronomique d’applications à maintenir et à faire évoluer. Pour une bonne partie de ces tâches, il faudra faire appel à un·e spécialiste. C’est comme pour l’ameublement : tout le monde peut acheter une étagère Billy chez Ikea, mais le jour où vous voulez une bibliothèque sur mesure, il faut bien faire appel à un menuisier. Ce métier-là n’a pas disparu, le nôtre ne disparaîtra pas non plus. 

Une conférence présentée par

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