SLO d’un agent IA : piloter la fiabilité sans promettre l’infaillibilité

Un agent IA n’a pas besoin d’être parfait pour être utile. Il doit en revanche rester prévisible sur une tâche clairement délimitée : répondre à temps, produire un résultat contrôlable et ne pas déclencher d’effet non maîtrisé. Un SLO, ou objectif de niveau de service, transforme cette attente en règle de pilotage. Il ne mesure pas une vague impression de qualité. Il dit ce qui compte, sur quelle fenêtre, avec quel seuil, et quelle décision prendre lorsque le seuil est franchi.

Cette discipline vient de la fiabilité des services numériques. Elle doit être adaptée aux agents : une réponse HTTP réussie ne prouve ni que le contenu est exploitable, ni que l’action proposée est sûre. Le bon contrat combine donc une couche métier, une couche de comportement et une couche technique.

Réponse en bref

Pour piloter un agent IA avec des SLO :

1. choisissez une tâche unique et un résultat accepté comme unité ;
2. séparez disponibilité, délai, acceptation humaine et sécurité ;
3. définissez un indicateur observable pour chaque promesse ;
4. fixez un objectif réaliste sur une fenêtre explicite ;
5. calculez le budget d’erreur restant, sans masquer les cas exclus ;
6. prévoyez une action quand le budget est consommé : pause, retour à une version stable ou validation renforcée ;
7. relisez chaque semaine les échecs par cause, pas seulement le pourcentage global.

La prochaine action utile est de prendre les cinquante dernières tâches d’un seul scénario et de leur attribuer quatre statuts : terminée, acceptée, à corriger, arrêtée en sécurité. Sans ce dénominateur, un objectif de fiabilité reste décoratif.

Ce qu’un SLO mesure, et ce qu’il ne mesure pas

Un indicateur de niveau de service, ou SLI, est une mesure. Un SLO est la cible convenue pour cette mesure. Par exemple : « sur 28 jours, 95 % des demandes complètes doivent aboutir à une proposition acceptée sans correction majeure en moins de dix minutes ». Le budget d’erreur est la part restante qui peut ne pas satisfaire cette cible. Google SRE recommande justement de lier le budget à une politique de décision, au lieu de poursuivre arbitrairement un 100 % rarement utile.

Pour un agent, la disponibilité technique seule est insuffisante. Un modèle peut répondre en trois secondes, mais inventer une référence, ignorer une règle métier ou échouer à joindre un outil. À l’inverse, une réponse refusée par un contrôle peut être un comportement sain. Les mesures doivent donc distinguer l’échec du service, le rejet qualité et l’arrêt volontaire de sécurité.

Le SLO ne remplace ni une évaluation avant déploiement, ni une revue des risques. Le protocole pour évaluer un assistant IA avant déploiement sert à établir le niveau de départ ; le SLO surveille ensuite la réalité d’exploitation. Le NIST recommande d’ailleurs de tester les systèmes avant déploiement puis régulièrement en fonctionnement, en documentant aussi ce qui ne peut pas être mesuré.

Le contrat en trois couches

1. Résultat métier

Commencez par la question du destinataire : « le résultat m’a-t-il permis de terminer la tâche ? » Une bonne unité contient un objet, un état final et une personne ou une règle qui l’accepte. « Un run » ou « une conversation » ne répond pas à cette question.

Exemples d’indicateurs utiles :

• part des dossiers complets qui reçoivent une proposition acceptée ;
• part des classifications confirmées sans correction majeure ;
• part des brouillons repris en moins de deux modifications ;
• part des demandes rendues au bon propriétaire avant l’échéance.

Ne mélangez pas des cas où l’entrée était incomplète avec des échecs de l’agent. Gardez-les visibles dans une catégorie séparée. Sinon l’équipe peut soit blâmer le système pour un processus amont défaillant, soit retirer les cas difficiles pour embellir le résultat.

2. Comportement contrôlé

Cette couche vérifie les conditions qui rendent le résultat acceptable : source exigée, champ obligatoire, validation humaine, absence d’action externe ou respect d’une permission. Elle ne se résume pas à une note moyenne d’un évaluateur automatique.

Un SLI peut être « pourcentage de propositions contenant toutes les pièces exigées », ou « proportion d’actions bloquées avant envoi lorsque la permission manque ». Les sorties structurées aident à mesurer ces conditions, mais un JSON conforme n’atteste pas la véracité de son contenu. Il faut conserver cette distinction, détaillée dans le guide sur les sorties structurées IA et JSON Schema.

3. Service technique

Enfin, observez ce qui permet au scénario de tourner : disponibilité des outils, délai au 95e percentile, taux d’expiration, files d’attente, limites de débit et erreurs de dépendance. OpenTelemetry propose des conventions dédiées aux applications GenAI : elles peuvent homogénéiser les traces, sans justifier la conservation des prompts ou données sensibles.

Cette couche explique souvent une dégradation, mais ne doit pas devenir le seul tableau de bord. Un taux de succès API de 99,9 % peut coexister avec une faible acceptation métier.

Écrire quatre SLO plutôt qu’un score artificiel

Un premier contrat de pilote peut tenir dans ce tableau :

Promesse	SLI	Fenêtre	Cible	Décision si échec
résultat exploitable	tâches acceptées / tâches évaluables	28 jours	90 %	revue des causes et gel du scénario si budget épuisé
délai	tâches acceptées avant l’échéance / tâches acceptées	28 jours	95 %	simplifier le flux ou revoir l’échéance
garde-fou	actions sans autorisation / actions proposées	28 jours	0	arrêt immédiat et analyse d’incident
disponibilité	runs démarrés et terminés / runs demandés	7 jours	99 %	bascule vers procédure manuelle

