Choisir des cas d’usage IA qui résistent à un dossier économique

Ce qui compte comme cas d’usage#

Un cas d’usage IA est une décision ou une tâche précise, dans un processus nommé, qu’un modèle réaliserait ou assisterait, avec un propriétaire désigné et un effet mesurable sur le coût, le revenu, le risque ou le service.

Tout ce qui est moins spécifique relève du thème et non du cas d’usage.

« l’IA dans le crédit » ou « l’IA au service client » sont des directions, pas des candidats, et elles ne peuvent être ni chiffrées, ni testées, ni refusées.

La discipline consistant à faire entrer un candidat dans cette phrase élimine une part surprenante d’une liste initiale avant toute analyse, ce qui est déjà utile.

Le premier test : la valeur#

Le premier test est celui de la valeur, et il doit précéder la faisabilité parce qu’il coûte moins cher. Un cas d’usage a de la valeur lorsque le volume est assez élevé pour qu’une petite amélioration unitaire se cumule en un montant qui mérite d’être piloté, et lorsque le coût actuel de la méthode alternative est réellement connu.

Les établissements surestiment régulièrement la valeur d’automatiser des tâches visibles et irritantes mais rares, et sous-estiment le travail invisible à fort volume — extraction documentaire, tri des alertes, rapprochements. La question honnête n’est pas de savoir si l’IA pourrait accomplir la tâche, mais ce que l’établissement ferait de la capacité libérée : si la réponse n’est rien de précis, l’économie est théorique.

Le deuxième test : les données#

Le deuxième test est celui des données, et il élimine plus de candidats que tout autre. La question pertinente n’est pas de savoir si l’établissement dispose de données, mais s’il dispose des bonnes données, exploitables légalement pour cette finalité, en volume suffisant, assorties d’étiquettes ou de résultats rendant l’apprentissage possible, et couvrant les conditions que le modèle rencontrera en production.

• Un modèle de crédit a besoin de résultats couvrant une période de retournement
• un modèle de fraude a besoin de cas avérés et non de simples alertes
• un modèle documentaire a besoin d’exemples de vraies soumissions désordonnées plutôt que de modèles propres

Des données jugées adéquates sur la foi d’un schéma, sans que personne n’ait examiné d’enregistrements réels, constituent le prédicteur le plus fiable d’un pilote qui sous-performe sans explication.

Le troisième test : l’adéquation à la décision#

Le troisième test est celui de l’adéquation à la décision : le processus a-t-il un endroit où placer la réponse ?

Un modèle produisant un score qu’aucune étape existante ne consomme, un classement qu’aucune file n’utilise, ou une recommandation qu’aucun rôle n’est habilité à suivre, produira un excellent résultat dans le vide.

C’est le test le plus souvent sauté, car il relève des opérations et non de la technologie, et aucun des deux camps ne le considère comme sien.

Pour l’appliquer, il faut parcourir le processus tel qu’il tourne aujourd’hui et identifier l’étape exacte où le résultat arriverait, qui s’y tient, ce que cette personne ferait différemment et de quelle autorité elle dispose. Si cette étape n’existe pas, il faut la concevoir — et la concevoir représente généralement plus de travail que construire le modèle.

Le quatrième test : la responsabilité#

Le quatrième test est celui de la responsabilité : quelqu’un signera-t-il pour le résultat ? Toute décision automatisée à conséquence exige une personne nommée qui accepte de répondre de son éventuelle erreur, et cette personne demandera légitimement quel est le taux d’erreur, à quoi ressemble une défaillance, auprès de qui le client se plaint, et ce qui se passe lorsqu’un superviseur ou un auditeur interroge.

Les cas d’usage meurent à ce test plus souvent qu’à aucun test technique, et généralement tard, une fois l’argent dépensé. Poser la question d’emblée — qui signe — réordonne aussitôt une feuille de route, car elle sépare les cas où la responsabilité est simple de ceux qui exigent une réponse de gouvernance avant même de pouvoir être construits.

L’écart entre le pilote et la production#

L’écart entre un pilote qui fonctionne et un système en production est l’endroit où se perd réellement l’essentiel de l’investissement en IA, et il vaut la peine de nommer précisément ce qui s’y trouve, car ce n’est presque jamais de la modélisation. La production exige :

• une intégration aux systèmes qui font tourner le processus
• une trace de décision permettant de reproduire tout résultat passé
• une surveillance détectant la dégradation
• une voie de contournement dotée d’une véritable interface
• un contrôle d’accès
• un plan de retour arrière
• un propriétaire avec une ligne budgétaire
• un dispositif de support pour le jour où cela tombera en panne en pleine clôture

Une preuve de concept cadrée sans tout cela n’est pas à quatre-vingts pour cent du chemin vers la production ; elle démontre que le modèle n’est pas l’obstacle.

Séquencer la feuille de route#

Bien séquencer une feuille de route suppose de résister à l’instinct de commencer par le cas le plus rentable. La première livraison doit être choisie pour sa capacité à éprouver le dispositif de bout en bout : significative mais non existentielle, avec des données propres, une place évidente dans le processus et un propriétaire qui la demande.

La livrer établit le circuit de gouvernance, le schéma d’intégration, l’approche de surveillance et la confiance de l’établissement — autant d’éléments qui rendront les deuxième et troisième cas plus rapides et moins coûteux. Commencer par le cas le plus difficile revient à inventer simultanément le dispositif, l’intégration et l’argument politique, sous l’enjeu le plus élevé possible.

Les formes qui tiennent et celles qui déçoivent#

Les candidats qui tiennent le mieux dans les établissements régulés partagent une même forme :

• fort volume
• tolérance à une erreur révisable
• une étape de processus existante où atterrir
• un propriétaire qui ressent déjà la douleur

L’extraction et le contrôle documentaires, le tri et la priorisation des alertes, la rédaction de premier jet avec validation humaine, le rapprochement et le routage des exceptions, et la recherche dans les politiques et procédures internes y correspondent tous.

Les candidats qui déçoivent le plus souvent partagent une autre forme :

• décisions à conséquence sur des personnes, où l’explication est exigée et l’erreur coûteuse
• arbitrages de jugement à faible volume, où il n’y a rien à apprendre
• tout ce dont la valeur dépend de données que l’établissement n’a pas confirmé pouvoir utiliser légalement

Les refus sont le livrable le plus précieux#

Le livrable le plus précieux d’un exercice de cas d’usage est généralement la liste des refus, à condition que les motifs y soient attachés.

• « Pas encore, car les données de résultats ne couvrent aucun retournement » est une décision qui pourra être réexaminée le moment venu.
• « Pas encore, car aucun rôle n’est habilité à agir sur le résultat » désigne un changement de processus que quelqu’un peut porter.
• « Non, car la décision est trop lourde de conséquences pour être automatisée avec notre capacité de validation actuelle » est une position défendable devant un conseil.

Une feuille de route ne comportant que des éléments approuvés, sans aucun refus, n’est pas issue d’un exercice — elle est issue d’une liste de souhaits.