Les cas d'usage de l'IA qui tiennent ne viennent pas d'un catalogue. Ils viennent de ceux qui font le travail, quand on leur pose la bonne question : qu'est-ce que vous détestez faire, et qui prend du temps ?
Pourquoi le catalogue ne marche pas
Tous les fournisseurs ont le leur. Rédaction d'emails, synthèse de documents, chatbot client, analyse de données. Ce n'est pas faux. C'est juste inutile, parce que ça ne dit rien de votre boîte. Un cas d'usage copié d'ailleurs est un cas d'usage que personne ne porte. Il finit en projet pilote, avec un comité, et il dure huit mois.
Les trouver avec ceux qui font le travail
La personne qui passe deux heures par semaine à reformater le même tableau sait exactement où l'IA lui ferait gagner du temps. Elle ne le dira pas en réunion de service, parce que ça ressemble à un aveu. Elle le dira dans un atelier où la question est posée franchement, où le manager n'est pas là pour juger, et où la réponse ne sera pas « on verra ».
C'est aussi là que sortent les usages déjà existants, ceux que les gens font en cachette sur leur téléphone. Ils sont précieux : ce sont des cas d'usage validés par la pratique, qu'il suffit de sortir de la clandestinité et d'encadrer.
L'atelier, concrètement
Une demi-journée, par équipe ou par service, dix à quinze personnes, avec un facilitateur et sans la hiérarchie directe si elle bloque la parole. Trois questions dans l'ordre : qu'est-ce qui vous prend du temps et n'a pas de valeur ? Qu'est-ce que vous faites déjà avec un outil, officiellement ou pas ? Qu'est-ce que vous ne voudriez jamais voir confié à une machine ? La troisième question est la plus importante : elle produit les lignes rouges, et elle rassure.
Trier, sans tout garder
L'atelier sort vingt idées. On n'en garde pas vingt. Deux critères, et un seul arbitrage : le temps réellement gagné, et le risque si l'outil se trompe. Un cas qui gagne beaucoup de temps avec un risque faible passe en premier. Un cas qui gagne peu avec un risque fort ne passe pas, même si le fournisseur le montre en démo. Le résultat alimente la feuille de route, et parfois la formation, dont le troisième module travaille précisément sur vos cas.
Ce qui ressort, en général
Sans surprise, beaucoup de documents : synthétiser ce qu'on n'a pas le temps de lire, préparer ce qu'on rédige toujours pareil, traduire, reformuler pour un autre public, comparer deux versions. Et, moins attendu, beaucoup de choses qui ne relèvent pas de l'IA du tout : des tâches en double, des validations inutiles, des tableaux que personne ne lit. L'atelier les fait remonter aussi. C'est un des effets secondaires les plus utiles.
Deux critères, un arbitrage
| Risque faible si l'outil se trompe | Risque fort si l'outil se trompe | |
|---|---|---|
| Beaucoup de temps gagné | En premier. Souvent des synthèses, des préparations, des reformulations. | Avec une relecture humaine obligatoire, écrite dans la règle. Jamais seul. |
| Peu de temps gagné | Plus tard, ou jamais. Ce n'est pas parce que c'est possible que c'est utile. | Non. Même si le fournisseur le montre en démo. |
La colonne de droite produit les lignes rouges. La ligne du haut produit les chantiers.
Vos questions
Ce qu'on nous demande sur ce sujet, et ce qu'on répond.
Comment identifier les cas d'usage de l'IA dans une entreprise ?
Pas avec un catalogue de fournisseur, mais en atelier avec ceux qui font le travail : ce qui leur prend du temps sans valeur, ce qu'ils font déjà avec un outil, ce qu'ils ne voudraient jamais confier à une machine. Une demi-journée par équipe suffit.
Comment trier les cas d'usage ?
Deux critères : le temps réellement gagné, et le risque si l'outil se trompe. Beaucoup de temps et peu de risque passe en premier. Peu de temps et beaucoup de risque ne passe pas, quelle que soit la démo.
Que faire des usages que les gens font déjà en cachette ?
Les sortir de la clandestinité. Ce sont des cas validés par la pratique, il suffit de les encadrer avec une règle de confidentialité claire. Les sanctionner, c'est perdre à la fois l'usage et la confiance.