Le problème des dirigeants en 2026 n’est pas le manque d’idées de cas d’usage IA. Ils en ont trop. Ce qui manque, c’est le filtre qui sépare le projet qui vaut six mois de travail du projet qui ne survivra pas à la première démo en interne. Voici les trois questions que je pose en réunion de cadrage. Trente minutes par cas d’usage, pas plus. Si une seule des trois reste sans réponse précise, on ne lance pas.

Quel problème précis l’IA résout-elle ?

Pas « comment l’IA pourrait améliorer notre productivité ». Quel problème précis, dans quel processus, avec quel volume actuel, quel temps de traitement, quelle qualité, quel coût ?

« Réduire le temps de traitement des demandes de support client » est une direction. « Réduire de 40% le temps de traitement des demandes de catégorie B (problèmes techniques simples) qui représentent 60% du volume et sont actuellement traitées en 48h » est un problème.

La différence n’est pas de détail. Un problème précis permet de définir un critère de succès mesurable. Un critère de succès mesurable permet de décider si le projet a fonctionné. Sans ça, vous ne pourrez pas évaluer le ROI et vous ne saurez pas quand arrêter.

Pourquoi l’IA et pas quelque chose de plus simple ?

C’est la question la plus inconfortable. Avant de lancer un projet IA, demandez-vous si le problème ne peut pas être résolu par un algorithme déterministe (règle métier, tri, filtre, regex). Sinon, par un tableau de bord et un processus de décision humain plus clair. Parfois, c’est une réorganisation de processus qui résout le sujet sans toucher à la technologie. Parfois, c’est juste un outil métier existant mieux configuré.

L’IA a des atouts : elle généralise sur des inputs non structurés, elle s’adapte à des variations, elle fonctionne sur des volumes élevés sans augmentation de coût proportionnel. Mais elle est probabiliste (donc faillible), opaque, difficile à auditer, et plus chère à maintenir qu’une règle déterministe. Un tri de documents par mots-clés avec des règles métier claires est moins cher, plus prévisible, et plus explicable qu’un LLM pour la même tâche si les catégories sont bien définies.

Qui gère les cas où l’IA se trompe ?

C’est la question que les démos ne posent jamais. Dans une démo, tout marche. En production, 3 à 20% des cas (selon la tâche et le modèle) ne marchent pas comme prévu. Quelqu’un doit s’en occuper.

Qui détecte les erreurs ? Comment sont-elles signalées ? Qui les corrige ? Qui est responsable des décisions basées sur une sortie IA incorrecte ?

Si vous ne pouvez pas répondre à ces questions, votre processus de déploiement est incomplet. Ce n’est pas un problème technique. C’est un problème d’organisation et de responsabilité. L’IA ne supprime pas la responsabilité. Elle la déplace.

Sur les grilles de scoring

Une matrice de scoring promet de transformer la décision en addition. Elle ne le fait pas. L’arbitrage se prend dossier par dossier, en regardant le contexte de l’organisation, la maturité de l’équipe, le coût d’opportunité du non-projet. Toute grille qui prétend trancher à votre place est une simplification dangereuse.