Comment identifier les cas d’usage IA à forte valeur

La plupart des organisations ont le même problème avec l’IA : pas trop peu d’idées, beaucoup trop. Une liste de quarante cas d’usage circule dans une présentation, trois reçoivent un budget, deux meurent silencieusement en pilote, et celui qui survit est rarement celui qui comptait le plus. Les échecs coûteux ne sont pas ceux qui échouent en production ; ceux-là livrent au moins des leçons. Ce sont les cas d’usage qui n’auraient jamais dû être retenus en premier lieu.

Cet article présente comment filtrer cette liste. Pas avec une matrice valeur-faisabilité empruntée à une présentation de prestataire, mais avec un petit ensemble de questions pratiques qui prédisent, à l’avance, quelles idées d’IA méritent l’investissement et lesquelles vont absorber un temps que l’organisation ne récupérera jamais. Une fois qu’un cas d’usage passe le filtre, la suite opérationnelle est traitée dans la checklist de préparation IA.

Quatre questions, posées tôt et auxquelles on répond honnêtement, éliminent la majorité des idées qui n’auraient pas dû figurer sur la liste.

La première : les données existent-elles réellement, sous une forme qu’un modèle peut utiliser, aujourd’hui. Pas « on les collecte quelque part », mais : sont-elles assez propres, assez à jour et assez accessibles pour qu’un modèle puisse être entraîné ou alimenté dessus, sans un projet data parallèle de six mois en prérequis. Si la réponse honnête est non, le cas d’usage est un projet data d’abord et un projet IA ensuite, et faire semblant du contraire est la manière dont les budgets se dépensent sans rien livrer.

La deuxième : ce cas d’usage a-t-il un propriétaire opérationnel volontaire. Pas l’exécutif qui l’a suggéré en atelier, mais la personne dont l’équipe utilisera la sortie au quotidien après le lancement. Si aucun propriétaire opérationnel n’est prêt à s’engager, le cas d’usage est un projet de recherche, pas un déploiement, et doit être financé comme tel (ou pas du tout).

La troisième : quel est le coût d’avoir tort. Les sorties d’IA sont probabilistes. Si le cas d’usage peut absorber quelques pourcents d’erreur sans qu’aucune personne ne soit lésée, attaquée en justice ou ne perde de l’argent, c’est un candidat pour l’IA. Si le coût d’une seule sortie fausse est un compte client gelé, une prescription médicale erronée ou un manquement réglementaire, le cas d’usage a besoin de bien plus qu’un modèle : il a besoin d’une revue humaine intégrée à la conception, d’un audit et d’un chemin de rollback avant qu’un déploiement ne soit réaliste.

La quatrième : ce problème a-t-il vraiment besoin d’IA, par opposition à une règle, à une requête, à un changement de workflow ou simplement à un meilleur dimensionnement des effectifs. Beaucoup d’« idées d’IA » sont des problèmes qu’une requête SQL, un formulaire structuré ou une checklist d’une page résoudraient à moindre coût, plus fiablement, et sans risque de modèle. L’IA est pertinente quand l’entrée est non structurée, quand les schémas sont trop variés pour des règles, et quand le volume justifie la charge opérationnelle. Quand ce n’est pas le cas, le construire avec de l’IA est une manière plus chère de moins bien résoudre le même problème.

Une fois qu’une idée a passé les quatre questions, le filtre suivant est comparatif. Placez les cas d’usage survivants sur une grille à deux axes : impact métier (l’argent ou la réduction de risque que le cas d’usage délivre vraiment s’il fonctionne) contre faisabilité (à quel point les données, la propriété, l’intégration et le calendrier sont réalistes). Les quatre quadrants racontent des histoires différentes.

Impact élevé, faisabilité élevée : ce sont ceux à construire en premier, avec un investissement adéquat. Ce sont aussi ceux que la plupart des organisations sous-financent, parce que les idées y paraissent moins glamour qu’à côté du quadrant impact élevé / faisabilité faible.

Impact élevé, faisabilité faible : ce sont les cas stratégiquement intéressants. Traitez-les comme des constructions de capacité sur plusieurs trimestres, pas comme des déploiements pour le trimestre prochain. Les financer comme s’ils étaient prêts est l’erreur la plus coûteuse de la matrice.

