Combien de cas d'usage faut-il abandonner

Abandonner un cas d’usage d’IA au cadrage, c’est décider de ne pas le construire maintenant, pour un motif écrit et vérifiable, avant qu’il ait consommé du budget et de l’attention. Ce n’est ni un échec ni un refus de principe : c’est une décision documentée, qui peut être revue.

Un cas d’usage, au sens du cadrage, est une tâche précise qu’un système d’IA pourrait prendre en charge ou assister : répondre à des questions sur un corpus réglementaire, préparer une première version de compte rendu, trier des demandes entrantes. La liste de départ est en général produite en atelier, à partir des irritants exprimés par les équipes.

L’abandon intervient quand l’examen montre qu’une condition manque : une donnée exploitable, un moyen de vérifier le résultat, un volume suffisant, un responsable. Il se distingue de l’arrêt d’un projet en cours, qui survient après des mois de travail et coûte beaucoup plus cher. La démarche d’ensemble, de la liste initiale au cas retenu, est décrite dans la GenAI en entreprise, de zéro au cas d’usage.

Sur les cadrages que j’ai menés depuis trois ans, sur cinq cas d’usage identifiés au départ, deux au plus méritaient d’être construits : c’est un constat d’expérience, pas une statistique. La proportion a été stable d’une mission à l’autre, mais elle ne prétend pas valoir pour toutes les organisations.

Ce n’est pas un signe que les organisations formulent mal leurs besoins. C’est le fonctionnement normal d’un cadrage : la liste initiale est produite avant qu’on ait regardé les données, les processus et les contraintes. Elle est faite pour être réduite.

Le bon objectif n’est donc pas un ratio, mais une liste courte de cas qui réunissent toutes leurs conditions. Si les cinq cas les réunissent, on les garde ; c’est simplement rare.

Un cas d’usage d’IA s’évalue sur cinq critères vérifiables en atelier, chacun associé à une question précise et à un signal d’élimination que tout le monde peut constater. La grille ci-dessous sert de support à cette revue.

L’ordre compte. La vérifiabilité vient en premier parce qu’elle conditionne tout le reste : sans moyen de juger une réponse, on ne peut ni construire un jeu de tests, ni mesurer un progrès, ni défendre le système devant un comité.

Un cas qui échoue sur un seul critère n’est pas forcément écarté définitivement ; il est écarté tant que la condition manque, et cette condition est écrite.

Écarter un cas d’usage non viable dès les premières semaines de cadrage évite qu’il consomme des trimestres de budget, d’équipes internes et d’attention de la direction avant que quelqu’un accepte de l’arrêter.

Un cas d’usage non viable ne s’arrête pas de lui-même. D’expérience, il consomme souvent deux à trois trimestres avant que quelqu’un accepte de le dire, et il occupe pendant ce temps des équipes internes, un budget, et surtout la fenêtre d’attention de la direction. C’est le scénario décrit dans l’anatomie d’un PoC qui ne passe jamais.

Écarter en deuxième semaine plutôt qu’en huitième mois est donc l’essentiel de la valeur d’un cadrage. C’est aussi la partie la moins facile à vendre, parce qu’elle ne produit rien de visible.

Une équipe qui poursuit cinq cas d’usage d’IA simultanément n’en livre souvent aucun, parce que l’attention, les arbitrages et les moyens se diluent entre des projets qui ne se mutualisent pas. C’est l’argument qui convainc le plus en comité.

Chaque cas d’usage mobilise un propriétaire métier, un corpus, un jeu de tests et un dispositif de supervision. Ces quatre éléments ne se mutualisent pas : ils sont propres à chaque cas.

Deux cas menés jusqu’à la production valent mieux que cinq prototypes, et ils produisent la confiance nécessaire pour élargir ensuite. Les traits communs aux systèmes qui aboutissent sont détaillés dans agents en entreprise : où s’arrêtent les projets, et les obstacles typiques du passage en production dans sortir du prototype : les cinq verrous.

