Comment détecter la dégradation d'une fonction d'IA ?

Une fonction d'IA s'est dégradée lorsque chaque tentative apporte moins de valeur aux utilisateurs, même si toutes les requêtes au modèle renvoient HTTP 200. Cette définition compte. Une fonction peut rester techniquement disponible alors que les réponses deviennent moins utiles, ralentissent, sont remplacées par un contenu de repli, consomment deux fois plus de jetons et poussent les utilisateurs à partir sans rien dire.

J'ai vu des équipes déclarer une correction réussie parce que la courbe d'erreurs était repassée au vert, tandis que le taux d'achèvement continuait de baisser. Elles avaient mesuré l'appel au fournisseur, pas le résultat pour l'utilisateur. Une vérification en production exige un enregistrement par requête qui relie tout le parcours : ce que l'utilisateur voulait faire, les versions de l'application et du modèle, la durée de chaque étape, la sortie produite, le recours éventuel à un repli, le coût et l'action suivante de l'utilisateur.

Les six familles de signaux de cet article répondent à des questions différentes. La latence indique si la fonction répond encore dans un délai utile. Le taux d'erreur trouve les échecs explicites et masqués. Les contrôles de qualité disent si la réponse fait le travail. Le recours au repli révèle une perte de capacité cachée. La dépense en jetons repère les prompts et les boucles inefficaces. L'abandon montre quand les utilisateurs cessent d'attendre ou de faire confiance au résultat. Une correction n'est vérifiée que lorsque la cohorte touchée progresse sur les signaux concernés sans en dégrader un autre.

Commencez par un événement pour chaque tentative

Un événement par requête est la plus petite unité utile de supervision d'une IA en production, car les moyennes ne peuvent pas relier après coup un appel lent, une mauvaise réponse et l'utilisateur qui est parti. Émettez un enregistrement quand la tentative atteint un état terminal. Donnez-lui un identifiant de requête opaque, puis associez cet identifiant aux traces, aux évaluations du modèle, aux coûts et aux événements produit. Ne journalisez pas les prompts ou sorties bruts par défaut. Stockez du contenu expurgé, des empreintes, des classifications ou une référence soumise à vos règles de conservation.

L'événement doit comporter assez de dimensions pour comparer des cas équivalents. Enregistrez au minimum la fonction et le type de tâche, les versions de l'application et du prompt, le modèle et le fournisseur, la catégorie de client ou d'offre, la région, la tranche de taille d'entrée, le mode streaming, l'état, le nombre de nouvelles tentatives, la raison du repli, les jetons d'entrée et de sortie, la latence du premier jeton et la latence totale, le résultat qualité et l'action suivante. Utilisez des libellés à cardinalité bornée pour les métriques. Gardez les identifiants et autres valeurs à forte cardinalité dans les journaux ou les traces.

Un événement terminal peut ressembler à ceci :

{"request_id":"req_7f2c","feature":"support_reply","task":"draft","app_version":"2026.07.4","prompt_version":"p18","model":"model-a","region":"eu-west","input_band":"1k-4k","status":"success","retry_count":1,"fallback":"none","latency_ms":4820,"first_token_ms":910,"input_tokens":1824,"output_tokens":436,"quality":{"policy_pass":true,"schema_pass":true,"grounded":"unknown"},"user_action":"accepted","action_delay_ms":6400}

Cet enregistrement est un contrat d'instrumentation, pas un schéma universel. Une fonction de recherche doit aussi enregistrer le nombre de résultats, l'absence de résultat, les identifiants ou catégories de sources et la validité des citations. Un agent doit enregistrer le nombre d'appels d'outils, la catégorie d'échec, la raison de fin de boucle et l'état des effets de bord. Un classificateur doit conserver la classe prédite, la tranche de confiance et la vérité terrain lorsqu'elle arrive.

