7. Exploiter la plateforme

La mise en œuvre n’est qu’un début. Exploiter durablement une plateforme d’observabilité de l’IA exige des choix délibérés : quelles données conserver, combien cela coûte, comment les protéger.

7.1 Stratégie d’échantillonnage

Tracer intégralement chaque requête LLM coûte cher en stockage et en traitement. L’échantillonnage devient nécessaire au-delà de quelques centaines de requêtes par seconde.

La figure simplifie : seuls les scores d’évaluations synchrones sont disponibles au moment de la décision d’échantillonnage (voir ci-dessous).

Figure 10. L’échantillonnage en tête (head sampling) décide au début de la trace, de façon aléatoire. L’échantillonnage en queue (tail sampling) décide à la fin de la trace, selon des règles. L’échantillonnage en queue conserve de façon déterministe les erreurs, les traces lentes et celles qu’une évaluation synchrone a signalées.

Politique recommandée

• Toujours conserver les traces en erreur.
• Toujours conserver les traces anormalement lentes.
• Toujours conserver les traces dont une évaluation synchrone (filtre de toxicité, classifieur de refus, évaluée pendant la requête) est sous le seuil.
• Échantillonner 10 % du reste de façon probabiliste, pour garder une visibilité de référence.

Mise en œuvre : processeur tail_sampling de l’OpenTelemetry Collector. Il ne peut décider que sur ce que contient la trace à l’expiration de son délai d’attente (decision_wait, 30 secondes par défaut) : erreurs, latences, attributs posés pendant la requête. Les scores des évaluateurs asynchrones et les retours utilisateurs arrivent bien après ; ils ne peuvent pas piloter cette décision. Pour conserver les traces notées après coup, gardez toutes les traces brutes sur une rétention courte (quelques jours), puis promouvez vers le stockage long celles qu’un évaluateur a mal notées ou qui ont reçu un retour négatif.

Le coût mémoire du processeur dépend du nombre de traces gardées en attente (num_traces) et de la durée de decision_wait, multipliés par la taille moyenne d’une trace : dimensionnez ces deux paramètres d’après votre débit.

7.2 Modélisation des coûts

Cette section est la référence du site sur le coût de l’observabilité elle-même. Le coût de la non-observabilité (l’exposition économique d’un système mal observé, avec son calculateur) est traité dans la méthode GenAI, partie V.

À grande échelle, le coût de l’observabilité de l’IA peut rivaliser avec celui des appels LLM eux-mêmes. Un modèle simple :

total_obs_cost  = storage_cost + processing_cost + judge_cost

stored_GB       = RPS * avg_payload_KB * 86400 * retention_days / 1024 / 1024
storage_cost    = stored_GB * cost_per_GB_month          (par mois)
processing_cost = collector_cost + ingestion_cost
judge_cost      = RPS * 86400 * sample_rate * tokens_per_judge * cost_per_token   (par jour)

Exemple à 100 RPS, charge utile moyenne de 4 Ko, rétention chaude de 30 jours :
  stored_GB    = 100 * 4 * 86400 * 30 / 1024 / 1024
               = 988,8 Go, soit environ 1 To conservé en stockage chaud
  storage_cost = 988,8 * cost_per_GB_month   (par mois)

Exemple de juge à 100 RPS, échantillon de 10 %, 1 500 jetons par jugement :
  jugements    = 100 * 86400 * 0,10
               = 864 000 jugements par jour
  jetons juge  = 864 000 * 1500
               = 1 296 millions de jetons par jour pour un seul évaluateur
  judge_cost   = 1 296 000 000 * cost_per_token   (par jour)

Les prix changent vite et varient selon les contrats : ce guide n’en donne pas ; utilisez la grille datée de votre fournisseur pour cost_per_GB_month et cost_per_token. Comparez les deux postes sur la même période : le stockage se facture au mois, le juge consomme chaque jour (environ 39 milliards de jetons sur 30 jours dans cet exemple). Un tarif unique par jeton est aussi une simplification, car les jetons de sortie sont en général facturés plus cher que les jetons d’entrée.