Dans les cadrages que j’ai menés, le corpus indisponible ou désordonné est devenu le premier motif d’écartement des cas d’usage d’IA, devant l’absence de propriétaire métier. C’est le déplacement que j’ai observé sur trois ans.

La raison est que les autres obstacles se sont allégés : les modèles sont meilleurs, les coûts ont baissé, l’intégration est plus simple. Le corpus, lui, n’a pas bougé.

D’après mon expérience, un cas d’usage dont personne ne sait dire quels documents font autorité coûte de l’ordre de trois fois plus qu’un cas équivalent sur une base tenue. C’est une estimation de praticien, non une mesure publiée, mais l’écart est assez net pour justifier qu’on le regarde au cadrage, où il ne se voit pas spontanément. Le raisonnement complet figure dans le corpus est le projet.

Trier une liste de cas d’usage d’IA demande cinq étapes courtes, menées avec les métiers, qui transforment une liste d’idées en un ou deux projets défendables et une liste d’écartements motivés.

1. Reformuler chaque cas en tâche : qui fait quoi aujourd’hui, à quelle fréquence, avec quels documents. Une idée qui ne se reformule pas en tâche est écartée d’emblée.
2. Passer chaque cas à la grille des cinq critères, en commençant par la vérifiabilité, et noter le premier critère qui échoue.
3. Examiner un échantillon réel de documents ou de demandes pour les cas restants : c’est là que l’état du corpus apparaît.
4. Demander un nom pour chaque cas restant : le responsable métier qui en répondra et qui validera les tests.
5. Retenir un ou deux cas, et écrire pour chaque cas écarté le motif précis et la condition qui permettrait de le rouvrir.

La cinquième étape n’est pas une formalité. Elle produit le document qui servira six mois plus tard, quand la question reviendra. C’est aussi ce que livre un audit IA bien mené : moins une liste d’opportunités qu’une liste de décisions motivées.

Un cas d’usage écarté au cadrage doit être remplacé par une action concrète, report conditionnel, réduction ou solution non-IA, sinon l’exercice est vécu comme un refus. C’est ce qui fait accepter la sélection.

Trois issues sont utiles. Le cas est reporté avec une condition explicite : « quand le référentiel produit sera versionné ». Le cas est réduit à une portion traitable : non pas tout le processus, mais l’étape de vérification. Ou le cas est renvoyé vers une solution non-IA, ce qui est parfois la bonne réponse.

Cette troisième issue est la plus mal reçue et souvent la plus juste : un problème de règle métier se traite par une règle, pas par un modèle probabiliste. C’est une application directe de agent ou simple appel.

Une partie des cas d’usage écartés revient plus tard, une fois la condition manquante remplie, et c’est tout l’intérêt de les documenter plutôt que de les enterrer.

Je tiens une liste des cas écartés avec le motif précis. Elle sert deux fois : elle évite de refaire le même débat six mois plus tard, et elle indique à l’organisation ce qu’elle gagnerait à corriger : un référentiel à tenir, un propriétaire à nommer, une donnée à structurer.

Cette liste est souvent le livrable de cadrage le plus consulté, alors qu’elle ne décrit que ce qu’on n’a pas fait.

Les erreurs qui faussent la sélection des cas d’usage d’IA consistent presque toujours à juger l’intérêt d’une idée au lieu de vérifier les conditions de sa réalisation.

• Classer par enthousiasme : le cas le plus spectaculaire en démonstration n’est pas celui dont le résultat est le plus vérifiable.
• Évaluer sur description sans ouvrir un seul document réel, ce qui masque l’état du corpus jusqu’au développement.
• Garder un cas sans nom en espérant qu’un propriétaire se déclarera en cours de route.
• Tout lancer en parallèle pour ne décevoir personne, ce qui dilue les moyens.
• Écarter sans écrire le motif, ce qui oblige à refaire le débat et empêche de rouvrir le cas quand la condition est remplie.
• Oublier la suite : un cas retenu doit aussi être suivi après sa mise en service, selon les indicateurs décrits dans mesurer l’adoption, pas la satisfaction.