Dès que la gateway logge les prompts et les completions, elle détient ce que l'utilisateur d'un agent du service client a tapé dans une fenêtre de chat, ce qui peut inclure une adresse, un numéro de compte ou une plainte concernant sa santé. Toutes les autres décisions de cette série arbitraient entre coût et latence, ou entre contrôle et confort. Celle-ci arbitre entre la debuggabilité et une obligation de protection des données, et elle vient en dernier parce que c'est celle qui a besoin que tout le reste soit déjà en place. La partie 9 a mis la plateforme en état de livrer. Cette partie clôt la série : quoi enregistrer, quoi surveiller, ce que demande la régulation, et si les chiffres de la partie 1 ont réellement bougé.

Trois couches, et celle que vous construisez vous-même

La plateforme émet désormais depuis trois endroits, et les confondre est la manière dont les équipes finissent avec trois dashboards qui se contredisent.

  • Gateway telemetry. Les métriques de tokens vers Application Insights avec les dimensions tenant, alias de modèle et environnement de la partie 5, plus les logs de requêtes vers Azure Monitor. C'est la vue faisant autorité sur qui a appelé quoi et ce que cela a coûté, et c'est la seule couche qui voit chaque requête synchrone.
  • La télémétrie applicative. Les traces propres de la couche d'orchestration : quels tools ont tourné, combien d'itérations de boucle, quels documents récupérés ont fini dans le prompt. Les outils spécifiques aux LLM comme LangSmith ou Openlayer vivent ici, et une équipe data science qui utilise déjà Dataiku voudra sa propre vue des mêmes données. Aucun d'eux ne voit le trafic qui ne passe pas par l'application qui les émet, ce qui mérite d'être dit à voix haute chaque fois que quelqu'un en propose un comme source de vérité de la plateforme.
  • Les signaux de modèle et de sécurité. Les blocages de content safety, les refus, les catégories de filtre déclenchées. Ils viennent de la policy de la gateway et appartiennent à la couche gateway, pas à la couche applicative, parce que tout l'intérêt est qu'ils tiennent même quand l'application se comporte mal.

La couche que l'équipe plateforme possède et que personne d'autre ne construira, c'est la jointure : un correlation ID qui suit une interaction utilisateur à travers les trois, pour qu'une seule question ayant déclenché quatre appels de tools et un blocage de content safety soit une seule chose dans une requête plutôt que six enregistrements sans lien. La partie 8 a mis cet ID dans l'enregistrement de log. C'est à cela qu'il servait.

Quoi logger, et quoi ne pas logger

Logger les prompts et les completions est réellement utile : c'est ainsi qu'on débogue une mauvaise réponse, qu'on construit le golden set à partir du trafic réel, et qu'on prouve ce que le système a dit quand quelqu'un le conteste. Cela transforme aussi le magasin de logs en dépôt de contenu généré par les utilisateurs, d'une sensibilité inconnue, répliqué partout où vont ces logs.

La position tenable est par produit plutôt que globale, et c'est une décision que l'équipe consommatrice prend avec la plateforme plutôt qu'une décision que la plateforme prend pour tout le monde :

  • Toujours logger les métadonnées : tenant, alias, déploiement résolu et version, comptes de tokens, latence, statut, cache hit, résultat du content safety, correlation ID. Rien de tout cela n'est du contenu utilisateur, et tout cela répond aux questions opérationnelles.
  • Logger le contenu par exception, avec une retention plus courte que celle des métadonnées, limité aux produits qui ont explicitement accepté, et avec la subscription key retirée de la requête comme l'exigeait la partie 5.
  • Échantillonner plutôt que tout capturer là où le logging de contenu est actif. Pour la plupart des usages, un échantillon représentatif débogue aussi bien qu'une capture complète et réduit l'exposition d'autant.

Écrivez les durées de retention et la base légale dans le même document que le modèle de chargeback. Une plateforme qui peut dire précisément ce qu'elle conserve, pour combien de temps et pourquoi, survit à une revue de protection des données. Une qui ne le peut pas se verra ordonner de couper entièrement le logging, ce qui coûte bien plus cher.

Des evals en production, pas seulement dans le pipeline

L'eval gate de la partie 9 répond à « ce changement est-il sûr à livrer ». Il ne répond pas à « le système est-il encore bon », parce que le trafic de production n'est pas le golden set et s'en éloigne continuellement.

Deux mécanismes, et ils répondent à des questions différentes. Les evals planifiées exécutent le golden set contre la configuration de production sur un timer, ce qui attrape la dérive dans des choses que personne n'a déployées : une version de modèle qui a bougé malgré le pin, un index qui s'est réindexé différemment, un chemin de retrieval devenu plus lent. L'évaluation online par sampling note une petite part du trafic réel, généralement avec un model-as-judge, et c'est la seule façon de remarquer une classe de défaillance que le golden set n'a jamais contenue, parce que le golden set est par définition fait de défaillances déjà connues.

