🧠 MCE – Mini-projets & Ateliers

Guide d’utilisation des mini-projets MCE

Pour la formation interne

Choisir 1 mini-projet par thématique (Backend, DevOps, MCE pur…).
Imposer l’usage du MCE Pack Generator + Session Logger.
Organiser une revue MCE : chaque équipe présente son pack, son code, ses limites.
Archiver tous les artefacts (packs + sessions) dans un repo mce_training/.

Pour l’évaluation de candidats

Donner 1 à 2 mini-projets selon le niveau (junior / senior / lead).
Temps limité (2–4 h) : méthode > quantité de code.
Scorer sur : Contexte, AF, IA, Code, Explication.
Option : session live 30 min où le candidat “pilote” un LLM devant vous.

Idée : constituer au fil du temps une “MCE Academy” IDEO-Lab, avec les meilleurs packs, prompts, sessions et corrections commentées.

Grille de scoring globale – Mini-projets MCE

Dimension	Question	Score 0–5
Contexte & CDCF	Le besoin, les limites et les non-objectifs sont-ils clairement posés ?
Analyse Fonctionnelle	Scénarios, cas d’erreur, données, règles sont-ils bien captés ?
Usage MCE / IA	Context Pack, prompts & sessions sont-ils structurés, versionnés, lisibles ?
Code & tests	Code lisible, découpé, testé, cohérent avec le CDCF & l’AF ?
Explication	Le candidat sait-il expliquer ses choix, arbitrages et limites ?

Exemple de lecture : > 20 / 25 = très bon niveau MCE ; 15–19 = solide ; < 15 = points à travailler (ou risque pour un rôle de lead / architecte).

1.1 Mini-projet Backend – API Todo / Tickets

Brief (à donner au candidat)

Concevoir une API REST de gestion de tâches (todo / tickets) pour une petite équipe interne (~20 utilisateurs).

Créer / lister / mettre à jour / clôturer des tâches.
Assigner une tâche à un membre d’équipe.
Filtrer les tâches par statut ou par assigné.
Historiser les changements de statut (qui ? quand ?).

Exemple de CDCF “light” (à donner comme modèle)

Objectif : - Permettre à une équipe interne de suivre les tâches en cours, les prioriser et savoir qui travaille sur quoi. Utilisateurs : - Membres d'équipe (créent et gèrent leurs tâches). - Lead (peut reassigner une tâche, changer la priorité). Fonctions principales : - Créer une tâche avec titre, description, priorité, statut initial TODO. - Assigner la tâche à un membre (facultatif). - Voir la liste des tâches filtrées par statut, assigné, priorité. - Mettre à jour le statut (TODO → DOING → DONE). - Voir l'historique des changements de statut. Non-objectifs : - Pas de gestion multi-projet. - Pas de pièces jointes. - Pas de notifications email / Slack.

Consignes MCE

Écrire un CDCF light (ou adapter l’exemple ci-dessus).
Produire une AF :
- liste des endpoints,
- schéma JSON des payloads,
- codes de retour et principaux cas d’erreur.
Créer un Context Pack MCE avec le MCE Pack Generator.
Utiliser un LLM pour :
- proposer un modèle de données,
- esquisser les endpoints,
- suggestion de tests unitaires.

Questions à poser au LLM

“Propose-moi un modèle de données minimal pour ce CDCF.”
“Donne-moi les endpoints REST avec exemples de requêtes / réponses.”
“Propose 5 tests unitaires utiles sur l’API de tâches.”

Exemple de Context Pack (extrait)

# API Todo – Context Pack MCE (extrait) ## 2. Objectif de la session IA Proposer un modèle de données et les endpoints REST pour une API de gestion de tâches (todo/tickets) pour une petite équipe interne (~20 users). ## 4. Contexte technique - Backend : Django + Django REST Framework - DB : PostgreSQL - Auth : JWT simple - Contraintes : simplicité, lisibilité, tests unitaires minimum ## 6. Format de sortie souhaité - Modèle Django (models.py) - Vue DRF (viewsets + serializers) - 5 exemples de tests pytest

Le candidat est évalué sur sa capacité à structurer et utiliser l’IA, pas à tout coder au pixel près.

Scoring spécifique Backend

