EN

À propos

Theo Martin, portrait

9 ans à mettre du MLMachine learning : des programmes qui apprennent une règle à partir d’exemples plutôt que de la recevoir écrite à la main. puis des LLMLarge language model : un modèle entraîné sur d’énormes volumes de texte pour prédire la suite d’un texte. Claude, GPT et Gemini en sont. 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 >100Md tokensLes morceaux de texte, de quelques lettres chacun, que le modèle lit et écrit. C’est l’unité dans laquelle on paie un modèle., et j’interviens dans les équipes qui veulent en tirer davantage : développeurs, product managers, designers.

Le parcours

Le même parcours, en pixels

J’ai commencé chez Amazon, au Luxembourg : 3,5 ans sur le pricing européen. J’y suis entré par l’optimisation de supply chainLa chaîne logistique : achats, stocks, entrepôts et livraisons. puis par l’architecture AWS, avec 4 certifications AWS passées en 4 mois, dont la Solutions Architect ProfessionalLa certification AWS de plus haut niveau pour concevoir des architectures cloud.. en pixels

Ensuite le pricing, comme seul data scientist d’une équipe passée de 3 à 13 personnes. De l’inférence causaleMesurer l’effet réel d’une décision (une baisse de prix, par exemple) en le séparant de tout ce qui a changé en même temps., avec du contrôle synthétiqueUne méthode qui fabrique un « jumeau » de ce qu’on a modifié à partir d’un mélange d’éléments non modifiés, puis compare les deux. codé à la main avant que les librairies soient mûres, des modèles bayésiens hiérarchiquesDes modèles statistiques qui partagent l’information entre groupes proches : un produit avec peu de ventes emprunte ce qu’on sait de sa catégorie. d’élasticité prixDe combien les ventes bougent quand le prix bouge de 1%., et des prix hédoniquesExpliquer un prix par la valeur de chaque caractéristique du produit : taille, marque, mémoire, etc. estimés sur des embeddingsUne suite de nombres qui représente un texte ou une image, construite pour que deux choses proches aient des nombres proches. texte et image, avec du ELMoUn modèle de langage de 2018, l’un des premiers à représenter un mot selon la phrase où il se trouve. puis du BERTLe modèle de langage publié par Google fin 2018, la base de la plupart des systèmes de traitement de texte jusqu’à l’arrivée des LLM. fine-tunéRé-entraîné un peu plus sur ses propres données, pour spécialiser un modèle déjà entraîné. 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. 30Md changements de prix analysés, une anomalie repérée sur 1Md visites. en pixels

Ensuite Unifai, où j’étais le premier ingénieur ML de la boîte. Pipeline MLOpsTout ce qui fait tourner un modèle en production : collecte des données, entraînement, déploiement, surveillance. de bout en bout sur GCPGoogle Cloud Platform, le cloud de Google. pour des groupes retail, et des modèles de langage d’avant ChatGPT, FLAN-T5Un modèle de langage ouvert de Google, sorti fin 2022. en zero-shotUtiliser un modèle sur une tâche sans lui en avoir montré un seul exemple. 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 diligenceL’audit qu’un acheteur fait d’une entreprise avant de la racheter., j’ai détaillé l’architecture et l’infra ML aux investisseurs, jusqu’au rachat par Akeneo en 2023. en pixels

Puis 2,5 ans chez Akeneo comme Tech Lead de l’équipe Core AI. J’ai architecturé et exploité la plateforme d’inférenceLe service qui reçoit les demandes des autres équipes et les envoie aux modèles, avec la gestion des quotas, des erreurs et des coûts. interne dont dépendaient toutes les équipes produit, et derrière elles >100 retailers enterprise. J’ai écrit la librairie qui fait passer ce trafic vers VertexAI, OpenAI et Anthropic par un proxy LiteLLMUn serveur intermédiaire open source qui expose une seule interface pour appeler tous les fournisseurs de modèles. unique, avec le coût de chaque client tracé dans les en-têtes de réponseLes métadonnées renvoyées avec chaque réponse d’un serveur, à côté du contenu lui-même., et le volume de logs par requête a baissé de 50 à 75%. Et le Data Architect Agent, un système multi-agentsPlusieurs agents qui se répartissent une tâche, chacun avec son rôle, et se passent le relais. avec gates humainesDes étapes où le système s’arrête et attend qu’un humain valide avant de continuer. 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. 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 harnessTout ce qu’on met autour du modèle pour en faire un agent : consignes, outils, vérifications, permissions. : des CLAUDE.mdLe fichier d’instructions que Claude Code lit au démarrage dans un projet. L’équivalent ouvert s’appelle AGENTS.md. versionnés dans le repoLe dossier qui contient le code d’un projet et tout son historique de modifications, géré avec git., 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

