Validation des données produit : l’IA si nécessaire, des règles ailleurs
Les données produit constituent un cas d’usage intéressant de l’IA en entreprise : les données d’entrée sont hétérogènes et le résultat attendu semble structuré. Mais un modèle capable de lire un document ou de rédiger une description ne devrait pas décider de la conformité d’un enregistrement. Nous séparons l’interprétation probabiliste du contrôle déterministe : les modèles extraient et formulent ; des règles traçables valident et décident.
Les données produit relèvent du contrôle, pas d’un travail de rédaction
Un enregistrement produit se situe au croisement des justificatifs des fournisseurs, des exigences commerciales, des obligations juridiques, des spécifications des canaux et des données de référence internes. Un attribut peut avoir une incidence sur la recherche, la logistique, la fiscalité, l’examen de sécurité, l’emballage ou les attentes des clients. Une modification apparemment mineure peut se propager à de nombreux systèmes en aval.
Définir le périmètre du système par la seule tâche « générer le contenu produit » est donc inadapté. La génération n’est qu’une activité parmi d’autres. Le véritable flux de travail reçoit les justificatifs, identifie les entités et les attributs, applique la politique, oriente les exceptions vers les responsables concernés, consigne les approbations et publie une version autorisée. La fiabilité dépend de toute la chaîne.
Nous commençons donc par distinguer deux catégories de travail :
- Interprétation : lire des documents, des images ou du texte libre de formes variables ; faire correspondre des termes inconnus à un concept connu ; rédiger une description concise.
- Contrôle : vérifier les champs obligatoires, les types de données, les valeurs autorisées, les unités, les dépendances entre champs, les exigences de preuve, les droits d’accès et le statut de publication.
L’interprétation est probabiliste et bénéficie de l’apport des modèles. Le contrôle devrait être déterministe partout où la politique peut être formulée. Réunir les deux dans un seul prompt rend le résultat difficile à auditer, à tester et à contester.
Définir l’enregistrement canonique avant d’ajouter l’IA
Le modèle canonique des données produit a besoin d’identifiants stables, de champs typés et de responsabilités explicites. Pour chaque attribut, nous documentons sa définition, son unité, sa cardinalité, les sources autorisées, les justificatifs requis, les marchés ou canaux concernés et l’autorité habilitée à approuver les modifications.
Les justificatifs bruts restent immuables. Nous stockons les valeurs candidates extraites séparément des valeurs approuvées. Cela empêche une valeur générée par un modèle de devenir discrètement un fait et permet aux personnes chargées de la vérification de comparer la valeur candidate à sa source. Un enregistrement minimal de traçabilité comprend :
product_id
attribute_id
candidate_value
source_document_id
source_location
extraction_method
model_or_rule_version
confidence
created_at
review_statusL’enregistrement de production contient uniquement les valeurs qui ont satisfait aux règles applicables et suivi le circuit d’approbation. Cette approche rejoint l’architecture d’un catalogue B2B avec pages de certification : les affirmations doivent rester liées à des justificatifs plutôt qu’être traitées comme des textes marketing interchangeables.
Là où les modèles créent de la valeur
Les modèles sont utiles dans les parties du flux de travail où les données varient.
Extraire des valeurs candidates de justificatifs non structurés
Les formulaires des fournisseurs, les fiches techniques, les étiquettes et les images présentent souvent un même attribut dans des mises en page ou des formulations différentes. Un modèle peut repérer des valeurs probables, normaliser le texte environnant et renvoyer une valeur candidate structurée accompagnée d’une référence au justificatif. Le contrat de sortie doit imposer null en l’absence de justificatif ; deviner ne signifie pas terminer la tâche.
Pour les tâches de vision, le système doit conserver la zone d’image ou la page qui étaye l’extraction. Pour le texte, il doit conserver un court passage source ou ses coordonnées. Le niveau de confiance est utile pour orienter le traitement, mais il ne constitue pas une preuve et ne doit jamais remplacer la référence à la source.
Faire correspondre les termes à un vocabulaire contrôlé
Un terme source ne correspond pas toujours exactement à la taxonomie de l’organisation. Un modèle peut proposer le concept du vocabulaire contrôlé le plus proche et expliquer la correspondance. L’acceptation finale reste déterminée par une règle ou par la décision d’une personne habilitée. Si la taxonomie dispose d’une table de synonymes exacts, la mise en correspondance déterministe doit intervenir en premier ; le modèle traite les cas restants non résolus.
Formuler le texte destiné au client
Les modèles peuvent rédiger des titres, des listes à puces, des résumés ou des traductions à partir d’attributs approuvés. Le prompt doit s’appuyer uniquement sur l’enregistrement approuvé et signaler clairement les consignes de style facultatives. Le texte généré passe ensuite par des règles portant sur la longueur, les affirmations interdites, les réserves obligatoires, la terminologie et les valeurs non étayées.
On ne demande pas au modèle si son propre texte est conforme : le même composant probabiliste serait alors à la fois auteur et juge.
Là où les règles doivent décider
Les règles conviennent lorsqu’une condition d’échec peut être formulée et testée. Les catégories habituelles sont les suivantes :
| Type de règle | Exemple de contrôle |
|---|---|
| Présence | L’attribut obligatoire est renseigné pour cette classe de produits |
| Type et format | La valeur peut être analysée selon le type et l’encodage déclarés |
| Plage | La valeur numérique est comprise dans un intervalle autorisé |
| Énumération | La valeur appartient au vocabulaire contrôlé en vigueur |
| Unité | L’unité est autorisée et la conversion est sans perte ou approuvée |
| Dépendance entre champs | Un champ dépendant est présent lorsqu’une valeur déclenchante s’applique |
| Preuve | L’affirmation dispose d’un document source admissible et à jour |
| Cohérence | La quantité par emballage, les dimensions et les totaux calculés concordent |
| Portée | La valeur est valide pour la langue, le marché et le canal cibles |
| Autorité | L’intervenant est autorisé à approuver ou à publier ce champ |
Chaque règle nécessite un identifiant, une version, un responsable, un niveau de gravité et un message compréhensible. Le message compte : « échec de la validation » crée un ticket d’assistance ; « la quantité nette nécessite une unité approuvée et une référence à la source » crée une tâche de correction.
Cette séparation rend aussi plus sûre l’automatisation des fichiers plats vers plusieurs destinations : le format propre à chaque destination peut changer sans affaiblir la politique de validation canonique.
Les règles doivent s’exécuter à plusieurs étapes : à l’ingestion, après l’extraction, après les modifications humaines, avant l’exportation et avant la publication. L’interface, le pipeline de traitement par lots et l’API doivent utiliser le même service de validation versionné. Dupliquer la logique des règles entre systèmes crée des résultats contradictoires.
Un flux de travail de référence
Nous mettons en œuvre le processus sous forme de transitions d’état explicites :
- Ingérer : enregistrer les fichiers sources, les sommes de contrôle, l’origine et l’heure de réception.
- Prétraiter : classer les documents et les associer aux identités produit candidates.
- Extraire : utiliser d’abord des analyseurs déterministes, puis des modèles pour les champs non résolus.
- Normaliser : convertir les formats et les unités sans changer le sens.
- Valider : exécuter l’ensemble de règles versionnées applicable.
- Vérifier : transmettre uniquement les exceptions ou les modifications à haut risque à une personne habilitée.
- Approuver : enregistrer la valeur acceptée, les justificatifs et l’identité de la personne ayant donné son approbation.
- Publier : écrire vers chaque destination au moyen d’un adaptateur contrôlé.
- Observer : recueillir les rejets en aval, les corrections et les indicateurs de résultat.
Chaque transition produit un événement. Ce journal d’événements permet de rejouer le traitement : lorsqu’une taxonomie ou une règle change, les enregistrements concernés peuvent être identifiés et revalidés sans tout extraire à nouveau.
Le même principe s’applique aux variantes linguistiques. Une architecture de commerce multilingue rigoureuse traite la traduction comme un résultat dérivé et versionné, tandis que les faits approuvés et les justificatifs restent partagés.
Le flux de travail évite également une pratique coûteuse : envoyer chaque champ au plus grand modèle disponible. Les identifiants exacts, les dates, les unités connues et les codes énumérés doivent suivre des traitements déterministes. Les modèles sont réservés aux champs ambigus. Cela réduit le coût et la latence tout en rendant l’évaluation des modèles restants plus pertinente.
La confiance oriente le traitement ; elle n’établit pas la vérité
Les scores de confiance sont souvent mal compris. Un niveau de confiance élevé du modèle ne prouve pas qu’une source est correcte, à jour ou autorisée. Il décrit uniquement l’évaluation du modèle selon une méthode donnée.
Nous utilisons la confiance conjointement avec le risque et les résultats des règles pour choisir un circuit de traitement. Une valeur candidate à faible risque, étayée directement et satisfaisant à toutes les règles, peut entrer dans une file de vérification allégée. Une affirmation réglementée ou commercialement sensible peut nécessiter une approbation humaine, quel que soit le niveau de confiance. L’absence de justificatif entraîne une abstention, pas un abaissement du seuil.
Les seuils doivent être calibrés sur des données représentatives, par attribut et par type de document. Un seuil global unique masque des différences majeures : extraire un identifiant standard n’équivaut pas à interpréter une affirmation sur un matériau. Nous suivons la précision, le rappel, l’abstention et les dérogations décidées lors de la vérification pour chaque segment pertinent.
Les exceptions font partie du produit
Les catalogues réels contiennent des lots de produits, des articles de remplacement, des variantes régionales, des enregistrements anciens et des documents de fournisseurs contradictoires. Un système conçu uniquement pour le cas nominal crée du travail manuel dans des endroits qui échappent à l’observation.
Une exception nécessite un code de motif, un niveau de gravité, un responsable, une échéance et un mode de résolution autorisé. Les personnes chargées de la vérification doivent voir la valeur candidate, les justificatifs sources, les règles non satisfaites et l’incidence en aval dans une même vue. Elles doivent pouvoir accepter, corriger, rejeter ou demander de nouveaux justificatifs sans modifier les données sources brutes.
Les dérogations doivent être explicites et limitées dans leur portée. Une personne chargée de la vérification peut déroger à un avertissement pour un produit et une destination, mais ne doit pas désactiver la règle sous-jacente globalement. Des dérogations répétées sont un signal : la règle, la taxonomie, le processus de collecte des données sources ou le modèle produit peut nécessiter une révision.
Les niveaux de service doivent refléter le risque métier plutôt que l’ordre d’arrivée. Un champ marketing facultatif manquant et un attribut de sécurité contradictoire n’ont pas leur place dans la même file.
Mesurer des performances de référence aux résultats
Avant l’automatisation, nous mesurons la complétude des champs, la validation au premier passage, les cycles de correction, le temps de vérification, le taux de rejet en aval et le taux de défauts graves. Pour les rapports internes confidentiels, nous pouvons exprimer chaque série sous forme d’indice avec Baseline = 100, en conservant les volumes absolus et les valeurs commerciales dans l’environnement autorisé.
Après la mise en production, nous séparons la qualité de l’extraction de la performance opérationnelle. Une extraction peut être techniquement correcte et pourtant arriver trop tard pour la publication. Un flux de travail peut réduire le temps de vérification tout en augmentant les défauts graves. Le tableau de bord comprend donc :
- exactitude des valeurs candidates et couverture des justificatifs par attribut ;
- taux de réussite aux règles et d’abstention ;
- taux de dérogation et de correction par les humains ;
- ancienneté des éléments en file et délai jusqu’à l’obtention d’un enregistrement approuvé ;
- rejets par les destinations et corrections après publication ;
- garde-fous contre les erreurs de gravité élevée.
Les modifications des modèles, des prompts, des taxonomies et des règles sont versionnées indépendamment. Les jeux d’évaluation incluent des enregistrements courants et des exceptions connues. Avant le déploiement, nous rejouons la version proposée et comparons les enregistrements nouvellement acceptés comme ceux nouvellement rejetés. Une mise en production est bloquée si un garde-fou se dégrade au-delà de la tolérance convenue, même lorsque la précision moyenne s’améliore.
Gérer les modifications comme des changements de politique
Les règles traduisent la politique opérationnelle. Leur mise à jour peut changer les produits publiables, les affirmations autorisées et les équipes qui reçoivent des tâches. Les modifications de règles nécessitent donc un responsable, une justification, une date d’effet, des tests et une approbation proportionnée à leur incidence.
Les modifications de modèles demandent une discipline similaire, mais des tests différents. Nous évaluons l’extraction et la formulation sur des cas annotés, y compris des entrées adversariales et de faible qualité. Nous testons aussi le contrat de sortie structurée : les champs inconnus, les types invalides et les justificatifs manquants doivent provoquer un échec sans risque.
Le déploiement doit être progressif. Le mode d’observation compare le nouveau traitement sans modifier les enregistrements. Une cohorte limitée suit, puis le déploiement s’élargit si les garde-fous sont respectés. L’adaptateur d’écriture impose l’idempotence, le moindre privilège et la possibilité de revenir à la version précédente. Aucun modèle ne reçoit un accès direct et sans restriction au système de référence.
Une division du travail qui passe à l’échelle
L’architecture durable ne repose pas sur une opposition « IA contre règles ». Elle repose sur une répartition délibérée du travail.
Les modèles transforment des justificatifs variables en valeurs candidates et des faits approuvés en textes utiles. Les règles expriment une politique reproductible. Les humains résolvent les ambiguïtés, approuvent les modifications à forte incidence et améliorent la politique lorsque les exceptions révèlent une lacune. Les journaux d’événements relient chaque décision aux justificatifs et à la logique versionnée.
Cette conception est plus facile à expliquer aux dirigeants, car le risque est circonscrit par les actions et les justificatifs. Elle est plus facile à construire, car les composants ont des contrats testables. Elle est aussi plus facile à exploiter, car les défaillances deviennent précises : une extraction a manqué une valeur, une source était inadmissible, une règle a rejeté une combinaison ou une personne habilitée a dérogé à un avertissement.
Les données produit de l’entreprise ne seront jamais parfaitement propres ni uniformes. Elles n’ont pas besoin de l’être. Le système doit savoir ce qui est observé, ce qui est inféré, ce qui est autorisé et qui a décidé. Placez l’IA là où l’interprétation est réellement nécessaire. Placez les règles partout où l’organisation sait déjà formuler la décision.