Comment je travaille avec Claude Code.

Un outil, pas un pilote automatique

Claude Code est un assistant de programmation créé par Anthropic. On lui décrit en français ce que l'on veut ; il lit le code du projet, le modifie, lance les tests et vérifie le résultat. Je m'en sers pour ce site, pour l'application Mopao et pour Zala Mayele.

Mais il ne décide de rien à ma place. Il propose, j'accepte ou je refuse. Le design, le ton, ce qui part en ligne : tout cela reste mon travail. C'est la règle qui guide tout le reste de cet article.

Le 14 octobre 2026, le compte officiel de Claude a publié sur Instagram les cinq habitudes de Boris Cherny, l'ingénieur qui a créé l'outil. Elles rejoignent beaucoup de choses que j'ai apprises en pratique. Les voici, avec la façon dont je les applique, et la seule où je fais autrement.

Planifier, ou pas

Boris Cherny estime que les modèles récents n'ont plus besoin d'une étape de planification : on décrit ce que l'on veut, et l'outil s'y met.

Pour une retouche, je fais exactement cela. Déplacer un bouton, changer une couleur, corriger un texte : je le demande directement. C'est ma seule vraie différence avec lui : dès qu'un changement touche plusieurs parties d'un site, je demande d'abord une analyse et un plan, que je valide avant toute modification.

L'analyse a d'abord trouvé les causes, puis proposé quatre étapes, des plus sûres aux plus visibles. J'ai lancé chaque étape séparément, en vérifiant le résultat entre deux. Le score de performance mesuré par Google est passé de 56 à 86 en quelques jours, sans changer l'apparence du site.

Pourquoi j'y tiens : un plan, c'est le moment où l'on peut encore dire non. Corriger une idée coûte une phrase ; corriger du code déjà écrit sur dix fichiers coûte une journée.

Faire noter les erreurs /memory

Deuxième conseil : quand Claude se trompe, lui faire écrire la leçon dans un fichier de consignes. Ce fichier est relu au début de chaque conversation : la même erreur ne se reproduit pas. Dans Claude Code, la commande /memory ouvre justement ces fichiers.

Chaque projet a ainsi sa mémoire : mes préférences, les décisions prises, les pièges déjà rencontrés. Quelques règles réelles de la mienne :

• Valider une maquette avant d'écrire la moindre ligne de code.
• Vérifier à l'écran, sur un vrai téléphone, et pas seulement dans le code.
• Ne jamais mélanger deux projets dans une même modification.
• Ne rien enregistrer tant que les tests ne passent pas.

La meilleure version d'une leçon reste un test automatique. Un exemple : en faisant le ménage dans le code de ce site, une classe de style mal écrite a rendu l'en-tête impossible à cliquer. L'erreur a été corrigée, puis transformée en test, qui bloque désormais toute erreur du même type. Une règle écrite peut être oubliée ; un test, non.

Travailler en boucles /loop

Boris Cherny dit ne plus parler à un agent, mais à une boucle : une routine qui relance Claude pour lui, jusqu'à ce que le travail soit fait. C'est le rôle de la commande /loop, qui relance une même demande à intervalle régulier, par exemple pour surveiller une mise en ligne ou un test qui tourne longtemps.

Ma boucle à moi : les relecteurs

Je l'applique surtout à la vérification, avec un mécanisme différent : après chaque modification, Claude lance trois relecteurs indépendants, en parallèle. Chacun ne voit que le code et sa mission. L'un cherche les erreurs, un autre vérifie l'affichage et l'accessibilité, le troisième la qualité du code. Puis les corrections sont faites, les tests relancés, et alors seulement le travail est enregistré.

La page que vous lisez est passée par là. Les relecteurs ont trouvé, entre autres :

• un titre d'onglet qui restait celui de l'article après un retour à l'accueil ;
• un sommaire trop pâle : 3,7 pour 1 de contraste, quand le minimum recommandé pour ce texte est 4,5 ;
• une carte d'article qu'un lecteur d'écran annonçait en lisant plus de 300 caractères, au lieu de son seul titre.

