Cas d'usage

Reconnaître un vrai cas d'usage

Un cas d'usage se décrit sans le mot IA. Il commence par une phrase du type : chaque semaine, quelqu'un passe deux heures à recopier des informations de bons de livraison dans un tableur. On identifie qui fait ce travail, à quelle fréquence, avec quels documents, quelles erreurs surviennent et ce que ces erreurs coûtent. La technologie n'entre dans la description qu'ensuite, comme un moyen parmi d'autres d'alléger cette tâche.

Cette formulation protège contre une illusion fréquente, celle du projet qui part de l'outil. Acheter une licence puis chercher à quoi l'employer conduit presque toujours à des démonstrations convaincantes et à aucun changement dans le travail réel. Partir du processus, avec ses irritants mesurés, permet au contraire de comparer plusieurs solutions, dont l'IA n'est parfois pas la meilleure : un formulaire mieux conçu, un export automatique ou une règle de gestion suffisent souvent.

Ce qui fait échouer un cas d'usage

Le premier échec est le périmètre trop large. Un projet qui vise à fluidifier toute la relation client ne se pilote pas ; un projet qui vise à trier les courriels de réclamation d'un service et à en extraire trois champs se pilote. Le découpage doit être assez fin pour qu'une personne puisse dire, à la fin, si le résultat est meilleur qu'avant. Sans cette limite, le projet n'a pas de fin et le budget se disperse en ajustements successifs.

Le deuxième échec est l'absence de propriétaire. Un cas d'usage porté par la seule direction informatique, sans un métier qui le réclame et qui acceptera de changer ses habitudes, s'arrête au premier contretemps. Il faut quelqu'un dont le travail change réellement, qui puisse dire ce qui ne va pas et qui ait intérêt à ce que l'outil fonctionne. C'est cette personne, plus que le choix du modèle, qui décide de la réussite.

Formuler et mesurer

Un cas d'usage bien formulé comporte quatre éléments : le processus concerné, le volume traité, le gain attendu et le critère de réussite. Le gain peut être du temps, une réduction des erreurs, un délai plus court ou une capacité nouvelle, comme traiter des demandes en créole. Le critère doit être vérifiable : taux d'extraction exacte, nombre de dossiers traités par jour, délai moyen de réponse, nombre de reprises par un humain.

La mesure de départ est l'étape la plus souvent sautée. Sans relevé initial, on ne peut pas démontrer de progrès, et les discussions se règlent à l'impression. Relever pendant deux semaines le temps passé, le nombre d'erreurs et les points de blocage suffit dans la plupart des cas. Ce relevé coûte peu et rend le bilan incontestable, y compris lorsqu'il conclut qu'il ne faut pas poursuivre, ce qui est aussi un résultat utile.

Du cas d'usage au portefeuille

Une organisation ne traite pas un cas isolé, elle en accumule. Les plus simples servent de démonstration et créent la confiance : résumer un compte rendu, préparer un brouillon de réponse, traduire une notice. Les plus complexes demandent des données propres, des intégrations et des contrôles : analyse de dossiers, aide à la décision, traitement de pièces scannées. Cette progression évite d'engager un budget lourd sur un premier projet encore mal cadré.

Le portefeuille se tient comme un tableau simple : cas, responsable, statut, gain mesuré, coût annuel. Cette vue permet de repérer les usages qui coûtent plus qu'ils ne rapportent et ceux qui plafonnent faute d'entretien. Elle évite aussi la multiplication d'outils redondants, achetés séparément par des services qui ne se parlent pas, et qui finissent par produire des résultats contradictoires sur les mêmes données. Ce tableau, tenu à jour, vaut mieux qu'un rapport de projet de quarante pages.