Surveiller et améliorer une solution d'IA

Ce que l'IA fait bien ici, ce qu'elle fait mal

Ce qu'elle fait bien

• Regrouper des retours en texte libre: le modèle range des centaines de commentaires par thème et cite les numéros des retours de chaque thème.
• Rapprocher retours et incidents: il relie une plainte d'utilisateur à l'incident du registre qui décrit le même défaut.
• Rédiger l'entrée d'un incident: il tire d'un fil de messages la date, l'effet, les personnes touchées et le repli.
• Comparer deux périodes: il signale qu'un thème double d'un mois à l'autre ou qu'un nouveau sujet apparaît.

Ce qu'elle fait mal

• Repérer le retour grave et isolé: il range un cas de santé ou de droits dans un grand thème banal.
• Compter juste: ses effectifs par thème s'écartent parfois du nombre d'entrées.
• Garder les mêmes thèmes d'un mois à l'autre: il renomme ou redécoupe les thèmes. La comparaison porte alors sur d'autres catégories.
• Voir sa propre dérive: la solution ne signale pas que ses réponses ont changé.
• Trouver la cause: il ne voit ni la base documentaire, ni les mises à jour, ni le contrat derrière la solution.
• Classer un incident en droit: la gravité au sens de l'AI Act dépend de faits que le juriste établit.
• Décider de la suite: corriger, restreindre ou retirer la solution engage le propriétaire.

Déroulé

Le Playbook du NIST demande un plan de surveillance après le déploiement. Ce plan prévoit la collecte des retours des utilisateurs, le recours contre une décision et sa correction par un humain, la réponse aux incidents, la reprise, la gestion des changements et le retrait du système (MANAGE 4.1). La page Portefeuille des solutions d'IA nomme pour chaque solution la personne qui la surveille. La page Du prototype à la production donne les déclencheurs d'une réévaluation en production.

Le plan de surveillance

Le plan donne à chaque dimension un signal, un responsable et un rythme. Google recommande de suivre, en plus des statistiques du modèle, les indicateurs de l'activité que la solution sert. Il conseille de lire les résultats par segment, par exemple par région ou par groupe de personnes. Le découpage en dimensions est pratique. Aucun des textes cités ne le fixe.

Une injection de prompt cache, dans un texte que la solution lit, une instruction qui la détourne de sa consigne.

Les signaux de dérive entre deux échantillons

La page Mesurer le succès d'une solution IA définit la dérive et l'échantillon mensuel qui la mesure. Cet échantillon arrive tard. Google demande de surveiller la baisse brutale ou lente de la qualité. Entre deux échantillons, d'autres signaux annoncent la dérive.

Evidently AI appelle dérive des données le changement des propriétés statistiques des entrées. Un test statistique compare la distribution des entrées de deux périodes (Kolmogorov-Smirnov, indice de stabilité de la population). Google compare aussi les données d'entraînement aux données reçues en service. Ce contrôle suppose l'accès aux données d'entraînement. Le fournisseur d'un modèle hébergé ne les communique pas.

Pour une solution générative, personne n'écrit la bonne réponse de chaque requête. Le propriétaire suit donc des signaux de comportement: la part des réponses refusées, des demandes transmises à un humain et des évaluations négatives, la longueur moyenne des réponses et les sujets nouveaux dans les questions. Quand l'un d'eux saute ou glisse, le propriétaire lit un échantillon.

Le fournisseur d'un modèle hébergé peut changer le modèle derrière le même service. Les signaux de comportement changent alors à une date précise. Le propriétaire compare les réponses d'avant et d'après cette date. La page Portefeuille des solutions d'IA recommande d'inscrire au contrat l'avis préalable d'un changement de modèle.

Du signalement à l'action

Le registre de la solution inscrit les incidents et les quasi-incidents. Un incident d'IA a causé un dommage. Un quasi-incident aurait pu en causer un. L'OCDE l'appelle danger. Chaque entrée porte la date, la requête et la réponse en cause, l'effet, les personnes touchées, le repli utilisé, la cause, la mesure prise et la date de clôture.

Selon le NIST, l'organisation communique les erreurs, les incidents et les effets négatifs aux parties prenantes, aux exploitants, aux utilisateurs et aux personnes touchées (MANAGE 4.3).

