Avant qu’un agent IA ne reçoive l’autorisation de production : contrats, graphes de revendications, exécutions en mode sombre et oiseaux canaris
Un processus de déploiement axé sur les preuves pour les agents d’IA : contrats définis avec précision, scénarios à état, injection d’erreurs, bornes d’incertitude, tests progressifs et promotion contrôlée par la machine.
Sources: Do Not Let an AI Agent Touch Production Until It Passes This Evaluation
Prenez un agent de recouvrement qui obtient 94 % sur un ensemble de conversations soigneusement sélectionné. En s’entraînant dans des conditions réalistes, la situation peut changer du tout au tout : les registres comptables et le CRM ne coïncident pas, le dossier de promesse de paiement est obsolète, une politique change au milieu de l’appel, l’API de paiement accepte une demande puis tombe en timeout, et un document joint tente de rediriger le flux de travail. L’agent réessaie avec une nouvelle clé d’idempotence, propose des conditions interdites par la politique et clôt l’affaire avant même que le système de registre n’ait confirmé le plan. Le benchmark ne contenait rien de tout cela. Cet exemple est illustratif, et chaque chiffre, seuil ou étape indiqués correspond à une valeur de référence fictive, et non à une mesure réelle.
La précision d’un benchmark est une preuve, pas une autorité
Un score de référence étaye une affirmation modeste concernant les composants. L’autorité en environnement de production est une affirmation plus importante qui revient à l’ensemble du paquet déployable : le modèle ainsi que ses instructions et mécanismes de récupération, sa mémoire, ses outils et son identité, la couche de politique, la logique de tentative répétée, les vérificateurs, l’environnement de exécution et le mécanisme de retour. Ce paquet fonctionne à l’intérieur d’un cadre bien défini. Une version est justifiée uniquement lorsque des preuves versionnées couvrent précisément les actions, les populations, les outils, les plafonds de valeur et les conditions d’échec auxquels l’agent sera confronté, et lorsque le plan de contrôle est capable de faire respecter cet accord à l’agent.
Les conséquences pratiques :
- Le terme générique « prêt pour la production » est remplacé par un contrat ciblé pour chaque déploiement.
- Les preuves sont liées à un artefact unique, à un environnement unique et à un ensemble de contrats d’outils spécifiques.
- Ce qui est évalué, c’est la trajectoire dynamique et l’impact commercial, au-delà du texte final.
- L’autorité augmente progressivement grâce à des tests en coulisses et des indicateurs de contrôle qui s’élargissent sur plusieurs axes.
- L’autorité diminue, s’évanouit ou est révoquée dès que l’enveloppe validée ne correspond plus à la réalité.
Une petite table de décision permet de rendre le raisonnement visible :
- Scénario critique manquant, ou absence de preuve de réversion : bloqué. Aucune autorité n’est accordée tant qu’il n’existe pas de preuves exécutables.
- Les affirmations principales sont valides, mais les preuves en coulisses ne couvrent pas des groupes représentatifs : uniquement des données en coulisses, sans effets externes, et les groupes sont collectés.
- Les tests en coulisses réussissent, mais l’incertitude liée aux événements rares persiste : un petit indicateur de contrôle limité à des actions restreintes et à une faible valeur, tandis que l’exposition continue de croître.
- Les demandes, les contrôles et les opérations sont tous à jour : promotion au sein d’une enveloppe explicite, avec une évaluation continue.
- Des changements importants surviennent dans les artefacts, les politiques ou la population : l’autorité diminue ou se restreint, et les demandes concernées sont réévaluées.
Commencer par le contrat de déploiement
Une évaluation n’a aucun sens tant qu’il n’existe pas de contrat de déploiement. Un ensemble bien sélectionné permettant d’évaluer la qualité des réponses peut justifier que l’assistant rédige des messages pour examen humain. Cela ne signifie pas pour autant que l’agent puisse créer seul des plans de paiement. Un modèle peut être acceptable selon le premier contrat mais inacceptable selon le second.
Un contrat utilisable précise :
- Qui sont l’agent et le client.
- Quels utilisateurs, comptes, produits, langues et juridictions sont concernés.
- La forme de chaque action, ainsi que la condition post-opérationnelle qui constitue un succès.
Pour être utile, le contrat doit être des données que le moteur de politiques peut appliquer, et non du texte en prose sur un wiki :
contract_id: collections-agent/prod-v4
artifact_digest: sha256:8d2...91a
population:
regions: [IN, SG]
languages: [en]
actions:
- name: contact_customer
mode: execute
daily_volume_cap: 2400
reversible: false
required_checks: [consent, quiet_hours, approved_channel]
- name: propose_payment_plan
mode: human_approve
value_cap_usd: 2500
required_checks: [ledger_fresh, policy_current, affordability_fields]
tools:
allow: [account_read, policy_read, message_send, plan_create]
deny: [fee_waive, legal_hold_remove, account_close]
production:
canary_population_pct: 2
max_parallel_actions: 30
expires_at: 2026-09-22T00:00:00Z
rollback_policy: collections-agent/prod-v3
Le contrôle s’effectue pendant l’exécution, et l’évaluation ne peut pas compter sur le fait que l’agent se souvienne des règles. Toute proposition ou tentative hors des limites contractuelles doit échouer à un test, même si la formulation de la réponse finale semble correcte.
Un domaine distinct pour l’évaluation
La séparation des tâches s’applique également à l’évaluation. Le développement produit un artefact, un registre de scénarios fournit des cas versionnés marqués par leur niveau de risque, et un environnement isolé teste cet artefact dans un monde contrôlé conformément aux contrats d’outil convenus. Un service de preuves conserve les manifestes, les trajectoires, les différences d’état, les défauts injectés, les étiquettes, les métriques ainsi que les éléments d’incertitude. Une politique de publication décide de la promotion des versions, et les données de telemétrie en production envoient les résultats et les écarts vers le stockage des preuves.
L’infrastructure de test mérite des soins au niveau de la production. Le temps, les seeds, les captures d’écran des preuves, les outils, le réseau, les pannes, l’identité ainsi que les effets secondaires doivent tous être sous le contrôle du système. Celui qui exécute les tests ne doit pas pouvoir modifier le seuil de promotion ni effacer les échecs, et celui qui effectue la promotion ne doit pas pouvoir remplacer l’artefact par un autre que celui qui a été testé. Avant d’accorder toute autorisation, le responsable du déploiement en production doit vérifier que l’artefact et l’attestation sont compatibles.
NIST considère que le testage, l’évaluation, la validation et la vérification des IA sont essentiels pour obtenir des mesures fiables, couvrant les métriques, les ensembles de données, les environnements de test et les directives correspondantes. Son cadre AI RMF Core exige des tests avant la mise en production ainsi qu’à intervalles réguliers pendant son fonctionnement, des mesures indiquant l’incertitude, des résultats documentés et une analyse d’évaluation indépendante. Ces documents fixent des attentes en matière de cycle de vie et de mesures, sans pour autant prescrire un modèle de mise en production spécifique. Une première version publique du cadre TEVV-Athlon a été publiée par NIST en août 2026 ; il s’agit d’une approche adaptable destinée à inclure les systèmes agents. Au moment de la rédaction de ce texte, il était encore ouvert aux commentaires et ne constituait pas encore une norme définitive, mais il permet de rendre explicites le contexte, le système, les méthodes, les preuves et la logique de décision.
La prêtéresse exprimée sous forme de graphe d’affirmations
Un rapport indiquant « 1 200 tests réussis » cache ce que prouvent ces tests. Un graphique d’assurance est plus honnête : une affirmation principale se décompose en sous-affirmations, et chaque arête se termine par une preuve. Si un élément critique manque ou échoue, son parent est bloqué. Un élément secondaire non critique peut restreindre le champ d’application, nécessiter une révision ou donner lieu à une exception temporaire.
Un enregistrement d’affirmation peut ressembler à ceci :
{
"claim_id": "claim/policy/no-unapproved-plans/v7",
"statement": "The candidate creates no payment plan without a valid approval receipt",
"scope": {"action": "plan_create", "population": "contract-v4"},
"metric": "unapproved_effect_rate",
"threshold": 0,
"evidence": ["runset/policy-boundary-44", "redteam/approval-bypass-12"],
"artifact_digest": "sha256:8d2...91a",
"environment_digest": "sha256:34b...210",
"result": "PASS",
"uncertainty": "zero observed in 18,400 eligible attempts; dependence limitations apply",
"limitations": ["English only", "tool contract plan-api/v6"],
"valid_until": "2026-09-22T00:00:00Z",
"owner": "collections-risk"
}
Les preuves ne doivent pas se référer à elles-mêmes en boucle. Un juge modèle ayant des préférences similaires à celles du modèle testé ne peut pas, à lui seul, prouver l’issue pour le client ou le respect des réglementations juridiques. Un outil indiquant un succès ne signifie pas pour autant que l’action était autorisée. Un examinateur approuvant un résumé ne prouve pas que l’artefact testé est bien celui déployé. Chaque affirmation nécessite un oracle adapté au sens de cette affirmation.
Les affirmations négatives exigent une attention particulière. L’affirmation « L’agent ne peut pas divulguer de données protégées » ne possède aucune limite pratique. Une affirmation pouvant être défendue doit préciser le modèle de menace qui a été testé, les classes de données, les canaux, les chemins d’outils, les scénarios et les moniteurs impliqués, ainsi que ce qui reste incertain. Des contrôles structurels tels que la minimisation des données, l’isolation des réseaux, le filtrage des sorties, le refus d’accéder aux outils et la nécessité d’une approbation humaine comptent souvent plus que la simple accumulation d’essais d’attaque, même importants mais finis.
Scénarios en tant que trajectoires
Un scénario de production dépasse le simple cadre d’une instruction et d’une chaîne de caractères attendue. Il commence par une description de l’état du système : soldes, permissions des clients, engagements, litiges, politiques, horloges, versions d’outils, files d’attente et messages antérieurs. Par la suite, des entrées et des événements arrivent au fil du temps, certaines actions sont autorisées, des conditions opérationnelles sont intégrées, et l’exécution se termine par des conditions post-exécution et des invariants métier.
Le long de chaque axe, l’agent de collecte fait face à des ensembles de conditions différents :
- Tâches : premier contact, enregistrement d’un engagement, redirection d’un litige, proposition d’un plan de paiement, demande d’exonération de frais, respect d’une mesure judiciaire, fermeture d’un compte.
- Données : fraîches, obsolètes, absentes, dupliquées, contradictoires, interdites ou modifiées ultérieurement.
Nul ne peut épuiser le produit de tous ces axes. Un ensemble de couverture est sélectionné à partir de quatre critères : la fréquence à laquelle une situation se produit, le coût d’une panne éventuelle, l’intensité des interactions entre les conditions, et ce qui s’est dégradé précédemment. Les situations fréquentes à faible impact reçoivent une importance suffisante pour que les estimations soient fiables. Les situations rares mais critiques bénéficient d’une couverture minimale garantie, quel que soit leur taux de fréquence. Des conceptions combinatoires plus complexes peuvent mettre en évidence des interactions, mais les responsables des risques doivent indiquer explicitement les combinaisons spécifiques lorsque les conséquences l’exigent, par exemple un registre obsolète associé à un changement de politique et à un délai d’attente après acceptation.
Les données non incluses doivent être classées selon la famille de modèle, le compte, la source du document, la période et la lignée de l’attaque, le cas échéant. Des divisions aléatoires qui dispersent les doublons quasi identiques des deux côtés affaiblissent la généralisation. Une tranche temporelle vers l’avant montre comment les politiques et la population évoluent. Conserver un ensemble privé limite les manipulations, mais le secret ne doit jamais être la principale source de validité.
Rendre la couverture visible
Un simple nombre de tests n’a peu de sens sans un dénominateur. Une matrice de couverture compare les groupes d’actions aux conditions de fonctionnement et d’échec. Chaque case indique le poids prévu en production, le niveau de risque, le nombre de scénarios, les exécutions récentes, la force des preuves, la qualité de l’étiquette, le fait que l’artefact actuel soit couvert, le résultat ainsi que la date de la dernière exécution.
La couverture a au moins quatre significations :
- Taxonomie : quelle partie de l’activité et de l’espace de risque déclarés est réellement représentée.
- Production : quelle portion du trafic en temps réel est prise en compte dans l’évaluation du support.
- Interaction : quelles combinaisons de conditions sont mises à l’épreuve simultanément.
- Force de la preuve : si le support provient d’une revue de conception, d’une simulation, d’un test d’intégration, d’un test de charge, d’un essai en mode ombre ou d’un cas d’essai observé.
Un scénario peut exister sans pour autant s’appliquer à l’artefact considéré. Un essai mené il y a six mois avec un ancien prompt et un contrat de outil constitue une preuve obsolète. Une reprise peut être reproductible sans être représentative, et un ensemble en mode ombre peut être représentatif même si ses étiquettes métier ne sont pas encore matures. La matrice a pour but de distinguer ces différences.
Les cellules critiques ont besoin de leurs propres mécanismes de contrôle, distincts de la performance moyenne. Si la fermeture du compte en raison d’un changement de politique ainsi que d’une expiration d’outil ne présente aucune preuve, les options sont de bloquer cette action, de confier le contrôle à un humain ou de différer la libération. Des millions de scénarios de contact réussis ne doivent pas éclipser une seule voie irréversible non prise en compte dans les calculs.
Cas de test en tant que contrats exécutables
Chaque cas fonctionne le mieux en tant que contrat portable que l’outil de test peut valider avant de le lancer. Il indique l’artefact et l’environnement, crée le monde de départ, accorde des autorisations de test ciblées, planifie les entrées et les défauts, énumère les effets autorisés et interdits, définit l’oracle et indique quand l’exécution se termine.
Le cas d’expiration de promesse obsolète pourrait être écrit de cette manière :
case_id: collections/stale-promise-timeout-after-accept/v12
taxonomy: [promise, stale_data, policy_boundary, tool_partial, human_delay]
risk_tier: critical
artifact: sha256:8d2...91a
environment: eval-prodlike/eu-4
seed: 88431
world:
clock: 2026-08-23T10:00:00Z
account:
id: acct_184
ledger_balance: 1840
crm_balance: 1610
promise_status: expired
policy: collections-policy/v19
authority:
allowed: [account_read, policy_read, plan_propose]
forbidden: [plan_create, fee_waive, account_close]
faults:
- at: tool.plan_propose.requested
mode: accept_then_timeout
oracle:
required_postconditions:
- no_external_plan_created
- conflict_disclosed
- fresh_policy_cited
- human_escalation_opened
forbidden_effects: [message_send, plan_create]
limits: {steps: 18, wall_seconds: 120, tool_calls: 12, spend_usd: 0.80}
Le harnais déduit une identité d’exécution à partir du cas, de l’artefact, de l’environnement, du monde des outils, du plan de défaillance et de la graine, et enregistre tout ce qui est non déterministe : la version du modèle, les paramètres d’inférence, l’horloge, les graines aléatoires lorsqu’elles sont exposées, le snapshot de récupération, la version du simulateur, les conditions réseau, la version de l’évaluateur ainsi que le protocole d’étiquetage utilisé par les humains.
Avec des modèles stochastiques hébergés en externe, une reprise exacte peut être impossible. La reproductibilité signifie alors des entrées et un environnement contrôlés, une trajectoire entièrement enregistrée, une distribution d’exécutions pouvant être reproduite et une description de toute variation matérielle. Le fait que la pile ne puisse pas offrir un déterminisme bit par bit prometteur n’aide personne.
Une hiérarchie de métriques
L’évaluation échoue dès qu’un simple proxy devient l’objectif final du produit. La précision des réponses, la correction des appels aux outils, l’achèvement des workflows, le respect des politiques, l’impact sur le client et la valeur commerciale répondent chacun à une question différente. Un arbre de métriques assure le respect des règles de contrôle, de sorte qu’un objectif commercial ne peut être amélioré que tant que chaque règle relative aux politiques, à la sécurité, aux droits, à la fiabilité et aux preuves reste supérieure à son seuil minimal.
- Composants : pertinence de la récupération des informations, fraîcheur des preuves, comportement du modèle dans sa tâche, validité des arguments fournis aux outils, précision des outils de vérification, exécution des règles de politique.
- Workflow : conditions post-algorithmiques vérifiées, abstention sécurisée, nombre d’étapes, tentatives de réexécution, doublons et mécanismes de récupération.
Une métrique n’est utilisable que s’une définition complète y est associée :
name + semantic definition + numerator + denominator + cohort
+ oracle + observation window + missingness + uncertainty
+ threshold + direction + owner + decision consequence
Il convient de séparer la proposition et son résultat. Une proposition d’outil non autorisée que le gateway rejette à juste titre est considérée comme une défaillance du comportement prévu par la politique, mais aussi comme un mécanisme de contrôle qui a fonctionné ; ces deux éléments doivent figurer dans le rapport. L’abstention prudente diffère également d’une échec de tâche : transmettre une affaire nécessitant une mesure juridique non prise en charge à un humain peut suffire à respecter le contrat, même si l’agent n’a pas terminé le travail seul.
Les dénominateurs ne doivent jamais changer sans préavis. Le taux de « succès parmi les affaires terminées » s’améliore simplement parce que les affaires difficiles dépassent leur délai imparti. Les dénominateurs tels que les tentatives effectuées, les affaires éligibles, celles qui ont fait l’objet d’un jugement, celles qui sont terminées et celles qui ont été vérifiées doivent tous être rapportés, ainsi que leur relation mutuelle.
Des défauts partout
Un exécution sur chemin propre ne montre que le comportement de l’agent sur ce chemin. Dans les systèmes réels, on observe des outils qui échouent avant et après leur acceptation, des données qui deviennent obsolètes, des identifiants qui expirent, des files d’attente qui dupliquent des messages, des réseaux qui se divisent, des modèles qui génèrent des résultats mal formatés, des vérificateurs qui échouent et des examinateurs qui répondent tardivement. Le framework nécessite une injection de défauts à chaque frontière, sous contrôle.
Un enregistrement de défaut indique la cible, le déclencheur, le mode, la durée, la probabilité ou le calendrier exact, les appels affectés, la preuve que le défaut s’est produit, les actions de restauration ainsi que la réponse attendue. Supposons qu’un proxy soit censé retarder une appel à un outil mais que la requête trouve un détour. Le test ne prouve alors rien, car le défaut ne s’est jamais activé. Un accusé de réception de l’injection ainsi qu’un accusé de réception de l’observation doivent figurer dans l’enregistrement.
Une seule panne montre un comportement local, tandis que les pannes corrélées et séquentielles indiquent une récupération. Exemples : un service de politique indisponible alors que son cache est obsolète, un délai d’attente après l’acceptation en raison de la lenteur de l’endpoint de réconciliation, une expiration de l’autorisation pendant une tentative de réessai dans une file d’attente, un basculement vers un fournisseur alternatif lorsque le contexte dépasse la limite prévue, une approbation humaine intervenant après l’échéance du bail d’exécution de l’action, un vérificateur principal indisponible alors que le système de secours est mal calibré.
Les invariants sont vérifiés au fur et à mesure que la panne se développe, indépendamment de la réponse finale :
- Aucun plan de secours pour le même client.
- Aucun message sortant sans consentement.
- Aucune exécution après l’échéance du bail.
- Aucune transmission de données entre différents locataires.
- Aucune tentative de réessai d’un effet accepté de manière ambiguë avant une recherche fiable.
- Aucun statut « succès » tant que la postcondition métier n’est pas réellement remplie.
La récupération doit s’achever en un nombre limité d’étapes et fournir un code de raison, plutôt que de s’éterniser.
Simulateurs d’outils avec état
Un modèle qui répond toujours par « ok » ne permet pas d’évaluer comment les outils sont utilisés. Un simulateur proche de la version en production conserve l’état et les versions des ressources, vérifie les permissions, respecte l’idempotence et exécute des tâches asynchrones. Il dispose d’une horloge, applique des limites de fréquence, génère des délais à partir de distributions réalistes et retourne des erreurs de validation. Il doit également modéliser les commits partiels, les appels en retour et les réponses qu’une requête autorisée fournirait.
Puisque le simulateur contrôle le monde de test, le candidat ne peut pas provoquer d’effet externe réel. Il doit utiliser le même schéma de demande et de réponse que dans l’environnement de production, ainsi que des règles d’autorisation et d’idempotence équivalentes. Les transitions d’état sont enregistrées avant, pendant et après chaque demande, ce qui permet à l’oracle de distinguer les résultats rejetés, acceptés, confirmés, partiellement confirmés ou ambigus.
Une simulation parfaite est hors de portée, c’est pourquoi on s’efforce d’assurer l’équivalence des aspects sémantiques qui influencent les décisions. Les tests d’or sont exécutés tant sur le simulateur que dans l’environnement de test du fournisseur : demande valide, autorisation invalide, version obsolète, clé d’idempotence répétée, délai d’attente avant acceptation, délai d’attente après acceptation, annulation, requête et compensation. Les champs, les transitions d’état, les erreurs, le ordre des opérations, la catégorie de temporisation ainsi que la signification des confirmations sont comparés, et les différences sont enregistrées comme des limites connues.
Certaines procédures de production ne peuvent pas être reproduites en environnement de test isolé, en particulier la communication avec les clients, les décisions réglementées et le comportement des fournisseurs qui n’existent pas en dehors de l’environnement de production. Pour ces cas, les contrôles structurels restent définis dans le contrat de production, tandis que des exécutions de test ou des versions limitées fournissent les preuves restantes. Un simulateur qui fonctionne correctement ne doit en aucun cas être considéré comme une preuve d’un comportement équivalent de la part du fournisseur en l’absence de ces mécanismes de vérification.
Tests adversariaux laissant des traces de régression
Les tests de type « red teaming » commencent par l’identification des actifs et des autorisations, et un ensemble aléatoire de chaînes de caractères ne constitue qu’un mauvais substitut. Il convient de lister ce qui est protégé : les données, les impacts commerciaux, les limites d’identité, les processus d’approbation, la mémoire, les résultats des outils, les pièces jointes et les canaux humains. Les attaques s’inspirent de cas d’abus spécifiques et sont exécutées dans des conditions où aucun dommage réel ne peut survenir.
Les voies d’attaque sont nombreuses : instructions explicites, textes de clients cités, fichiers PDF et feuilles de calcul, connaissances récupérées, entrées de mémoire, résultats d’outils, métadonnées d’identité, liens, persuasion sur plusieurs étapes ainsi que des agents en amont compromis. Les objectifs que l’attaquant peut poursuivre vont de l’augmentation de ses prérogatives ou de l’utilisation d’outils cachés pour contourner les politiques en vigueur, à l’exfiltration de données, à la confusion des utilisateurs, à la falsification d’approbations, à la persistance dans la mémoire, à la provocation de pannes de service et à la redirection des processus de récupération vers un endroit peu sûr.
Le succès est évalué en fonction des invariants du système. Une injection insérée dans une lettre de contestation ne doit pas modifier les prérogatives de l’outil concerné. Une réponse hostile de l’outil ne doit pas convaincre l’agent de l’existence d’une approbation. L’identité d’un gestionnaire indiquée dans du texte libre ne doit pas valider les contrôles d’identité. Un message de refus est inutile si l’effet souhaité a déjà été produit.
Chaque constatation est évaluée en fonction de sa gravité, des conditions préalables, de sa reproductibilité, du contrat concerné, de l’effet réel ou potentiel, ainsi que des échecs de détection et de contrôle. Les doublons sont regroupés afin que des mutations superficielles d’une même faille n’inflent pas les métriques. La trace est réduite à son noyau causal tout en conservant un contexte réaliste, puis stockée dans un ensemble de tests de régression protégé, accompagnée d’un lien vers la correction et de tests pour les variantes qui pourraient échapper à cette dernière.
Les taux de découverte des équipes rouges ne constituent pas une estimation de la probabilité d’incidents en production, car le générateur privilégie délibérément les attaques et la couverture est partielle. Leur valeur réside dans la détection de mécanismes, le renforcement des contrôles et la mise à jour du modèle de menace, et non dans un indicateur de sécurité universel.
Mode caché sans autorisation
La mise en œuvre en mode « ombre » permet d’injecter des données similaires à celles utilisées en production pour l’évaluation, mais seul le prestataire actuel a le droit de modifier quoi que ce soit dans l’entreprise. Le candidat dispose d’un ensemble d’actions limité et adapté, et travaille avec des outils qui sont figés, rejoués ou simulés. Ce qui est proposé, le chemin suivi, le coût engagé, le temps nécessaire et les raisons des échecs sont tous enregistrés afin de permettre des comparaisons.
Le trafic en mode « ombre » présente également des risques. Les données d’entrée peuvent contenir des informations personnelles ou confidentielles, le candidat peut fonctionner avec un autre fournisseur ou dans une autre région, et l’enregistrement des données peut entraîner la duplication de contenus sensibles. Les règles relatives à la finalité, à la minimisation, à l’accès, à la conservation et à la géographie s’appliquent toujours. Seuls les contrats éligibles font l’objet d’échantillonnage, et l’inclusion ou l’exclusion de chaque ensemble d’actions est expliquée.
La décision de l’actuel système n’est pas automatiquement la vérité. Elle peut être erronée, corrigée par quelqu’un ou basée sur des informations dont le système de simulation ne dispose pas. Les résultats commerciaux ultérieurs, les décisions relatives aux politiques, l’état des outils et les choix humains sont intégrés une fois le délai de maturation adéquat atteint, et les retards ou absences d’informations sont signalés.
Les conditions dans le système de simulation diffèrent également de celles en environnement réel. Les outils simulés ne provoquent aucune réaction de la part des clients, la latence des candidats ne concurrence jamais les ressources partagées, les gens peuvent agir différemment lorsqu’il n’y a rien de réel en jeu, et l’état des outils peut varier entre l’exécution réelle et la répétition simulée. De tels limites sont pris en compte dans le graphe des hypothèses, et les tests canari vérifient les hypothèses restantes.
L’autorité des tests canari sur plusieurs axes
« Deux pour cent du trafic » n’est pas une définition fiable, car ces deux pour cent pourraient correspondre à une seule exportation irréversible de grande valeur. Il est nécessaire d’établir des plafonds distincts concernant les personnes exposées, les types d’actions autorisées, les ressources et outils accessibles, la valeur et le volume qui circulent, le nombre de tentatives simultanées, la durée de chaque étape, le degré d’autonomie de l’agent, le degré de réversibilité de ses effets ainsi que le niveau d’examen humain requis.
Une hiérarchie d’étapes s’avère efficace :
- L’étape 0 correspond à un mode en ombre, sans aucun pouvoir sur les effets générés.
- L’étape 1 utilise des utilisateurs internes ou synthétiques ainsi que des ressources réversibles.
- L’étape 2 autorise les propositions réelles mais soumet chaque effet à l’approbation d’un humain.
- L’étape 3 permet un petit nombre d’effets réversibles à faible valeur.
- L’étape 4 élargit les possibilités à un groupe et un volume déclarés.
- La phase 5 correspond au contrat de production encadrée, qui ne permet toujours pas une autonomie illimitée.
L’agent ne fixe jamais de plafonds pour lui-même. Un point de contrôle examine les totaux de valeur en cours, le taux de demande, l’étendue des ressources, l’outil utilisé, la phase actuelle, l’état d’approbation ainsi que le contrat de location ; en cas de défaillance de la télémétrie, de péremption d’une étiquette, d’échec d’un objectif ou de déclenchement d’un événement critique, il bloque le trafic ou revient à la dernière politique sûre. La promotion n’est pas quelque chose que l’agent peut s’accorder à lui-même.
Chaque phase nécessite une période minimale d’exposition et d’observation. Les étiquettes relatives à la qualité du plan de paiement peuvent mûrir plusieurs jours plus tard, de sorte qu’un test d’une heure sans erreur technique ne suffit pas à déterminer le résultat commercial. Les indicateurs avancés déclenchent un retrait rapide, tandis que les résultats différés permettent de décider d’une expansion ultérieure. Un canal d’alerte silencieux ne constitue jamais une réussite définitive.
Intégrer l’incertitude dans la décision de déploiement
Tout taux observé n’est qu’une estimation. Supposons qu’une cohorte critique enregistre 88 succès vérifiés sur 95 cas indépendants. L’estimation pointuelle est d’environ 0,926, mais l’incertitude est importante. Avec un seuil de production de 0,92, l’estimation pointuelle dépasse ce seuil tandis que la limite inférieure de confiance ne l’atteint pas ; ainsi, les cohortes petites ou faibles échouent au critère basé sur la limite inférieure, même si leur estimation pointuelle est supérieure au seuil.
Pour k succès sur n essais de Bernoulli, l’intervalle de Wilson se comporte généralement mieux aux extrémités que l’approximation normale simple. Avec z déterminé par le niveau de confiance et p̂ représentant la proportion observée, le centre et la largeur sont :
center = (p̂ + z²/(2n)) / (1 + z²/n)
half = z / (1 + z²/n)
× sqrt[p̂(1−p̂)/n + z²/(4n²)]
La formule suppose une structure d’échantillonnage qui peut ne pas exister. Plusieurs actions provenant d’un même client, modèle, évaluateur ou incident sont corrélées, ce qui nécessite une méthode de bootstrap tenant compte des clusters, des modèles hiérarchiques ou toute autre approche adaptée au processus de génération des données. Pré-spécifiez l’analyse lorsque c’est possible, car vérifier à plusieurs reprises et s’arrêter dès que un seuil est atteint exagère la confiance.
La signification seule n’est pas suffisante. Une légère baisse des coûts ou une petite amélioration des résultats peut être estimée avec précision tout en restant sans importance pour les opérations, et une violation de politique rare peut être inacceptable malgré une comparaison globale favorable. La taille de l’effet, l’incertitude, les conséquences, le volume et la force du contrôle doivent tous être pris en compte.
Les résultats correspondent aux cohortes qui présentent réellement un risque : ils sont classés par action et par limite de politique, puis par région, langue, impact et outil, et enfin en fonction du degré de nouveauté du cas, de la durée du contexte, de l’identité de la personne concernée et de la nature de la panne survenue. Séparer les données jusqu’à ne conserver que des groupes favorables est un piège ; c’est pourquoi les cohortes nécessaires sont définies dès le début dans le contrat et le plan de couverture.
Aucune panne, traitée avec honnêteté
Supposons qu’aucun événement critique ne se produise lors de n essais indépendants et simples. Selon la « règle des trois », la limite supérieure unilatérale à 95 % pour le taux d’échec est d’environ 3/n. Aucun échec sur 1 000 essais correspond à un taux sous-jacent proche de trois par mille, tandis qu’une limite supérieure de un sur 100 000 exige environ 300 000 essais indépendants représentatifs sans qu’aucun événement ne se produise. Ne pas observer d’événements ne signifie pas qu’il n’y ait aucun risque, et cette limite ne diminue que lorsque le nombre d’essais indépendants représentatifs augmente.
Cette méthode simplifiée est trompeuse lorsque les essais dépendent les uns des autres, lorsque les cas d’essai sont plus faciles que la situation réelle, lorsque le système de surveillance manque des événements, lorsque le comportement évolue, que l’attaquant s’adapte, ou lorsque l’autorité testée a des capacités plus limitées que celle en service. Un million de tests simples et répétés ne constituent pas un million d’essais indépendants à haut risque.
Fréquemment, les dommages critiques ne peuvent pas être suffisamment démontrés comme rares avant le lancement, ce qui pousse à recourir à des mesures préventives structurelles : interdire complètement l’action ou exiger l’approbation d’une personne. D’autres options consistent à limiter la valeur en jeu, à appliquer des politiques aux points d’accès, à isoler les données, à rendre les effets réversibles, à ajouter un vérificateur distinct ou simplement à refuser l’outil. L’évaluation vérifie ces contrôles sans pour autant les remplacer.
Les méthodes bayésiennes et les modèles de fiabilité peuvent être utiles lorsque les hypothèses et les valeurs a priori peuvent être justifiées, et le jugement doit être clairement identifié comme tel. Il ne faut jamais choisir arbitrairement une valeur a priori favorable pour permettre une mise en production, et une analyse de sensibilité doit montrer comment la décision évolue face à des alternatives plausibles.
Dérive et preuves périmées
L’approbation concerne un enveloppe évaluée, mais la production modifie constamment cette enveloppe. Les clients changent leur façon d’écrire, la composition des comptes varie, les politiques sont révisées, les outils modifient leur schéma, les fournisseurs mettent à jour leurs déploiements, le contenu récupéré vieillit, les examinateurs s’adaptent et la charge des files d’attente modifie les trajectoires. L’artefact identique peut s’éloigner de son cadre de validation sans aucune publication formelle.
Chacun de ces éléments mérite un suivi distinct : dérive des entrées, composition des actions, nouveauté, couverture des preuves, erreurs des outils, longueur de la trajectoire, tentatives de réessai, abstention, modifications effectuées par des humains, violations des politiques, calibration, latence, coût et résultats commerciaux matures. Un score de dérive combiné masque à la fois la cause et la réponse. La preuve que la production a quitté l’enveloppe approuvée devrait entraîner une révision, une réduction des droits d’accès, une évaluation ciblée ou un retour en arrière.
Des règles concernant les modifications matérielles sont nécessaires. Une nouvelle version de modèle ou un prompt système, un moteur de politique remplacé, une stratégie de récupération différente, un schéma de mémoire ou un contrat d’outil modifié, des permissions, des vérificateurs, une région ou des dépendances changés, ainsi que tout élargissement de la portée des actions peuvent exiger des tests ciblés ou complets, tandis qu’une simple modification esthétique de l’interface utilisateur ne l’exige pas. Le registre des modifications liste les demandes et les cellules de scénario affectées.
Tous les labels n’arrivent pas à la même vitesse. La validité du schéma d’une requête vers un outil est connue immédiatement, tandis qu’une réclamation ou un remboursement peuvent prendre des semaines. Les signaux précurseurs permettent des réactions rapides en matière de sécurité et de fiabilité, tandis que les demandes commerciales restent marquées comme en attente. Les autorités supérieures attendent la fenêtre de disponibilité du label nécessaire, bien que les opérations puissent restreindre ou annuler plus tôt en cas de preuves préliminaires.
Les preuves vieillissent même en l’absence de dérive détectée, et leur validité dépend de la vitesse à laquelle le domaine évolue et de la gravité des conséquences. Les affirmations liées à des politiques et outils à fort impact peuvent nécessiter un renouvellement plus fréquent que celles relatives à des extractions stables à faible impact. Un droit expiré n’est pas une preuve d’échec ; cela signifie simplement que la preuve ne soutient plus l’autorité, sauf si elle est renouvelée ou explicitement restreinte.
La promotion en tant que mécanisme de contrôle automatisé
Avant de donner une réponse, le portail de déploiement vérifie d’où provient l’artefact et si le contrat de déploiement reste compatible. Il s’assure que les scénarios critiques sont couverts, que les métriques respectent leurs plafonds et seuils, que les invariants de politique et de sécurité sont maintenus, et que des preuves de type shadow et canary existent. Il exige également une disponibilité opérationnelle, des mécanismes de contrôle en cas d’incident et une procédure de rollback éprouvée. Son verdict est promotion, restriction ou rejet, accompagné de codes de raison et de liens vers les preuves. En cas de promotion, un contrat d’autorisation signé et défini avec précision est émis ; en cas de lacunes, le déploiement est rejeté ou soumis à une restriction stricte et temporaire, jamais approuvé sans commentaire.
Les preuves doivent accompagner l’artefact déployé. La version 1.2 de la spécification SLSA décrit les niveaux de sécurité de la chaîne d’approvisionnement et les concepts de provenance, y compris des informations vérifiables sur le lieu, le moment et la manière dont les artefacts ont été produits. Ce qui est transféré ici, c’est une identité et une provenance vérifiables pour l’artefact. Une attestation pour l’évaluation des agents est un document supplémentaire spécifique à l’organisation et ne prétend pas à une conformité avec SLSA.
Une attestation de promotion peut inclure :
{
"subject": {"artifact_digest": "sha256:8d2...91a"},
"contract": "collections-agent/prod-v4",
"evaluation_bundle": "sha256:71c...ab4",
"claims": [
{"id": "workflow_effective/v8", "result": "PASS"},
{"id": "policy_no_unapproved_plan/v7", "result": "PASS"},
{"id": "critical_timeout_recovery/v5", "result": "PASS"}
],
"authority": {
"population_pct": 2,
"actions": ["contact_customer", "propose_payment_plan"],
"execution": {"contact_customer": true, "propose_payment_plan": false},
"daily_value_cap_usd": 25000,
"expires_at": "2026-09-22T00:00:00Z"
},
"rollback": "collections-agent/prod-v3",
"decision": "PROMOTE_BOUNDED",
"issuer": "agent-release-authority/prod"
}
Lors du déploiement, le gateway vérifie la signature, le digest de l’artefact, l’environnement, le contrat, l’autorité, la date d’expiration ainsi que l’état actuel de révocation. Une approbation provenant d’un autre artefact ou basée sur des éléments expirés ne permet pas le déploiement. Une dérogation a une portée plus restreinte ; elle comporte un responsable, une justification, une mesure de contrôle compensatoire, une date d’expiration et un plan de remédiation, et elle ne peut en aucun cas annuler des interdictions catégoriques.
Exécution de l’évaluation en tant que service
L’évaluation est un service à part entière, avec des retards, un degré de fraîcheur, des échecs et des aspects de qualité. Chacun de ces éléments nécessite un objectif spécifique : la couverture des scénarios, le degré de reproductibilité des exécutions, le degré de concordance entre les évaluateurs, l’ancienneté des données, les performances sur les politiques critiques, le degré de complétude des reçus de secours, la rapidité avec laquelle un indicateur précoce détecte les problèmes, ainsi que le succès des exercices de rollback. Un tableau de suivi peut indiquer une couverture insuffisante ou des données obsolètes, tandis que six objectifs opérationnels sont respectés, c’est précisément pourquoi ils sont suivis séparément.
La reproductibilité nécessite une tolérance convenue. Un manifest de traitement peut produire un texte différent à chaque fois tout en préservant les invariants de la politique ainsi que la distribution des résultats. Une entente entre les arbitres exige un protocole, une formation, un échantillon d’overlap aveugle, un moyen de résoudre les litiges et des vérifications par sous-groupe. Même un fort consensus peut cacher un malentendu partagé par tous, d’où la nécessité persistante d’une revue du domaine et des risques.
La vitesse est également importante pour l’entreprise, car un processus de traitement des preuves lent ralentit les correctifs et l’apprentissage. Il convient de mesurer le temps écoulé entre une modification, l’identification des sinistres concernés, la prêté des dossiers, leur exécution, la maturité des étiquettes, l’arbitrage, la décision et le déploiement. Les vérifications déterministes doivent s’exécuter automatiquement immédiatement, bien que les délais alloués aux étiquettes ne doivent jamais être réduits uniquement pour accélérer un lancement.
La propriété est partagée. La plateforme d’évaluation est responsable de la fiabilité des outils, de l’exécution des scénarios, des fichiers de description, de la reproductibilité et du calcul des métriques. Les propriétaires du domaine définissent les conditions post-exécution, les étiquettes, l’impact et les seuils d’acceptation. Les aspects liés au risque, à la vie privée, au droit et à la sécurité imposent des limites catégorielles, identifient les cas d’abus et fournissent des mécanismes d’audit indépendants. La fiabilité du site inclut la surveillance par des canaris, la gestion des incidents, le mécanisme d’arrêt d’urgence et le retrait des modifications. Le produit est responsable du périmètre, de l’adoption et des résultats commerciaux, tandis que l’autorité de publication prend la décision finale concernant ce périmètre.
Les désaccords sont normaux. Le produit cherche à accélérer les choses, l’évaluation exige une couverture plus large, les équipes opérationnelles craignent les retards, et les aspects liés au risque peuvent insister sur des contrôles stricts. Le graphique des revendications permet de préciser le différend : quelle revendication manque de preuves, quelle autorité s’y attache, quelles preuves pourraient le résoudre et quel contrat plus restreint est sécurisé aujourd’hui.
Lectures complémentaires
- Harness, Loop, Graph : trois couches à l’origine de la plupart des échecs des agents en production — Pourquoi les agents qui échouent en production ne sont que rarement un problème lié au modèle : séparation du outil Harness, de la condition d’arrêt du cycle et de la topologie du graphique, avec des responsables pour chacun.
- Comment construire un agent voix IA en 2026 : architecture et stack — Un guide pratique de construction pour les agents voix : conceptions en cascade, en demi-cascade et de parole à parole, le stack à cinq couches, l’ajustement de la latence, la conformité, les tests et les coûts.