Critère	Description	0–5
Modèle de données	Entités claires (Task, User), statuts cohérents, relations simples.
Endpoints & AF	Endpoints bien définis, cas d’erreur prévus, cohérence avec le CDCF.
Tests	Tests pertinents (création, update, filtres, erreurs).
Usage IA	Context Pack utilisé, session log, prompts lisibles.

Exemple d’API (à garder comme référence interne)

GET /api/tasks/ # liste / filtres ?status=TODO&assigned_to=... POST /api/tasks/ # créer GET /api/tasks/{id}/ # détail PATCH /api/tasks/{id}/ # MAJ partielle (titre, desc, assigné, statut) GET /api/tasks/history/{id}/ # historique des statuts Status: TODO, DOING, DONE

1.2 Mini-projet Fullstack – Mini SaaS

Brief

Créer un mini SaaS “Contact Manager” (ou équivalent) avec :

Backend API (CRUD contacts)
Front (React / Vue) avec 3–4 écrans max
Login simple (fake ou vrai JWT)

Exemple d’écrans

Écran 1 : Login / Sélection d’un “tenant” simple.
Écran 2 : Liste des contacts + recherche + filtres.
Écran 3 : Formulaire de création / édition de contact.
Écran 4 (option) : petit tableau de bord (compter les contacts par tag).

Consignes

Définir un CDCF + AF sur :
- les écrans,
- les flux (CRUD basiques),
- les rôles (user simple / admin optionnel).
Utiliser un LLM pour :
- suggérer la structure des composants,
- définir les endpoints et le typage TS (si utilisé),
- générer quelques tests front (facultatif).
Produire un Context Pack “mini_saas_contacts”.

Exemple de Context Pack (extrait)

## 2. Objectif de la session IA M'aider à concevoir la structure front (React) + les endpoints API pour un mini SaaS de gestion de contacts (3-4 écrans). ## 4. Contexte technique - Front : React + React Router + fetch (ou axios) - Backend : API REST (Django ou Node) - Auth : page login simple, pas de social login

Scoring Fullstack

UX simple mais logique : navigation claire, on ne se perd pas.
Clarté des responsabilités : front vs back.
Usage IA : prompts orientés écrans / API, pas juste “code moi ça”.
Tests / validation : au moins une forme de vérification (tests ou scénario manuel).

1.3 Mini-projet DevOps & Cloud – Script de déploiement

Brief

Automatiser le déploiement d’une petite app web (Django + Postgres, ou équivalent) sur une VM Linux (Ubuntu).

Exemple de plan de déploiement (extrait)

1. Pré-requis - VM Ubuntu 22.04, accès SSH, user "deploy". - Nom de domaine pointant vers la VM. 2. Étapes principales - Installation des paquets (python, venv, nginx, postgresql...). - Création utilisateur système pour l'app. - Création venv + installation dépendances. - Création DB + user PostgreSQL. - Config systemd (gunicorn) + config Nginx. - Test de l'URL / healthcheck. 3. Non-objectifs - Pas de HA, pas de multi-VM, pas de monitoring avancé.

Consignes

Rédiger un plan de déploiement clair (comme ci-dessus).
Utiliser un LLM pour :
- générer un script bash ou un playbook Ansible,
- identifier les pièges classiques (permissions, firewall, systemd…),
- proposer des checks finaux (curl, systemctl status, etc.).

Exemple de script (extrait)

#!/usr/bin/env bash set -e APP_USER="myapp" APP_DIR="/opt/myapp" sudo apt update sudo apt install -y python3-venv python3-pip nginx postgresql # user + répertoires sudo useradd -m -s /bin/bash ${APP_USER} || true sudo mkdir -p ${APP_DIR} sudo chown ${APP_USER}:${APP_USER} ${APP_DIR} # (suite : venv, git clone, gunicorn, nginx...)

Le but n’est pas d’avoir un script prêt-prod, mais de vérifier que le candidat sait dialoguer avec un LLM sur un sujet DevOps réel.

Scoring DevOps

Script rejouable, lisible, commenté.
Prise en compte des droits / users / services.
Vérifications finales (healthcheck, status services).
Session IA documentée, prompts non “magiques”.