Les conventions sémantiques d'OpenTelemetry donnent aux équipes un vocabulaire commun pour la durée des opérations, les attributs du modèle et l'utilisation des jetons. Employez ces noms quand votre instrumentation les prend en charge, tout en gardant les résultats produit à côté. Un span de modèle standard ne peut pas savoir qu'un client a accepté un brouillon ou fermé la boîte de dialogue. Cette dernière jointure relève de l'application.

Avant de modifier le code, capturez une période de référence représentative du même trafic que celui de la vérification. Conservez la requête, les filtres de cohorte, les tailles d'échantillon et le fuseau horaire du tableau de bord. Comparer le trafic professionnel du lundi au trafic gratuit du dimanche peut faire bouger la courbe plus que la correction.

La latence de queue révèle le défaut sous charge

La dégradation de latence apparaît souvent dans la queue avant de modifier la moyenne. Suivez la médiane, les p90, p95 et p99 de latence totale, ainsi que le délai du premier jeton en streaming. La médiane décrit une requête ordinaire. Les percentiles élevés exposent les files d'attente, les limites de débit, les démarrages à froid, les longs contextes, les nouvelles tentatives et une petite région ou catégorie de clients masquée par la moyenne.

Mesurez au moins quatre limites : du clic dans le navigateur à la réponse visible, le temps du serveur d'application, le temps d'appel au fournisseur et le post-traitement. Le fournisseur peut rester rapide tandis que la recherche ou la base de données bloque. Le serveur peut sembler sain alors que le navigateur attend un flux bloqué. Un seul chronomètre conduit l'équipe à corriger la dépendance qui possède déjà un graphique.

Définissez l'objectif de service d'après la patience des utilisateurs, pas d'après un chiffre rond pratique. Pour une fonction de rédaction, vous pouvez demander que 95 % des tentatives éligibles affichent le premier jeton utile dans la fenêtre de patience mesurée dans le produit. Pour une extraction en arrière-plan, la durée totale compte davantage. Établissez ces limites à partir du comportement de référence et des recherches produit, sans copier les seuils d'une autre fonction.

Les histogrammes Prometheus permettent d'agréger les percentiles lorsque les bornes des compartiments correspondent à la décision. La documentation Prometheus rappelle que les résumés côté client et les histogrammes côté serveur ne s'agrègent pas de la même façon. Pour un histogramme classique, cette requête par version est utile :

histogram_quantile(0.95,
  sum by (le, app_version) (
    rate(ai_feature_duration_seconds_bucket{feature="support_reply",status="success"}[10m])
  )
)

N'excluez les échecs que si un graphique d'erreur les couvre juste à côté. Sinon, retirer les délais dépassés fait paraître la latence meilleure pendant une panne. Gardez des vues séparées pour les appels réussis, tous les états terminaux et les délais dépassés. Affichez aussi le volume, car une baisse du p95 lors d'un effondrement du trafic ne signifie pas une reprise.

En streaming, la latence du premier jeton et la latence totale peuvent partir dans des directions opposées. Un prompt modifié peut produire vite un premier jeton, puis divaguer deux fois plus longtemps. La fonction semble réactive alors que le coût de calcul et le délai jusqu'à une réponse utilisable se dégradent. Traitez les deux durées comme des contrôles de mise en production indépendants.

Après correction, comparez les distributions du segment touché et d'un segment témoin inchangé. Exigez assez d'observations pour alimenter la queue. Un p99 calculé sur quelques tentatives n'a aucune valeur. Regardez simultanément la hausse des nouvelles tentatives et la profondeur de file. Un p95 réduit parce qu'un délai plus court abandonne davantage de requêtes est un échange, pas une réparation.

Comptez les échecs silencieux avec les exceptions

