La plupart des projets d’IA démarrent par l’outil ou par le cas d’usage. La question des données arrive ensuite, souvent au moment où le projet devrait produire ses premiers résultats. C’est l’ordre inverse qui fonctionne : vérifier d’abord que les données permettent de répondre à la question posée, puis choisir la manière d’y répondre.
Encore faut-il poser la question au bon niveau. Il n’existe pas de maturité des données dans l’absolu. Une organisation peut avoir des données de facturation impeccables et des données logistiques inexploitables. La préparation à l’IA s’évalue donc cas d’usage par cas d’usage : pour une décision donnée, a-t-on les données qu’il faut, dans l’état qu’il faut ?
Les dix questions qui suivent servent à cela. Elles ne demandent aucune compétence technique particulière : un responsable métier et la personne qui connaît le système source peuvent y répondre ensemble en une réunion.
La question métier
1. Quelle décision le projet doit-il améliorer, et qui la prend ?
Un projet d’IA utile change une décision : relancer un client, réordonner une production, ajuster une prévision de trésorerie, orienter une demande. Si l’on ne sait pas nommer la décision ni la personne qui la prend, il n’y a pas encore de cas d’usage, seulement une intention.
2. Comment cette décision est-elle mesurée aujourd’hui ?
Sans indicateur actuel, impossible de savoir si le projet apporte quelque chose. Le taux de livraison à l’heure, le délai réel de paiement, le temps de traitement d’une demande : la mesure existante sert à la fois de point de comparaison et, souvent, de cible pour le modèle.
Les données disponibles
3. Les données nécessaires existent-elles, et où se trouvent-elles ?
Lister les sources : ERP, CRM, entrepôt de données, fichiers partagés, documents. Une donnée qui n’existe que dans des fichiers consolidés à la main n’est pas exclue, mais elle impose un travail préalable qu’il faut chiffrer dès le départ.
4. L’historique est-il suffisant, et couvre-t-il les situations à anticiper ?
Un modèle apprend sur le passé. Il faut assez d’historique pour couvrir les cycles de l’activité (saisonnalité, clôtures, pics), et savoir où se trouvent les ruptures : changement d’ERP, réorganisation, nouveau catalogue. Un historique long mais interrompu par une migration vaut parfois moins qu’un historique court et homogène.
5. Les définitions sont-elles partagées ?
Qu’est-ce qu’une commande livrée à l’heure : par rapport à la date demandée ou à la date confirmée ? Qu’est-ce qu’un client actif ? Si deux services répondent différemment, le modèle apprendra une moyenne de deux définitions. Stabiliser le vocabulaire est souvent le premier livrable du projet.
6. Sait-on isoler les populations qui ne se comportent pas comme les autres ?
Avoirs, retours, règlements partiels, écritures non affectées, commandes exceptionnelles, données de test : toutes les lignes d’une table ne racontent pas la même histoire. Si l’on ne sait pas les identifier et les écarter par des règles justifiées et tracées, elles brouillent l’apprentissage. C’est l’étape qui pèse le plus sur le résultat, et celle qui est la plus souvent sous-estimée.
La qualité et la responsabilité
7. Qui est responsable de ces données ?
Quand une valeur est fausse, qui la corrige, et à la source ou dans un fichier d’export ? Une donnée sans responsable se dégrade, et un modèle alimenté par une donnée qui se dégrade se dégrade avec elle. Il ne s’agit pas de lancer un programme de gouvernance complet, seulement de nommer, pour le périmètre du cas d’usage, qui répond de quoi.
8. La qualité est-elle mesurée, ou découverte au fil des incidents ?
Taux de valeurs manquantes, doublons, incohérences entre systèmes : quelques indicateurs suivis dans le temps suffisent à savoir si l’on peut faire confiance aux données. S’ils n’existent pas, les premières semaines du projet serviront à les produire, ce qui est une bonne chose à condition de l’avoir prévu.
9. A-t-on le droit de les utiliser pour cet usage ?
Données personnelles, informations confidentielles, clauses contractuelles, documents de tiers : certaines données ne peuvent pas être exploitées pour n’importe quelle finalité ni envoyées n’importe où. La question se pose avec une acuité particulière pour l’IA générative, qui manipule des documents entiers et repose souvent sur des services hébergés. Mieux vaut la trancher avec les personnes concernées dans l’entreprise avant de construire que l’apprendre après.
L’exploitation
10. Où la réponse sera-t-elle livrée, et qui la fera vivre ?
Une prédiction que personne ne voit ne change aucune décision. Elle doit arriver là où les équipes travaillent déjà : le tableau de bord qu’elles consultent, le rapport qu’elles ouvrent, l’outil qu’elles utilisent. Il faut aussi savoir qui suivra le modèle une fois en service, car les données et les comportements évoluent, et la qualité d’une prédiction avec eux.
Lire les réponses
Il ne s’agit pas d’obtenir dix réponses parfaites. Les réponses disent surtout par où commencer.
- Les questions 1 et 2 restent sans réponse : il n’y a pas encore de cas d’usage. Mieux vaut revenir à la décision métier que lancer une expérimentation.
- Les questions 3 à 6 révèlent des manques : la préparation des données est le premier chantier. Ce n’est pas un échec du projet, c’en est souvent la partie la plus utile, et elle profite à d’autres usages que l’IA.
- Les questions 7 à 9 posent problème : un travail de gouvernance s’impose, limité au périmètre du cas d’usage et mené en parallèle.
- La question 10 n’a pas de réponse : le risque est de livrer un modèle juste qui ne sera pas utilisé. La restitution se conçoit dès le départ.
- Les réponses sont globalement positives : une preuve de concept peut être cadrée, avec un périmètre, une durée et une mesure de réussite définis avant de commencer.
Ce que nous constatons en mission
Dans nos projets prédictifs, la difficulté se situe rarement là où on l’attend. Chez un équipementier industriel, l’historique des commandes existait déjà dans le datamart Opérations ; le travail a consisté à définir avec le métier les règles d’exclusion, puis à restituer la prédiction dans le tableau de bord que les équipes utilisaient, à côté de l’indicateur réel. Dans la direction financière d’un groupe industriel, il a fallu séparer factures réglées et factures ouvertes et écarter règlements partiels, avoirs et écritures non affectées avant toute modélisation. Dans les deux cas, ce sont les questions 5, 6 et 10 qui ont fait le résultat.
C’est pourquoi notre Diagnostic Data & IA évalue la préparation des données de chaque cas d’usage retenu, avec une matrice valeur / faisabilité et une feuille de route. Pour un cas d’usage déjà identifié, le cadrage de deux à trois semaines décrit sur la page Intelligence Artificielle & Automatisation aboutit à une note de cadrage et à une décision motivée de lancer, ou non, une preuve de concept. Et lorsque les données vivent encore dans des fichiers consolidés à la main, Data Ready Express pose en dix jours un socle centralisé et automatisé sur lequel bâtir la suite.
L’IA utile commence par des données fiables. Répondre honnêtement à ces dix questions coûte une réunion ; ne pas le faire coûte souvent une preuve de concept.