Un système automatisé dont on ignore le fonctionnement, la date, les données utilisées et les raisons n'est pas exploité ; il est maintenu. La différence devient flagrante le jour où un dysfonctionnement survient, et à ce moment-là, il est impossible de reconstituer le déroulement des événements : les données nécessaires n'ont pas été sauvegardées, car personne n'a pris la peine de le faire.
Il s'agit probablement du défaut de conception le plus répandu dans les systèmes de composants d'IA que nous auditons, et le moins coûteux à éviter s'il est pris en compte dès le début.
La surveillance consiste à vérifier que le système est opérationnel : il répond, ne génère pas d’erreurs et la latence est acceptable. Elle est nécessaire, mais non suffisante.
L'observation permet de répondre à des questions inattendues. Pourquoi ce cas précis s'est-il résolu ainsi ? Quelle version du modèle était utilisée mardi dernier ? Combien de fois le système a-t-il dû réessayer avant de répondre ? Quel pourcentage des suggestions de l'agent sont corrigées avant approbation ?.
Cette distinction est particulièrement importante pour les composants probabilistes, car un système d'IA peut présenter une infrastructure parfaitement fonctionnelle (zéro erreur, faible latence, disponibilité totale) et pourtant produire des résultats de plus en plus médiocres. Un tableau de bord de surveillance classique ne détecte pas ce phénomène : il affiche tout au vert.
Nous l'avons développé plus en détail dans L'observabilité LLM, la métrique que personne ne mesure
|
Couche |
Ce qui est enregistré |
À quoi ça sert ? |
|
Entrée |
Quelles données et quel contexte le système a-t-il reçus ? |
Reproduisez le cas et détectez les données anormales. |
|
Décision |
Quels résultats a donnés le modèle, avec quelle version et avec quelle configuration ? |
Expliquez le résultat et détectez la dérive. |
|
Action |
Quels systèmes ont été exécutés ? |
Audit, annulation et responsabilité |
|
Validation |
Qui l'a examiné, qu'est-ce qui a changé et quand ? |
Mesurer la qualité réelle et assurer la supervision humaine |
|
Coût |
Consommation par exécution et par cas d'affaires |
Contrôler le coût unitaire à grande échelle |
La couche de validation est la plus souvent négligée, et pourtant la plus précieuse. Consigner les corrections apportées avant validation transforme le contrôle humain en un flux de données sur la qualité du système. Sans cet enregistrement, le seul signal disponible est la réclamation du client, qui arrive tardivement et est souvent biaisée.
Le coût est le deuxième aspect le plus négligé. Un système d'IA a un coût variable par exécution, ce qui est inhabituel pour un logiciel d'entreprise. Si ce coût n'est pas suivi dans le cadre de l'analyse de rentabilité, il est impossible de savoir si le processus automatisé est rentable, et cette question se pose systématiquement, généralement lors de la revue budgétaire du trimestre suivant.
Les indicateurs techniques (latence, jetons, taux d'erreur de l'API) sont utiles à l'équipe opérationnelle. Seuls quatre d'entre eux sont pertinents pour un comité de pilotage :
Taux d'acceptation inchangé. Parmi les propositions générées par le système, quel pourcentage est approuvé tel quel ? Il s’agit de l’indicateur de qualité le plus fiable car il repose sur une utilisation réelle et non sur des tests en laboratoire.
Taux d'échelle humain. Quel est le pourcentage de dossiers que le système ne parvient pas à résoudre ? Il convient de définir une valeur cible : si elle est trop élevée, le système est inefficace ; si elle est nulle, il résout probablement des dossiers qui ne relèvent pas de sa compétence.
Coût par dossier résolu. Le coût total est calculé en divisant le résultat par le nombre de dossiers effectivement clos, et non par le nombre de tentatives. C'est ce chiffre qui est ensuite comparé au coût de la procédure précédente.
Temps de détection des pannes. Combien de temps faut-il à une organisation pour se rendre compte que son système produit des résultats erronés ? Si personne n’a mesuré ce délai, la réponse est généralement : « lorsqu’un client se plaint ».
Ces quatre indicateurs peuvent être présentés sur une seule diapositive et répondre à la seule question qui compte pour un conseil d'administration : cela fonctionne-t-il, combien cela coûte-t-il et combien de temps faut-il pour savoir si cela cesse de fonctionner ?
Jusqu'à récemment, la traçabilité était justifiée par des raisons techniques. Depuis 2025, un second argument s'est imposé, plus difficile à réfuter en commission.
Le règlement européen sur l'IA exige, pour certaines catégories de systèmes, la consignation des événements, la documentation technique et une supervision humaine démontrable. Le cadre de gestion des risques liés à l'IA du NIST structure la gestion des risques autour de la capacité de mesure et de surveillance. La norme ISO/IEC 42001 exige la preuve d'un contrôle continu pour certifier un système de gestion de l'IA.
Ces trois cadres de référence requièrent la même chose, bien qu'avec des vocabulaires différents : la capacité de démontrer le fonctionnement du système. Un système qui n'a pas enregistré ses actions ne peut pas les démontrer, et l'ajout ultérieur de ces informations nécessite une modification de l'architecture.
Il est important de le dire clairement car cela change l'ordre des priorités : L'observabilité n'est plus une tâche opérationnelle, mais une exigence de conception..
Il n'est pas nécessaire de le réécrire. Le cheminement habituel comporte trois étapes et peut être exécuté sans interrompre l'opération :
L'erreur à éviter est de vouloir tout implémenter en même temps. Un système à deux couches bien alignées est infiniment plus facile à gérer qu'un système à cinq couches partiellement alignées.
Avant de considérer un projet d'automatisation comme achevé, il est conseillé de réaliser un test concret : Choisissez un cas au hasard datant d'il y a trois semaines et demandez-leur d'expliquer précisément ce qui s'est passé..
Si l'équipe parvient à reconstituer le système (quelles données ont été saisies, quelle version du modèle a été utilisée, quelles opérations ont été exécutées et qui les a validées), le système est opérationnel. Si la réponse commence par « il faudrait consulter les journaux, mais je ne sais pas si nous les conservons », le système est en production, mais pas encore finalisé.
Il s'agit de la capacité à répondre à des questions inattendues concernant le comportement du système : pourquoi un cas précis a été résolu d'une certaine manière, quelle version du modèle était concernée, combien de tentatives ont été effectuées ou encore quelle proportion des propositions est en cours de correction. Cela diffère de la surveillance, qui se limite à vérifier la disponibilité et la réactivité du système.
Cinq niveaux : entrée (données reçues et contexte), décision (sortie du modèle, version et configuration), action (ce qui a été exécuté et sur quel système), validation (ce que le réviseur a corrigé) et coût par exécution et par cas d’utilisation.
Quatrièmement : le taux d’acceptation inchangé, le taux d’escalade vers un humain, le coût par cas résolu et le délai de détection des pannes. Les indicateurs techniques tels que la latence ou la consommation de jetons sont utiles à l’équipe des opérations, et non à la décision commerciale.
Oui. Le règlement européen sur l'IA exige la consignation des événements, la documentation technique et une supervision humaine démontrable pour certaines catégories de systèmes. Le cadre de gestion des risques (RMF) du NIST en matière d'IA structure la gestion des risques autour de la capacité de mesure et de surveillance, et la norme ISO/IEC 42001 exige la preuve d'un contrôle continu pour la certification.
Oui, sans le réécrire. L'ordre optimal consiste à implémenter d'abord la saisie et l'action (qui permettent de reconstituer un incident), puis à ajouter l'enregistrement de validation humaine et à définir les seuils d'alerte avant même de disposer des données, et non après.
En effet, les indicateurs d'infrastructure (disponibilité, latence, erreurs) peuvent être au vert alors que la qualité des résultats se dégrade. La qualité d'un composant probabiliste ne se mesure pas avec les outils de surveillance traditionnels, mais avec des indicateurs de performance basés sur l'utilisation réelle.
|
Pourriez-vous reconstituer aujourd'hui ce que votre système d'IA a fait il y a trois semaines ? Si la réponse n'est pas claire, il est préférable de la revoir avant qu'un client ou un auditeur ne pose la question. Nous analyserons votre dossier en deux heures, sans engagement. Parlons-en → |
Español Español 
English
Français
العربية
Português
Deutsch
Italiano
