Comment on construit avec Claude — la méthode Domaine du Net

Quelqu'un m'a demandé la semaine dernière : « c'est qui, ton équipe ? ». J'ai répondu sincèrement : « Claude et moi ». La personne a souri, puis a réalisé que je ne plaisantais pas. Aujourd'hui, à travers les 42 repos que je maintiens activement dans la suite Domaine du Net, environ 70 à 80% du code passe d'abord par Claude avant d'arriver dans un commit. Et le résultat tient en production, parfois mieux que ce que je faisais seul.

Cette newsletter n'est pas un article promo pour Anthropic. C'est ce qu'on a appris à faire — et à ne pas faire — en 18 mois de travail quotidien avec un modèle de langage comme collaborateur principal. Si vous dirigez une boîte tech, ou si vous codez seul comme moi, cette méthode est probablement utile.

🎯 Le contrat — où Claude excelle, où on garde le contrôle

D'abord ce qui ne marche pas : lui demander de comprendre votre business à partir d'un prompt vague. Claude n'a pas de contexte projet par défaut. Si vous l'invoquez sans documentation, sans conventions, sans skills, vous obtenez du code générique de stack overflow déguisé en solution sur mesure.

Ce qui marche, en revanche :

• Implémentations de fonctionnalités à spec claire — fix de bug avec test de reproduction, ajout d'un endpoint REST, refactor d'un module bien isolé. Là, Claude est plus rigoureux que moi sur la moitié des points (gestion d'erreurs, tests, edge cases).
• Recherche dans une codebase — « où est définie cette fonction », « quelles sont les routes qui consomment cette API », « cherche les usages de ce flag ». Plus rapide que grep + cerveau.
• Documentation et conventions — rédaction de READMEs, schémas Zod, types TypeScript, commit messages. Sans réticence, sans ego.
• Migrations mécaniques — passer 50 fichiers d'un pattern à un autre, mettre à jour des imports après un rename. Ennuyeux pour un humain, parfait pour une IA.

Ce qu'on garde strictement humain :

• Décisions d'architecture qui engagent plusieurs trimestres (migration d'un produit vers un autre framework, choix d'une base de données, contrats d'API publique).
• Validation des PRs — Claude propose, je valide. Aucune merge automatique sur du code qui touche au business.
• Décisions produit — quoi construire, pour qui, dans quel ordre. Ça reste de la stratégie humaine, informée par les retours clients.

🛠 La méthode concrète

Le secret n'est pas dans le modèle — c'est dans l'infrastructure autour du modèle. Trois briques rendent ça opérationnel chez nous :

• Les skills Claude Code : des workflows packagés (/write-article, /process-issues, /site-audit, /security-review) hébergés dans un repo central platform/infra/ia/claude. Quand j'invoque /write-article, Claude lit le catalogue projet, applique le ton, télécharge l'image Pexels, ouvre la MR. La newsletter que vous êtes en train de lire est née comme ça.
• Les runners autonomes : un agent qui tourne sur mon iMac, écoute les issues GitLab labelées Type: Feature ou Type: Bug, dispatch la tâche à Claude Code en mode claude -p, qui crée la branche, code, push, ouvre la MR avec Closes #N. Je reviens 30 minutes plus tard, je regarde la preview Netlify, je commente, je merge ou je redispatche pour corrections.
• Le cockpit dashboard : un dashboard interne (infra.domainedunet.fr) qui pilote l'ensemble. Je vois en stream SSE ce que l'agent fait pendant qu'il bosse. Je peux dispatcher manuellement, suivre les pipelines, gérer les MRs et les commentaires. Claude exécute, je pilote.

L'ensemble est versionné, testé, documenté. Quand un workflow casse, je débug le skill — pas le modèle. Quand un nouveau besoin émerge (par exemple : déclinaisons sociales d'un article web), j'ajoute une skill, et tous les futurs articles bénéficient du nouveau workflow.

📊 Ce que ça donne en pratique

En chiffres bruts : 42 repos actifs répartis sur une dizaine de lignes produits, environ 70-80% du code passé par Claude avant commit. Côté qualité, ce qui change vraiment c'est que les tests sont écrits systématiquement (alors que je les zappais souvent quand je tapais tout à la main) et que les revues humaines — les miennes, comme propriétaire des MRs — sont plus exigeantes maintenant que je ne suis plus dans le « j'ai écrit ça à 3h du matin, ça doit marcher ».

En qualitatif : je travaille sur des projets que je n'aurais jamais lancés seul. Une plateforme événementielle gratuite (Runify), un agent IA support multi-canal, un éditeur de publications souverain, un dashboard infra unifié, des applis sportives multi-marques (Fairway, Livesports), un tracker GPS qui ne décroche jamais, une infrastructure Pulse, Analytics, IAM, DevOps qui les fait tenir debout. Ça serait une équipe d'une dizaine d'ingénieurs en stack classique. Ici c'est moi, Claude, et des skills.

Ce n'est pas une méthode magique. C'est une méthode disciplinée : écrire les conventions, isoler les workflows, garder l'humain sur les choix stratégiques, accepter que Claude propose mieux que vous sur certains points et apprendre à dire oui quand il a raison.

Et pour vous ?

Si vous codez seul ou en très petite équipe, vous avez probablement plus à gagner que les grosses structures à passer à ce mode de travail. Le manifeste IA détaille la philosophie — c'est court, c'est franc, et ça pose les bonnes questions avant les bonnes réponses.

À très vite, Julien