canonical_url: https://yycode.net/docs/fr/recommended-global-rules
lang: fr
updated_at: 2026-07-04T13:33:48.616Z
source_html: https://yycode.net/docs/fr/recommended-global-rules

# Règles globales AGENTS.md personnelles

> Voici un ensemble de règles globales Claude code et codex que j'ai consolidées pour mon usage personnel. Placées à la racine d'un projet dans `AGENTS.md` ou `CLAUDE.md`, elles constituent une base très pratique pour les débutants.

---

## Philosophie : Spec progressive

Le cœur de ces règles est la **Spec progressive (Progressive Specification)** : les besoins de complexités différentes suivent des processus de profondeur différente, afin d'éviter la surconception pour les tâches simples tout en imposant suffisamment de contraintes aux tâches complexes.

En bref : **la complexité accidentelle doit être comprimée autant que possible ; seule la complexité essentielle mérite d'être gérée avec soin.**

---

## Vue d'ensemble du processus de codage

| Taille du besoin | Processus |
|---------|------|
| Simple (modifier un champ, corriger un bug) | Exécution directe, pas de Spec nécessaire |
| Moyen (3+ étapes, décisions d'architecture) | Spec légère, puis codage après confirmation HARD-GATE |
| Complexe (multi-modules, multi-systèmes) | Propose → Apply → Review complet |

Règles fondamentales :
- **No Spec, No Code** — pour les besoins moyens ou plus complexes, pas de code sans Spec
- **HARD-GATE** — une fois la Spec écrite, attendre la confirmation explicite de l'utilisateur avant de coder
- **Reverse Sync** — si un écart apparaît pendant l'exécution, corriger d'abord la Spec, puis le code

La liberté de chaque phase est explicite : la recherche peut explorer librement, la conception peut imaginer largement, mais **la liberté d'exécution est nulle**. Il faut suivre strictement le plan et s'arrêter immédiatement pour demander en cas d'écart.

---

## À propos des comportements des différentes IA

Ces règles fonctionnent très bien avec **Codex** : il suit généralement le processus de façon stricte et reste stable lorsque les contraintes sont claires.

**Claude** a davantage ses propres « idées » : il peut parfois faire des choses supplémentaires sans instruction explicite, ou interpréter les règles à sa façon. Sa flexibilité d'exécution est plus élevée que prévu. Il est globalement moins « obéissant » que Codex, mais il s'exprime mieux sur les tâches créatives et la conception de solutions.

> Les deux ont leurs forces et faiblesses ; les combiner selon le type de tâche donne de meilleurs résultats.

---

## Texte complet des règles (copiable en une fois)

```
# Langue

- La langue par défaut pour dialoguer avec moi est le chinois.

# Attention

Par défaut, ne créez aucun nouveau document explicatif ni fichier de documentation.
Ne générez pas automatiquement de README.md, document de conception, guide d'utilisation, note d'architecture, etc.
Ne créez ou modifiez de la documentation que lorsque je demande explicitement « rédiger de la documentation / générer un README / écrire un document explicatif ».

# Normes de code

- Le code doit comporter des commentaires chinois clairs ; toutes les fonctions et logiques clés doivent être commentées.

---

# Workflow Orchestration

## 1. Spec progressive : complexité à la demande

Les besoins de complexité différente suivent des processus de profondeur différente ; la complexité accidentelle doit être comprimée autant que possible :

| Taille du besoin | Processus |
|---------|------|
| Simple (modifier un champ, corriger un bug) | Exécuter directement, sans Spec |
| Moyen (3+ étapes, décisions d'architecture) | Écrire une Spec légère, puis coder après HARD-GATE |
| Complexe (multi-modules, multi-systèmes) | Propose → Apply → Review complet |

**Trois lois de la Spec** (déclenchées uniquement pour les besoins moyens et plus complexes) :
1. **No Spec, No Code** — sans Spec, il est interdit d'écrire du code
2. **Spec is Truth** — si la Spec et le code se contredisent, c'est toujours le code qui a tort
3. **Reverse Sync** — si un écart apparaît pendant l'exécution, corriger d'abord la Spec, puis le code

**HARD-GATE** : une fois la Spec complète générée, attendre la confirmation explicite de l'utilisateur avant de commencer à coder. Toute modification de code est interdite avant confirmation.

**La recherche doit citer ses sources** : lorsqu'on décrit l'état du code, chaque conclusion doit indiquer le chemin de fichier + le nom de fonction. Les suppositions du type « en général » ou sans preuve ne sont pas acceptées.

**Confirmation segmentée de la Spec** : ne pas générer toute la Spec d'un coup. Sortir par sections (analyse de l'état actuel → fonctionnalités → risques et décisions), puis attendre la confirmation utilisateur avant de continuer. Plus l'écart de direction est détecté tôt, moins il coûte à corriger.

## 2. Plan Node Default

- Pour toute tâche de complexité moyenne ou supérieure, entrer en plan mode
- En cas de problème, s'arrêter immédiatement et replanifier ; ne pas forcer l'avancement
- Le plan mode s'applique aussi à la vérification, pas seulement à la construction

## 3. Subagent Strategy

- Utiliser largement les subagents pour garder le contexte principal propre
- Confier la recherche, l'exploration et l'analyse parallèle aux subagents
- Investir davantage de calcul via subagents pour les problèmes complexes
- Chaque subagent ne fait qu'une seule chose et s'y concentre

## 4. Courbe de liberté d'exécution

| Phase | Liberté | Principe |
|------|--------|------|
| Recherche | Moyenne | Explorer librement, mais les conclusions doivent citer le code |
| Conception de solution | Élevée | Imaginer pleinement, proposer des options et recommander |
| Planification | Faible | Préciser les chemins de fichiers et signatures de fonctions |
| Exécution | Zéro | Suivre strictement le plan ; en cas d'écart, s'arrêter et demander |
| Validation | Moyenne | Vérifier librement, avec conclusions fondées |

## 5. Self-Improvement Loop

- Après chaque correction de l'utilisateur : consigner le schéma dans `tasks/lessons.md`
- Écrire des règles pour éviter que les mêmes erreurs se reproduisent
- Au début de chaque session, relire les règles pertinentes dans lessons
- Pour les pièges utiles et découvertes de domaine, proposer activement de les capitaliser dans la base de connaissances du projet

## 6. Règles strictes de vérification

- Une tâche non vérifiée ne doit pas être marquée comme terminée
- Fournir des preuves vérifiables (sortie de compilation / résultats de tests / journaux d'exécution)
- Interdire les déclarations sans preuve comme « ça devrait aller »
- Comparer si nécessaire le comportement avant et après modification

## 7. Demand Elegance (avec mesure)

- Pour les changements non simples, s'arrêter et demander : « Existe-t-il une manière plus élégante ? »
- Si la solution semble hacky : « maintenant que l'on sait cela, implémenter une solution élégante »
- Pour les corrections simples et évidentes, agir directement sans surconcevoir

## 8. Autonomous Bug Fixing

- Quand un bug est signalé, le corriger sans attendre des instructions pas à pas
- S'appuyer sur les journaux, erreurs et tests échoués, puis résoudre
- Ne pas obliger l'utilisateur à changer de contexte
- Si les tests CI échouent, les corriger activement

---

# Task Management

1. **Écrire d'abord le plan** : écrire le plan dans `tasks/todo.md` avec des cases à cocher
2. **Exécuter après confirmation** : pour les tâches moyennes ou plus complexes, commencer l'implémentation seulement après HARD-GATE
3. **Suivre la progression** : marquer immédiatement chaque élément terminé
4. **Expliquer les changements** : fournir une explication de haut niveau à chaque étape
5. **Consigner les résultats** : ajouter une section review à la fin de `tasks/todo.md`
6. **Capitaliser les leçons** : mettre à jour `tasks/lessons.md` après correction utilisateur

---

# Core Principles

- **Simplicity First** : chaque changement doit rester aussi simple que possible. Minimiser la portée d'impact.
- **No Laziness** : chercher la cause racine, ne pas poser de rustine, appliquer un standard de senior developer.
- **Minimal Impact** : ne modifier que le code nécessaire pour éviter d'introduire de nouveaux problèmes.
- **Séparation des intentions** : traiter une seule intention à la fois ; ne pas mélanger exploration, décision, exécution et revue.
```