Le taux d'erreur doit inclure toute tentative incapable de fournir le résultat promis, pas seulement les exceptions et les réponses hors 2xx. Délais fournisseur, limites de débit, données structurées invalides, sorties vides, refus de politique, échecs d'outils, recherche sans source exploitable, refus de validation et nouvelles tentatives épuisées méritent des catégories terminales explicites. Si l'application les remplace par un texte aimable et renvoie 200, l'utilisateur a tout de même subi un échec.

Utilisez des états terminaux mutuellement exclusifs pour conserver un dénominateur honnête. Commencez par success, user_error, system_error, policy_block et abandoned, puis ajoutez une raison précise. Décidez par écrit si un résultat partiel compte comme un succès. Un rapport sans une section obligatoire peut être un succès partiel dans un éditeur, mais une erreur système dans un export automatique.

Le contrôle de base est tentatives éligibles échouées / toutes les tentatives éligibles. Écartez du numérateur de fiabilité les erreurs utilisateur, comme un format de fichier refusé avant l'inférence, mais affichez-les séparément. Une hausse peut révéler une interface confuse ou un nouveau mélange d'entrées. Montrez le taux et le nombre. Un échec sur deux essais et cinq cents échecs sur un million posent des problèmes inverses que le pourcentage seul décrit mal.

Les nouvelles tentatives ont besoin de leur propre taux et de leur distribution. Amazon Builders' Library explique qu'elles ajoutent de la charge à une dépendance parfois déjà saturée et que plusieurs couches peuvent multiplier le travail. Cet avertissement vaut directement pour les appels d'IA, assez lents et coûteux pour rendre l'amplification pénible. Enregistrez la couche responsable, limitez les essais, appliquez un recul avec dispersion aléatoire et émettez l'échec initial même si un essai suivant réussit.

Surveillez les erreurs récupérées comme signal précoce. Si le succès reste stable tandis qu'une part croissante des requêtes exige un deuxième ou troisième appel, la capacité ou la dépendance s'est déjà dégradée. L'utilisateur subit la latence et l'équipe financière voit la dépense avant que la disponibilité ne bouge.

Alertez sur les consommations rapides et lentes. Une pointe brutale exige une fenêtre courte, tandis qu'un parseur de prompt qui échoue un peu plus pendant plusieurs jours exige une comparaison longue. Découpez par version, modèle, prompt, région, catégorie de client, tranche d'entrée et tâche. N'alertez pas sur chaque tranche. Déclenchez une alerte générale et servez-vous des tranches pour trouver la source.

Pour vérifier la correction, exigez que la raison visée revienne au niveau de référence ou le dépasse et que le total des échecs baisse. Sinon, le code a peut-être seulement renommé l'échec. Inspectez un échantillon d'événements terminaux et confirmez que chaque état correspond à ce que l'utilisateur a reçu.

La qualité exige une vérité tardive et des indicateurs directs

La qualité de sortie n'est pas la disponibilité. Une réponse fluide peut être fausse, non étayée, incomplète, dangereuse, mal formatée ou hors sujet alors que l'infrastructure est parfaite. Mesurez-la avec une grille propre à la tâche et séparez les contraintes absolues des jugements gradués. Un score unique cache la nature de l'échec.

Exécutez les contrôles absolus sur chaque réponse éligible quand c'est possible. Validez le JSON contre son schéma, les champs obligatoires contre les règles métier, les citations contre les sources récupérées, les arguments d'outils contre des listes autorisées et la langue contre la langue demandée. Enregistrez chaque contrôle comme booléen ou motif nommé. Une moyenne ne doit jamais annuler une violation de schéma qui casse l'étape suivante.

L'évaluation graduée exige un échantillon stable et des critères observables. Pour un brouillon de support, notez s'il répond à la demande, utilise les faits du contexte approuvé, n'invente pas de règle et propose une résolution applicable. Conservez la version de la grille, de l'évaluateur et de la règle d'échantillonnage. Lors d'un changement d'évaluateur, exécutez les deux versions sur le même échantillon avant de raccorder leurs séries.