Correction

La première version de ce guide présentait le coût de stockage de cet exemple comme un coût journalier. Ce n’est pas un coût journalier : c’est le volume conservé sur 30 jours de rétention (environ 1 To) multiplié par un prix au Go-mois, donc un coût mensuel.

Postes de coût, par ordre d’importance

1. Taille des charges utiles : prompts, complétions et contextes récupérés peuvent peser chacun des dizaines de kilo-octets. Le volume de stockage croît linéairement avec le trafic.
2. Évaluations par LLM juge : elles consomment des jetons au moment de l’évaluation. Un évaluateur trivial exécuté sur chaque trace peut doubler la consommation totale de jetons.
3. Attributs à forte cardinalité : user_id, request_id, session_id font gonfler le stockage des métriques s’ils sont attachés aux métriques plutôt qu’aux traces.

Stratégies d’atténuation

• Compresser et hiérarchiser le stockage des anciennes traces (chaud pendant sept jours, tiède pendant trente, archivage froid au-delà).
• Utiliser de petits modèles pour l’évaluation en ligne et de grands modèles uniquement pour des lots d’audit périodiques.
• Réserver les attributs à forte cardinalité aux traces et garder des métriques à faible cardinalité par agrégation.
• Échantillonner les exécutions de LLM juge plutôt que d’évaluer chaque trace.
• Hiérarchiser les évaluateurs par coût et réserver les plus chers à un petit échantillon et aux traces signalées.

7.3 Maîtrise de la cardinalité

La cardinalité des métriques est le premier risque de passage à l’échelle d’une plateforme d’observabilité de l’IA. Les charges d’IA ont naturellement des dimensions à forte cardinalité : versions de prompt, versions de modèle, versions d’index de recherche, identifiants de locataire, identifiants d’utilisateur.

Règles empiriques

• Les attributs qui prennent des milliers de valeurs distinctes par jour vont sur les traces, pas sur les métriques.
• Les dimensions des métriques doivent être bornées : model_name (quelques dizaines), feature (quelques dizaines), tenant (quelques centaines au plus).
• Les métriques par utilisateur sont un anti-modèle : interrogez plutôt les traces par user_id.
• Changer de dorsal ne règle pas le problème. Certains dorsaux (VictoriaMetrics, Grafana Mimir, Thanos, ou les offres gérées) annoncent une meilleure tenue de la forte cardinalité que Prometheus seul ; ce sont des indications des éditeurs, à mesurer sur votre charge. La vraie réponse reste de corriger la conception des métriques.

7.4 Données personnelles et souveraineté

Les prompts et les complétions contiennent fréquemment des données personnelles. Trois contrôles sont recommandés, a fortiori en contexte régulé.

Caviardage avant stockage

• Par expressions régulières pour les motifs connus : e-mail, téléphone, IBAN, carte bancaire, numéros de sécurité sociale. Le processeur redaction du Collector le fait (valeurs bloquées masquées ou hachées, clés non autorisées supprimées).
• Par reconnaissance d’entités nommées pour les noms de personnes, d’organisations et de lieux. Le Collector ne le fait pas nativement : il faut un service externe (par exemple un moteur de détection de données personnelles appelé par l’application ou par un composant intermédiaire) ou un processeur personnalisé.
• Par LLM pour le nettoyage dépendant du contexte, là où expressions régulières et NER échouent. Même contrainte : un composant externe, avec son coût et sa latence.
• Faire le caviardage par expressions régulières dans le collecteur (avant l’export) et placer les traitements NER ou LLM en amont du stockage ; jamais dans le dorsal de stockage, une fois les données écrites.

Contrôle d’accès

