Validation des données produit : l’IA lorsque nécessaire, des règles ailleurs

Les données produit sont un cas séduisant d’IA d’entreprise : les entrées sont désordonnées et le résultat attendu semble structuré. Mais un modèle capable de lire ou de rédiger ne doit pas décider de la conformité. Nous séparons interprétation probabiliste et contrôle déterministe : les modèles extraient et formulent ; des règles traçables valident et décident.

Les données produit sont un système de contrôle

Un enregistrement relie preuves fournisseur, exigences commerciales, obligations juridiques, spécifications de canal et données maîtres. Un attribut peut toucher recherche, logistique, fiscalité, sécurité, emballage ou attentes client. Une petite modification se propage.

« Générer le contenu » est donc une mauvaise frontière. Le workflow reçoit les preuves, identifie entités et attributs, applique la politique, route les exceptions, journalise les validations et publie une version autorisée.

Interprétation : lire documents, images ou texte variables ; mapper des termes à un concept ; rédiger.
Contrôle : vérifier champs requis, types, valeurs, unités, dépendances, preuves, droits et statut.

L’interprétation bénéficie des modèles. Le contrôle reste déterministe lorsqu’une politique peut être énoncée. Réunir les deux dans un prompt complique audit, test et contestation.

Définir le record canonique avant l’IA

Le modèle produit requiert identifiants stables, champs typés et propriétaires. Pour chaque attribut : définition, unité, cardinalité, sources admissibles, preuve, portée marché/canal et droit d’approbation.

La preuve brute reste immuable ; les candidats extraits sont séparés des valeurs approuvées. Une lignée minimale contient :

product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_status

Le record de production ne contient que des valeurs validées. Comme dans un catalogue B2B avec pages de certification, les affirmations restent liées aux preuves.

Là où les modèles créent de la valeur

Extraire des candidats de preuves non structurées

Formulaires, fiches techniques, étiquettes et images expriment un attribut différemment. Un modèle localise, normalise et retourne un candidat avec référence. Sans preuve, le contrat impose null, pas une supposition. Région d’image, page ou passage sont conservés. La confiance route le travail mais ne remplace jamais la preuve.

Mapper le langage vers un vocabulaire contrôlé

Le terme source peut différer de la taxonomie. Le modèle propose un concept et explique le mapping ; une règle ou un réviseur autorisé accepte. Les synonymes exacts sont déterministes et passent d’abord.

Formuler le texte destiné au client

Les modèles rédigent titres, puces, résumés ou traductions uniquement depuis des attributs approuvés. Des règles vérifient longueur, affirmations interdites, qualificatifs, terminologie et valeurs non étayées. Le modèle ne juge pas son propre texte.

Là où les règles doivent décider

Type de règle	Exemple de contrôle
Présence	Attribut requis rempli pour cette classe
Type et format	Valeur conforme au type et à l’encodage
Plage	Nombre dans l’intervalle autorisé
Énumération	Valeur dans le vocabulaire actuel
Unité	Unité permise et conversion approuvée
Interchamp	Champ dépendant présent si déclenché
Preuve	Affirmation liée à une source admissible et actuelle
Cohérence	Quantité, dimensions et totaux concordent
Portée	Valeur valide pour langue, marché et canal
Autorité	Acteur autorisé à approuver ou publier

Chaque règle possède identifiant, version, propriétaire, sévérité et message lisible. Elle s’exécute à l’ingestion, après extraction et édition, avant export et publication. Interface, batch et API utilisent le même service versionné.

Cette séparation sécurise aussi l’automatisation flatfile vers plusieurs destinations : le format de destination peut changer sans affaiblir la politique canonique.

Un workflow de référence

Ingest: enregistrer fichiers, sommes de contrôle, origine et réception.
Preprocess: classifier et associer aux identités produit candidates.
Extract: parseurs déterministes puis modèles pour les champs non résolus.
Normalise: convertir formats et unités sans changer le sens.
Validate: exécuter les règles versionnées applicables.
Review: router exceptions et changements à risque vers une personne autorisée.
Approve: enregistrer valeur, preuve et identité approbatrice.
Publish: écrire via un adaptateur contrôlé vers chaque destination.
Observe: capturer rejets, corrections et résultats.

Chaque transition émet un événement, permettant de revalider après changement de règle sans tout extraire. Identifiants, dates, unités et codes exacts suivent des chemins déterministes ; les modèles traitent l’ambiguïté. Coût et latence baissent.

Le principe vaut pour les langues. Une architecture de commerce multilingue traite la traduction comme sortie dérivée et versionnée, tandis que faits et preuves approuvés restent partagés.

La confiance route le travail, elle ne crée pas la vérité

Une confiance élevée ne prouve pas qu’une source est correcte, actuelle ou autorisée. Nous la combinons avec risque et règles. Un candidat peu risqué, directement prouvé, peut suivre une revue légère ; une affirmation sensible demande approbation malgré la confiance. L’absence de preuve impose l’abstention.

Les seuils sont calibrés par attribut et document. Nous suivons précision, rappel, abstention et overrides par segment, sans les masquer dans une moyenne globale.

Les exceptions font partie du produit

Les catalogues contiennent lots, remplacements, variantes régionales, legacy et documents contradictoires. Chaque exception a code motif, sévérité, propriétaire, échéance et résolution permise. Le réviseur voit candidat, preuve, règles échouées et impact, puis accepte, corrige, rejette ou exige une preuve.

Les overrides sont explicites et limités ; ils ne désactivent pas la règle globale. Leur répétition signale une règle, taxonomie, source ou modèle à revoir. Les SLA suivent le risque, non l’ordre d’arrivée.

Mesurer de la référence au résultat

Avant automatisation, nous mesurons complétude, validation au premier passage, corrections, temps de revue, rejets et défauts graves. Les rapports confidentiels utilisent Baseline = 100; volumes et valeurs absolus restent dans l’environnement autorisé.

exactitude des candidats et couverture des preuves par attribut ;
taux de passage des règles et d’abstention ;
overrides et corrections humaines ;
âge de la file et délai jusqu’au record approuvé ;
rejets de destination et corrections après publication ;
garde-fous pour erreurs graves.

Modèles, prompts, taxonomies et règles sont versionnés séparément. Les évaluations contiennent cas courants et exceptions. Un replay compare nouveaux acceptés et refusés. Une dégradation de garde-fou bloque la release malgré une meilleure moyenne.

Gouverner les changements comme des politiques

Les règles encodent la politique et exigent propriétaire, justification, date d’effet, tests et approbation proportionnée. Les modèles sont testés sur entrées labellisées, adversariales et dégradées, ainsi que sur le contrat structuré : champ inconnu, type invalide ou preuve absente échoue sûrement.

Le déploiement passe par shadow mode, cohorte limitée puis extension. L’adaptateur d’écriture impose idempotence, moindre privilège et retour arrière. Aucun modèle n’accède directement et sans limite au système de référence.

Une division du travail qui passe à l’échelle

Ce n’est pas « IA contre règles », mais une répartition nette. Les modèles transforment preuves variables en candidats et faits approuvés en langage. Les règles expriment une politique répétable. Les humains résolvent l’ambiguïté et approuvent les changements sensibles. Les événements relient décision, preuve et version.

Le risque est borné par action et preuve, les contrats sont testables et les pannes précises. Les données n’ont pas à être parfaites : le système doit savoir ce qui est observé, inféré et permis, et qui a décidé. L’IA va là où l’interprétation est nécessaire ; les règles là où l’organisation sait formuler la décision.