Ce que vous écrivez autour de vos agents ne compte que si l’agent le suit vraiment
Un hook qui surveille Edit et Write ne voit pas passer un sed -i, une règle qui interdit de lire .env n’empêche pas un cat .env. Je regarde si vos gardes portent sur ce qu’elles doivent empêcher ou seulement sur l’outil, et même l’éditeur s’y reprend à plusieurs fois : Anthropic a corrigé puis annulé deux fois sa propre règle sur .env entre les versions 2.1.259 et 2.1.273.
Fin août j’ai lu 269 repos publics fichier par fichier pour savoir qui possède les fichiers qui pilotent leurs agents. Chez PostHog, 112 lignes de CODEOWNERS, et aucune ne couvre les 255 fichiers de skills.
Ce que je vends, c’est un agent à qui votre équipe délègue pour de bon, avec des fichiers qui tiennent dans le temps, et quand ce qu’il vous faut est du code livré plutôt qu’un avis, je le livre.
Ce que je fais
Neuf ans de ML et de systèmes LLM en production, dont trois ans et demi chez Amazon sur le pricing européen. Ensuite Tech Lead de l’équipe Core AI d’Akeneo, un SaaS B2B, où la plateforme d’inférence que j’ai architecturée servait toutes les équipes produit et, derrière elles, des centaines de retailers enterprise et des dizaines de millions d’attributs produit générés chaque mois.
C’est là que j’ai poussé les agents de code dans mon équipe dès leur sortie, puis que j’ai fait la bascule de l’outil vers le harness, avec des CLAUDE.md tenus dans le repo et revus comme du code. C’est cette partie-là que je vends.
En ce moment je suis en mission dans un groupe du CAC 40, sous NDA, ce qui me met un vrai repo d’entreprise sous les yeux tous les jours.
Le NDA fait que je ne parle ni du client, ni de son secteur, ni de sa stack. La méthode se raconte entièrement, les artefacts non, et je préfère le dire avant l’appel plutôt que pendant.
À quoi ressemble le travail
Ce qui s’écrit pendant une mission, ce sont des règles tenues dans le repo et revues comme du code. Le CLAUDE.md de ce site en est un, lisible en entier sur GitHub, en voici un extrait :
## Modifier le build
`build.py` tient en 300 lignes et se lit de haut en bas. Il n'a qu'une dépendance externe, `markdown`. Entre une astuce élégante et trois lignes évidentes, écrire les trois lignes. Un ajout qui ferait dépasser le budget de lignes est le signe qu'il faut retirer autre chose, pas augmenter le budget.
Un marqueur laissé non substitué dans une page produite fait échouer le build. Inventer un marqueur dans un gabarit sans l'alimenter dans `build.py` casse donc le déploiement, ce qui est le comportement voulu.Quatre formats
Si vous cherchez une formation Claude Code au catalogue, deux jours en salle sur un projet d’exemple, ce n’est pas ce que je vends, et j’ai relevé les prix publics de ceux qui le font dans un article à part. J’arrive dans votre repo, sur vos tickets, et ce qui s’écrit pendant la journée y reste, le déroulé est sur la page de la formation.
Audit du setup agentique
1 500 € HT par jour, forfait de deux à quatre jours
Je regarde ce qui est écrit pour l’agent dans votre repo, ce qui s’applique encore quand il change d’outil, ce qui bloque un merge et où part la facture. Vous repartez avec un playbook écrit et un plan à 90 jours, exécutable sans moi.
Atelier intra sur votre repo
2 500 € HT par jour, facturé au jour et jamais par tête
Une journée sur votre propre code et vos vrais tickets, avec vos développeurs aux claviers plutôt que moi.
Office hours
300 €/h HT, ou 1 400 € HT par mois pour quatre sessions
Une heure avec vos leads sur le problème du moment, écran partagé, y compris en fin de journée.
Build d’un système d’agents
7 500 € HT la semaine, deux semaines minimum
Quand ce qu’il vous faut n’est pas un avis mais du code livré, un agent branché dans votre produit, un socle d’évaluation qui dit si les réponses sont bonnes, un RAG qui tient la charge, une plateforme d’inférence qui ne tombe pas. Je code, vos développeurs relisent le code et les CLAUDE.md qui pilotent l’agent, tout vit dans votre repo.