Positions revues le 6 octobre 2026.

Le premier succès arrête beaucoup d’équipes, le premier échec aussi

Je n’ai encore jamais vu d’équipe où l’outil était le facteur limitant. Souvent l’équipe installe l’agent, le voit réussir une tâche et se dit « ok, ça il sait faire », ou le voit rater et s’arrête là. Dans les deux cas elle croit avoir trouvé les limites de l’agent, alors qu’elle a eu de la chance, ou pas.

Du code qui ne compile pas, on sait que c’est le code. Avec un agent, on distingue mal la limite de notre usage de la limite de l’outil, d’autant que le résultat dépend du contexte qu’on lui donne. Quand un dev d’une autre boîte dit avoir codé la même fonction, on sait que c’est faisable et que le problème est chez nous. Quand il dit que son agent le fait, on se dit que ça dépend de son setup.

Ce que je vise, c’est une équipe qui délègue pour de bon. Chez moi, l’agent écrit des features entières en boucle autonomeL’agent enchaîne seul code, tests et corrections jusqu’à ce que le résultat passe, sans attendre un humain à chaque étape. à partir de maquettes Figma, laisse ses questions en commentaire dans Notion, et reprend le travail dès qu’un PM a répondu.

Les modèles et les harness convergent

La tête de la course change de main en quelques jours. Depuis janvier 2025, Claude a eu le meilleur modèle 55 % du temps, GPT 45 %. En septembre 2026, Fable 5.1, GPT-6 Astra puis Opus 5.5 sont passés devant tour à tour sur Terminal-BenchUn banc public qui mesure si un agent arrive à finir de vraies tâches dans un terminal., en trois semaines. Un saut en avant se fait rattraper en quelques semaines, c’est pour ça qu’on parle de modèles frontièreLes quelques modèles les plus avancés du moment, chez OpenAI, Anthropic et Google, qui se tiennent de près.. Les harness suivent la même pente.

Claude et GPT depuis 2025Oct 2026

Scores publiés à la sortie : SWE-bench Verified en 2025, de Claude 3.7 Sonnet (63,7 %) à Claude Opus 4.5 (80,9 %) ; Terminal-Bench 2.0 début 2026, jusqu’à GPT-5.5 (82,7 %) ; Terminal-Bench 2.1 de mai à juillet, Claude Mythos 5 (88,0 %) passe devant GPT-5.5, puis GPT-5.6 Sol (88,8 %) ; Terminal-Bench 4.0 depuis juillet 2026, de Claude Opus 5 (52,3 %) à Claude Sonnet 5.5 (70,6 %), GPT-6 Astra (57,9 %) passant devant Claude Fable 5.1 (55,8 %) deux jours après lui.

Ce qui a toujours compté, c’est le contexte : ce que l’agent sait de votre code, de vos règles, et ce qu’il peut vérifier seul. Une fois le contexte en place, ça vaut le coup d’essayer d’autres harness et d’autres modèles. Par exemple faire relire le code d’un modèle par un concurrent : GPT et Opus n’ont a priori pas été entraînés sur les mêmes données, l’écart entre eux est bien plus grand qu’entre Opus et Sonnet, qui sortent de la même maison.

Le modèle mental vaut plus que la stack

Ce qui marche aujourd’hui sera remplacé. J’ai construit mon propre système de review automatique des PRPull request : une proposition de modification du code, qu’un membre de l’équipe relit avant de l’intégrer., puis je suis passé à celle de Copilot quand elle est arrivée. Un nouveau modèle n’a plus besoin de certaines consignes qu’il fallait écrire pour le précédent. Ce qui reste, c’est une bonne idée de ce qu’est un LLM, et la capacité à s’adapter.

J’ai lu 269 repos publics fichier par fichier, et ça recoupe ce que je vois dans les équipes que j’accompagne : très peu automatisent la péremption des fichiers qui pilotent leurs agents.

Ce qui disparaît est un métier, pas des gens

