La parole est aux speakers : Yoann Blot
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
Mago, ou comment Rust et l'IA réinventent l'outillage qualité PHP10 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. |
Tu indiques dans ta bio être beaucoup plus productif grace à l'IA. Comment as tu évalué ce gain de productivité ?
Ça fait plusieurs années que j'utilise l'IA au quotidien, et ce qui a changé n'est pas ma vitesse de frappe, c'est mon métier. Je suis passé d'écrire du code en maîtrisant bien mon IDE à orchestrer plusieurs agents en parallèle.
Le gain se joue sur trois axes. D'abord le périmètre : je n'ai plus vraiment de limite de compétence. L'exemple le plus parlant est lié à ma conférence, justement. Je ne fais pas de Rust, et j'ai quand même pu lire le code de Mago, comprendre où vivait un problème et proposer des choses sur le dépôt. Sans IA, je n'aurais jamais ouvert ne serait-ce qu'une issue sur un projet Rust.
Ensuite la parallélisation : pendant qu'un agent fait une tech discovery sur la prochaine feature, un autre code une feature en cours, et deux ou trois autres travaillent sur du refactoring dans des git worktrees séparés. En nombre de tâches menées simultanément, c'est un facteur 3 à 4 par rapport à avant.
Enfin la vitesse d'exécution : même en connaissant très bien mon IDE, un agent avec un bon harness va plus vite que moi. Ça déplace mon travail vers le besoin, le design et les patterns, et je laisse l'agent exécuter.
Pour ne pas rester dans le ressenti, je suis deux indicateurs DORA sur nos données GitHub : le nombre de PR mergées et le lead time. En trois ans, le délai médian entre l'ouverture d'une de mes PR et son merge a été divisé par 4 (16h => 2h), et le nombre de PR mergées par jour a été multiplié par 5 (2 => 11). Avec une précision qui compte : sur ces 11, 3 seulement sont écrites de ma main. Le reste vient d'agents que je pilote et dont je valide le travail. Le changement n'est donc pas que j'écris cinq fois plus de code, c'est qu'une part croissante de mon travail consiste à faire produire plutôt qu'à produire.
Et c'est là le vrai sujet, parce que mon rôle de staff engineer n'est pas d'être le plus productif de l'équipe, c'est d'amener le reste de l'organisation là où j'en suis. Ça bouge dans le bon sens : toute l'équipe dispose maintenant d'une analyse complète de la codebase en quelques secondes. Sur trois ans, le développeur médian chez nous a doublé son nombre de PR mergées par jour. C'est cette courbe-là qui m'intéresse le plus.
Si tu ne devais choisir qu'une seule raison de passer à Mago, quelle serait-elle ?
La vitesse. Mais pas la vitesse pour elle-même, la vitesse pour ce qu'elle change dans le comportement de l'équipe.
Avant Mago, on lançait plusieurs outils qualité en local (Deptrac / PHPStan / PHP CS Fixer / Rector), qui prenaient une dizaine de minutes à chaque lancement sans cache. Avec un cache frais, on était plutôt sur 1-2min, mais il fallait le mettre à jour plusieurs fois par jour. C'était une source de frustration réelle dans l'équipe, et beaucoup de temps perdu à attendre en local, parfois on préférait faire tourner la CI et faire des aller retours à la place...
Aujourd'hui, Mago analyse toute la codebase sans aucun cache en quelques secondes. Il n'y a plus de cache à reconstruire, donc plus de mauvaise surprise, et l'analyse tourne aussi sur chaque PR en moins d'une minute.
C'est pour moi le seul argument nécessaire : un outil qualité qu'on hésite à lancer ne sert à rien. Mago est assez rapide pour qu'on le lance sans y penser.
Et cette vitesse débloque des choses qu'on n'imaginait pas au départ. Quand vérifier coûte quelques secondes au lieu de quelques minutes, tu peux construire de l'automatisation par dessus. C'était hors de portée avant.
C'est la première fois que nous t'accueillerons sur un événement AFUP. Peux-tu nous parler de ton parcours de conférencier et de ce qui t'a motivé pour te lancer et répondre au CFP du Forum PHP ?
Ça fait plusieurs années que j'ai envie de monter sur cette scène. Je suis venu plusieurs fois au Forum PHP en tant que spectateur, et chaque fois je repartais avec l'idée qu'un jour je proposerais quelque chose.
J'ai déjà parlé en public, mais dans des formats plus petits : des meetup (au Canada) où j'ai donné plusieurs présentations, quelques petites confs sur Paris ensuite, et aujourd'hui je présente environ une fois par mois en interne chez PlayPlay, sur les outils IA ou sur des sujets backend. Le Forum PHP est donc mon premier grand format, mais pas ma première prise de parole.
Quant au sujet, j'ai voulu parler de Mago parce que personne ne l'avait encore fait et que j'ai l'impression que beaucoup de monde passe à côté. C'est pour moi le meilleur outil de l'année. L'écart de confort et de productivité est tellement important que ça aurait été dommage de ne pas le partager avec la communauté PHP française.
J'avais d'ailleurs soumis un second talk, qui n'a pas été retenu, mais qui découle directement de Mago. On s'en est servi pour monter une usine de correction de dette technique : Mago et PHPStan identifient, des agents corrigent, chaque correction part en PR et doit passer la CI comme n'importe quelle autre. Sur notre application principale, on est passés de 10 782 violations en baseline à 819, soit 92 % résorbées, dont l'essentiel sur les trois derniers mois. Et si ça tient, c'est précisément parce que vérifier une correction coûte quelques secondes. Avec l'ancienne chaîne, cette usine n'aurait jamais tourné.
Une conférence présentée par
 Yoann BLOT |
Yoann est un dév passionné par la qualité et la productivité. En tant que Staff engineer chez PlayPlay, il fait en sorte que l'équipe garde le contrôle de leur codebase et stack backend tout en étant beaucoup plus productif qu'hier grâce à l'IA. |