Les évaluateurs automatiques donnent de la couverture, pas une vérité incontestable. Calibrez-les avec des humains, mesurez les désaccords par tâche et langue, et envoyez les cas incertains ou sensibles à des personnes. Un modèle qui note un modèle peut dériver quand l'un des deux change. Si le prompt d'évaluation partage l'angle mort du prompt de production, le graphique peut approuver une mauvaise sortie avec assurance.

Les recommandations de Google sur le ML en production font une distinction utile : la vérité terrain arrive souvent tard ou jamais, donc les équipes ont besoin d'indicateurs indirects et doivent observer leurs variations plus que leur valeur brute. Pour une fonction générative, on peut suivre le respect du schéma, l'appui des citations, la distance d'édition avant acceptation, la régénération, la copie ou l'acceptation, les plaintes et l'achèvement de la tâche suivante. Aucun n'est universel. Un taux de copie élevé peut signaler un excellent brouillon ou un texte que les utilisateurs déplacent ailleurs pour le réparer.

Constituez un petit ensemble continuellement étiqueté à partir de tâches réelles expurgées. Échantillonnez les tranches importantes plutôt qu'au hasard, sinon la tâche facile et fréquente dominera. Incluez les échecs, les longues entrées, les langues rares, les nouveaux clients et les demandes proches des limites de politique. Réévaluez le même ensemble sentinelle à chaque version, puis ajoutez un échantillon tournant de production pour suivre l'évolution du trafic.

Déclarez une dégradation lorsqu'un taux de respect absolu franchit son seuil, qu'un critère gradué baisse nettement avec un échantillon suffisant, ou qu'un indicateur utilisateur évolue comme les conclusions des relecteurs. Ne cherchez pas un chiffre magique. Les preuves sont plus fortes lorsque contraintes, relecteurs et comportement concordent, et plus instructives lorsqu'ils divergent.

Une correction passe lorsque le critère défaillant progresse sur la tranche d'origine sans dégrader la sécurité ni un autre critère sensible. Lisez des exemples avant et après. Les scores agrégés disent qu'une chose a bougé. Les exemples appariés disent si le défaut réel a disparu.

Le repli masque une perte de capacité

Un repli peut maintenir la page alors que la fonction d'IA a déjà échoué. Mesurez son taux comme tentatives ayant servi un repli / tentatives éligibles, par type et par raison. Mesurez aussi sa réussite du point de vue utilisateur. Un conseil statique, une réponse en cache, un modèle réduit et un traitement manuel ne fournissent pas le même service.

Nommez chaque chemin : autre fournisseur, modèle dégradé, cache, modèle déterministe, fonction désactivée ou transfert humain. Indiquez si le changement survient avant l'inférence, après un appel échoué, après validation ou après le délai toléré par l'utilisateur. Ce moment permet de distinguer capacité, qualité, politique et latence.

Les équipes incluent souvent les replis réussis dans le taux de succès principal. La disponibilité paraît stable pendant que la capacité prévue disparaît. Publiez deux taux : réussite du chemin principal et réussite du résultat utile. Leur écart mesure la dépendance au repli. Si le premier chute et le second tient, le repli fonctionne mais le chemin principal reste dégradé.

Fixez un budget de repli selon les promesses produit et la capacité. Un autre modèle convient à un incident bref, mais peut coûter plus cher ou perdre en qualité pendant une semaine. Un modèle de texte évite une page vide sans pouvoir compter comme une recherche achevée. Ajoutez une durée continue maximale au seuil de taux pour qu'un faible trafic ne cache pas un repli laissé actif toute la nuit.

Testez ces chemins par injection contrôlée de pannes. Simulez délai fournisseur, sortie invalide, quota épuisé, contexte absent et validation refusée. Vérifiez que l'événement terminal nomme la cause initiale, le repli choisi, la latence ajoutée et le résultat utilisateur. Un chemin jamais exercé échoue souvent au même moment que le principal.

