🛠️ MCE 1.0 — Méthode de Context Engineering
📚 Méthode Context Engineering 1.0
Manifeste IDEO-Lab pour industrialiser le développement logiciel avec les LLM.
🧭 Context Engineering — Manifest & Méthodes
Formater des méthodes d’accès aux LLM : stabilité, traçabilité, reproductibilité.
🧪 MCE — La Méthodologie Officielle
Cycle en “C” : une pipeline rigoureuse en 4 étapes pour transformer le besoin en code via l’IA.
🧰 MCE Playbook — Context Engineering
Recettes, templates, check-lists et anti-patterns pour appliquer la méthode en équipe.
⚙️ MCE — Context Pack Generator
Générateur automatique de Context Packs : structure, sections, résumés, sources, tests.
🗂️ MCE — Session Logger
Session Logger & timeline structurée : décisions, prompts, sorties, validations, actions.
🧩 MCE — Mini-projets & Ateliers
Bibliothèque de mini-projets pour former les juniors au MCE : du besoin au code.
🧾 MCE — CDCF “LLM-Ready”
Le livrable de base : contexte structuré, contraintes, tests, APIs, data model, règles.
MCE 1.0 — Fondations
Le problème
Dans les projets réels (Python, Java, C++, microservices, data pipelines…), un LLM devient vite instable si le contexte est incomplet, contradictoire ou non versionné : prompts jetables, réponses non reproductibles, dettes cognitives, et “effet loto”.
Ce que MCE 1.0 apporte
Principes clés
- Context is Code : le contexte est un artefact versionné (Git) avec un format stable.
- Just-enough context : fournir le minimum utile (sinon bruit + dérive).
- Sources & preuves : tout fait non trivial doit pointer vers une source (docs, tickets, code, logs).
- Contraintes d’abord : non-fonctionnels (perf, sécurité, compat) guident la solution.
- Tests & garde-fous : critères d’acceptation, cas limites, scénarios d’erreur.
- Traçabilité : session logger et timeline, pour auditer et reproduire.
Anti-patterns fréquents
- “Prompt magique” sans architecture ni contraintes.
- Contexte trop long, non structuré → hallucinations et incohérences.
- Pas de “definition of done” ni tests → code fragile.
- Aucune trace des décisions → impossible de maintenir.
Pipeline MCE (Cycle en “C”)
| Étape | But | Sorties |
|---|---|---|
| 1) Clarify | Comprendre le besoin, les acteurs, la contrainte business | Problem statement, objectifs, non-objectifs |
| 2) Contextualize | Construire un contexte LLM-Ready (domain, API, data, règles) | Context Pack, glossary, sources, invariants |
| 3) Construct | Générer / adapter l’implémentation + tests | Code, tests, scripts, checklists |
| 4) Control | Valider, auditer, stabiliser (qualité, sécurité, perf) | Validation report, session log, corrections |
Exemple de “session” (résumé)
Session: MCE#2025-CE-042
Goal: Ajouter un moteur de règles de validation (Java) + tests JUnit
Constraints:
- Java 21, Spring Boot 3
- Latence < 20ms (p95) sur 1k req/s
- Interdit: dépendances lourdes / reflection
Inputs:
- Domain model, API contract, 12 règles, exemples
Outputs:
- RuleEngine + validators, tests, benchmarks, changelog
Control:
- checklist perf, SAST, couverture 85%, reviewLivrables MCE 1.0
- CDCF LLM-Ready (spec structurée)
- Context Pack (domain + contraintes + sources + tests)
- Playbook (templates, patterns, anti-patterns)
- Session Logger (timeline + décisions + prompts + sorties)
- Validation Pack (doD, checklists, acceptance tests)
Quand c’est utile ?
- Projets multi-équipes / multi-langages (Python + C++ + Java)
- Legacy et contraintes fortes (perf, safety, conformité)
- Refactorings critiques et migrations
- Industrialisation IA dans une orga (reproductibilité)
Manifest & Méthodes
Manifest (version IDEO-Lab)
- Un LLM sans contexte est un générateur de texte, pas un ingénieur.
- Le contexte doit être structuré, sinon il se dégrade au fil des itérations.
- La réussite se mesure : répétabilité, qualité, temps gagné, bugs évités.
- La méthode doit être transmissible (playbook), sinon elle ne scale pas.
Ce qui change dans les équipes
| Avant | Après (MCE) |
|---|---|
| Prompts jetables | Artifacts versionnés |
| Résultats variables | Process reproductible |
| “On verra” | Tests + DoD |
| Aucune trace | Session logger |
Méthodes d’accès au LLM
- Prompt contractuel : format d’entrée/sortie strict + contraintes.
- Chunking contrôlé : séparation Domain / API / Tests / Constraints.
- Grounding : sources autorisées + “no source → no claim”.
- Diff context : envoyer uniquement ce qui a changé.
Exemple (contrat de sortie)
Output must include:
- Files changed (list)
- Rationale (5 bullets max)
- Tests added/updated
- Edge cases handled
- Security notes
If any item is missing: return "BLOCKED" + missing itemsQualité, sécurité, performance
- Checklists (SAST, secrets, deps, lint, perf budgets)
- Benchmarks reproductibles (p95, p99, RAM/CPU)
- Tests : unit, integration, contract, regression
- Politique de conformité (PII, données, logs, RGPD)
Règle simple
La Méthodologie Officielle
Diagramme (texte)
Clarify ──► Contextualize ──► Construct ──► Control
▲ │
└─────────────── feedback loop ───────────┘Chaque étape produit des artefacts. Le cycle se répète tant que les critères de contrôle (tests, perf, sécurité, conformité) ne sont pas satisfaits.
Garde-fous
- Définir les non-objectifs explicitement
- Ajouter exemples réels (inputs/outputs)
- Verrouiller les contraintes (versions, libs, environnement)
- Bloquer si tests manquants ou contrat non respecté
MCE Playbook
Template — “Problem Statement”
Context:
- Business goal:
- Users / Actors:
- Scope:
- Non-goals:
Constraints:
- Tech stack:
- Perf budgets:
- Security rules:
Acceptance:
- Scenarios:
- Edge cases:
- Tests required:Template — “LLM Task Card”
Task:
- Objective (1 line)
- Inputs (links to sources)
- Output contract (strict)
- Forbidden actions
- Validation steps
- Rollback planChecklist Qualité (extrait)
- Le contexte cite les sources (docs / code / tickets)
- Le contrat de sortie est vérifiable
- Les tests couvrent happy path + erreurs
- Les contraintes perf/sécurité sont présentes
- La stratégie de rollback est décrite
Checklist Revue (extrait)
- Risques identifiés + mitigation
- Compatibilité versions / environnements
- Logs & observabilité (metrics)
- Documentation technique mise à jour
Anti-patterns
- “Fais-moi le projet complet” sans contraintes ni sources.
- Context pack énorme sans structure (bavard + incohérent).
- Pas de tests → code non livrable.
- Pas de trace (logger) → impossible à maintenir.
Remède
Context Pack Generator
Un Context Pack, c’est quoi ?
Un paquet structuré (fichiers ou sections) qui contient :
- Domain model + glossary
- API contract / interfaces
- Constraints (versions, NFR, security)
- Scenarios + edge cases
- Tests & validation plan
- Sources autorisées
Format suggéré (exemple)
context_pack/
00_summary.md
01_domain.md
02_api_contract.md
03_constraints.md
04_examples.md
05_tests.md
06_risks.md
07_changelog.md
sources/
links.md
excerpts.mdIdée clé : génération + déduplication
Le générateur produit des contextes cohérents à partir de sources (repo, docs, tickets, logs), et applique un modèle standard (sections + contrat). L’équipe gagne du temps et assure l’homogénéité.
Session Logger
Pourquoi logger ?
- Rejouer une session et obtenir les mêmes sorties
- Auditer décisions & sources
- Déboguer les dérives (context drift)
- Assurer la conformité (PII, sécurité, RGPD)
Structure conseillée
session.yml
- id, date, owner
- goal
- inputs (links)
- prompts (versions)
- outputs (files, diffs)
- validations (tests, perf)
- decisions
- next actionsMini-projets & Ateliers
Exemples d’ateliers (niveau croissant)
| Atelier | Objectif | Livrables |
|---|---|---|
| API Contract | Transformer un besoin en contrat API stable | OpenAPI + scénarios + erreurs |
| Rule Engine | Implémenter des règles avec tests | Code + tests + edge cases |
| Perf Budget | Tenir une latence cible | Bench + optimisations + rapport |
| Legacy Refactor | Refactoriser sans casser | Plan + tests + diff + rollback |
CDCF “LLM-Ready”
Sections recommandées
- Objectifs / non-objectifs
- Contexte métier + glossary
- Modèle de domaine (texte ou UML light)
- Contrats API / interfaces
- Contraintes (versions, perf, sécurité, conformité)
- Scénarios + cas d’erreur
- Critères d’acceptation + tests attendus
Mini-exemple (UML light)
Entities:
- User(id, email, role)
- Project(id, name, owner_id)
- ContextPack(id, project_id, version, status)
Relations:
User 1..n Project
Project 1..n ContextPack