Dans plusieurs démos d’IA, les données arrivent toujours à l’heure, propres, bien étiquetées et parfaitement d’accord entre elles. Personne ne doit expliquer pourquoi un produit porte deux codes différents selon le système.

Dans un vrai projet, on passe beaucoup de temps exactement là-dessus. Ce n’est pas un ménage ponctuel avant le vrai travail. C’est un pipeline qui doit prendre les mêmes décisions chaque fois qu’une nouvelle donnée arrive.

Une ligne propre vient de plusieurs opérations

Imaginons un modèle qui prédit le retour d’un produit. Les commandes viennent de l’ERP, les dossiers clients du CRM et les retours d’une application d’entrepôt. Le pipeline doit construire une ligne par article vendu :

order_line_id | customer_id | product_id | quantity | price_cad | returned_30d
L-88421       | C-1842      | P-91       | 2        | 129.99    | 1

Pour arriver là, je vois au moins six étapes :

1. lire chaque source avec son schéma et son encodage attendus;
2. convertir les types, les dates, les devises et les unités;
3. résoudre les identifiants qui représentent la même entité;
4. appliquer les règles de qualité et isoler les rejets;
5. joindre le résultat futur pour produire l’étiquette;
6. écrire une table versionnée avec la provenance de chaque champ.

Chaque étape doit être déterministe. Relancer le traitement du 12 janvier ne devrait ni doubler les lignes ni changer silencieusement un montant. Je garderais un identifiant de lot, l’empreinte des fichiers d’entrée, la version du code et le nombre de lignes acceptées ou rejetées.

Le doublon est souvent une décision d’identité

Deux dossiers avec le même courriel ne sont pas automatiquement la même personne. Une adresse familiale peut être partagée. Un client peut aussi apparaître avec C-1842 dans le CRM et 00001842 dans l’ERP. La résolution d’identité utilise des clés fiables quand elles existent, puis des règles plus prudentes pour le reste.

correspondance certaine:
  crm.customer_id ↔ table_de_reference ↔ erp.account_id

correspondance à réviser:
  nom normalisé + téléphone identique + adresse proche

Je ne fusionnerais pas automatiquement les cas incertains. Une mauvaise fusion contamine toutes les transactions du client et peut être plus difficile à corriger qu’un doublon conservé. Le pipeline produit plutôt une file de révision et garde les identifiants sources pour pouvoir défaire la décision.

Les unités demandent la même discipline. 12,50 peut utiliser une virgule décimale ou un séparateur de colonnes mal interprété. 100 peut être en dollars ou en cents. Une date 03/04/2019 change de sens selon la culture. Le parseur doit connaître le format de la source, refuser l’ambiguïté et écrire l’unité dans le nom ou les métadonnées du champ.

Une valeur absente n’est pas toujours vide

Un NULL peut vouloir dire « non demandé », « inconnu », « sans objet » ou « perdu pendant la migration ». Remplacer tous les manquants par zéro mélange ces situations. Pour certaines features, je garderais la valeur imputée et un indicateur séparé :

revenu_estime = médiane du segment
revenu_estime_manquant = 1

Le modèle peut alors apprendre que l’absence elle-même porte de l’information, et l’équipe peut surveiller si le taux de valeurs manquantes augmente. Attention quand même : si l’absence vient d’un processus discriminatoire ou d’un système brisé, l’apprendre fidèlement n’est pas nécessairement souhaitable.

L’étiquetage demande aussi du jugement. Pour returned_30d, faut-il compter un échange? un retour partiel? un colis refusé? Deux personnes peuvent classer le même cas différemment pour de bonnes raisons. Je documenterais la règle, mesurerais l’accord sur un échantillon et garderais indéterminé plutôt que de forcer une fausse certitude.

Empêcher le pipeline de produire proprement du faux

Une source remplacée, une colonne renommée ou une équipe qui remplit maintenant un code autrement peut laisser le job au vert. J’ajouterais des tests à plusieurs niveaux :

• schéma : colonnes, types et clés attendus;
• volume : nombre de lignes dans une plage raisonnable;
• domaine : devises connues, quantités positives, dates plausibles;
• relations : proportion de commandes sans client ou produit;
• distribution : taux de NULL, moyenne et catégories comparés à l’historique;
• étiquette : délai suffisant avant de déclarer qu’un article n’a pas été retourné.

Un échec place le lot en quarantaine et alerte le responsable. Le dernier jeu valide reste disponible; on ne réentraîne pas automatiquement sur une table à moitié vide. Après correction, le même lot peut être rejoué grâce à ses identifiants et à ses entrées conservées.

Avec mes études en IA, je deviens sceptique devant un modèle annoncé comme « prêt en quelques clics ». Avant de regarder sa courbe, je veux prendre une ligne au hasard et remonter jusqu’aux trois systèmes qui l’ont produite. Si on peut expliquer les conversions, les fusions, les rejets et l’étiquette, le modèle a une base qu’on pourra maintenir. Sinon, il attend pendant qu’on démêle les données — et c’est exactement la bonne chose à faire.