Après réparation, le succès principal doit revenir et le repli retrouver son niveau de référence. Vérifiez que personne n'a seulement désactivé son compteur ou déplacé la branche. Comparez les appels fournisseur aux succès principaux. Les écarts inexpliqués révèlent souvent une nouvelle tentative ou une route non instrumentée.

La dépense en jetons doit suivre un résultat achevé

La dépense devient un signal de dégradation lorsque la fonction consomme plus de jetons d'entrée ou de sortie pour la même tâche réussie. Le total quotidien mesure surtout le trafic. Suivez les jetons d'entrée, de sortie et de cache, ainsi que le coût monétaire par tentative, puis normalisez par résultat accepté ou achevé.

Les mesures utiles incluent les jetons par tentative éligible, par succès principal, le coût par sortie acceptée et par tâche suivante achevée. Les deux dernières empêchent un modèle bon marché mais inutile de paraître efficace. Découpez par modèle, prompt, fonction, tâche, tranche d'entrée, nombre d'essais et repli. Gardez les prix dans une table versionnée plutôt que d'inscrire les tarifs actuels dans les événements historiques.

Les conventions GenAI d'OpenTelemetry définissent les attributs d'utilisation des jetons et les durées, avec la distinction entrée et sortie. C'est un bon vocabulaire de transport. L'application doit encore relier cette utilisation à accepted, edited, regenerated, abandoned ou au résultat porteur de valeur.

La croissance du prompt mérite ses propres alertes. Séparez les jetons d'instructions statiques, de contenu utilisateur et de contexte récupéré si votre pile le permet. Un bug de gabarit peut dupliquer la conversation, la recherche répéter un passage ou un agent boucler sur les outils. Les limites de sortie peuvent masquer le coût en tronquant et détériorer la qualité. Surveillez donc aussi la raison de fin et le taux de troncature.

Rapprochez les événements applicatifs des exports de facturation. La télémétrie peut se perdre, des essais contourner l'enveloppe principale et le fournisseur compter différemment cache ou raisonnement. Sans identifiant fournisseur, le rapprochement ne doit pas forcément se faire requête par requête, mais les totaux par modèle et période doivent rester dans une tolérance convenue. Enquêtez sur le résidu au lieu d'appliquer discrètement un coefficient.

Une alerte pratique compare le coût par résultat réussi à un budget fixe et à une référence comparable récente. Imposez un volume minimal et excluez les expériences dotées de leur propre budget. Associez ensuite l'alerte aux distributions de jetons. Une moyenne supérieure peut venir de davantage d'entrées longues, tandis qu'un p50 supérieur dans toutes les tranches indique une croissance du prompt ou du contrôle.

Une correction qui réduit les jetons tout en baissant l'acceptation ou en augmentant le repli transfère le coût aux utilisateurs. Vérifiez coût et jetons sur la même cohorte, puis les garde-fous de qualité, d'achèvement et de latence. L'efficacité mesure le travail utile par unité de dépense, pas la plus petite facture.

L'abandon relie la santé du système à la patience

L'abandon est la preuve la plus nette que la fonction a dépassé sa fenêtre utile, mais il exige une définition exacte. Comptez une tentative abandonnée si l'utilisateur ferme ou quitte avant un résultat exploitable, annule la génération, lance une tentative de remplacement sans utiliser la première ou reste inactif au-delà d'un délai propre à la fonction. Gardez ces raisons séparées.

Le dénominateur doit contenir les tentatives éligibles réellement lancées. Ne divisez pas par les pages vues et ne traitez pas toute déconnexion comme un abandon sans vérifier si la tâche a continué et si l'utilisateur est revenu. En arrière-plan, l'abandon peut être la suppression de la tâche ou l'absence d'ouverture du résultat dans un délai défini. Pour un assistant intégré, annuler puis relancer immédiatement est un signal plus fort.