Rien de spectaculaire, et c'est justement le point : ce sont des défauts qu'un œil pressé ne voit pas, et que personne ne signale, mais qui font la différence entre un travail correct et un travail soigné.

Donner peu de contexte /context

Quatrième conseil, contre-intuitif : donner à l'outil le moins de consignes possible, et le laisser chercher lui-même dans le projet. Son contexte est limité ; le remplir d'explications inutiles, c'est lui laisser moins de place pour réfléchir. La commande /context montre la place qu'il occupe, pour le garder léger.

Peu de contexte ne veut pas dire flou. Je dis précisément ce que je veux, rarement comment le faire. Je découpe le travail en tâches courtes, un projet à la fois, et chaque relecteur ne reçoit que ce dont il a besoin pour sa mission. Une demande claire de trois lignes donne souvent un meilleur résultat qu'un long cahier des charges.

Accepter d'avoir tort /rewind

« I'm actually wrong so often now. »

« Je me trompe tellement souvent maintenant », dit le créateur de Claude Code, qui explique devoir jeter une partie de ce qu'il a appris en des années d'ingénierie. Et quand une piste ne mène nulle part, la commande /rewind ramène le projet et la conversation à un point antérieur, comme si l'essai n'avait jamais eu lieu.

Je le vis aussi. Pour les mots encore éteints de l'accueil, j'avais validé un gris qui me semblait lisible. La mesure a montré qu'il ne l'était pas sur le bas de l'écran, où le ciel s'éclaircit : 2,9 pour 1 de contraste, sous le minimum de 3 pour un grand texte. Nous l'avons éclairci. Mon œil avait tort, la mesure avait raison.

L'important n'est pas d'avoir raison du premier coup, ni pour moi ni pour l'outil, mais de tout vérifier : sur un vrai navigateur, sur téléphone, avec des chiffres.

Par où commencer

Si vous voulez essayer, que vous soyez développeur ou simplement curieux, voici ce que je conseillerais, dans l'ordre :

1. Commencez par une petite tâche sur un projet sans enjeu : corriger un texte, ajouter une page simple.
2. Lisez ce que l'outil propose avant d'accepter, et demandez-lui d'expliquer ce que vous ne comprenez pas.
3. Créez votre fichier de consignes avec /memory dès la première erreur, et enrichissez-le à chaque leçon.
4. Pour tout changement important, demandez une analyse et un plan avant la moindre modification.
5. Vérifiez vous-même le résultat, sur un vrai écran. Et si une piste tourne mal, revenez en arrière avec /rewind plutôt que de corriger par-dessus.

Ce que cela change

Ces outils prennent en charge une grande partie du travail technique : écrire, tester, mesurer, relire. Le temps gagné, je le consacre à ce qui ne s'automatise pas : comprendre le besoin, soigner chaque détail du design et vérifier avant la mise en ligne.

L'intelligence artificielle accélère le travail. Elle ne remplace ni le goût, ni le jugement, ni la responsabilité de ce qui part en ligne. Ceux-là restent humains.

Questions fréquentes

Qu'est-ce que Claude Code ?

Claude Code est l'assistant de programmation d'Anthropic. On lui décrit en français ce que l'on veut ; il lit le code d'un projet, le modifie, lance les tests et vérifie le résultat, sous la direction d'une personne qui décide et valide.

Faut-il savoir programmer pour l'utiliser ?

Pas pour commencer : on lui parle en langage courant. Mais pour juger le résultat, il faut savoir vérifier : lire ce qu'il propose, demander des explications, tester sur un vrai appareil. Plus on comprend le code, mieux on le dirige.

Quelles commandes de Claude Code sont citées dans cet article ?

/memory pour les fichiers de consignes, /loop pour relancer une demande à intervalle régulier, /context pour voir la place occupée par le contexte et /rewind pour revenir à un point antérieur.

Un site créé avec l'aide de l'IA est-il moins soigné ?

Non, à condition de vérifier. L'IA prend en charge une partie du travail technique ; le design, les contenus et les choix restent humains. Chaque modification est relue par des relecteurs indépendants, testée et mesurée avant la mise en ligne.