Impact faible, faisabilité élevée : utiles comme preuves de concept, comme terrain d’apprentissage pour l’équipe, et comme manière de bâtir le muscle opérationnel. Construisez-les quand ils permettent directement de débloquer ceux à fort impact, pas parce qu’ils sont faciles.

Impact faible, faisabilité faible : abandonnez. Le fait que quelqu’un dans la salle soit attaché à l’un d’eux n’est pas une raison de le garder sur la liste.

Pour les organisations qui n’ont pas encore mis d’IA réelle en production, le premier cas d’usage compte de façon disproportionnée, parce que tout ce que l’organisation va croire de l’IA pendant les dix-huit mois suivants sera façonné par lui. Cinq caractéristiques séparent systématiquement les premiers cas d’usage qui construisent de la crédibilité de ceux qui la détruisent.

Ils traitent une tâche à fort volume, où même une amélioration modeste se cumule. Gagner vingt secondes sur une tâche faite quatre cents fois par jour est plus utile que gagner une heure sur une tâche faite une fois par trimestre.

Ils s’appuient sur une douleur opérationnelle structurée : un workflow répétitif dont la douleur est visible et chiffrée, pas une aspiration vague comme « améliorer l’expérience client ».

Ils sont facilement mesurables : il existe aujourd’hui un chiffre de référence, et une manière claire de mesurer si la version IA est meilleure, pire ou identique.

Ils sont facilement réversibles : si la version IA s’avère fausse, l’organisation peut revenir à la manière de travailler précédente en quelques jours, pas en plusieurs mois.

Et ils ont un propriétaire nommé qui veut le résultat, pas un sponsor qui veut l’annonce. La différence entre ces deux motivations est généralement la différence entre un cas d’usage qui s’installe et une diapositive que tout le monde finit par cesser de citer.

Quelques catégories de « cas d’usage IA » reviennent dans presque chaque atelier et méritent rarement le créneau qu’on leur donne.

L’IA de vitrine : le cas d’usage qui existe surtout pour être mentionné dans un rapport annuel ou une présentation aux investisseurs. Ils sont généralement sur-cadrés, sous-portés, et abandonnés le trimestre qui suit la sortie de la présentation.

L’automatisation totale des cas limites : la longue traîne des cas inhabituels est précisément là où les modèles échouent le plus souvent. Essayer d’automatiser les cas limites en premier, plutôt que le travail courant à fort volume, est une mauvaise allocation structurelle qui gaspille à la fois le temps et la confiance.

Le remplacement complet d’un humain compétent sur une tâche de jugement : les tâches qui demandent un jugement contextuel (un souscripteur senior, un médecin expérimenté, un avocat spécialisé) ne deviennent presque jamais un déploiement IA d’un seul tenant. Elles deviennent un déploiement IA-assistant, où l’humain reste dans la boucle et fait le même travail plus vite. Cadrer cela autrement au moment de la sélection mène à une année de déception.

Construire pour la démo : choisir le cas d’usage qui démontre le mieux, pas celui qui s’installera le mieux en production. Un cas d’usage qui gagne le comité de pilotage mais ne survit pas à son premier mois d’usage opérationnel réel n’aurait pas dû passer la sélection.

Le moment à plus fort effet de levier dans tout portefeuille IA est la sélection. Une fois qu’un cas d’usage est financé, l’inertie organisationnelle rend très difficile de l’arrêter, même quand la réponse à l’une des quatre questions de filtre est désormais clairement non. Choisir les bons cas d’usage en amont fait économiser plus d’argent, de temps et de crédibilité que n’importe quelle amélioration de delivery par la suite. Choisir les mauvais coûte les trois, à répétition, et apprend silencieusement à l’organisation à croire que « l’IA ne marche pas chez nous ».

Le contexte plus large, dont la manière dont la sélection des cas d’usage se relie à la stratégie IA, à la gouvernance et au modèle opératoire, est rassemblé dans le cluster stratégie IA et automatisation. Et lorsque la question passe de « nous avons une longue liste d’idées » à « il nous faut un portefeuille qui livre, avec les bons retenus, les mauvais déclinés proprement, et les survivants armés pour réussir », c’est exactement ce sur quoi mon accompagnement transformation digitale est centré.