Combien de cas d'usage faut-il abandonner

Sur les cadrages que j'ai menés depuis trois ans, la proportion est stable : sur cinq cas d'usage identifiés au départ, deux au plus méritent d'être construits.

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.

Un cas d'usage non viable ne s'arrête pas de lui-même. Il consomme 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.

É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 partie revient, et c'est 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.

Le corpus indisponible ou désordonné est devenu le premier motif d'écartement, devant l'absence de propriétaire métier. C'est le déplacement 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é.

Un cas d'usage dont personne ne sait dire quels documents font autorité coûte trois fois plus qu'un cas équivalent sur une base tenue, et cet écart ne se voit pas au cadrage. Le raisonnement complet figure dans le corpus est le projet.

Un cas écarté au cadrage doit être remplacé par une action concrète, 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 équipe qui poursuit cinq cas simultanément n'en livre aucun, parce que l'attention et les arbitrages se diluent. 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.