Les deux ont besoin d'un endroit où déposer le résultat, et c'est le même que pour tout le reste : un score avec les dimensions tenant et alias, sur le même dashboard que la dépense et la latence. Un chiffre de qualité qui vit dans un outil séparé est regardé pendant les incidents et ignoré le reste du temps.

La gouvernance, et ce que demande réellement la régulation

Sous l'EU AI Act, l'essentiel de ce que cette entreprise exploite relève du risque limité plutôt que du haut risque, et les obligations qui en découlent portent surtout sur la transparence et la traçabilité plutôt que sur la certification. Ce n'est pas une raison de traiter la gouvernance comme un exercice de documentation, parce que les questions d'un auditeur correspondent presque exactement à des choses que la plateforme enregistre, ou n'enregistre pas.

  • Quels modèles sont utilisés, dans quelles applications, dans quelles versions ? Le model catalog et la carte d'alias y répondent. Sans eux, c'est un sondage.
  • Quelles données sont allées à quel fournisseur, et où ont-elles été traitées ? La configuration des backend pools et les logs de requêtes y répondent requête par requête, ce qui est aussi la réponse à une question de résidence des données portant sur une région précise.
  • Quels contrôles de sécurité étaient en vigueur, et se sont-ils déclenchés ? La policy de content safety est versionnée dans le dépôt et ses résultats sont loggés par requête.
  • Qui pouvait appeler quoi, et quand cela a-t-il changé ? La configuration des tenants est du Terraform, donc la réponse est un historique git plutôt qu'un souvenir.
  • Une interaction précise peut-elle être reconstruite ? Seulement si le logging de contenu était actif pour ce produit, ce qui est exactement pourquoi cette décision se prend par produit et s'écrit noir sur blanc plutôt que de rester implicite.

Le point à retenir : c'est la gateway qui rend ces questions répondables. Cinq applications appelant directement cinq endpoints de modèles peuvent produire cinq réponses différentes à chaque question, et l'effort pour les réconcilier est le coût de conformité que l'investissement dans la plateforme a supprimé.

Le bilan

La partie 1 a fixé cinq objectifs. Notation honnête, y compris celui qui n'a pas atterri proprement.

  • Chaque product owner voit sa propre dépense de tokens sous un jour. Tenu, avec les classes de précision de la partie 3 indiquées sur le rapport : exact pour le non-streamé et le batch, estimé pour le streamé, avec un résidu publié.
  • Aucune application ne détient de credential de modèle à longue durée de vie. Tenu. Les applications détiennent un client credential Entra ID et une subscription key de produit ; aucun des deux n'atteint un endpoint de modèle, et la révocation est un changement de configuration.
  • Un avis de retrait produit une requête, pas une enquête. Tenu, et il a fallu trois décisions antérieures plutôt qu'un outil : des versions épinglées, des alias, et le logging par requête du déploiement résolu.
  • Un tenant ne peut pas épuiser le quota d'un autre. Tenu pour le trafic synchrone, via des clés de compteur par subscription. Le batch est borné par le fait que le control plane est le seul soumetteur, ce qui est un contrôle de processus plutôt qu'un contrôle imposé techniquement, et cet écart doit être nommé plutôt que lissé.
  • Une latence de gateway sous 60 ms au 95e percentile pour les appels non cachés. C'est celui qu'il faut mesurer plutôt que supposer, et c'est le chiffre le plus sensible aux choix faits pour d'autres raisons : le check de content safety ajoute un appel avant le modèle, le lookup du semantic cache ajoute un appel d'embedding, et les deux ont été adoptés pour de bonnes raisons qui coûtent des millisecondes. Une plateforme qui les a tous ajoutés sans re-mesurer a changé son propre SLO en silence.

Ce que cela a coûté, et quand cela ne vaut pas le coup

La série serait malhonnête sans cette section. Une gateway centrale, c'est une équipe plateforme, une instance API Management dans un tier choisi pour un schéma plutôt que pour la charge, un cache Redis avec un module qui ne peut pas être ajouté après coup, un déploiement d'embeddings servant deux usages, et un control plane qui est un vrai service avec une vraie astreinte. C'est un coût permanent, et il achète l'attribution, la gouvernance et une histoire de cycle de vie.

En dessous d'environ trois applications consommatrices, cela ne vaut pas le coup. Le coût de coordination que la gateway supprime n'existe pas encore, et la même discipline s'obtient avec un module Terraform partagé et une convention. Le seuil n'est pas un nombre de tokens, c'est le point où un changement dans la façon d'accéder aux modèles exige que plus d'une équipe agisse. C'est là que la seconde porte commence à coûter plus que la première.

À lire ensuite

Pour le volet infrastructure et plateforme de l'exploitation de tout cela à grande échelle, les notes de terrain sont sur ercan.cloud, et le hub se trouve sur ercanermis.com.

Références