Cadrer son LLM développeur — discipline et bonnes pratiques

Le constat — pourquoi cadrer un LLM développeur

Sur du code trivial, un assistant LLM fait gagner du temps sans cadrage particulier. Sur du code sérieux, les choses se gâtent vite : la fonction simple devient une classe abstraite avec injection de dépendance, le bug d'une ligne entraîne un refactor de trois fichiers adjacents "tant qu'on y est", la consigne floue ("fais que ça marche") génère une cascade de features qui n'avaient pas été demandées.

Ce n'est pas un défaut isolé d'un modèle. C'est une propriété structurelle des LLM actuels : leur entraînement les pousse à produire du contenu "professionnel d'apparence" — c'est-à-dire dense, structuré, avec garde-fous, donc potentiellement sur-conçu. Sans cadre explicite, l'assistant glisse vers cet attracteur.

Fin janvier 2026, Andrej Karpathy (ex-OpenAI, ex-Tesla AI) a partagé publiquement son passage d'un usage à 80 % manuel à 80 % agent-driven dans Claude Code, en nommant quatre types d'erreurs récurrentes qu'il devait corriger. Un développeur indépendant a transformé ces observations en un fichier CLAUDE.md de quelques dizaines de lignes — adopté massivement (plus de 150 000 stars cumulés sur les mirrors GitHub courants en quelques mois). Les quatre principes ci-dessous en sont la formulation appliquée.

Ils ne sont pas spécifiques à Claude Code : ils s'appliquent à n'importe quel agent de codage (Cursor, Copilot, Codex, Aider, Gemini Code Assist, Mistral Codestral).

Principe 1 — Réfléchir avant de coder

Avant d'implémenter, l'assistant doit : - expliciter ses hypothèses ("je suppose que tu veux X parce que Y") ; - présenter les interprétations possibles quand c'est ambigu, plutôt que choisir silencieusement ; - proposer une approche plus simple s'il en existe une, même si l'utilisateur n'a rien demandé ; - s'arrêter et nommer ce qui n'est pas clair plutôt que produire du code à l'aveugle.

Principe 2 — Simplicité d'abord

Concrètement : - aucune feature au-delà de ce qui a été demandé ; - aucune abstraction pour du code à usage unique ; - aucune "flexibilité" ou "configurabilité" non demandée ; - aucune gestion d'erreur pour des cas impossibles ; - si 200 lignes peuvent en faire 50, réécrire.

Principe 3 — Modifications chirurgicales

Quand l'assistant modifie du code existant : - ne pas "améliorer" le code adjacent, les commentaires, le formatage ; - ne pas refactorer ce qui n'est pas cassé ; - respecter le style existant, même si le LLM ferait différemment ; - s'il remarque du code mort sans rapport, le mentionner — ne pas le supprimer.

Quand les modifs créent des orphelins : - supprimer uniquement les imports/variables/fonctions que ses propres changements ont rendus inutilisés ; - ne pas supprimer du code mort préexistant sans demande explicite.

Principe 4 — Exécution dirigée par les critères de succès

Transformer chaque tâche en objectif vérifiable : - "Ajouter de la validation" → "Écrire des tests pour les entrées invalides, puis les faire passer". - "Corriger le bug" → "Écrire un test qui reproduit le bug, puis le faire passer". - "Refactorer X" → "S'assurer que les tests passent avant et après".

Pour les tâches multi-étapes, énoncer un plan court avec vérification par étape : `` 1. [Étape] → vérifier : [check] 2. [Étape] → vérifier : [check] 3. [Étape] → vérifier : [check] ``

Comment appliquer concrètement

Ces principes sont des règles de comportement. Pour qu'elles soient respectées en pratique, il faut qu'elles soient dans le system prompt à chaque session, pas affichées dans un README.

Sur Claude Code (CLI ou GitHub Action) - Créer ~/.claude/CLAUDE.md pour appliquer les règles globalement à tous tes projets. - Créer ./CLAUDE.md à la racine d'un projet spécifique pour ajouter ses contraintes propres (stack, conventions, contraintes de déploiement). - Le fichier est lu automatiquement à chaque session.

Sur Cursor / Continue.dev (IDE) - Settings → Rules / Custom Instructions : coller les principes. - Possibilité d'avoir des règles par projet ou globales.

Sur ChatGPT (Custom GPT "Développeur" ou Projet Code) - Créer un Custom GPT ou un Projet → Instructions : coller les principes. - Limite : les Custom Instructions de compte ne s'appliquent pas dans tous les contextes (API, partages). Pour un usage sérieux, privilégier un Projet dédié.

Sur API directe (Anthropic, OpenAI, Mistral) - Encoder les principes dans le paramètre system de chaque appel. - Compléter par un middleware côté serveur qui détecte les violations manifestes (diff trop large, ajout d'imports non demandés) et déclenche une re-prompt automatique.

La règle pratique : un assistant code sans cadre est un assistant qui produit du bruit. Cinq lignes de règles bien placées valent mieux que cinq cents lignes de revue de code après coup.

Comment ces principes croisent PromptSecOps

Les principes Karpathy traitent la discipline d'écriture d'un LLM développeur. PromptSecOps traite la sécurité des productions LLM (jailbreaks, fuite de données, injection, supply chain). Les deux se complètent — l'un sans l'autre laisse un angle mort.

Dans la bibliothèque PromptSecOps, plusieurs fiches sont des cousines directes de cette discipline :

• PS-0027 (Revue de code orientée sécurité) — la passe d'audit que l'assistant doit faire sur sa propre production.
• PS-0051 (Validation des entrées dans le code généré) — l'application disciplinée du principe de validation côté entrée.
• PS-0075 (Architecture Decision Record automatique) — la trace écrite des décisions, indispensable pour cadrer un LLM agissant en autonomie sur la durée.
• PS-0086 (Anti-typosquatting des dépendances IA-générées) — sécurité supply chain quand l'assistant invente un nom de package.

L'usage canonique : partir d'un `CLAUDE.md` projet intégrant les 4 principes (cadrage de production) + ajouter les fiches PS-0027 / PS-0051 / PS-0075 au moment du code review (cadrage de sécurité). Les deux couches forment ensemble une discipline opérationnelle complète.

Sources et lectures recommandées

Repo de référence (CLAUDE.md adopté massivement) - multica-ai/andrej-karpathy-skills — fichier CLAUDE.md formalisant les 4 principes (~150k stars cumulés sur les mirrors).

Standards émergents pour cadrer un agent code - agents.md — convention émergente pour décrire le contrat comportemental d'un agent IA dans un repo (analogue à README.md pour les humains). - Le pattern CLAUDE.md / AGENTS.md / CURSOR.md se généralise : un seul fichier par convention, lu automatiquement par l'agent au démarrage.

Pour aller plus loin sur la discipline LLM - Karpathy a publié plusieurs threads X et notes courtes sur l'évolution de sa pratique ("vibe coding", "context engineering"). Chercher ses interventions publiques sur le sujet pour le contexte original. - Le concept de "context engineering" (par opposition à "prompt engineering") s'impose progressivement comme cadre de réflexion adapté aux agents autonomes : ce n'est plus le prompt unique qui compte, mais l'ensemble du contexte que l'agent voit à chaque étape — y compris les règles comportementales du fichier CLAUDE.md.

Bonnes pratiques complémentaires côté sécurité - Consulter les fiches PromptSecOps PS-0027, PS-0051, PS-0075, PS-0086 et les guides code-review + agent-developpement de la bibliothèque pour la couche sécurité qui complète cette discipline.