Après le pilote IA : qui entretient les usages ?

Ne pas confondre service disponible et usage maîtrisé

Une interface peut s’ouvrir normalement alors que le document dont elle tire une réponse n’est plus applicable. À l’inverse, un utilisateur peut signaler un problème qui vient d’une consigne ambiguë plutôt que du modèle. Le suivi doit permettre de distinguer ces situations au lieu de les regrouper sous « l’IA marche mal ».

Le NIST inclut dans MANAGE 4.1 le suivi après déploiement, les retours des utilisateurs, la réponse aux incidents, la reprise et la gestion des changements. ^[1] Ce cadre donne des dimensions à examiner ; il ne prescrit pas le fonctionnement exact de votre équipe.

Ma proposition est de partir du service attendu : quelle tâche reste réalisable, à quelle qualité, avec quel contrôle ? Si personne ne peut répondre à cette question après le pilote, le projet a surtout livré un accès à un outil.

Conserver une référence compréhensible

Gardez une courte fiche de l’usage accepté : tâche, utilisateurs, documents autorisés, résultat attendu, vérification humaine et exclusions. Ajoutez la date, les paramètres connus et les cas qui ont servi à décider. Il ne s’agit pas de figer le système pour toujours, mais de savoir ce qui change.

Une documentation de configuration peut aider, sans être accessible à tous les utilisateurs. La consigne quotidienne doit, elle, expliquer quoi faire et qui contacter. Ne placez pas de secrets d’accès dans la fiche partagée. Le dossier technique et la consigne métier n’ont pas les mêmes destinataires.

Pour un usage documentaire, identifiez la personne qui décide qu’une nouvelle version fait autorité. Un fichier ajouté par quelqu’un n’est pas automatiquement une règle applicable. Le guide sur les sources documentaires aide à clarifier cette distinction.

Répartir quatre responsabilités concrètes

Dans une petite structure, la même personne peut suivre plusieurs lignes. Cela ne dispense pas de nommer un relais ni de prévoir du temps. Le fournisseur peut intervenir sur le fonctionnement ; il ne connaît pas nécessairement la priorité de votre activité ou la validité de votre règle interne.

La matrice de décision peut compléter cette organisation si les rôles se chevauchent. Un intitulé « référent IA » ne suffit pas à expliquer ce que la personne est autorisée et capable de faire.

Exemple fictif : une réponse correcte hier, périmée aujourd’hui

Une équipe fictive utilise un assistant pour retrouver des règles internes de réservation. Le document A indiquait deux jours de préavis. Un document B, validé pour remplacer A, indique désormais trois jours. Un utilisateur obtient encore « deux jours » et transmet la question, la réponse et la référence citée au responsable de l’usage.

Ce constat ne démontre pas encore la cause. Il faut vérifier quelle version était accessible, si le remplacement a été pris en compte et ce que la réponse cite réellement. Ajouter une consigne « sois à jour » sans examiner les pièces ne ferme pas le problème.

La suite proposée : limiter temporairement l’usage pour cette question, renvoyer vers la source validée, corriger le traitement documentaire et rejouer le cas. Ces étapes sont illustratives ; aucun logiciel n’a été exécuté pour produire cette scène et aucun délai réel de réservation n’est donné.

Traiter le signalement jusqu’à une décision vérifiée

Un canal de remontée doit demander assez d’informations pour comprendre, sans imposer une enquête à chaque utilisateur : tâche, moment, résultat problématique et conséquence. Les pièces sensibles ne doivent pas être copiées dans un espace ouvert pour faciliter le diagnostic. Faites définir le canal adapté par les personnes responsables.

Le journal conserve un état clair : reçu, à examiner, correction en cours, vérification en attente ou clos. Ce vocabulaire est une proposition d’organisation. « Clos » doit être accompagné de ce qui a été contrôlé, pas seulement du message « le prestataire a corrigé ».

Le NIST distingue aussi la communication, le suivi et la reprise après incidents ou erreurs dans MANAGE 4.3. ^[1] Pour notre exemple, expliquez aux utilisateurs quelle question est concernée et quelle voie utiliser en attendant. Ne diffusez pas une promesse générale de fiabilité parce qu’un cas a été corrigé.

Prévoir des déclencheurs en plus du calendrier

Une revue programmée sert à examiner les difficultés récurrentes, le travail de contrôle et les usages abandonnés. Ajoutez des déclencheurs : changement d’un document de référence, d’une fonction, d’un accès, du public ou de la finalité. Chacun peut modifier ce qu’il faut vérifier.

Le journal de maintenance d’un usage IA fournit une trame et un exemple rempli. Il complète le pilote ; il ne remplace pas une investigation spécialisée quand une difficulté sort de votre compétence.

Je veux qu’un usage puisse être corrigé, limité ou arrêté sans que cela soit vécu comme l’échec du projet entier. Le résultat à préserver est le travail utile. Continuer par habitude n’est pas un critère de qualité.

Questions fréquentes

Faut-il une réunion de suivi chaque semaine ? Pas systématiquement. Choisissez un rythme selon les changements, la fréquence d’usage et les conséquences possibles. Un signalement important ne doit pas attendre la prochaine réunion.

Le fournisseur assure-t-il tout le suivi ? Vérifiez son périmètre réel. Le suivi du service technique ne répond pas forcément aux questions de validité documentaire, d’usage local et de décision métier.

Une correction réussie suffit-elle à reprendre ? Elle doit répondre aux critères fixés pour la reprise et au périmètre affecté. Un seul cas rejoué ne démontre pas que toutes les autres fonctions sont correctes.