2.1 Mini-projet – Moteur de recherche simplifié

Brief

Construire un mini moteur de recherche (fichiers Markdown ou pages HTML IDEO-Lab), avec :

indexation (titre, tags, contenu),
recherche texte + score de pertinence simple,
autocomplete basique sur les titres ou tags.

Exemple de petit dataset

docs = [ { "id": 1, "title": "Guide Django 2025", "tags": ["django","backend"], "text": "..." }, { "id": 2, "title": "Nginx Tuning", "tags": ["nginx","perf"], "text": "..." }, { "id": 3, "title": "PostgreSQL Analyzer", "tags": ["postgres","dba"], "text": "..." } ]

Consignes MCE

Écrire un CDCF avec :
- queries typiques (3–5 exemples),
- critères de pertinence (titre, tags, texte),
- non-objectifs (pas besoin d’Elastic full, pas de multi-langue, etc.).
Utiliser un LLM pour :
- proposer un schéma d’index simple,
- décrire un scoring (TF-IDF light, boost sur titre, etc.),
- générer pseudo-code de ranking + autocomplete.

Exemple d’API (référence)

GET /search?q=django&limit=10 → { "query": "django", "results": [ { "id": 1, "title": "Guide Django 2025", "score": 0.87 }, { "id": 4, "title": "Intro Django", "score": 0.65 } ] } GET /search/autocomplete?q=ng → ["Nginx Tuning", "NGINX Analyzer 2025"]

Scoring spécifique Search

Compréhension des critères de pertinence / ranking.
Clarté de l’API de search / autocomplete.
Context Pack search : bien structuré, exemples de queries, non-objectifs.

2.2 Mini-projet – Refactor de code legacy

Brief

À partir d’un module Python (ou JS) volontairement “spaghetti”, proposer une version refactorisée + tests.

Exemple de code legacy (extrait)

def process_items(items, user, verbose=False): # beaucoup de logique mélangée, if imbriqués, prints, etc. ...

Consignes

Comprendre le comportement existant (AF minimale).
Utiliser un LLM pour :
- identifier les “smells”,
- proposer un plan de refactor étapes par étapes,
- esquisser une version refactorisée.
Écrire des tests pour figer le comportement avant refactor.

Exemple de questions IA

“Explique-moi ce que fait cette fonction aujourd’hui.”
“Propose une décomposition en fonctions plus petites sans changer le comportement.”
“Propose 5 tests unitaires qui couvrent les cas importants.”

Scoring Refactor

Niveau de compréhension de l’existant avant refactor.
Qualité du plan proposé (pas juste “recoder from scratch”).
Code refactorisé lisible, découpé, testé.
Capacité à expliquer ce qui a changé et ce qui a été laissé en l’état.

2.3 Atelier “MCE pur” – Contexte, Packs & Sessions

Brief

À partir d’un mini-projet au choix (ex : API Todo, Search Engine, DevOps), produireles artefacts MCE, sans coder l’implémentation complète.

Objectif : mesurer la capacité à “penser” un projet logiciel avec la Méthode Context Engineering, avant de toucher au code.

Artefacts à livrer

CDCF light (1–2 pages) pour le mini-projet choisi.
AF textuelle :
- acteurs, scénarios principaux, cas d’erreur, règles métier,
- schéma haut-niveau (tableau ou diagramme simple).
Context Pack MCE complet (via MCE Pack Generator).
1 session IA documentée (via MCE Session Logger) :
- objectif de la session,
- prompts clés,
- décisions prises,
- limitations / TODO.
Un plan de réalisation (liste de tâches / étapes de dev).

Utilisation idéale pour : Architectes, Leads, Chefs de projet techniques ; mais aussi pour former les juniors à “penser avant de coder”.

Scoring MCE pur

Clarté et structuration du CDCF / AF.
Qualité du Context Pack (compact, précis, exploitable par un LLM).
Organisation de la session IA (objectifs, tournants, décisions).
Capacité à dégager un plan de réalisation réaliste.

🧠 MCE – Mini-projets & Ateliers

API Backend – Todo / Tickets

Mini SaaS Fullstack

DevOps & Cloud – Script de déploiement

Moteur de recherche simplifié

Refactor de code legacy

Atelier “MCE pur”