Série d'apprentissage de l'IA · Leçon 3 sur 4
Chaque nouvelle session d'IA démarre sans aucune mémoire de votre dépôt. Si les conventions ne vivent que dans la tête de quelqu'un — ou dans un document que personne ne relit — le modèle les enfreint sans bruit, et l'infraction ressemble à du code qui marche, jusqu'au jour où il ne marche plus.
Statut : plan. La démonstration à l'écran n'a pas encore été enregistrée — cet article est le plan qu'elle suivra, et il recevra la vraie démonstration une fois la leçon diffusée.
| Leçon | Sujet | Question traitée |
|---|---|---|
| 1 — L'usage des modèles | Niveau de modèle, contexte, tokens | De quel modèle cette tâche a-t-elle besoin ? |
| 2 — Prompt, projet et contexte | Structure du prompt, contexte permanent | Que place-t-on devant le modèle ? |
| 3 — Documentation, règles et skills | Structure du dépôt | Comment un dépôt reste-t-il cohérent d'une session à l'autre ? |
| 4 — Réduire le coût | Mesure, leviers, garde-fous | Comment dépenser moins sans perdre en qualité ? |
Ce que vous saurez faire
- Donner à un dépôt trois choses distinctes : une documentation navigable, des règles à suivre et des skills réutilisables
- Ranger n'importe quelle consigne dans la bonne des trois couches
- Transformer une règle écrite en vérification qui échoue quand la règle est enfreinte
S'appuie sur les leçons 1 et 2 : le contexte permanent de la leçon 2 était un seul bloc d'instructions. Cette leçon le découpe en couches aux rôles distincts, pour que chaque session ne charge que ce dont elle a besoin — l'idée de coût du contexte de la leçon 1, appliquée à l'échelle du dépôt.
Hors périmètre : mesurer ou réduire les dépenses (leçon 4) et construire une application complète. Ce qui est construit à l'écran est volontairement petit — le sujet, c'est la structure qui l'entoure.
Les trois couches
| Couche | Contient | Chargée | Symptôme quand elle manque |
|---|---|---|---|
| Documentation | Des faits — ce qui existe et comment ça marche | Quand c'est pertinent | L'assistant redécouvre le système, lentement et de façon incohérente |
| Règles | Contraintes toujours vraies et interdits, avec le pourquoi | À chaque session | Les conventions dérivent, une nouvelle session après l'autre |
| Skills | Procédures répétables pour des tâches précises | À la demande (selon l'outil) | La même procédure est recollée dans chaque prompt |
Documentation — trouvable, un responsable par fait
- Un index, un fait clairement attribué par sujet et une table d'impact des changements
- La documentation reste trouvable et ne devient pas obsolète en silence quand ce qu'elle décrit change
Règles — courtes, toujours chargées, justifiées
- Le fichier toujours chargé énonce les interdits — et cite le pourquoi, pas seulement le quoi
- Tout ce qui est plus long va dans un document lié, pas dans le fichier que chaque session paie pour charger
Skills — des procédures chargées seulement au besoin
- Un skill est une procédure réutilisable que l'assistant charge quand une tâche précise et répétable se présente
- Le dépôt de l'exemple pratique n'a pas encore de répertoire de skills au niveau du projet : le skill est donc construit en direct — pas préparé pour la démo
L'exemple pratique
La leçon s'appuie sur un vrai dépôt utilisé au quotidien, pas sur un jouet construit pour l'occasion. Cinq motifs, chacun avec un rôle distinct :
Fichier d'entrée — lu en premier
- Un fichier dit ce qu'est le projet, ce qu'il faut faire et ce qu'il ne faut pas faire — avant tout le reste
- Quand plusieurs agents d'IA travaillent dans le dépôt, il est dupliqué au point d'entrée attendu par chaque agent, pour qu'aucun ne lise une copie périmée ou partielle
Règle garantie par un test — plus forte que la prose
- Une règle vérifiée par un test vaut mieux qu'une règle qui vit dans un paragraphe que l'on peut sauter
- Ce blog le fait pour les traductions : la catégorie et la date doivent rester identiques octet pour octet d'une langue à l'autre, et
npm run check:translationséchoue si ce n'est pas le cas
File de décisions — autorisé avant de commencer
- Le travail est écrit et approuvé avant de commencer
- Aucun agent ne déduit le périmètre d'un message de chat vague
Index d'impact des changements — « si vous modifiez X… »
- Une table qui indique quels documents deviennent obsolètes quand un fichier donné change
- Le lien se consulte, au lieu d'être redécouvert après une casse
Définition de « terminé » — selon le type de changement
- Ce qui compte comme vérifié dépend du type de changement
- Une modification de documentation n'exige pas la même preuve qu'une migration de schéma
▶ show code▼ hide code
# Rules File — Skeleton
## What this project is
One paragraph. Link to README for everything else.
## Never
- Edit generated or vendored directories (why: overwritten on update)
- Commit secrets or expose them via public env vars (why: shipped to the browser)
- Mark work done without the check for its change type (why: see Definition of Done)
## Where things live
- Architecture → docs/ARCHITECTURE.md
- Change impact → docs/CHANGE_IMPACT.md
- Definition of done → docs/DONE.md
À l'écran
- D'abord, l'échec — une nouvelle session fait un changement qui viole une convention que personne n'a écrite là où le modèle pouvait la trouver
- Structure documentaire — index, un responsable par fait, table d'impact des changements
- Règles — ce qui va dans le fichier toujours chargé et ce qui va dans un document lié
- Application — une règle écrite devient un test, cassé exprès, puis réparé
- Un skill, construit en direct — pour une tâche qui se répète vraiment, puis comparé au travail sans lui
- Exercice de tri — de vraies consignes rangées en documentation, règles ou skills, dont une rangée au mauvais endroit exprès puis corrigée
Dans quelle couche ça va ?
▶ show code▼ hide code
# Sorting Guidance
Is it a fact about how the system works? → Documentation
Is it always true, and does breaking it hurt? → Rules (with the why)
Is it a procedure you repeat for a specific task? → Skill
Can a test check it? → Also write the test
Vérifiez avant de vous y fier
- Que chaque fichier et chemin de l'exemple pratique existe toujours et dit toujours ce qui est affirmé — les dépôts dérivent, et cette leçon s'appuie sur de vrais chemins
- Comment l'outil présenté nomme un fichier de règles et un skill, où chacun se trouve et comment chacun est chargé
- Si les skills se chargent à la demande ou en permanence dans cet outil — le segment de skills en direct en dépend
- Si la recommandation de taille du fichier de règles correspond toujours aux conseils actuels du fournisseur
- Que le skill construit en direct est réellement réutilisé ensuite, et pas un accessoire de démo
Questions fréquentes
« Je ne peux pas tout mettre dans le fichier de règles ? » Vous pouvez, et chaque session le paie. Les longs fichiers de règles sont survolés par les humains et dilués pour les modèles. Gardez les règles courtes ; liez le reste.
« Comment savoir qu'une règle est vraiment respectée ? » Écrivez une vérification qui échoue quand elle ne l'est pas. Une règle sans vérification est une suggestion.
« Quand un prompt devient-il un skill ? » La troisième fois que vous collez la même procédure. Enregistrez-la une fois et chargez-la quand la tâche se présente.
Ensuite : leçon 4
La leçon 4 vient en dernier, exprès. Elle utilise tout ce qu'enseignent les trois premières — choix du modèle, qualité du prompt et du contexte, structure du dépôt — comme leviers pour réduire ce que coûte un flux de travail IA.