Si Claude Code élargit trop souvent vos modifications, utilisez CLAUDE.md pour préciser le périmètre, demander un plan, limiter les changements au strict nécessaire et exiger une vérification honnête. Ces consignes orientent le travail, mais ne garantissent pas leur respect et ne remplacent pas les permissions ni la revue de code.
Cet article s’adresse aux développeurs qui utilisent Claude Code et veulent contenir les modifications non sollicitées. Il s’adresse aussi aux responsables techniques qui définissent des règles communes et aux équipes qui souhaitent adapter les idées associées à Andrej Karpathy Skills à leur propre dépôt.
Comprendre ce que CLAUDE.md peut réellement imposer
CLAUDE.md sert à transmettre des instructions de projet à Claude Code : conventions de travail, contexte utile et attentes propres au dépôt. La documentation officielle présente ces fichiers comme un mécanisme de mémoire et d’instructions, et décrit comment Claude Code les utilise dans son fonctionnement. Cela peut rendre les réponses plus cohérentes avec votre projet, à condition que les consignes soient visibles, précises et pertinentes. Cela ne transforme toutefois pas une instruction écrite en contrôle technique infaillible. Consultez la documentation officielle sur la mémoire et les fichiers CLAUDE.md.
Cette distinction est importante lorsque vous cherchez à réduire les modifications intempestives du code par l’IA. Une consigne comme « ne modifiez pas les fichiers de configuration » exprime une règle de travail. Elle n’est pas équivalente à une autorisation système qui rendrait ces fichiers inaccessibles. Si le respect du périmètre doit être techniquement contrôlé, examinez les mécanismes de permissions décrits dans la documentation officielle sur les permissions. Pour les actions que vous souhaitez faire contrôler par un mécanisme automatisé, la documentation officielle sur les hooks explique un autre dispositif, distinct des instructions en langage naturel.
Vous devez donc envisager CLAUDE.md comme un moyen de clarifier la tâche, pas comme un verrou. Une demande peut rester ambiguë, une règle peut entrer en conflit avec une autre et un plan peut omettre une contrainte. Le modèle peut également proposer ou effectuer des changements qui nécessitent une vérification humaine. La conséquence pratique est simple : utilisez les consignes pour réduire les écarts, puis contrôlez les fichiers modifiés et les résultats.
Andrej Karpathy Skills et les règles de projet
Le titre associe Andrej Karpathy Skills à une méthode d’encadrement, mais les quatre règles présentées ici ne sont ni une citation attribuée à Andrej Karpathy ni une norme officielle de Claude. Pour vérifier la provenance des éléments associés à ce nom, distinguez la publication originale d’Andrej Karpathy du dépôt public portant le nom Andrej Karpathy Skills. Un dépôt qui reprend un nom ou diffuse des idées attribuées à une personne ne suffit pas, à lui seul, à établir que chaque règle est une citation directe ou une méthode officielle de cette personne.
De même, CLAUDE.md et les Skills ne sont pas interchangeables. La documentation officielle décrit les Skills de Claude Code comme un mécanisme distinct des fichiers de mémoire. En pratique, vous devez vérifier les instructions et mécanismes réellement utilisés dans votre environnement, au lieu de supposer qu’un terme recouvre l’autre.
Pour exploiter ces idées sans brouiller les responsabilités, écrivez vos règles en fonction de votre codebase. Les consignes doivent parler des répertoires, des pratiques de revue et des vérifications réellement utilisées par votre équipe. Les bonnes pratiques officielles de Claude Code peuvent compléter ce travail, mais elles ne remplacent pas la validation de vos propres conventions.
Définir un périmètre avant de lancer la tâche
La première source de dérive est souvent une demande qui décrit le résultat attendu sans dire ce qui peut être touché. « Corrigez l’affichage » peut inciter l’outil à remanier un composant, ses styles, des paramètres ou des fichiers connexes. Une consigne de périmètre sépare l’objectif du travail autorisé.
Votre règle doit préciser les fichiers ou répertoires permis, signaler ce qui est hors périmètre et établir une conduite à suivre si un autre changement semble nécessaire. Évitez les formulations vagues comme « ne modifiez pas trop de fichiers » : elles ne donnent pas de critère à appliquer.
Comment demander à Claude Code de ne modifier que les fichiers prévus ? Nommez les fichiers ou zones autorisés, puis demandez une confirmation si le travail semble nécessiter un changement supplémentaire. Ce cadrage réduit les initiatives non souhaitées ; il ne garantit pas techniquement que l’outil ne touchera jamais un autre fichier.
Exemple à adapter à votre dépôt :
## Périmètre des modifications
- Travaillez uniquement dans les fichiers explicitement indiqués dans la demande.
- Ne lancez pas de refonte, de renommage ou de mise à jour de dépendance sans rapport avec l’objectif.
- Si un autre fichier semble nécessaire, expliquez pourquoi et demandez confirmation avant de le modifier.
Cette règle reste exploitable parce qu’elle prévoit le cas difficile : un problème connexe découvert pendant le travail. Sans cette clause, l’outil peut interpréter une correction souhaitable comme une autorisation implicite d’élargir la tâche.
Exiger un plan avant tout changement
La deuxième règle intervient avant la première modification. Demandez à Claude Code de reformuler l’objectif, d’indiquer les emplacements envisagés et de préciser comment il compte vérifier le résultat. Vous pouvez alors repérer une compréhension erronée ou un fichier inattendu avant qu’un diff soit produit.
Quelles règles inscrire dans CLAUDE.md pour réduire les modifications intempestives ? Demandez un périmètre explicite, un plan préalable, des changements minimaux et un compte rendu de vérification. Le plan aide à faire apparaître les suppositions ; il ne prouve pas que l’exécution sera correcte.
Exemple de règle :
## Avant de modifier le code
- Reformulez l’objectif en une phrase.
- Indiquez les fichiers concernés, les changements prévus et les vérifications adaptées au projet.
- Si le périmètre ou une modification supplémentaire est incertain, arrêtez-vous et demandez confirmation.
- Ne présentez pas un plan comme une preuve de réussite.
Supposons que vous demandiez d’ajuster un état vide dans une interface. Avant d’éditer, Claude Code devrait annoncer l’écran concerné, le composant envisagé et la manière de contrôler le rendu selon les possibilités de votre projet. Si le plan inclut une refonte des styles globaux ou une modification d’un autre parcours, vous pouvez demander pourquoi ces changements sont indispensables, puis confirmer ou réduire le périmètre.
Le point de contrôle est un moment de décision, pas une formalité. Si votre équipe ne veut pas d’étape d’approbation pour chaque demande, faites au moins exiger un arrêt lorsque le périmètre est flou ou que le plan sort des fichiers autorisés.
Maintenir un diff minimal et compréhensible
La troisième règle limite les changements à ce qui est nécessaire pour répondre à la demande. Elle évite qu’une correction locale devienne une occasion de changer l’architecture, d’adopter une autre dépendance ou de reformater des fichiers voisins selon une préférence personnelle.
CLAUDE.md peut-il empêcher une modification sans confirmation ? Il peut demander à Claude Code de s’arrêter avant une extension du périmètre, mais ce texte n’est pas un mécanisme de permission. Pour une restriction technique, vérifiez les permissions de l’environnement et les règles applicables à votre dépôt ; relisez ensuite le diff avant d’accepter les changements.
| Approche | Ce que vous demandez | Quand la choisir | Limite à surveiller |
|---|---|---|---|
| Consigne générale | Respecter le style du projet et éviter les changements sans rapport | Pour rappeler des habitudes communes | Le périmètre reste sujet à interprétation |
| Liste de fichiers | Modifier uniquement les fichiers nommés, demander confirmation pour le reste | Pour une tâche locale ou facilement délimitée | Un fichier indispensable peut être oublié |
| Plan avec approbation | Exposer les fichiers et changements prévus avant de commencer | Quand une extension de tâche doit être examinée | Un plan accepté n’est pas une validation du résultat |
| Permissions ou contrôle complémentaire | Restreindre les actions au moyen des mécanismes prévus à cet effet | Quand une limite doit être appliquée techniquement | Les règles doivent être configurées et vérifiées dans l’environnement |
Utilisez ce tableau comme outil de choix, non comme promesse de sécurité. Une demande confinée à un fichier n’a pas forcément besoin du même niveau de contrôle qu’une tâche dont les conséquences touchent des paramètres ou des données sensibles.
Comment repérer un changement de trop ? Comparez la liste des fichiers modifiés au périmètre annoncé, puis inspectez le diff. Demandez-vous si chaque modification contribue directement au résultat demandé. Un fichier simplement « nettoyé », une dépendance remplacée par préférence ou un changement de format sans rapport doit être expliqué avant d’être conservé.
Vous pouvez ajouter une consigne concrète :
## Taille des changements
- Modifiez uniquement ce qui est nécessaire pour satisfaire la demande.
- Respectez les conventions et l’architecture déjà présentes.
- N’ajoutez pas de dépendance et ne réorganisez pas du code sans nécessité liée à la tâche.
- Dans le compte rendu, signalez tout écart par rapport au plan et expliquez-le.
Le principe du diff minimal ne doit pas devenir un prétexte pour laisser un défaut nécessaire en place. Si une correction exige de toucher une seconde zone, demandez une justification claire et, lorsque le périmètre prévu l’impose, une confirmation.
Un diff compact n’est pas automatiquement un bon diff : vérifiez que la correction traite le besoin, qu’elle n’omet pas un cas pertinent et que chaque fichier modifié a une raison identifiable.
Demander une vérification et un compte rendu vérifiables
La quatrième règle exige une validation adaptée au projet et un rapport fidèle. N’inscrivez pas dans CLAUDE.md une commande de test choisie au hasard. Les outils disponibles et les scripts varient d’un dépôt à l’autre ; indiquez plutôt que Claude Code doit s’appuyer sur les vérifications documentées ou déjà utilisées par l’équipe.
Comment demander à Claude Code de vérifier ses changements ? Demandez-lui d’identifier les contrôles pertinents du projet, d’exécuter ceux qui sont adaptés et de préciser ce qui n’a pas été exécuté, avec la raison. Un compte rendu doit distinguer une vérification lancée, une vérification réussie et une vérification impossible ou non pertinente.
Exemple :
## Vérification après modification
- Repérez les contrôles documentés ou déjà utilisés dans le projet qui correspondent aux changements.
- Exécutez les vérifications adaptées et rapportez leur résultat réel.
- Indiquez les contrôles non exécutés et la raison.
- Ne déclarez jamais une vérification réussie si elle n’a pas été lancée ou si son résultat est inconnu.
Cette formulation évite deux mauvaises habitudes : annoncer que « tout passe » sans preuve et imposer une commande qui ne correspond pas au projet. Elle vous aide aussi à distinguer une limite de l’environnement d’un défaut du code. Si une vérification visuelle est pertinente pour un changement d’interface, demandez ce qui a effectivement été observé, sans confondre une inspection du code avec une validation du rendu.
Tester les règles sur une tâche limitée
Pour savoir si vos consignes diminuent réellement les changements non souhaités, ne commencez pas par une tâche vaste ou ambiguë. Choisissez un correctif dont le résultat attendu et la zone concernée sont faciles à reconnaître, puis comparez ce que Claude Code avait annoncé à ce qu’il a effectivement modifié.
Voici un déroulement reproductible :
- Sélectionnez une demande étroite. Choisissez un défaut local que vous pouvez décrire sans demander une refonte.
- Vérifiez les instructions existantes. Recherchez les règles vagues, redondantes ou contradictoires, notamment celles qui encouragent à la fois l’autonomie et l’arrêt en cas d’incertitude.
- Demandez une reformulation et un plan. Examinez les emplacements envisagés avant d’autoriser les changements.
- Contrôlez les fichiers et le diff. Comparez les modifications réelles avec les fichiers autorisés, l’objectif et le plan.
- Examinez la vérification et le compte rendu. Confirmez que les contrôles annoncés ont bien été exécutés et que leurs résultats sont rapportés sans extrapolation.
- Ajustez la consigne à partir de l’écart observé. Remplacez « gardez les changements limités » par une règle indiquant précisément quand s’arrêter et demander confirmation.
Cette démarche ne nécessite pas d’attribuer un score artificiel au comportement. Notez plutôt les écarts concrets : fichier ajouté sans justification, plan qui omet une dépendance réelle, refactorisation inutile, vérification annoncée mais non lancée. Vous pouvez ensuite préciser CLAUDE.md et refaire l’essai sur une tâche comparable.
Avant de généraliser la règle à l’équipe, vérifiez qu’elle n’empêche pas une correction nécessaire et qu’elle reste compatible avec le fonctionnement du dépôt. Une consigne trop restrictive peut provoquer des arrêts inutiles ; une consigne trop permissive réintroduit les dérives. La revue humaine et le contrôle de version restent essentiels, et les restrictions techniques doivent être traitées par les mécanismes adaptés plutôt que par le seul texte d’instructions.
Si vous devez tester Claude Code dans un environnement macOS temporaire, séparez cette décision de la configuration de CLAUDE.md : louer une machine ne rend pas les instructions plus fiables. Un Mac que vous possédez convient mieux à un usage régulier et stable ; une location peut être plus commode pour un besoin ponctuel, tandis qu’une machine locale existante ou un autre environnement de développement peut suffire si votre travail ne dépend pas de macOS. Pour comparer les options disponibles, consultez les offres de location Mac de Kvmkit et, si un Mac mini dans cette région répond à votre besoin, la page consacrée à la location de Mac mini à Singapour.
Commencez par relire votre fichier CLAUDE.md avec ces critères, puis éprouvez les règles sur une tâche limitée avant de les diffuser. Si le diff déborde, si le plan change en cours de route ou si le rapport de vérification manque de précision, améliorez la consigne correspondante ; ne confiez pas à ce fichier le rôle d’une revue de code, du contrôle de version ou d’une barrière de permissions.