À propos
Neuf ans à mettre du ML puis des LLM en production, d’abord sur le pricing chez Amazon, ensuite sur des catalogues produit en SaaS. Aujourd’hui j’utilise des agents de code tous les jours, à raison de centaines de milliards de tokens, et j’interviens dans les équipes qui veulent en tirer davantage : développeurs, product managers, designers.
Le parcours
J’ai commencé chez Amazon, au Luxembourg : trois ans et demi sur le pricing européen. J’y suis entré par l’optimisation de supply chain puis par l’architecture AWS, avec quatre certifications AWS passées en quatre mois, dont la Solutions Architect Professional. en pixels
Ensuite le pricing, comme seul data scientist d’une équipe passée de trois à treize personnes. De l’inférence causale, avec du contrôle synthétique codé à la main avant que les librairies soient mûres, des modèles bayésiens hiérarchiques d’élasticité prix, et des prix hédoniques estimés sur des embeddings texte et image, avec du ELMo puis du BERT fine-tuné en 2019. en pixels
De là est sorti le programme de surveillance de la volatilité des prix, que j’ai lancé et qui a fini par être repris à l’échelle mondiale du groupe. Trente milliards de changements de prix analysés, une anomalie repérée sur un milliard de visites. en pixels
Ensuite Unifai, où j’étais le premier ingénieur ML de la boîte. Pipeline MLOps de bout en bout sur GCP pour des groupes retail, et des modèles de langage d’avant ChatGPT, FLAN-T5 en zero-shot contre mon extracteur fine-tuné, sur des catalogues industriels réels : meilleur sur les booléens, pire sur les nombres. C’est ce travail qui a mis la boîte en position d’être rachetée : pendant la due diligence, j’ai détaillé l’architecture et l’infra ML aux investisseurs, jusqu’au rachat par Akeneo en 2023. en pixels
Puis deux ans et demi chez Akeneo comme Tech Lead de l’équipe Core AI. J’ai architecturé et exploité la plateforme d’inférence interne dont dépendaient toutes les équipes produit, et derrière elles des centaines de retailers enterprise. J’ai écrit la librairie qui fait passer ce trafic vers VertexAI, OpenAI et Anthropic par un proxy LiteLLM unique, avec le coût de chaque client tracé dans les en-têtes de réponse, et le volume de logs par requête a baissé de moitié à trois quarts. Et le Data Architect Agent, un système multi-agents avec gates humaines qui a fait passer l’onboarding catalogue d’un retailer enterprise de plusieurs mois à quelques jours. en pixels
De l’outil au harness
Chez Akeneo, j’ai poussé Cursor dans mon équipe, puis Claude Code dès sa sortie. J’ai donné des cours à plusieurs équipes, et des gens que j’avais convaincus ont ensuite convaincu les leurs à leur tour. J’ai aussi poussé la direction, très tôt et très fort, à payer des licences : au bout du compte, tout le monde a eu la sienne pour Claude Code. en pixels
Puis je suis passé de l’outil au harness : des CLAUDE.md versionnés dans le repo, pour que le harness de tout le monde s’améliore sans que chacun ait à s’en occuper de son côté. Mon setup a fini par servir de base à une formation interne.
Ce que je pense
Le premier succès arrête beaucoup d’équipes
Je n’ai encore jamais vu d’équipe où l’outil était le facteur limitant. On installe l’agent, il écrit quelques tests, ils passent, et ce premier succès convainc tout le monde que l’outil est pris en main. Ce jour-là il avait lu les bons fichiers ; le lendemain il passe par un autre chemin, un script, un grep, le shell, une partie des règles ne s’applique plus, et personne ne le voit. C’est en général là que ça se fige. Le même mécanisme joue dans l’autre sens : un premier essai raté suffit à convaincre qu’on a compris que ça ne marche pas.
Ce que je vise, c’est qu’une équipe délègue pour de bon, pas qu’elle fasse écrire des tests à l’agent une fois et s’arrête là. Le gain se prend en ambition, en attaquant des choses qu’on ne se serait pas autorisé à commencer avant. Anthropic décrit son usage interne dans ces termes, jusqu’à laisser Claude écrire une feature entière en boucle autonome à partir de maquettes Figma. Ça recoupe ce que j’observe, sans le démontrer, et je garde en tête qu’Anthropic vend l’outil, publie ses succès et consomme des tokens sans compter. Je n’ai aucun lien financier avec Anthropic, Codex ni Cursor, mon conseil vaut pour les trois.
Les harness se valent à peu près aujourd’hui
Ce n’est pas « l’outil ne compte pas », qui est faux, et qui sonne comme un vendeur en train de dévaluer ce que vous connaissez déjà pour valoriser ce qu’il pousse. C’est une observation datée sur l’état du marché : les harness ont convergé, donc l’écart s’est déplacé ailleurs, sur ce qu’on met dedans. Les CLAUDE.md, les hooks, les skills, la structure du repo, ce que l’agent peut vérifier tout seul avant de vous rendre la main.
Si un outil reprend une avance nette dans six mois, la phrase tombe et je le dirai.
Une réalisation vaut surtout par sa date
Décrire ce que j’ai construit ne vaut plus grand-chose en soi. La review automatique des PR par un agent, GitHub l’a banalisée depuis avril 2025 : une case à cocher dans un ruleset de branche. La présenter aujourd’hui comme une prouesse, c’est se présenter comme quelqu’un qui découvre le sujet.
Donc la partie de mon travail qui a le plus compté n’est pas l’outillage de review, que GitHub a banalisé depuis. Ce sont les CLAUDE.md versionnés à l’échelle d’une équipe entière. Ces fichiers existent partout, AGENTS.md est dans plus de 60 000 projets d’après agents.md, et ce qui est rare, c’est qu’ils tiennent dans le temps, comme le montre la note qui suit.
Fin août 2026 j’ai lu 269 repos publics fichier par fichier, pas par une recherche de code qui arrondit ses compteurs, pour savoir qui possède vraiment les fichiers qui pilotent les agents de code. Une seule organisation sur les 269 a automatisé la péremption des siens, avec un responsable nommé par fichier et un cron, sur son miroir interne, qui ouvre un ticket quand la date passe. Sept de ses entrées étaient déjà en retard le jour où j’ai regardé. Je dis ça de l’extérieur et sur des sources publiques, la liste n’est pas publiée et le chiffre date de fin août, donc si votre équipe fait mieux, écrivez-moi, ça m’intéresse davantage que l’inverse.
Ce qui disparaît est un métier, pas des gens
En septembre 2024 j’ai écrit dans un post court que « 80%+ of us » seraient obsolètes, « probably within 3 years ». Je me trompais sur un point : ce ne sont pas les développeurs qui disparaissent, c’est la partie de leur travail qui consiste à traduire une spécification claire en code. Le métier se déplace vers la spécification, la vérification et la décision, et la spécification elle-même monte de niveau quand on laisse l’agent chercher son contexte (Notion, Confluence, Jira, Slack) plutôt que de croire qu’on peut tout lui donner. Je ne crois pas à une niche « fait à la main » : celui qui achète un logiciel ne regarde pas comment il est fait, contrairement à un vase ou à un verre soufflé. La phrase tombe si les offres de développeurs sans IA rebondissent. Les chiffres que j’ai vus montrent plutôt un marché qui se ferme à l’entrée qu’une disparition.
On est devenus des relecteurs, et relire est une probabilité
Mon travail ressemble à celui d’un directeur qui vérifie ses seniors : orienté résultat, avec des tests que l’agent doit faire passer pour faire ses preuves. Je suis d’accord avec ce que dit Karpathy de l’orchestration d’agents. Relire minimise une probabilité d’erreur sans l’éradiquer, cinq relectures valent mieux que deux, jamais zéro erreur. Avec des tests robustes sur des parties isolées, certaines zones ne se relisent plus, sauf ce qui est dur à tester (les race conditions) ou critique. La phrase tombe si une mesure montre que du code jamais relu mais bien testé casse davantage en production.
Je teste tout, mon propre harness compris
Sur mon repo, un CLAUDE.md passé de 108 à 30 lignes a donné 22 cas sur 22 avant et après sur mon banc, et 2 sur 16 sans aucun fichier. Le banc est petit et son juge est une règle simple. Je le donne comme la preuve qu’on peut mesurer cela chez soi en une heure, pas comme un résultat général. La phrase tombe si une mesure indépendante montre qu’un fichier plus long tient mieux.
Ce sur quoi je travaille
J’ai travaillé avec des grands comptes, dont un groupe du CAC 40. En grand compte, ce qui bloque l’adoption des agents n’est presque jamais technique : c’est qui décide, sur quel critère, et à quel moment quelqu’un écrit la décision quelque part.
Je prends des interventions courtes, souvent à distance, chez des équipes qui veulent que leur harness serve vraiment. Un audit pour savoir si vos gardes tiennent quand l’agent change d’outil, une journée d’atelier dans votre repo dont le travail est commité le soir même, des office hours régulières pour rattraper ce qui dérive, ou un build quand ce qu’il vous faut est du code livré. L’audit est la porte d’entrée la plus simple.
J’écris aussi de temps en temps sur ce que je casse et ce que je répare en chemin.