Partie IX. Mise en œuvre

26. Démarche pas à pas

flowchart LR
  P0["Phase 0<br/>Cartographie"] --> P1["Phase 1<br/>Instrumentation"] --> P2["Phase 2<br/>SLI, SLO, alerting"] --> P3["Phase 3<br/>Évaluation"] --> P4["Phase 4<br/>FinOps"] --> P5["Phase 5<br/>Compliance"] --> P6["Phase 6<br/>Amélioration continue"]
  P6 -.->|"boucle fermée"| P3

• Phase 0, cartographie : composants, flux, frontières de sensibilité, obligations réglementaires, utilisateurs de l’observabilité.
• Phase 1, instrumentation : OTel GenAI partout, pas de capture de contenu par défaut, collecteur branché sur les backends existants.
• Phase 2, SLI et SLO : SLI de service, qualité et coût, tableaux de bord corrélés par trace, alerting sur dérive de qualité et de coût.
• Phase 3, évaluation : golden set, calibration du juge, gating en intégration continue, échantillonnage en production.
• Phase 4, FinOps : attribution, suivi par requête, session et tâche, budgets, alertes de dérive, leviers.
• Phase 5, compliance : masquage, séparation contenu et métadonnées, rétentions distinctes, audit immuable, remontée MCP au SOC, matrice de preuve.
• Phase 6, amélioration continue : la production alimente les datasets, les régressions remontent vers les tests, les seuils sont revus.

27. Le lab de référence

Pour transformer la méthode en compétence, la cible est un environnement exécutable qui reproduit chaque défaillance silencieuse et montre comment on l’attrape. Ce lab complet est en préparation : il n’est pas encore publié et les configurations et règles de cette méthode n’y ont pas encore été exécutées.

Ce qui existe déjà sur la forge publique labstraining :

• labs/genaiotel : une application RAG instrumentée avec les conventions OTel GenAI (modèle et embeddings simulés, sans clé d’API), un Collector qui calcule le coût de chaque span (OTTL) et dérive les métriques par modèle (spanmetrics), VictoriaMetrics et vmalert (règles de coût, alertes de latence, de coût, d’erreur, de tokens d’entrée, de contexte récupéré faible et de qualité évaluée), Jaeger, Grafana et une passe d’évaluation vers Phoenix. Il couvre une partie des scénarios 2 et 3 ci-dessous ; il ne contient ni agent, ni MCP, ni sidecar de borne de Wilson.
• labs/aiobsagent : un agent d’investigation d’alertes écrit en Go, en lecture seule, qui isole le contenu tiers contre l’injection de prompt et tient un journal chaîné. Il illustre les garde-fous contre l’injection et le moindre privilège des grilles agent et MCP de la partie III, mais ne reproduit aucun des quatre scénarios ci-dessous.

Structure cible du lab complet, en préparation :

labstraining/observability-genai/
  docker-compose.yml        # collecteur OTel, VictoriaMetrics, VictoriaLogs, Grafana, Langfuse
  otel-collector.yaml       # config de référence (partie II)
  rules/                    # recording rules et alertes MetricsQL
  dashboards/               # tableaux de bord Grafana provisionnés
  agent-demo/               # agent instrumenté OTel GenAI (Python)
  scenarios/                # scénarios de défaillance reproductibles
  evals/                    # golden set, harnais RAGAS ou DeepEval

Scénarios pédagogiques prévus, un par défaillance silencieuse :

1. Boucle d’agent : l’agent boucle, le coût par tâche explose. L’apprenant active la détection de boucle et l’alerte de coût, puis la rejoue.
2. Gonflement de prompt : croissance progressive des tokens entrée, visible seulement par la recording rule dédiée.
3. Hallucination par contexte RAG dégradé : on dégrade la recherche, la fidélité chute, l’éval échantillonnée la détecte là où la latence reste verte.
4. Mutation de serveur MCP : un outil change de définition entre deux appels, la détection de mutation et le tool pinning l’attrapent.

28. Checklists par axe

Fiabilité

• Évaluation par échantillonnage en production active
• Golden set constitué, accord du juge suivi, juge versionné
• SLO de qualité avec intervalle de confiance
• Tests de régression en intégration continue
• Détection de dérive configurée
• Distribution des finish_reasons surveillée

Disponibilité

• SLO de service par couche
• Health checks inférence, base vectorielle, serveurs MCP
• Repli multi-fournisseur testé
• Dégradation gracieuse en cas d’indisponibilité d’outil

Coût

• Tokens et coût tracés avec dimension d’attribution
• Budgets et alertes à 80 pour cent
• Surveillance du gonflement de prompt et des boucles d’agent
• Taux de hit du cache mesuré et leviers actifs

Compliance

• Contenu non capturé par défaut, capture opt-in maîtrisée
• Masquage et expurgation au collecteur
• Séparation contenu et métadonnées, rétentions distinctes
• Piste d’audit immuable sur invocations et accès
• Événements de sécurité MCP remontés au SOC
• Matrice de preuve AI Act, NIS2, RGPD documentée
• Backends auto-hébergés si souveraineté requise

Organisation

• RACI établi sur les huit capacités
• Astreinte qualité définie, playbooks de mitigation écrits

---

Révisé le 2 octobre 2026 : le lab complet de la méthode est présenté comme en préparation, avec un renvoi précis vers les deux labs publics existants.

Marquer comme lue