Pourquoi l'IA n'écrit-elle pas du code comme vous ? (et comment le lui apprendre)

Vous utilisez Claude, mais vous avez souvent des retouches à faire pour qu'il respecte votre manière de faire. Les mêmes remarques reviennent en boucle à la review : « on ne nomme pas les types comme ça ici », « pas de valeur magique », « ce n'est pas notre façon de découper les composants ». Vous corrigez, vous re-promptez, et la semaine suivante, rebelote.

Les rules sont un mécanisme intégré à Claude pour limiter ces allers-retours. Dans cet article, on va voir ce qu'est une règle, à quoi ça sert et comment en écrire.

Article 1/3 de la série Wana-Rules

Temps de lecture : ~4 min

Sommaire

• Comment Claude décide-t-il d'écrire son code ?
• C'est quoi, une rule ?
• Où est-ce qu'on les met ?
• À quoi ça sert, concrètement ?
• Débunker quelques a priori

Comment Claude décide-t-il d'écrire son code ?

Sans consigne, Claude se base sur la moyenne d'internet. Le code est correct, standard, mais standard au sens de tout le monde, pas au sens de votre équipe. Il ne va pas forcément respecter vos règles ni celles de votre équipe. Parfois il respecte les conventions du fichier ouvert, mais sur un autre fichier du même type où vous faisiez autrement, il ne suivra pas. Et ce qui fait la qualité d'une codebase sur la durée, ce n'est pas seulement que chaque fichier soit bon : c'est que tous les fichiers se ressemblent.

La solution est d'ajouter des règles.

C'est quoi, une rule ?

Les rules sont des instructions que Claude charge dans la mémoire de sa session et qu'il utilise pour répondre à une problématique. Elles représentent vraiment votre savoir-faire en tant que développeur. Comme si vous formiez quelqu'un : « quand on fait ça, on a plutôt tendance à le faire comme ça ».

OK, mais à quoi ça ressemble ? Une règle, c'est une instruction claire, et Claude aime particulièrement le format DO / DON'T :

// ✅ DO
const elementWidthInCm = 29.7; // centimeters

// ❌ DON'T
const elementWidth = 29.7;

Ceci est une règle simple qu'on a dans l'équipe 2D/3D à Wanadev. On se doit d'être précis sur les unités. On a déjà eu un décalage de 12 pixels parce qu'on pensait travailler en pixels alors que notre PDF avait des pouces comme unité. Ce genre d'erreur devient une rule : elle est écrite une seule fois, au bon endroit, et l'IA la lit avant de générer la première ligne.

