Cas d’usage IA : définition et méthode pour le décrire

Que recouvre un cas d’usage IA ?

Un cas d’usage IA répond à trois questions : quelle tâche, pour qui, avec quel gain mesurable. « Utiliser l’IA au service client » n’est pas un cas d’usage. « Classer par motif les réclamations reçues par courriel avant de les affecter aux conseillers » en est un.

Une description utile tient en une page. Elle précise cinq points.

1. La tâche : son début, sa fin, son volume, ses exceptions.

2. Les personnes : celles qui font la tâche aujourd’hui, celles qui utiliseront le résultat, et le responsable métier qui en répond.

3. Le gain attendu : un indicateur (temps, délai, taux d’erreur) et sa valeur actuelle, que vous mesurez avant le projet.

4. Les données : leur existence, leur qualité, les droits d’accès.

5. L’alternative simple : une règle, une automatisation classique ou une meilleure organisation feraient-elles le même travail ?

Cas d’usage, POC ou projet IA : quelle différence ?

Le cas d’usage décrit un besoin ; le POC teste une solution ; le projet engage un budget et des équipes. Le cas d’usage vient en premier. Un POC lancé sans cas d’usage écrit prouve qu’un outil fonctionne, pas qu’il sert.

Ne confondez pas non plus le cas d’usage IA avec le use case du génie logiciel. Ivar Jacobson et Alistair Cockburn définissent ce dernier comme toutes les façons d’utiliser un système pour atteindre un objectif particulier, pour un utilisateur particulier. Le use case décrit un système à construire. Le cas d’usage IA décrit une tâche à transformer et le gain à prouver.

Que change un cas d’usage bien décrit pour votre décision ?

Un cas d’usage bien décrit vous permet de comparer les projets entre eux et de dire non tôt, avant d’engager le budget.

• Partez de la tâche, pas de l’outil. Un même assistant IA peut servir plusieurs tâches, avec des gains très différents. Chaque tâche mérite sa propre description.

• Sans mesure de départ, vous ne prouverez aucun gain. Mesurez le temps, le volume ou le taux d’erreur avant le projet. Comptez aussi le temps que vos équipes passeront à vérifier les réponses. Calculez le ROI du projet sur cette base.

• L’usage décide du régime juridique. Pour classer un système à haut risque, le règlement européen sur l’IA regarde son usage, pas sa technologie. Un système d’IA qui filtre des candidatures relève de l’annexe III, point 4 a), donc en principe du haut risque. Les obligations de ces systèmes s’appliquent à partir du 2 décembre 2027 (règlement 2026/1744).

• La description révèle tôt les causes d’abandon. Données inaccessibles, gain impossible à mesurer, coût d’usage sous-estimé : une description complète expose ces risques avant tout engagement.

• Les personnes qui font la tâche entrent dans la décision. Elles connaissent les exceptions qu’aucune procédure ne décrit, et leur participation prépare l’adoption. Dans les entreprises d’au moins 50 salariés, le Code du travail prévoit aussi d’informer et de consulter le CSE sur l’introduction de nouvelles technologies (article L2312-8) ; les juges apprécient au cas par cas si un outil d’IA l’exige.

Exemple illustratif

Ce cas est fictif. Le comité de direction d’une ETI de distribution reçoit une demande : « mettre de l’IA au service client ». La responsable du service la reformule en cas d’usage. Tâche : lire chaque réclamation reçue par courriel, la classer par motif et l’affecter au bon conseiller. Personnes : les conseillers, qui trient aujourd’hui à la main, et la responsable, qui répond du délai de traitement. Gain visé : réduire le délai entre la réception et la première réponse. L’équipe mesure ce délai pendant un mois avant tout projet. Elle vérifie que l’historique des réclamations indique le motif de chaque dossier. Elle compare enfin avec une alternative simple : des règles de tri par mots-clés dans la messagerie. Le comité peut alors choisir : tester, préparer, différer ou écarter.