En septembre 2024 j’écrivais que « 80%+ of us » seraient obsolètes, « probably within 3 years ». Je me trompais sur un point : ce n’est pas le dev qui disparaît, c’est la partie du travail qui traduit une spec claire en code. Prendre un ticket et livrer une PR, ce bout du cycle est déjà remplacé. C’est le travail qu’on confie aux juniors, d’où l’idée qu’ils partent en premier.

Et ça remonte la chaîne. Un PM prend en entrée les retours clients et le marché, et sort des specs. L’IA aide déjà à écrire la spec et à trier les retours, et couvre petit à petit un bout de plus. Là où la chaîne est continue, l’agent la tient seul. Là où elle casse, on met un humain.

Ce que l’IA sait faire seuleFévr 2026

Les tâches du cycle produit, de la complétion de lignes de code aux retours clients, passent une à une de l’humain à l’IA entre janvier 2021 et février 2026 Produit Code Vérifier et livrer Aligner l’équipe Rédiger la spec Découper en tickets Lire les retours clients Écrire une feature Écrire des fichiers entiers Compléter des fonctions Compléter des lignes Écrire les tests Faire passer les tests Relire la PR Mettre en prod
un humain, l’IA.

Le métier se déplace vers la spec, la vérification et la décision. Les chiffres que j’ai vus montrent un marché qui se ferme à l’entrée plutôt qu’une disparition.

Je ne crois pas à une niche « fait main » pour le code. Celui qui achète un vase en verre soufflé à la main paie pour la façon dont il a été fait, celui qui achète un logiciel ne regarde que ce qu’il fait. L’amour du métier pour lui-même a sauvé certains artisans, malheureusement il ne sauvera pas les codeurs.

On est encore des relecteurs, et relire ne garantit rien

Je bosse comme un directeur qui vérifie ses seniors : orienté résultat, avec des tests que l’agent doit faire passer. Relire réduit la probabilité d’erreur sans l’éradiquer : 3 relectures valent mieux qu’une.

Avec des tests robustes sur des parties isolées, il est envisageable, croyez-moi, de ne pas relire certaines zones. Et cette zone peut être une feature entière, voire tout un logiciel.

40 tickets, 3 façons de les livrer

Les mêmes 40 tickets, tous avec des tests. Un dev qui code avec l’IA sans contexte : 6 bugs en prod, 64 h humaines. Claude Code avec le contexte du repo et une relecture humaine : 1 bug, 21 h. Tests relus par un humain, Copilot en aller-retour, relecture humaine du seul code critique : 0 bug, 12 h.
1 h pour coder une PR avec l’IA, 30 min par relecture, 10 min pour relire les tests.

Ici, sans le contexte du repo, l’IA écrit deux fois plus de bugs, et le dev passe ses journées à la piloter. Avec le contexte, l’agent code seul. Dans ce que je mets en place, l’humain relit les tests plutôt que le code, et ne relit le code que là où il est critique.

Le reste se relit encore : ce qui ne se teste pas automatiquement, les tests trop longs ou trop coûteux, et ce qui est critique, comme les race conditionsDes bugs qui n’apparaissent que quand 2 opérations se croisent dans un certain ordre, donc rares et durs à reproduire.. L’IA se trompe encore un peu, et tout l’enjeu est de savoir où. Mais j’en suis convaincu, bientôt l’IA pourra tout faire, relecture comprise.

Tout ce qui se teste, je le teste

Mon propre harness compris. J’ai un bancUne série fixe d’épreuves que l’agent doit réussir, rejouée à chaque changement pour comparer avant et après. de 22 épreuves que je relance de temps en temps, et je vérifie régulièrement qu’elles passent encore. Pour réduire un CLAUDE.md, j’enlève tout, je regarde ce qui passe encore, puis je remets les règles une par une. La dernière fois, le fichier est passé de 108 à 30 lignes et toutes les épreuves passent toujours.

Réduire un CLAUDE.mdÉtape 1 · Le fichier de départ

108 lignes au départ. Sans aucune règle, une partie des épreuves échoue. Chaque règle remise en fait repasser quelques-unes, et à 30 lignes toutes passent.

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.

Voir l’offre

J’écris aussi de temps en temps sur ce que je casse et ce que je répare en chemin.

Lire les écrits


Basé à Paris, fuseau européen, avec un recouvrement avec la côte est des États-Unis jusqu’à 17 h, heure de New York. À distance partout, sur site dans toute la France. [email protected], LinkedIn, GitHub.