La plupart des projets d'intelligence artificielle qui s'arrêtent avant la mise en production n'échouent pas pour des raisons techniques : ils partent d'un cas d'usage mal défini. Ce guide décrit la méthode de cadrage que nous utilisons en atelier, en six étapes, sans outil imposé et sans budget préalable.
1. Partir d'un irritant décrit par ceux qui le vivent
Un bon point de départ n'est pas une technologie mais une tâche pénible, répétée et documentée : retrouver une information dispersée dans plusieurs documents, reformuler un même type de réponse, contrôler manuellement des saisies, produire un rapport récurrent.
Faites décrire la tâche par les personnes qui l'exécutent, avec leurs mots, leurs exceptions et leurs contournements. Un irritant que personne ne sait raconter précisément n'est pas encore un cas d'usage.
2. Écrire le cas d'usage en une phrase vérifiable
Formulez le cas d'usage sous la forme : « pour tel rôle, l'assistant produit tel résultat, à partir de telles données, dans telle limite ». Si la phrase ne tient pas, le périmètre est encore trop large.
- Le rôle concerné est nommé, pas « les équipes ».
- Le résultat attendu est un livrable observable, pas une intention.
- Les données d'entrée existent déjà et sont accessibles.
- Les limites (ce que l'assistant ne fait pas) sont explicites.
3. Vérifier la matière disponible avant la technologie
Un cas d'usage ne vaut que ce que valent ses données. Avant toute maquette, listez les sources réellement mobilisables, leur format, leur fraîcheur, leur propriétaire et leur niveau de confidentialité.
Ce recensement révèle souvent un travail préalable de mise en ordre documentaire. C'est un résultat utile en soi : il évite d'imputer à l'IA un problème d'organisation de l'information.
4. Choisir un indicateur de réussite avant de construire
Définissez, avec le métier, un indicateur unique et mesurable dès la phase d'essai : temps consacré à la tâche, taux de réponses réutilisables sans correction, nombre de reprises manuelles, délai de traitement.
L'indicateur doit pouvoir être mesuré avant le projet. Sans mesure initiale, aucun gain ne pourra être démontré, quelle que soit la qualité de la solution.
5. Traiter les risques dès le cadrage
Trois questions se posent systématiquement : quelles données personnelles sont concernées, qui valide les productions avant usage externe, et que se passe-t-il en cas de réponse erronée.
- Base légale et minimisation des données pour tout traitement de données personnelles.
- Point de contrôle humain nommé pour les usages à effet externe.
- Traçabilité : conserver la source utilisée pour chaque réponse produite.
- Procédure de repli si l'assistant est indisponible ou inexact.
6. Fixer une durée d'essai courte et une décision explicite
Un essai utile se mène sur quelques semaines, avec un périmètre restreint, un groupe d'utilisateurs identifié et une date de décision fixée à l'avance. À cette date, trois issues sont acceptables : généraliser, ajuster le périmètre, ou arrêter.
Prévoir explicitement l'arrêt libère la parole des utilisateurs pendant l'essai et améliore la qualité des retours.
À retenir
- Un cas d'usage se décrit en une phrase vérifiable, sinon il n'est pas cadré.
- La disponibilité des données conditionne la faisabilité, avant tout choix d'outil.
- L'indicateur de réussite se mesure avant le début du projet.
- Une date de décision fixée à l'avance évite les essais qui s'étirent sans conclusion.