Dans Azure Pipelines, une approval qui n'est pas complétée dans son timeout marque le stage skipped, pas failed. Un stage skipped est vert dans la plupart des dashboards et des templates de notification, si bien qu'une promotion de modèle que personne n'a regardée peut conclure un run de pipeline qui annonce un succès alors que le changement n'est jamais parti, ou pire, alors qu'un stage précédent en a déjà fait la moitié. La partie 8 a posé les applications au-dessus de la gateway. Cette partie met la gateway elle-même en production de façon répétable, et transforme l'email de retrait de modèle de la partie 1 en requête de base de données.

Ce qui est réellement déployé

Quatre artefacts, qui changent à trois rythmes différents, et c'est pourquoi ce sont trois pipelines plutôt qu'un seul.

  • L'infrastructure de plateforme du 10-platform de la partie 2 : API Management, AKS, réseau, observabilité. Elle change quelques fois par an, se déploie avec une approval humaine, et personne n'est pressé.
  • Les déploiements de modèles et la configuration de la gateway, la couche 20-models plus le policy XML et la carte d'alias. Change chaque semaine. C'est le pipeline qui a besoin de l'eval gate.
  • La configuration des tenants, la couche 30-tenants. Change à l'onboarding, et c'est le seul endroit où une pull request en self-service venant d'une équipe consommatrice a du sens.
  • Le conteneur du control plane sur AKS. Du CI/CD applicatif ordinaire, et le moins intéressant des quatre précisément parce qu'il est ordinaire.

Le policy XML mérite sa propre note. Il est exécuté à chaque requête, c'est donc du code de production, et il atteint la production par le même pipeline avec la même revue que le Terraform. Le portail sert à lire, pas à éditer, et la façon de faire tenir cette règle est un drift check dans le pipeline qui échoue quand la policy déployée diffère du dépôt.

La service connection, et le minuteur que personne ne règle

Les pipelines s'authentifient auprès d'Azure avec une service connection Azure Resource Manager, et la configuration recommandée est la workload identity federation, avec une app registration ou une managed identity, ce qui retire entièrement les secrets et leur gestion du tableau. Pour une plateforme dont tout l'argument de la partie 5 portait sur le cycle de vie des credentials, un secret stocké ici serait difficile à défendre.

Deux détails opérationnels méritent d'entrer dans le runbook plutôt que d'être découverts. Azure Pipelines désactive automatiquement les service connections inutilisées depuis 100 jours, et il faut un administrateur de la service connection ou un Project Administrator pour les réactiver. Un pipeline qui ne tourne que sur des changements d'infrastructure trimestriels est exactement celui qui déclenche cette règle, et la panne arrive au pire moment, quand quelque chose d'urgent doit être déployé. Et une service connection convertie d'un secret vers la federation peut être rétablie pendant sept jours ; ensuite, un nouveau secret doit être créé à la main, et les connections converties puis modifiées manuellement ne peuvent plus du tout être rétablies via l'outil.

L'eval gate appartient à l'environment, pas au job

L'instinct est d'ajouter une étape d'eval à la fin du job de déploiement. Cela fait de l'eval une chose que le pipeline fait, ce qui signifie que l'auteur du pipeline peut la réordonner, la sauter avec une condition, ou la déplacer après le déploiement qu'elle était censée garder.

Azure Pipelines a la bonne primitive : des checks sur l'environment ou sur la service connection que le stage consomme. Avant qu'un stage ne s'exécute, tous les checks sur toutes les ressources qu'il utilise doivent être satisfaits, et une seule décision négative refuse le stage. Configurez l'eval comme un check Invoke REST API qui appelle le service d'eval du control plane, et le gate cesse d'appartenir à la définition du pipeline pour appartenir à l'environment.

Les règles de finalité comptent ici. Les décisions des approvals et de la plupart des checks sont finales. Les checks Invoke Azure Function et Invoke REST API sont l'exception, ils peuvent être réexécutés, et si vous définissez un time between evaluations non nul, la décision du check devient non finale et il sera réévalué. Pour un eval gate, c'est un choix de conception plutôt qu'un détail : un check non final qui se réévalue en continu convient à « l'eval doit encore passer au moment où ce stage démarre enfin », et un check final convient à « ce build a passé ses evals, expédiez-le ». Choisissez l'un des deux, et sachez que la forme asynchrone configurée de la manière recommandée est finale.

Ajoutez une approval humaine par-dessus l'eval, sur l'environment de production, avec l'option restrict approvers from approving their own runs activée. Et réglez le timeout délibérément, à cause de l'ouverture de ce billet : une approval qui expire marque le stage skipped, et skipped se lit comme du vert. La parade tient en trois gestes : un timeout court, une alerte portant spécifiquement sur les stages skipped, et ne jamais traiter un pipeline vert comme la preuve qu'un déploiement a eu lieu.

