Déployer l’IA : du premier essai à un usage qui tient.

Choisir une tâche, pas une ambition abstraite

« Mettre de l’IA dans l’établissement » ne permet pas de choisir une solution. « Réduire le temps consacré au premier jet d’un compte rendu, sans perdre les décisions prises » donne un objet de travail. Le périmètre est compréhensible, les personnes concernées peuvent le discuter et le résultat peut être examiné.

Je commence par reconstruire la situation actuelle : qui produit le document, à partir de quelles informations, qui le relit, qui le valide et ce qu’il devient ensuite. Si le processus est confus, l’IA risque de déplacer la confusion. Une clarification de l’organisation peut être plus utile qu’un nouvel outil.

Définir la réussite avant de voir une démonstration

Une sortie fluide ne prouve pas qu’elle est correcte. Je propose de définir, avant l’essai, ce que l’équipe attend et ce qu’elle refuse. Pour un compte rendu, cela peut être : décisions correctement restituées, responsables identifiés, absence d’action inventée, distinction entre une hypothèse et une décision.

Ajoutez le temps de préparation et de relecture. Si un outil produit un brouillon en trente secondes mais demande vingt minutes de correction, ces vingt minutes appartiennent au coût du travail. Comparez des tâches comparables et conservez les exemples qui ont posé problème.

Le NIST décrit le risque de contenus faux présentés avec assurance et recommande de vérifier les références produites par une IA générative. Une réponse accompagnée de citations ne dispense donc pas de lire ce qu’elles soutiennent réellement. ^[1]

Pour approfondir ce point : Choisir un outil IA : commencer par le besoin.

Préparer un essai que l’on peut réellement interrompre

Choisissez un petit groupe, une durée et un responsable. Le groupe doit représenter les utilisateurs prévus, pas seulement les personnes les plus enthousiastes. Prévoyez des cas faciles, des cas ambigus et des cas où la bonne réponse consiste à signaler une information manquante.

Les données utilisées, les accès, la conservation et les destinataires doivent être examinés avec les personnes compétentes de l’organisation. Un outil agréable à utiliser ne tranche pas ces questions. Une expérimentation ne dispense pas de respecter les règles applicables aux données et au contexte.

La CNIL recommande notamment de définir les besoins et les usages, d’organiser la gouvernance et de former les utilisateurs. ^[2] Concrètement, je propose de consigner la version du modèle, les consignes données, les documents utilisés et les conditions de l’essai. Si ces éléments changent, deux résultats apparemment comparables peuvent correspondre à des situations différentes.

La personne qui contrôle doit disposer du document de référence, du temps nécessaire et de la compétence pour repérer un écart. Elle doit aussi pouvoir refuser le résultat. Sinon, « une relecture humaine est prévue » décrit une intention, pas une organisation opérationnelle.

Pour approfondir ce point : Gain de temps avec l’IA : calcul et méthode.

Observer les reprises, autant que les réussites

Voici un exemple fictif de grille de suivi : pour chaque essai, noter la tâche, le temps complet, les corrections nécessaires, la décision de l’utilisateur et la raison d’un éventuel rejet. Une erreur récurrente dans les noms ou les dates doit pouvoir être repérée séparément d’un problème de style.

Demandez aussi ce que l’outil change dans le travail. Qui hérite de la vérification ? Le résultat est-il plus facile à partager ? Les utilisateurs comprennent-ils quand ils doivent s’en passer ? Une amélioration locale peut transférer une charge ailleurs. C’est ce transfert qu’il faut rendre visible.

Ce calcul n’est pas un retour sur investissement. Il exclut le paramétrage, la formation, les abonnements et la maintenance ; il suppose aussi une qualité finale comparable. Si une erreur importante apparaît, il faut l’examiner séparément : une moyenne de temps favorable ne la rend pas acceptable. Pour décider d’un achat, complétez cette observation par les coûts fixes et les charges récurrentes propres au projet.

Décider : continuer, modifier ou arrêter

La fin d’un pilote doit produire une décision. Continuer si les critères définis sont atteints ; modifier si une difficulté peut être traitée ; arrêter si l’intérêt ne se confirme pas ou si les conditions ne sont pas réunies. Arrêter un essai utilement évalué est une décision de gestion, pas un échec à dissimuler.

La décision doit préciser ce qui est autorisé, pour qui et dans quel périmètre. Un bon résultat sur un type de document ne valide pas automatiquement tous les autres usages. Conservez une trace des limites de l’essai afin de ne pas leur faire dire davantage.

Le NIST invite à ne pas extrapoler à partir d’évaluations étroites ou anecdotiques. ^[1] Je recommande donc de noter les catégories de situations effectivement testées et celles qui ne l’ont pas été. Dix exemples choisis pour une démonstration ne permettent pas d’annoncer un taux général de fiabilité.

• Continuer : préciser les utilisateurs, tâches et données concernés, ainsi que le responsable du suivi.
• Modifier : nommer la difficulté à résoudre et ce qui sera réévalué.
• Arrêter : conserver les enseignements et organiser le retour au fonctionnement habituel.

Installer une pratique et prévoir sa révision

Le déploiement commence lorsque le travail ordinaire intègre la solution. Il faut une consigne compréhensible, des exemples de bons et de mauvais résultats, un interlocuteur et une manière de remonter les difficultés. Une formation initiale est utile, mais les questions les plus concrètes apparaissent souvent après.

Fixez un point de revue : les personnes utilisent-elles la solution ? Les corrections restent-elles acceptables ? Les documents, les outils ou les besoins ont-ils changé ? Le suivi doit rester proportionné. Son rôle est de rendre les décisions possibles, pas de créer une administration du pilote.

Une modification du modèle, du corpus documentaire ou du processus métier peut justifier une nouvelle vérification. Le dossier du pilote doit permettre de comprendre ce qui avait été accepté et pourquoi. Je préfère quelques traces exploitables — cas testés, erreurs rencontrées, décisions et responsables — à un tableau de bord abondant que personne n’utilise pour arbitrer.

Après le lancement, précisez qui entretient l’usage IA et traite les changements.

La fiche à compléter avec votre équipe

Notre tâche : … / Les utilisateurs : … / Le résultat attendu : … / Les erreurs inacceptables : … / Les données utilisables : … / La personne qui vérifie : … / La durée de l’essai : … / Les critères de poursuite et d’arrêt : …

Cette fiche est un point de départ opérationnel. Elle ne remplace ni une analyse technique, ni l’examen des obligations propres à votre activité. Sa valeur tient à la discussion qu’elle rend possible entre ceux qui décident et ceux qui utiliseront la solution.