Pour un système à haut risque, l'AI Act ajoute un circuit légal. Il appelle incident grave un incident qui entraîne, directement ou indirectement, un décès ou une atteinte grave à la santé, une perturbation grave et irréversible d'une infrastructure critique, une violation des obligations du droit de l'Union qui protègent les droits fondamentaux ou un dommage grave aux biens ou à l'environnement (art. 3, point 49). Le déployeur en informe immédiatement le fournisseur. Il informe ensuite l'importateur ou le distributeur et l'autorité de surveillance du marché (art. 26 par. 5). Le fournisseur fait rapport à l'autorité dans les délais que fixe l'art. 73. Il surveille aussi tous les usages de son système selon un plan de surveillance après commercialisation (art. 72). Le déployeur surveille son propre usage. Ces devoirs s'appliquent aux systèmes à haut risque aux dates que donne la page AI Act: classer le risque. Une fuite de données personnelles suit en plus les règles de la page La LPD et les données confidentielles.

Les retours des utilisateurs

La solution reçoit des retours par plusieurs canaux: le bouton d'évaluation avec son champ de commentaire, le formulaire de contact, les tickets du support et les décisions qu'un collaborateur corrige. Chaque entrée porte la date, le canal et le texte. Le support transmet le jour même au propriétaire tout retour qui mentionne la santé, la sécurité ou un appareil médical. Les autres retours attendent la lecture mensuelle. Le propriétaire examine chaque thème qui n'a pas d'incident au registre. Il ouvre un incident ou suit le thème au mois suivant.

Le cycle d'amélioration

Le propriétaire conduit l'amélioration selon le cycle PDCA (Plan, Do, Check, Act). Il planifie: il fixe les mesures, les seuils et les responsables. L'équipe exploite la solution et alimente le journal. Chaque mois, elle vérifie: elle confronte aux seuils les mesures, le registre des incidents et les retours. Le propriétaire agit: il corrige la consigne, la base documentaire ou les données, fait réentraîner le modèle, restreint l'usage ou retire la solution. Le NIST demande que les mises à jour d'un système intègrent des actions d'amélioration mesurables et un échange régulier avec les parties intéressées (MANAGE 4.2). La vérification suivante mesure l'effet de chaque action.

La page ISO/IEC 42001 et NIST AI RMF situe la fonction Manage du NIST face aux exigences de la norme.

La revue de conformité

La revue de conformité vérifie que la solution respecte encore les règles en vigueur. Elle se tient à date fixe au rythme de la revue des risques que donne la page Du prototype à la production. Un changement des règles avance la revue: une loi, une ordonnance, une ligne directrice de l'autorité ou une politique interne. La veille sur l'IA repère ces changements.

Le juriste lit la règle face à l'entrée du registre. Il note ce qui change pour la solution et la date d'effet. L'équipe traite chaque écart comme une action du cycle. Une modification substantielle est un changement que l'évaluation de conformité initiale n'avait pas prévu et qui touche la conformité ou la destination du système (art. 3, point 23). La page Portefeuille des solutions d'IA dit ce qu'elle entraîne.

Les étapes

1. Le propriétaire de la solution établit le plan de surveillance. Il fixe pour chaque dimension le signal, le seuil, le responsable et le rythme. Une matrice RACI répartit qui relève et qui décide.
2. L'analyste ouvre les canaux et le registre. Il relie le bouton d'évaluation, le formulaire et le support à un même fichier. Il crée le registre des incidents avec ses champs.
3. Chaque mois, le modèle regroupe les entrées. L'analyste retire les noms des retours du mois et des incidents ouverts. Il fournit ces textes au modèle avec les thèmes du mois précédent.
4. L'analyste vérifie le regroupement. Il lit en entier toute entrée de la liste à part (consigne 4). Il lit aussi toutes les entrées des thèmes qui touchent à la santé, à l'argent ou à l'accès à un service. Il compte lui-même les entrées de chaque thème dans le fichier.
5. Le propriétaire trie le jour même chaque incident et chaque retour que le support lui transmet. Il restreint la solution le jour même quand l'entrée touche la santé, la sécurité ou les droits d'une personne. Les autres entrées attendent la lecture mensuelle. Le juriste établit si le circuit de l'AI Act s'applique.
6. L'équipe trouve la cause et agit. Elle mène une analyse des causes racines. Une AMDEC classe les modes de défaillance que l'exploitation révèle. Chaque action reçoit un responsable et une date.
7. Le propriétaire contrôle l'effet à la lecture suivante. Il clôt l'incident quand le signal revient sous son seuil. L'équipe tient une rétrospective sur les incidents du trimestre.
8. Le juriste tient la revue de conformité. Le propriétaire du registre inscrit le résultat et la date de la revue suivante dans l'entrée de la solution.

Prompt modèle