Ce que l'eval vérifie réellement

Un golden set de cas qui comptent pour les consommateurs de la plateforme, versionné dans le dépôt à côté du policy XML, exécuté contre la configuration candidate à travers la gateway plutôt que contre un endpoint de modèle. Ce dernier point est ce qui en fait une eval de plateforme et non un benchmark de modèle : il exerce la résolution d'alias, les policies, le filtre de content safety et le chemin de retrieval, qui peuvent tous casser une réponse sans que le modèle change le moins du monde.

Trois seuils, et le troisième est celui que l'on saute. Un score de qualité agrégé contre le golden set. Un budget de latence, parce qu'un modèle marginalement meilleur et nettement plus lent n'est pas une amélioration pour un assistant interactif. Et une liste de régressions : des cas précis qui ne doivent pas se dégrader, quelle que soit la moyenne. Une nouvelle version de modèle qui améliore la moyenne tout en cassant les trois prompts dont dépend l'équipe du service client est la forme normale d'une mauvaise promotion, et seule la liste de régressions l'attrape.

Promotion, canary et rollback sont un seul mécanisme

Parce que la partie 3 a placé un alias devant un backend pool, un changement de version de modèle ne touche aucune application. C'est un changement de configuration à trois formes :

  • Canary : ajoutez le nouveau déploiement au pool de l'alias avec un poids faible dans le même groupe de priorité. Une petite part du trafic y va, les métriques de la partie 5 montrent les écarts de latence et de tokens par alias de modèle, et rien n'a dû être redéployé.
  • Promotion : déplacez les poids, puis retirez l'ancien déploiement du pool.
  • Rollback : le changement de poids inverse. Des secondes, pas un redéploiement, ce qui est tout l'argument de l'existence de l'alias.

La seule chose que cela ne fait pas, c'est rendre les réponses identiques de part et d'autre de la frontière du canary. Deux versions de modèle servant le même alias produisent des sorties différentes pour le même prompt, donc tout ce qui met en cache, compare ou rejoue des réponses doit savoir quelle version a répondu. C'est un champ de log, ajouté en même temps que le canary, pas après coup.

Le retrait, désormais une requête

L'email de retrait de la partie 1 a coûté deux jours de grep à travers les dépôts. Il devrait désormais coûter une requête, parce que trois décisions antérieures ont rendu la réponse connaissable. La partie 2 a épinglé les versions de modèles et réglé version_upgrade_option délibérément, donc aucun déploiement ne bouge de lui-même. La partie 3 a placé chaque application derrière un alias, donc la correspondance entre alias et déploiement est une donnée. La partie 5 a loggé chaque requête avec son tenant et son modèle résolu, donc l'ensemble des tenants qui ont réellement utilisé un déploiement dans les 30 derniers jours est une requête de logs plutôt qu'une supposition.

Le runbook de retrait tient alors en quatre étapes qui rentrent dans un ticket : interroger quels tenants ont utilisé le déploiement récemment ; monter le déploiement de remplacement et exécuter l'eval gate contre lui ; passer l'alias en canary et surveiller la liste de régressions ; basculer et retirer. Les applications n'apprennent jamais que quoi que ce soit s'est passé, et c'est le résultat pour lequel toute la série existait.

Modes de défaillance à surveiller

  • Skipped lu comme réussi. Une approval expirée saute le stage. Alertez explicitement sur l'état skipped, dans la notification du pipeline et dans le dashboard que l'équipe regarde vraiment.
  • L'eval comme étape de job. Si elle peut être réordonnée ou neutralisée par une condition, c'est de la documentation. Comme check d'environment, c'est un gate.
  • Le bypass sans visibilité. Contourner un check exige une permission d'administrateur sur la ressource et enregistre qui l'a fait, ce qui est une bonne chose, et vaut d'être remonté dans une revue hebdomadaire plutôt que laissé dans le panneau des checks.
  • Une service connection désactivée à 100 jours. Le pipeline d'infrastructure trimestriel le découvre pendant un incident.
  • Des éditions de policy dans le portail. Sans drift check, un hotfix fait dans le portail survit jusqu'à ce que le prochain déploiement l'écrase en silence, ce qui est le pire timing possible.
  • Un jeu d'eval que personne ne met à jour. Un golden set inchangé depuis un an mesure le produit de l'an dernier.

Ce dont hérite la partie 10

Une gateway qui part en production par des pipelines, avec les evals comme gates et les changements de modèles comme configuration. Chaque mécanisme de la série est maintenant en place, et chacun émet quelque chose. La dernière partie traite de quoi en faire : les traces, les evals en production plutôt que dans le pipeline, les questions de gouvernance que pose l'EU AI Act, et les chiffres promis par la partie 1.

À 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