Un projet d'IA échoue rarement parce que l'équipe n'a pas trouvé le modèle le plus spectaculaire. Il échoue plus souvent parce que personne n'a défini quelle décision devait s'améliorer, pour qui, avec quelles données et selon quel critère. Le cadrage transforme une promesse vague en système testable.
Partir d'une décision, pas d'une technologie
« Ajouter de l'IA » n'est pas un objectif produit. Une formulation utile décrit un acteur, une situation et une décision. Par exemple, « aider un conseiller à prioriser les demandes qui nécessitent une réponse humaine aujourd'hui » est plus exploitable que « automatiser le support ». La première phrase indique déjà qui utilise le résultat et à quel moment.
Il faut ensuite définir la valeur attendue. Veut-on réduire le temps de traitement, détecter plus tôt un risque, augmenter la pertinence d'une recommandation ou diminuer les erreurs de saisie ? Un indicateur principal suffit pour démarrer, accompagné d'une limite à ne pas dégrader, comme la satisfaction, l'équité ou le taux de faux positifs.
Vérifier que les données racontent la bonne histoire
Une bonne question ne garantit pas que l'organisation possède les données nécessaires. Il faut inventorier les sources, leur fraîcheur, leur couverture et la manière dont elles ont été produites. Une donnée disponible peut être un mauvais substitut de ce que l'on cherche réellement à mesurer. Le nombre de clics, par exemple, ne représente pas toujours la satisfaction.
Le test le plus utile consiste à prendre quelques cas réels et à simuler la décision avec les informations disponibles. Si un expert ne peut pas décider de façon cohérente à partir de ces éléments, un modèle apprendra surtout les ambiguïtés du processus. Cette étape révèle aussi les informations sensibles, les droits d'accès et les cas où une réponse doit rester humaine.
Concevoir le test avant la solution
Le premier livrable peut être une règle, un prototype ou une analyse manuelle, pas nécessairement un modèle entraîné. Une base simple permet de savoir si l'IA apporte un gain réel. Sans comparaison, une démonstration impressionnante peut masquer un résultat moins fiable qu'un formulaire bien conçu ou qu'une recherche classique.
Le protocole doit préciser les exemples de test, les erreurs les plus coûteuses et le seuil à partir duquel le système peut agir. En dessous de ce seuil, il peut demander une information, proposer plusieurs options ou transférer le cas. On obtient ainsi une expérience complète, pas seulement une prédiction isolée.
Questions de cadrage
- Quelle décision précise doit devenir plus rapide ou plus fiable ?
- Qui utilise le résultat et peut-il le corriger ?
- Quel indicateur prouve la valeur sans masquer les dommages ?
- Quelles données existent réellement au moment de la décision ?
- Quel comportement est prévu quand le système ne sait pas ?
Le meilleur point de départ n'est donc pas « quel modèle choisir ? », mais « quelle décision voulons-nous améliorer et comment saurons-nous que nous y sommes arrivés ? ». Une réponse claire réduit le coût technique, facilite l'adoption et rend l'IA beaucoup plus utile.