Ajouter un nouveau chapitre
Context Engineering
Le contexte n’est pas « plus il y en a, mieux c’est », mais « contrôlable, vérifiable et réutilisable ». L’objectif est d’obtenir une sortie stable avec un contexte minimal.
Modèle de contexte à trois couches
Contexte statique
Règles, contraintes, normes d’architecture (stables et immuables)
- Conventions du projet (lint/contraintes)
- Contrat d’interface (OpenAPI)
- Frontières de sécurité et modèle d’autorisations
Contexte de l’espace de travail
Fichiers et extraits de code fortement liés à la tâche actuelle
- Chemins de fichiers associés
- Fragment minimal nécessaire (diff/fonction)
- Étapes de reproduction et journaux
Contexte dynamique
États et mémoire qui changent avec le temps (doivent être contrôlables)
- Résultats de recherche (RAG)
- Décisions récentes et raisons
- Conclusions provisoires et hypothèses à vérifier
Liste de contrôle pratique (exécution par défaut recommandée)
- D’abord fournir à l’IA : objectif + situation actuelle + contraintes + format de sortie
- Regrouper explicitement les « documents de référence » : règles/code/journaux/données
- Limiter le contexte : ne fournir que les 3 à 8 fichiers les plus pertinents (ou des extraits clés)
- Exiger que les points incertains soient marqués [à confirmer], afin d’éviter d’inventer
- Laisser une trace à chaque itération : modifications + preuves (tests/journaux/captures d’écran)