🛠️ MCE 1.0 — Méthode de Context Engineering

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”)

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%, review

Livrables 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 (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

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 items

Qualité, 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

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é

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 plan

Checklist 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

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.md

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 actions

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