Une rule peut être une règle de nommage, des conventions internes, mais aussi être beaucoup plus globale, architecturale, comme les principes DRY (Don't Repeat Yourself) ou SOLID.

À Wanadev, on les utilise pour définir quelles langues utiliser et où, la façon de commenter, de nommer nos branches git, de tester, ce que doit contenir un controller, un helper, etc. C'est aussi, par exemple, un très bon outil pour transmettre les bonnes pratiques, comme ici sur les performances :

Debounce During Drag

Drag operations fire continuously (`mousemove` / `pointermove`). Debounce the expensive work they trigger — validation, recomputation, persistence — so it runs at a controlled rate instead of on every event.

// ❌ DON'T — run full validation on every drag event
onDrag(() => validateAll());

// ✅ DO — debounce the expensive work
const debouncedValidate = debounce(() => validateAll(), 50);
onDrag(() => debouncedValidate());

Nous avons déjà plus de 100 règles en interne, et ça augmente fréquemment. Notre priorité : les remarques qu'on avait tendance à remonter souvent en review ou qu'on abordait en réunion technique.

Où est-ce qu'on les met ?

Par défaut, Claude crée un CLAUDE.md, qui est déjà un petit résumé de comment votre projet fonctionne. Vous pouvez ajouter vos règles dedans. Mais dès que vous en avez plusieurs, Claude recommande de les mettre dans un sous-dossier rules/.

À Wanadev, on a organisé les nôtres par techno :

.claude/rules/
├── shared/      # javascript, git, nommage…
├── frontend/    # vue, tailwind, three.js…
└── backend/     # symfony, api…

Claude intègre de base un chargement intelligent des règles, avec une propriété nommée glob. Concrètement, Claude charge une règle selon le type de fichier sur lequel il travaille, ou l'endroit de l'arborescence où il se trouve. Deux exemples :

1. Nos règles Tailwind ne sont chargées que quand Claude travaille sur un fichier Vue. Si on est en train de faire de la 3D, il n'en a pas besoin.
2. Nos règles de comment créer des tests ne sont chargées que sur les fichiers *.spec.ts ou *.test.ts.

Ça permet une gestion plus intelligente de sa mémoire.

À quoi ça sert, concrètement ?

• Sortir de la moyenne d'internet. Le code adopte vos conventions dès la génération, pas après trois allers-retours.
• Harmoniser. Deux devs qui promptent Claude sur le même projet obtiennent du code cohérent entre eux, et cohérent avec l'existant.
• Arrêter de répéter les mêmes retours. Le dev ne corrige plus l'IA et le reviewer ne corrige plus le dev. La review se concentre sur le métier, pas sur la forme.
• Documenter les bonnes pratiques. C'est l'avantage qu'on voit le moins venir. Le format reste facilement lisible par un humain : un nouveau dev peut parcourir les rules pour comprendre comment on travaille, et de notre côté on s'y réfère souvent au cours de nos reviews. En bonus, Claude les utilise aussi pour ses reviews.

Débunker quelques a priori

Au cours du travail sur les rules, je me suis posé (et on m'a posé) souvent les mêmes questions. On va les parcourir.

1. « Ça fait beaucoup de tokens dès le début de la session »

C'est vrai qu'en début de session on augmente le nombre de tokens, mais le nombre reste assez petit et s'optimise avec les globs. Le gain se fait surtout à l'utilisation. Sans rules, la review relève les écarts et on corrige : le cosmétique se rattrape, mais une architecture non conforme se réécrit, on repart de zéro, soit deux fois le coût. Avec les rules, le code est conforme dès la première passe. Vous faites beaucoup moins d'allers-retours entre dev et Claude, puis entre reviewer et dev, et là on gagne beaucoup.

2. « J'utilise déjà eslint qui me fait ça »

Nous aussi ! En fait eslint est complémentaire. On a gardé (et même agrandi) nos règles de lint, car eslint est rapide, sans token et souvent autofixable. Cependant il y a beaucoup de règles d'architecture, un peu méta, qui ne sont pas ou très difficilement implémentables en eslint.

3. « J'ai peur que ça influence ses décisions »

Une rule ne change pas la façon dont le modèle raisonne, elle contraint la façon dont il écrit. Il résout le problème avec toute sa capacité, il le restitue juste dans votre style plutôt que dans le style moyen d'internet. Comme un dev senior qui rejoint une nouvelle équipe. Et surtout, c'est un système intégré à Claude, pas un hack qui marche un jour et casse le lendemain.

4. « J'utilise les skills pour créer des fichiers en suivant des règles précises »

Très bon réflexe, on en utilise aussi ! Mais le skill n'agit qu'à la création du fichier. Dès que vous (ou Claude) le modifiez ensuite, le skill n'est plus là. Les rules, elles, s'appliquent à chaque édition. En fait les deux se complètent : le skill construit vite, les rules garantissent que le fichier reste conforme les jours suivants. Et cerise sur le gâteau : le code généré par un skill respecte lui aussi vos rules.

La suite

Vous savez désormais ce qu'est une règle, à quoi ça sert et où les mettre. Reste une question : ces règles, il faut bien les écrire. D'où sortent-elles ? Comment passe-t-on de conventions implicites dans la tête des développeurs ou des leads à une library de plus de 100 règles versionnées, partagée entre tous les projets de la boîte ?

C'est le sujet des prochains articles : comment nous avons créé nos règles, et comment nous les gérons en multi-projet et multi-technos.