Tu regroupes par thème les retours des utilisateurs de [SOLUTION] pour [PÉRIODE]. Tu les rapproches du registre des incidents.

<retours>
[RETOURS NUMÉROTÉS]
</retours>

<incidents>
[INCIDENTS OUVERTS]
</incidents>

<mois_précédent>
[THÈMES DU MOIS PRÉCÉDENT]
</mois_précédent>

<consignes>
1. Range chaque retour de <retours> dans un seul thème. Nomme chaque thème en cinq mots au plus.
2. Pour chaque thème, donne les numéros des retours qu'il contient et une citation exacte d'un retour.
3. Rapproche chaque thème des incidents de <incidents> qui décrivent le même défaut. Écris «aucun incident» quand rien ne correspond.
4. Liste à part chaque retour qui touche à la santé, à la sécurité, à l'argent ou aux droits d'une personne, même s'il est seul de son genre. Cite son numéro et sa phrase.
5. Reprends le nom d'un thème de <mois_précédent> quand il décrit le même défaut. Signale les thèmes nouveaux et ceux qui ont au moins doublé.
6. N'invente aucun retour. N'ajoute aucune cause que les retours ne donnent pas.
7. Termine par les retours que tu n'as pas su classer.
</consignes>

• [SOLUTION] nomme la solution et ce qu'elle fait en une phrase.
• [PÉRIODE] donne le mois relevé.
• [RETOURS NUMÉROTÉS] reçoit les retours du mois. Chaque ligne porte un retour avec son numéro, sa date et son canal. L'analyste retire les noms, les adresses et les numéros de client avant l'envoi.
• [INCIDENTS OUVERTS] reçoit le numéro, la date et l'effet de chaque incident ouvert au registre.
• [THÈMES DU MOIS PRÉCÉDENT] reçoit les thèmes du mois précédent avec le nombre d'entrées que l'analyste a recompté.

La consigne 2 demande les numéros des retours plutôt qu'un effectif. L'analyste compte lui-même dans le fichier. La consigne 4 sort du lot le retour grave et isolé. La consigne 5 garde le nom des thèmes d'un mois à l'autre. Les retours décrivent des clients et parfois leur santé. L'analyste lance le prompt sur l'assistant que l'organisation a validé. La fiche Sondage ou questionnaire montre comment contrôler chaque thème du modèle contre ses verbatims. La fiche Analyse des causes racines montre comment un modèle trie les incidents par similarité. La cause qu'il propose y reste une hypothèse à vérifier.

Exemple

Un distributeur d'électricité vaudois sert 60'000 ménages. Un agent conversationnel répond sur son site aux questions sur les factures, les tarifs, les coupures et les déménagements. Une agence l'a construit sur le modèle d'un fournisseur. Il puise ses réponses dans une base documentaire. La cheffe du service clientèle en est la propriétaire. L'agent sert des clients en Suisse. L'AI Act ne le vise pas. Les valeurs sont inventées.

Fin janvier 2026, l'analyste réunit 269 retours: 212 évaluations négatives avec commentaire et 57 messages du formulaire de contact. Il y joint les 6 incidents du registre et lance le prompt. Le modèle rend cinq thèmes et 37 retours non classés. L'analyste recompte chaque thème dans le fichier.

Le thème du tarif montre une dérive. Les questions n'ont pas changé. La bonne réponse a changé le 1^er janvier avec les nouveaux tarifs. La base documentaire contenait encore la grille de 2025. Le premier retour sur ce sujet date du 3 janvier. Dans la deuxième semaine, la part des évaluations négatives sur les questions de tarif est passée de 6% à 21%. Elle a franchi le seuil de 10% du plan. Le 12 janvier, la propriétaire a lu un échantillon et ouvert l'incident 2026-01. L'agence a chargé la grille de 2026 le 21 janvier. L'échantillon mensuel n'aurait révélé le défaut qu'à la fin du mois.

Les gestionnaires de réseau publient les tarifs de l'année suivante au plus tard le 31 août (OApEl art. 7b). La propriétaire inscrit donc au plan une date fixe: chaque septembre, elle fait vérifier que la base contient la grille de l'année suivante. En février, deux retours seulement parlent du tarif. Tous deux portent sur une facture de 2025.