Instrumentez navigateur et serveur avec le même identifiant. Émettez les instants de soumission, premier jeton visible, résultat utile, annulation, navigation, nouvelle tentative, acceptation, édition et achèvement suivant. Les événements client peuvent disparaître à la fermeture d'un onglet. Utilisez un battement ou une livraison de type sendBeacon lorsque c'est pertinent et marquez les résultats incertains. Ne classez pas chaque événement absent comme un utilisateur perdu.

Tracez l'abandon par tranches de latence. Vous obtenez la courbe de patience : part des tentatives abandonnées avant 2, 5, 10 secondes et au-delà, avec des bornes adaptées. Comparez le délai jusqu'au premier résultat utile, pas jusqu'à n'importe quel jeton. Un préambule rapide et vide de sens améliore le premier jeton sans retenir personne.

Mesurez aussi régénération et correction. Les utilisateurs peuvent attendre une mauvaise réponse puis recommencer au lieu de partir. Regroupez abandoned, cancelled et regenerated_before_use dans une vue des tentatives ratées, tout en conservant chaque composant. L'acceptation sans retouche aide, mais les parcours forcés et clics accidentels la rendent imparfaite.

La saison et l'intention compliquent le comportement. Découpez nouveaux et anciens utilisateurs, tâche, appareil et point d'entrée. Comparez même heure et même jour lorsque le trafic varie. Utilisez une fonction inchangée ou un groupe témoin si un ralentissement général, une campagne ou une modification d'interface peut affecter le comportement.

Après correction, la cohorte touchée doit moins abandonner à trafic et intention comparables. Vérifiez que les démarrages n'ont pas baissé parce que le bouton est devenu introuvable. Contrôlez ensuite l'achèvement aval. Retenir plus longtemps les utilisateurs devant un indicateur peut réduire les départs enregistrés tout en dégradant leur expérience.

Segmentez d'abord, agrégez ensuite

La plupart des défauts touchent une tranche avant toute la flotte. Un nouveau prompt peut casser l'espagnol, une route de modèle échouer dans une région, une recherche pénaliser les longs documents ou les données d'un client déclencher une boucle d'outil. La moyenne globale dilue chaque cas.

Ajoutez des dimensions correspondant à une action possible : versions de l'application et du prompt, modèle, fournisseur, région, fonction, tâche, langue, tranche d'entrée, version d'index, groupe expérimental et repli. Pour les agents, ajoutez l'outil et la raison de fin. Employez des catégories de clients respectueuses de la vie privée plutôt que leur identité dans les tableaux partagés.

Ne faites pas de chaque valeur un libellé de métrique. La forte cardinalité coûte cher et rend les requêtes instables. Définissez des tranches bornées pour entrées, sorties, latence et catégorie de client. Gardez les détails exacts dans les traces ou journaux, puis passez d'un agrégat suspect à des tentatives représentatives.

Chaque comparaison de version exige une table de cohortes. Affichez nombre de requêtes et part du trafic avec latence, échecs, contrôles qualité, replis, coût par résultat et abandon. Comparez candidat et témoin, puis période actuelle et référence. Si la composition change, stratifiez ou repondérez avant de conclure.

Le paradoxe de Simpson est fréquent. Chaque tâche peut ralentir alors que la moyenne s'améliore parce que le trafic s'est déplacé vers une tâche rapide. L'inverse peut condamner une bonne version ayant reçu des entrées difficiles. Inspectez toujours les changements par tâche avant le chiffre combiné.

Les canaris séparent l'effet de version de l'effet du temps. Envoyez une part stable et déterministe du trafic éligible au candidat, gardez l'affectation stable par utilisateur ou parcours et journalisez l'éligibilité comme l'affectation. Si seules les affectations réussies atteignent l'analyse, l'expérience comporte déjà un biais de survivant.

