Un projet IA échoue rarement parce que l’équipe n’a pas trouvé un algorithme assez sophistiqué. Les difficultés apparaissent plus tôt : objectif métier flou, données dispersées, historique inutilisable, définitions incohérentes ou droits mal compris. Préparer les données ne signifie donc pas nettoyer un fichier à la dernière minute, mais vérifier que l’information disponible permet réellement de traiter le problème dans les conditions futures d’utilisation.
Cette phase réduit les risques avant les investissements lourds. Elle relie une décision attendue à des données observables, rend explicites les limites du corpus et installe les responsabilités nécessaires pour maintenir la solution. Elle peut conduire à collecter de nouvelles informations, réduire le périmètre ou reporter le projet. Ce constat constitue un résultat utile lorsqu’il évite d’industrialiser une démonstration sans fondations.
Partir de la décision métier à améliorer
La première question n’est pas « quelles données possédons-nous ? », mais « quelle décision voulons-nous mieux prendre ? ». Il faut préciser l’utilisateur, le moment où il agit, les options possibles et le coût d’une erreur. Prévoir une demande pour organiser des stocks n’implique pas les mêmes conséquences que classer automatiquement une sollicitation client. La sortie attendue doit être reliée à un usage : un score sans processus de décision reste une démonstration. L’équipe décrit donc comment le résultat sera présenté, validé et contesté, puis choisit une référence actuelle, manuelle ou fondée sur une règle simple, pour juger l’apport réel de l’IA.
- Nommer l’utilisateur et la décision soutenue.
- Décrire les erreurs possibles et leurs conséquences.
- Préciser quand la prédiction reste actionnable.
- Choisir une solution de référence.
Inventorier les sources et comprendre leur histoire
L’inventaire recense systèmes, fichiers, événements et référentiels susceptibles d’alimenter le projet. Pour chaque source, il indique le propriétaire, le mode de collecte, la fréquence de mise à jour, la profondeur d’historique et les restrictions d’usage. Une colonne disponible aujourd’hui n’existait peut-être pas au moment des événements passés. Les équipes opérationnelles savent aussi qu’un changement d’outil a modifié une codification, qu’une valeur par défaut masque une absence ou qu’une période exceptionnelle ne représente pas l’activité habituelle. Cette mémoire explique des ruptures que le profilage détecte sans pouvoir les interpréter et évite de considérer l’historique comme une vérité homogène.
Définir la cible et éviter les fuites d’information
Pour un apprentissage supervisé, la cible doit traduire le phénomène métier sans ambiguïté excessive. Si elle dépend d’une saisie facultative, d’une appréciation variable ou d’un événement très tardif, le modèle apprend une approximation fragile. Un atelier d’annotation vérifie que plusieurs experts appliquent la définition de façon cohérente. Il faut ensuite contrôler la date de disponibilité des variables : une information enregistrée après la décision ou causée par le résultat ne sera pas accessible au moment réel de la prédiction. Son inclusion améliore artificiellement les tests. Pour une IA générative, la question équivalente est de savoir si les documents de référence contiennent effectivement les réponses attendues.
- Rédiger une définition métier testable de la cible.
- Documenter la date de disponibilité de chaque variable.
- Mesurer et résoudre les désaccords d’annotation.
Profiler la qualité dans le contexte d’usage
La qualité ne se résume pas aux cellules vides. Elle couvre la validité des formats, l’unicité des identifiants, la cohérence entre champs, la stabilité temporelle et la représentativité. Une adresse incomplète peut convenir à une segmentation régionale et bloquer une livraison : les règles sont donc liées au cas d’usage. Le profilage compare périodes, canaux et populations, car une moyenne masque souvent une catégorie rare absente de l’entraînement ou un canal récent utilisant une autre convention. Chaque anomalie reçoit un traitement explicite : correction à la source, transformation reproductible, exclusion justifiée ou limite assumée. Les modifications manuelles sans trace sont proscrites.
- Contrôler volumes, doublons, absences et distributions.
- Comparer les résultats par période et population pertinente.
- Faire valider les anomalies par les propriétaires métier.
Gouverner les données et valider par un pilote
Disposer techniquement d’une donnée ne rend pas son usage légitime. L’équipe clarifie finalité, droits, conservation et transferts, puis ne retient que les informations nécessaires. Chaque jeu est versionné ou relié à une extraction identifiable avec ses transformations et règles d’exclusion. Un échantillon pilote teste ensuite toute la chaîne : extraction, préparation, entraînement ou indexation, évaluation et restitution. Il couvre les cas ordinaires, les situations rares importantes et différentes périodes. Le rapport final décrit données utilisables, lacunes, biais, maintenance et contrôles. Il permet de poursuivre, collecter davantage, réduire le périmètre ou retenir une solution plus simple selon des conditions décidées à l’avance.
- Utiliser des accès contrôlés et des données masquées si nécessaire.
- Séparer les jeux selon le fonctionnement réel du processus.
- Tester la restitution avec les futurs utilisateurs.
- Documenter les limites qui resteront vraies en production.
En conclusion
Préparer les données revient à construire les fondations du produit IA. Cadrage de la décision, inventaire des sources, définition de la cible, analyse de qualité et gouvernance forment un seul travail. Ignorer l’un de ces éléments déplace simplement le problème vers une phase plus coûteuse.
Une préparation réussie ne garantit pas qu’un modèle complexe soit nécessaire. Elle apporte une décision informée sur la faisabilité, un périmètre défendable et une chaîne reproductible. Le projet peut alors avancer sur des preuves, avec des limites connues et des responsabilités claires.
