Labs · exécutables sans clé API

Des labs qui tournent, pas des slides

Tout ce que nous enseignons est livré en code : serveurs MCP, pipeline multi-agents, intégrations CRM SaaS et open data, guardrails de sécurité, API et front de validation humaine. Chaque session repart d’un monorepo testé en CI.

Voir les formations Adapter à votre SI

Architecture

Un monorepo, six formations

Une couche métier partagée (shared/), exposée en tools MCP, orchestrée par des agents, testée et servie à des humains via une API. Les mêmes données servent au N1 (exports CSV) et à l’Expert (formats API réels).

Serveurs MCP du lab : rôle et tools exposés
Serveur MCP	Rôle	Tools
`crm-lab`	CRM sandbox (JSON) — le serveur MCP du TP1 Expert	search_customers · get_customer · get_ticket · list_open_tickets · apply_business_rule · generate_report
`crm-saas`	Même contrat quel que soit le CRM : sandbox, HubSpot CRM API v3, Salesforce REST / SOQL (mock ou live)	crm_search_accounts · crm_get_account · crm_list_tickets · crm_get_ticket · crm_create_note (HITL)
`opendata-fr`	Enrichissement par l’open data français — Licence Ouverte 2.0, cache hors-ligne	geocode_address · search_company_sirene · get_company_by_siren · commune_by_postcode · enrich_account
`bugzilla`	Triage de bugs : mock « Lab Platform », réponses réelles de bugzilla.mozilla.org, instance Docker	bz_search_bugs · bz_get_bug · bz_get_comments · bz_add_comment (HITL)

Pipeline multi-agents

Sept scénarios, un verdict attendu chacun

Analyste → Enrichisseur (open data) → Trieur (Bugzilla) → Rédacteur → Validateur. Le code de sortie vaut 0 si le verdict est celui attendu : la CI et l’auto-évaluation s’en servent.

Scénarios du pipeline multi-agents : verdict attendu et point démontré
Scénario	Verdict	Ce qu’il démontre
`golden`	`PASS`	Chemin nominal : client + ticket critique → rapport validé
`failure`	`FAIL`	Ticket inexistant → échec contrôlé, pas de crash
`injection`	`NEED_APPROVAL`	Ticket piégé (prompt injection) → quarantaine + escalade humaine
`hubspot`	`PASS`	Même agent sur HubSpot (format API v3) + enrichissement open data
`salesforce`	`PASS`	Même agent sur Salesforce (REST / SOQL), mapping Critical → critique
`enrich`	`PASS`	Adresse → BAN → commune → SIRENE, avec limites explicites
`triage`	`PASS`	Ticket support ↔ bugs Bugzilla liés, commentaire en dry-run

Modules RAG et Agents codeurs

Deux labs de plus, sans aucune dépendance

Les deux modules ajoutés au catalogue livrent leur lab dans le même dépôt. Pur Python pour le RAG (BM25, projection vectorielle, fusion, reclassement écrits à la main) ; diffs figés et garde-fous exécutables pour les agents codeurs. Chacun est vérifié en CI.

Labs RAG et agents codeurs : ce que chacun fait apparaître et comment il est vérifié
Lab	Ce qu’il fait apparaître	Vérification
`08-module-rag`	Un découpage fixe qui sépare l’article de sa ligne de tableau ; un terme précis que le vectoriel seul relègue au rang 4 ; deux notes contradictoires dont une remplacée ; quatre questions hors corpus où le système doit se taire ; une injection indirecte mise en quarantaine ; des droits d’accès filtrés avant classement, fuite mesurée ; un générateur simulé qui ment trois fois, attrapé phrase par phrase.	`rag.eval` — recall@5, ancrage, abstention, seuils bloquants
`09-module-agents-codeurs`	Six diffs générés, quatre défectueux : dépendance inventée, test qui rejoue l’implémentation, constante fausse mais plausible, périmètre débordé. La CI en attrape deux ; les deux autres relèvent de la revue. Un linter distingue règle vérifiable et intention ; soixante PR fictives départagent les indicateurs.	`verifier.sh` — chaque garde-fou vu échouer là où il doit

Ce qu’il y a dedans

Réaliste, sécurisé, automatisé

CRM

HubSpot & Salesforce

Fixtures aux formats des API réelles (v3, REST / SOQL), contrat de provider, mapping des priorités et statuts, passage en live par variable d’environnement sur un portail de test.

DATA

Open data français

Base Adresse Nationale, annuaire SIRENE, découpage administratif. Réponses réelles figées pour la salle sans Wi-Fi, attribution de licence dans chaque réponse, cas limites assumés.

BUG

Bugzilla

Client REST : produit fictif cohérent avec les tickets CRM, réponses réelles de bugzilla.mozilla.org, instance locale Docker. Triage assisté et lien ticket ↔ bug, écriture sous validation.

SEC

Sécurité

Scan d’injection et quarantaine, politique d’outils (allowlist, quotas, HITL), masquage PII, traces sans secret, gitleaks en CI. Un ticket et un bug piégés pour apprendre à ne pas obéir aux données.

Front de validation humaine

API FastAPI, flux SSE des événements, timeline d’outils, décision approuver / rejeter journalisée, publication d’une note CRM en dry-run. Portable en React / Next.js.

Automatisation

Tests pytest, preflight de poste (35 vérifications), auto-évaluation du barème, GitHub Actions, Devcontainer / Codespaces, Docker Compose. Zéro clé API requise.

Démarrer

Cinq commandes

cd 03-niveau-expert/travaux-pratiques/lab-expert
python -m venv .venv && .venv\Scripts\activate      # source .venv/bin/activate
pip install -r requirements.txt
python -m scripts.preflight                          # poste prêt ?
python -m pytest                                     # 38 tests, ~1 s, sans clé
python -m agents.run_pipeline --scenario injection --dump-draft
uvicorn api.app:app --reload --port 8000             # front HITL → http://localhost:8000

Le dépôt des labs est remis aux participants et aux clients intra. Les données sont fictives ou open data sous Licence Ouverte 2.0 ; aucune donnée client réelle.

Votre CRM, votre tracker, vos données

En intra, nous adaptons les fixtures et les providers à votre SI (HubSpot, Salesforce, Dynamics, Jira, GitLab…) et au niveau de vos équipes.

Parler de votre contexte Journée Sécurité