Le modèle a rangé l'entrée 117 dans le thème des coupures. Il ne l'a pas listée à part malgré la consigne 4. L'analyste l'a trouvée en lisant tout le thème. Le message datait du 12 janvier. Le support ne triait pas encore les retours chaque jour. L'agent avait renvoyé à la page générale des travaux sans donner le numéro de piquet. La fille du client a appelé le support. Aucun dommage n'a suivi. La propriétaire a inscrit le quasi-incident 2026-02. L'agent transmet désormais au piquet toute question qui lie une coupure à un appareil médical. Le jeu d'évaluation reçoit dix questions de ce type.

Essayer avec l'AI Incident Database

L'AI Incident Database du Responsible AI Collaborative recense des dommages et des quasi-dommages causés par des systèmes d'IA. Sans créer de compte, saisissez un terme en anglais qui décrit votre solution, par exemple «customer service». Ouvrez un incident. Sa page donne la date, la description, le déployeur, le développeur, les parties touchées et les articles sources. Comparez ces champs à ceux de votre registre des incidents.

Vérifier le résultat

• Chaque dimension du plan a-t-elle un signal, un seuil, un responsable et un rythme?
• Le plan suit-il au moins un signal de comportement entre deux échantillons mensuels?
• Le support transmet-il le jour même chaque retour qui mentionne la santé ou la sécurité?
• Les retours envoyés au modèle sont-ils exempts de noms, d'adresses et de numéros de client?
• Chaque thème rendu par le modèle renvoie-t-il à des numéros de retours?
• L'analyste a-t-il recompté chaque thème dans le fichier?
• L'analyste a-t-il lu en entier les thèmes qui touchent à la santé, à l'argent ou à l'accès à un service?
• Chaque entrée du registre porte-t-elle la date, la requête et la réponse en cause, l'effet, les personnes touchées, le repli, la cause, la mesure et la date de clôture?
• Les quasi-incidents figurent-ils au registre?
• Le juriste a-t-il établi pour chaque incident grave si le circuit de l'AI Act s'applique?
• Chaque action porte-t-elle un responsable, une date et un contrôle à la lecture suivante?
• La date de la prochaine revue de conformité figure-t-elle dans l'entrée de la solution?

Limites et risques

Les retours contiennent des données personnelles. Un client décrit sa santé, son adresse ou sa facture. L'analyste retire les noms et les numéros avant l'envoi au modèle. Un détail de santé suffit parfois à reconnaître une personne dans une petite commune. La LPD range les données sur la santé parmi les données sensibles (art. 5 let. c). La page La LPD et les données confidentielles donne les règles qui s'y appliquent. L'organisation emploie les retours pour les finalités qu'elle a annoncées à la collecte (LPD art. 6 al. 3). Le formulaire et le bouton d'évaluation annoncent donc l'amélioration du service. L'analyste détruit ou anonymise les retours quand la surveillance n'en a plus besoin (LPD art. 6 al. 4).

Surveiller la solution peut revenir à surveiller le personnel. L'art. 26 de l'ordonnance 3 relative à la loi sur le travail (OLT 3) interdit les systèmes destinés à surveiller le comportement des travailleurs. Le plan lit donc les journaux d'un assistant interne par équipe ou par type de requête. La page La conduite du changement dit comment suivre l'usage sans surveiller les personnes.

Les retours décrivent les utilisateurs qui écrivent. Un client mal servi ferme souvent la fenêtre sans rien dire. Le propriétaire compare donc le nombre de conversations abandonnées d'un mois à l'autre. Un sondage annuel interroge les personnes qui n'écrivent pas.

La responsabilité reste à l'organisation. Le propriétaire de la solution répond devant les utilisateurs des réponses qu'elle donne, même quand le fournisseur a changé le modèle sans prévenir. Le contrat règle seulement ce que le fournisseur doit à l'organisation.

Techniques liées

• Cycle PDCA: un modèle tient le registre des tours et propose des explications rivales à un écart. La prédiction et l'observation restent à l'équipe.
• Métriques et KPI: un modèle repère les ruptures et les dérives de tendance dans une série. La cible et le statut d'un indicateur restent une décision humaine.
• Analyse des causes racines: un modèle trie des milliers d'incidents par similarité. La cause qu'il propose reste une hypothèse à vérifier sur les faits.
• AMDEC: un outil de texte regroupe les tickets et les plaintes par mode de défaillance pour étayer les notes d'occurrence.
• Rétrospectives: un modèle regroupe les notes de séance. Son regroupement lisse les désaccords.
• Matrice RACI: un modèle trouve les défauts de structure d'une matrice. Le choix du A reste un acte politique.
• Sondage ou questionnaire: un modèle regroupe le texte libre et invente des thèmes plausibles. L'analyste contrôle chaque catégorie contre ses verbatims.