🧠 MCE Playbook – Context Engineering en pratique

Diagramme très simple du Kick-off MCE

Métier  ──► Atelier Kick-off ──► Chef de projet MCE
                           │
                           ├─► CDCF v0.1 (brouillon)
                           ├─► Liste d'acteurs & cas d’usage
                           └─► Risques & non-objectifs

Étape suivante :
    ▸ transformation du brouillon en CDCF v1.0
    ▸ début de l’Analyse Fonctionnelle
                

Extrait de CDCF – “Gestion de tickets support”

# 1. Contexte & objectifs
Contexte :
    Plateforme SaaS B2B gérant les tickets de support client.
Objectif :
    Centraliser les demandes et suivre leur résolution.
KPI :
    - 80% des tickets résolus < 48h
    - Satisfaction > 4/5

# 4. Cas d’usage (extrait)
CU-01 : Créer un ticket
    Acteur : Client connecté
    Déclencheur : l’utilisateur a un problème ou une question
    Résultat attendu : ticket créé avec ID unique
    Critères :
        - champ "sujet" obligatoire
        - priorité par défaut = "normale"

CU-02 : Répondre à un ticket
    Acteur : Agent support
    Critères :
        - historique visible
        - temps de réponse horodaté
                

Conseils MCE pour un bon CDCF

• Écrire pour un humain + un LLM : phrases simples, pas de jargon inutile.
• Séparer clairement “in” et “out” du périmètre.
• Préciser les critères d’acceptation (utilisés ensuite pour les tests AI + QA).
• Maintenir le CDCF dans un format diff-friendly (Markdown, reST…).

Exemple – Application de todo

Scénario S1 : "Ajouter une tâche"
Pré-conditions :
    - l’utilisateur est connecté
Étapes :
    1. L’utilisateur saisit le titre + description.
    2. Il clique sur "Ajouter".
    3. Le système enregistre la tâche avec le statut "TODO".
Résultat :
    - la tâche apparaît en haut de la liste.

Scénario S2 : "Marquer comme terminé"
    1. L’utilisateur clique sur la case "Terminé".
    2. Le système passe le statut à "DONE".
                

Diagramme textuel (style Mermaid)

sequenceDiagram
    actor User
    participant Frontend
    participant API
    participant DB

    User->>Frontend: Créer une tâche
    Frontend->>API: POST /tasks {title, desc}
    API->>DB: INSERT task (status="TODO")
    DB-->>API: OK (id=42)
    API-->>Frontend: 201 Created (id=42)
    Frontend-->>User: Tâche affichée dans la liste
                

Exemple condensé pour un projet Django IDEO-Lab

stack:
  language: python
  framework: django 5
  database: postgresql 16
  cache: redis
  runtime: docker + gunicorn + nginx

architecture:
  pattern: "Django apps par domaine"
  apps:
    - accounts
    - context_engineering
    - analyzer
    - dba_tuning

testing:
  framework: pytest
  coverage_min: 80
  tools:
    - pytest-django
    - factory-boy

observability:
  logs_format: json
  tracing: opentelemetry (optionnel)
  metrics: prometheus
                

Check rapide avant d’envoyer ce contexte à un LLM

• Les versions sont-elles précises (ex: django 5.1 plutôt que “Django”)?
• Les contraintes de tests et de logs sont-elles explicites ?
• La liste des données sensibles est-elle définie ?
• Les patterns archi souhaités sont-ils indiqués (hexagonal, CQRS, Clean Architecture) ?

Mini Context Pack – “Todo API Django”

Résumé :
API REST pour gérer des tâches partagées entre membres d’une petite équipe.

Objectif de la session :
Générer le pseudo-code et les modèles Django pour la V1.

Contexte métier (condensé) :
- 5 à 20 utilisateurs par équipe
- tâches simples (titre, desc, statut, assignée à)
- pas de sous-tâches pour la V1

Contexte technique :
- Django 5 + DRF
- Postgres
- Authentification par token simple (JWT)

Format attendu :
- models.py (Task, Team, Membership)
- serializers.py
- esquisse de tests pytest

Non-objectifs :
- pas de UI HTML
- pas de notifications push
                

Tips pour des packs efficaces

• Penser “compact” : un pack doit tenir dans quelques milliers de tokens max.
• Mettre en avant les contraintes importantes (sécurité, perfs, business).
• Éviter les documents copiés/collés en bloc sans tri.
• Versionner les packs (`pack_v1`, `pack_v2`…) et documenter les changements.

Recipe – Générer code + tests

Rôle IA :
    "Tu es un développeur [langage] expérimenté, rigoureux et pédagogue."

Contexte :
    - Design technique validé (ci-dessous)
    - Extrait du Context Pack (stack, contraintes, style)

Tâche :
    "À partir du design ci-dessous, génère :
        - le fichier [nom].py
        - les tests unitaires associés avec [framework]
    Contraintes :
        - respect strict des signatures
        - types explicites
        - docstrings courtes mais claires"

Sortie :
    - bloc de code unique par fichier
    - pas de texte autour du code
                

Recipe – Revue de code & refactor

Rôle IA :
    "Tu es un reviewer de code senior, pointilleux mais bienveillant."

Contexte :
    - Extrait de code (ci-dessous)
    - Règles internes (style, sécurité, performance) :

Tâche :
    "Analyse ce code et :
        1. liste les problèmes potentiels (bugs, design, lisibilité)
        2. propose un plan de refactor en 5 points max
        3. donne une version refactorisée du code"

Format :
    ## Problèmes détectés
    - ...

    ## Plan de refactor
    - ...

    ## Code proposé
    ```langage
    ...
    ```
                

Avant de merger une branche

• ✅ Tous les tests passent en local / CI.
• ✅ Les principaux choix IA sont documentés (prompt + réponse).
• ✅ Pas de TODO ou “magic numbers” laissés sans explication.
• ✅ Lecture froide : un dev externe comprend la feature en < 5 minutes.

Avant une mise en production

• ✅ Revue MCE faite (Chef projet + Archi + Devs).
• ✅ Monitoring / alerting prêts (logs, métriques, dashboards).
• ✅ Plan de rollback simple en cas de problème.
• ✅ Rétrospective planifiée après la release.

Pattern MCE pour une feature FastAPI

1. Définir le schéma Pydantic (AF + données).
2. Remplir le contexte technique (FastAPI, async, DB).
3. Utiliser le LLM pour :
    - proposer routes + dépendances
    - générer le code router + tests
4. Compléter les contrôles de sécurité (auth, rate limit).
                

Pattern MCE pour Node (Express / Nest)

1. AF : endpoints, middlewares nécessaires, schémas JSON.
2. Contexte : framework choisi, conventions de code (ESLint, TS).
3. IA :
    - structure de modules / controllers
    - génération des handlers + tests Jest
4. Intégration :
    - attention au typage TypeScript
    - logs + gestion d’erreurs centralisée
                

Grille d’évaluation (candidat / formation)

Tips pédagogiques

• Faire travailler les participants en binôme : un “Architecte contexte”, un “Dev IA”.
• Montrer la différence entre “prompt freestyle” et démarche MCE structurée.
• Refaire le même exercice 3 mois plus tard pour mesurer la progression.