Les nombres ne sont pas des normes universelles. Une tâche informative peut tolérer davantage de corrections qu’une tâche qui modifie un dossier. Un seuil ne peut être décidé qu’après observation de la référence manuelle, du risque et de la capacité réelle de revue humaine.

Évitez aussi un score composite. Additionner vitesse, qualité et risque donne une valeur séduisante mais cache la raison de la décision. Une seule violation du garde-fou peut être plus importante que cent réponses rapides ; elle doit rester lisible comme telle.

Calculer le budget d’erreur

Avec 1 000 tâches évaluables par période et une cible d’acceptation de 90 %, le budget autorise 100 tâches non acceptées. Ce n’est pas un droit à dégrader le système. C’est un seuil qui permet de choisir quand ralentir les changements.

budget total = tâches évaluables × (1 - objectif)
budget consommé = tâches évaluables - tâches acceptées
budget restant = budget total - budget consommé

Comptez séparément les refus sûrs. Si le système refuse correctement une demande hors périmètre, il faut mesurer cette protection, pas la classer comme une réponse ratée. Documentez la règle dans le registre : catégorie, exemple non sensible, propriétaire et traitement. La journalisation d’un agent IA fournit un format de trace qui permet de relier une tâche, un run et un statut sans recopier la conversation.

La fenêtre doit être assez longue pour éviter qu’une matinée anormale impose une conclusion générale, et assez courte pour rendre la décision actionnable. Pour un faible volume, complétez le pourcentage par le nombre brut de cas : « 2 sur 12 » est plus honnête que « 83,3 % » présenté seul.

Une politique qui donne une conséquence au chiffre

Un tableau de bord sans action est un relevé, pas un SLO. Définissez trois états avant l’incident :

• vert : budget disponible, changements limités et observés ;
• orange : budget consommé à moitié, revue quotidienne des échecs et aucun élargissement de périmètre ;
• rouge : budget épuisé ou garde-fou violé, gel des nouveautés, retour au dernier comportement vérifié ou circuit manuel.

Précisez qui peut déclarer chaque état et comment l’utilisateur est informé. Un retour manuel n’est pas un aveu d’échec : c’est la continuité de service prévue. Pour les actions ayant un effet externe, reliez ce plan à une validation humaine et à une stratégie de reprise ; l’idempotence d’un workflow IA évite qu’une relance de récupération ne double l’effet initial.

La revue hebdomadaire en trente minutes

Prenez un échantillon des réussites, tous les incidents de garde-fou et les échecs les plus coûteux. Pour chaque ligne, notez : version du scénario, type d’entrée, statut final, cause première, impact, correctif et décision de réévaluation. Ne corrigez pas immédiatement chaque cas par un prompt plus long. Cherchez d’abord le défaut de contrat, de donnée, d’outil, de permission ou de définition du résultat.

Posez ensuite quatre questions :

1. le dénominateur représente-t-il toujours le même travail ?
2. une cause domine-t-elle les échecs ?
3. un changement de modèle, de donnée ou d’outil coïncide-t-il avec la dérive ?
4. le seuil actuel protège-t-il réellement les personnes et l’activité ?

Conservez la réponse et la date. Cette boucle matérialise l’idée du NIST : la mesure alimente le pilotage et les plans de réponse, au lieu de rester un rapport séparé.

Si la dérive suit un changement de fournisseur ou de version, le protocole pour migrer un modèle IA sans régression ajoute une double exécution, un canary et un retour arrière au suivi des SLO.

Éviter cinq faux bons indicateurs

Le premier piège consiste à compter les réponses produites. Une réponse livrée n’est pas nécessairement une tâche terminée. Le deuxième est de suivre une note automatique sans contrôle humain sur les cas qui comptent : elle peut détecter une forme, mais rarement le contexte métier complet. Le troisième est de viser le délai moyen. Une moyenne de deux minutes masque très bien les quelques demandes qui attendent une heure et bloquent un travail urgent.

Le quatrième piège est de compter toutes les erreurs de la même manière. Une indisponibilité de recherche, une sortie à corriger et un refus de sécurité n’appellent ni le même responsable ni la même correction. Enfin, il faut résister à l’objectif de 100 %. Une cible absolue pousse parfois à exclure des cas, à contourner des contrôles ou à déclarer une réponse « terminée » trop tôt. Un SLO utile rend les compromis visibles, il ne les efface pas.

Exemple de feuille de calcul de départ

Pour un pilote, une feuille suffit si chaque ligne représente une tâche et non un événement technique. Ajoutez des colonnes task_id, scenario, received_at, completed_at, accepted, safety_stop, failure_cause, reviewer et version. À la fin de la période, produisez deux vues : une vue de pilotage avec les quatre SLI, et une vue d’apprentissage avec les causes des exceptions.

Ne déduisez pas la qualité de la simple absence de commentaire. Définissez un délai de revue et un statut explicite. Une tâche sans verdict reste « en attente », elle ne rejoint ni les réussites ni les erreurs. Cette précision rend le budget plus lent à calculer, mais beaucoup plus crédible.

Limites

Un SLO ne certifie pas la conformité, l’exactitude de chaque réponse ni l’absence de biais. Il dépend d’une définition honnête des cas évaluables et d’une revue suffisamment compétente. Les petits volumes produisent des variations fortes ; ne changez pas une cible à chaque semaine. Enfin, les métriques d’observabilité doivent être conçues pour minimiser les données personnelles et confidentielles enregistrées.

Articles liés

• Évaluer un assistant IA avant déploiement
• Mode dégradé d’un agent IA : continuer, arrêter et reprendre
• Journaliser un agent IA sans conserver les prompts
• Calculer le coût par tâche acceptée