Les petites tranches exigent de la retenue. Affichez intervalles de confiance ou incertitude, imposez des nombres minimaux et combinez des fenêtres voisines si possible. N'ignorez pas un défaut grave parce que l'échantillon est petit. Examinez les exemples et appliquez une règle de sécurité absolue. Confiance statistique et gravité opérationnelle répondent à deux questions différentes.

Cette segmentation révèle souvent du code d'application généré par IA qui disperse les appels au modèle entre plusieurs routes sans enveloppe commune. FixMyMess utilise le diagnostic du code et la vérification humaine pour réparer ce type de parcours de production, mais le résultat durable dépend encore d'un contrat d'instrumentation que tout futur code doit respecter.

Une réparation exige une règle de preuve écrite

Une correction est terminée quand une comparaison définie à l'avance montre le rétablissement du signal défaillant, protège les autres et tient assez longtemps sous trafic réel pour couvrir le défaut. « La courbe semble meilleure » n'est pas un critère d'acceptation. Écrivez la règle avant le déploiement afin que l'équipe ne choisisse pas ensuite une période flatteuse.

Suivez cette séquence pour un incident ou une correction planifiée :

1. Figez la cohorte de l'incident. Notez fonction, tâche, versions, route de modèle, régions, tranches d'entrée et période. Conservez des identifiants représentatifs après retrait des données sensibles.
2. Formulez l'échec en termes mesurables. Donnez métrique principale, référence, valeur observée, seuil et échantillon minimal. Ajoutez des garde-fous pour erreurs, contrôles qualité, repli, coût par résultat et abandon.
3. Déployez un canari déterministe. Vérifiez la complétude de la télémétrie avant le code. Candidat et témoin doivent recevoir un trafic comparable et chaque tentative atteindre un état terminal.
4. Comparez distributions et exemples. Comparez le candidat au témoin, puis tous deux à l'historique. Relisez des tâches défaillantes appariées ou un ensemble sentinelle afin qu'une moyenne ne masque pas le défaut initial.
5. Promouvez, attendez ou revenez en arrière selon la règle écrite. Surveillez pendant le cycle de trafic pertinent suivant, puis consignez résultats des requêtes, versions et décision.

Une règle pourrait exiger que le p95 total de rédaction des longs documents repasse sous le seuil antérieur sur le nombre convenu de requêtes, que délais et replis ne dépassent pas la référence, que schéma et notes humaines ne baissent pas, que le coût par brouillon accepté reste dans le budget et que l'abandon progresse face au témoin. Vos valeurs doivent venir de la référence et du risque propres au produit.

La complétude de télémétrie fait partie de la règle. Comparez démarrages et événements terminaux, appels fournisseur et consommation, acceptations et taux connus de livraison client. Si une version perd 15 % des événements terminaux, tous les taux suivants peuvent sembler meilleurs. Bloquez la promotion lorsque les données manquantes suffisent à changer la conclusion.

Séparez les critères de retour arrière des seuils d'alerte. Une alerte demande une enquête. Une règle de retour affirme que le candidat a causé assez de tort pour couper l'exposition. Un seul cas confirmé peut imposer un retour immédiat pour la sécurité ou la qualité, alors qu'une latence modérée exige un échantillon stable.

Effectuez une évaluation en miroir ou par relecture lorsque l'exposition réelle présente un risque élevé, sans l'appeler preuve de production. Une relecture ne reproduit ni les files en direct, ni les limites fournisseur, ni le navigateur, ni l'évolution des données récupérées, ni les réactions des utilisateurs. Elle réduit l'incertitude avant le canari, sans le remplacer.

Le dossier final doit permettre à un ingénieur sceptique de reproduire la décision : cohorte, texte des requêtes, définitions, périodes de référence et candidate, tailles d'échantillon, incertitude, exemples relus, couverture de télémétrie et décision de promotion. S'il n'explique pas pourquoi la situation des utilisateurs s'améliore et ce que cela a coûté, la correction reste une opinion.