Un pilote d’IA donne de bons résultats, les métiers sont satisfaits, et la question du déploiement se pose naturellement. Ce qu’on regarde moins, c’est le travail qui a rendu ces résultats possibles : des données préparées à la main, des réponses du modèle relues et corrigées avant d’arriver aux équipes.
Ce travail ne disparaît pas au moment de généraliser. Il change d’échelle, parfois de nature, et doit trouver sa place dans le quotidien des équipes. Pour savoir si un usage d’IA peut durer, il faut donc distinguer ce que fait le modèle de ce que font les humains autour de lui. Et ce travail humain consiste surtout à apporter le contexte que les demandes ne contiennent pas.
Ce que le pilote ne montre pas
Prenons une IA qui classe les demandes internes (création d’accès, rétablissement de compte…) pour les orienter vers la bonne équipe. Pendant le test, une personne harmonise les formulations en amont, puis relit et corrige les catégories proposées en aval.
Le pilote a réussi, mais c’est l’ensemble qui a réussi, pas le modèle seul : ses résultats ont été obtenus sur des données déjà préparées, puis corrigés avant d’arriver aux équipes.
À plus grande échelle, le travail change
Quand l’usage s’étend à d’autres directions, le vocabulaire se diversifie et les cas deviennent plus ambigus : un « accès à rétablir » peut viser un compte existant ou une habilitation jamais activée. Le modèle classe toujours aussi bien les demandes préparées, mais les préparer et les vérifier demande plus de travail.
Ce travail consiste surtout à apporter le contexte : la direction qui émet la demande, le système concerné, l’historique du compte. Le modèle, lui, ne voit que le texte. Une partie de ce contexte peut être fournie en amont, avec quelques champs structurés (direction, application, compte existant ou non), ce qui réduit les cas que seul un humain peut trancher.
Ce travail fait partie du quotidien
Pendant le pilote, une équipe dédiée s’en charge sur un périmètre limité. En production, ce travail revient avec chaque demande et doit trouver sa place à côté des autres tâches. Une demande ambiguë reste bloquée tant que quelqu’un qui connaît son contexte ne l’a pas validée, même si le modèle a répondu. Le cadre AI RMF du NIST distingue d’ailleurs les rôles des humains et de l’IA, notamment pour la supervision des systèmes (airc.nist.gov).
Ces interventions ne sont pas un obstacle : ce sont elles qui rendent les résultats exploitables. L’enjeu n’est pas de les supprimer, mais de leur faire une place dans l’organisation.
L’effort évolue même après le déploiement
Même sans nouvelle direction, les demandes changent (nouvelles abréviations, nouvelles formulations) et les attentes aussi : un jour, « problème d’accès » ne suffit plus, il faut distinguer rétablissement de compte et modification d’habilitation. Le modèle n’a pas changé, mais il faut plus d’effort pour rendre ses réponses exploitables. Le succès du pilote ne dit donc pas une fois pour toutes ce que les équipes devront apporter.
Mesurer l’effort humain : cinq indicateurs
L’effort décrit plus haut reste invisible tant qu’on ne mesure que la précision du modèle. Cinq indicateurs simples permettent de le suivre dès l’expérimentation, puis après le déploiement.
| Indicateur | Ce qu’il mesure | Signal à surveiller |
|---|---|---|
| Taux de reformulation en amont | Part des demandes harmonisées avant d’être soumises au modèle | Hausse à chaque nouvelle direction ou au fil des mois |
| Taux de correction en aval | Part des propositions modifiées avant transmission aux métiers | Écart croissant entre précision du modèle et qualité finale |
| Temps humain par demande | Minutes de préparation et de vérification par demande traitée | Hausse alors que la précision du modèle est stable |
| Délai des cas ambigus | Temps d’attente des demandes bloquées faute de validation métier | Files d’attente qui s’allongent, toujours chez les mêmes personnes |
| Concentration des compétences | Nombre de personnes capables de trancher les cas difficiles | Une ou deux personnes seulement, sans relais |
Mesurés pendant l’essai, ces indicateurs donnent une base de comparaison. Suivis ensuite, ils montrent si l’usage reste soutenable, même quand les résultats techniques ne bougent pas.
Avant de passer à l’échelle : sept questions à se poser
Avant d’étendre un usage validé en expérimentation, ces questions aident à rendre explicite le travail qui l’accompagne.
- Qui a préparé les données pendant l’essai, et combien de temps y a-t-il consacré ? Sans réponse chiffrée, le coût réel de l’expérimentation reste inconnu.
- Quelle part des résultats a été corrigée avant d’arriver aux métiers ? Elle sépare la performance du modèle de celle du dispositif complet.
- Les nouvelles directions parlent-elles le même langage que le périmètre de l’essai ? Un vocabulaire différent signifie plus de préparation, même si le modèle reste aussi précis.
- Quel contexte manque aux demandes entrantes, et peut-on l’y ajouter ? Chaque information fournie en amont (direction, système, historique) est une vérification humaine en moins.
- Qui saura trancher les cas ambigus dans chaque direction ? Ces personnes doivent être identifiées et disponibles, pas seulement compétentes.
- Dans quelles tâches existantes ce travail va-t-il s’insérer ? S’il n’a de place dans aucun planning, il reposera sur la bonne volonté de quelques personnes.
- Comment saura-t-on que l’effort augmente ? Sans indicateurs suivis après le déploiement, la dérive ne se voit que lorsque le traitement bloque.
Conclusion
Un usage d’IA dure si le travail humain qui l’accompagne est prévu, mesuré et intégré au quotidien. La qualité du modèle peut rester stable pendant que cet effort change, parce que les situations se diversifient, que les données évoluent ou que les attentes se précisent. Ce travail n’est pas à côté de l’usage : il en fait partie.