• Un contrôle d’accès fondé sur les rôles (RBAC) sur les requêtes de traces est le minimum.
• Un contrôle d’accès au niveau des champs lorsque le dorsal le permet : les clés d’attributs sont lisibles par tous, mais le corps des prompts et des complétions exige des droits élevés.
• Un journal d’audit de tous les accès aux traces, conservé selon les exigences réglementaires.

Politique de rétention

• Alignée sur le principe de limitation de la conservation (article 5, paragraphe 1, point e) du RGPD) et sur les réglementations sectorielles.
• Rétention distincte pour les métadonnées de traces (plus longue) et le corps des traces (plus courte).
• Processus de purge automatisés, vérifiés par audit.

Secteurs régulés

NIS2 et DORA n’imposent pas, en eux-mêmes, que le dorsal d’observabilité réside dans une juridiction donnée. Cette exigence peut venir d’une politique interne, d’un régulateur sectoriel ou d’un contrat ; vérifiez celles qui s’appliquent à vous. DORA impose en revanche aux entités financières de gérer le risque lié aux prestataires tiers de services TIC et de tenir un registre d’information qui recense notamment les pays de stockage et de traitement des données : un dorsal qui stocke des prompts doit y figurer. Dans tous les cas, les pistes d’audit doivent couvrir l’accès aux prompts stockés.

7.5 Sécurité

L’observabilité des LLM ouvre une nouvelle surface d’attaque que l’APM classique ne connaît pas.

Menaces

• Les prompts stockés peuvent contenir des secrets collés par erreur par les utilisateurs (clés d’API, jetons, mots de passe).
• Les complétions stockées peuvent contenir des données d’entraînement ayant fuité par mémorisation.
• Les chaînes d’évaluation qui appellent des LLM juges externes peuvent exfiltrer des données sensibles vers des fournisseurs tiers.
• Les interfaces de requête de traces exposent le contenu intégral des interactions passées à toute personne qui y a accès.
• Des attaques par injection de prompt peuvent viser le modèle juge lui-même et manipuler les scores des évaluateurs.

Mesures d’atténuation

• Nettoyage avant stockage des motifs de secrets, en plus des données personnelles.
• Refus par défaut des appels sortants vers des LLM juges, avec une liste explicite de fournisseurs autorisés.
• Contrôle des flux réseau sortants du collecteur vers les points d’accès des juges.
• Journal d’audit de tous les accès aux traces, avec revue périodique.
• Chiffrement au repos et en transit du stockage des traces.
• Prompts de juge durcis contre l’injection : assainir les champs d’entrée, utiliser des délimiteurs, ne jamais placer le contenu évalué dans le prompt système.

7.6 Répartition des responsabilités

• La plateforme porte la pile (collecteurs, dorsaux, tableaux de bord, routage des alertes), le ML les évaluateurs, les seuils de qualité et le jeu de non-régression, la sécurité le caviardage, les politiques d’accès et la revue d’audit.
• Les trois équipes tiennent ensemble la revue hebdomadaire des traces en échec et à faible score : à mon avis, l’instance récurrente la plus utile et la seule qui ferme la boucle.
• La matrice RACI complète (produit, conformité et astreinte qualité compris) est dans la méthode GenAI, partie VII, qui fait référence ; l’AI Act et la preuve réglementaire sont dans la partie VI.

Suite : 8. Versionnage, rejeu et expérimentation.

À manipuler

Le simulateur d’échantillonnage en queue et le simulateur de cardinalité mettent des chiffres sur les règles de ce chapitre.

Révisé le 2 octobre 2026 : prix retirés, limites de l’échantillonnage en queue (évaluations asynchrones et retours utilisateurs), dimensionnement mémoire, caviardage NER et LLM hors du Collector, article 5 du RGPD, exigences de localisation de NIS2 et DORA corrigées.

Révisé le 4 octobre 2026 : section 7.2 désignée comme référence sur le coût de l’observabilité, avec renvoi à la méthode pour le coût de la non-observabilité ; section 7.6 résumée en trois lignes avec renvoi au RACI de la méthode.

Marquer comme lue