Le contexte métier n'est pas de la donnée : 

ce que votre outil ignore

Donnée, règle, contexte : trois choses différentes

Ces trois mots sont souvent employés l'un pour l'autre, et cette confusion explique une bonne partie des déceptions sur les projets de pricing. Ils désignent pourtant trois objets distincts, qui s'acquièrent de trois façons différentes.

• La donnée décrit ce qui s'est passé : des ventes, des prix relevés, des stocks, des marges réalisées. Elle est factuelle, datée, et elle s'extrait d'un système, qu'elle soit endogène ou exogène.
• La règle décrit ce que le système doit faire : ne pas descendre sous tel plancher, ne pas s'écarter de plus de tant face à tel concurrent. Elle est formalisée, exécutable, et elle se paramètre : c'est la mécanique que nous décrivons dans comment fonctionne un moteur de pricing IA.
• Le contexte décrit pourquoi la règle existe, et ce qui serait absurde même sans règle pour l'interdire. Il n'est ni factuel ni exécutable. Il vit dans des têtes, et il ne s'extrait de nulle part. C'est l'une des raisons pour lesquelles l'IA générative se trompe sur les prix : elle raisonne sur ce qu'on lui donne, pas sur ce que l'entreprise sait.

La qualité de la donnée est aujourd'hui un sujet bien identifié, et nous lui avons consacré un article entier sur le plafond de verre de l'IA pricing. Mais une donnée parfaite ne résout qu'une partie du problème. Elle permet de répondre à la question « qu'est-ce qui s'est passé ? ». Elle ne dit rien de la question « qu'est-ce qui, ici, ne se fait pas ? ».

Un exemple qui résume tout

Prenez une référence de fond de rayon, faible rotation, marge correcte, aucun concurrent positionné dessus, aucune contrainte réglementaire. Un moteur bien alimenté recommandera logiquement de monter son prix de quelques centimes. La recommandation est juste sur toutes les dimensions mesurables.

Et elle est inapplicable, parce que cette référence est celle que le directeur régional cite systématiquement en réunion pour illustrer le positionnement de l'enseigne, parce qu'un journaliste local l'a prise comme exemple il y a deux ans, et parce que la direction commerciale a décidé qu'elle ne bougerait pas. Rien de tout cela n'existe dans une base. Tout cela est parfaitement connu de cinq personnes dans l'entreprise.

Ce chiffre est généralement lu comme un constat sur la qualité technique des données. Il mérite une lecture plus large : une donnée « prête pour l'IA » n'est pas seulement une donnée propre et accessible, c'est une donnée accompagnée de ce qui permet de l'interpréter.

Les quatre familles de contexte qu'aucune base ne contient

1. Les repères de prix

Toutes les références ne pèsent pas le même poids dans la perception du client. Une poignée d'entre elles porte l'image-prix de l'enseigne : celles que le client connaît par cœur, celles qu'il compare d'un magasin à l'autre, celles qui figurent dans les comparatifs. Les données de vente ne les distinguent pas des autres ; elles se vendent parfois moins bien que des références banales.

Une partie de ce savoir peut se reconstituer statistiquement, et c'est précisément le travail d'un moteur bien conçu. Une autre partie ne le peut pas, parce qu'elle tient à l'histoire locale, à un positionnement revendiqué, à une promesse faite publiquement.

2. Les contraintes relationnelles

Ce fournisseur qui n'acceptera pas de voir sa gamme démarquée avant telle date. Cette marque dont le contrat de référencement impose un écart maximal avec la marque de distributeur. Ce partenaire avec lequel une négociation sensible est en cours et sur lequel il vaut mieux ne rien bouger ce trimestre.

Ces contraintes sont réelles, elles ont des conséquences financières directes, et elles vivent dans des contrats, des comptes rendus de réunion et des conversations. Aucune ne se trouve dans un flux de données de vente.

3. Les interdits non écrits

Ce sont les plus dangereux, parce que personne ne pense à les mentionner. On ne passe jamais sous un certain seuil psychologique sur cette famille. On ne fait jamais de promotion sur ce produit pendant cette période. On ne s'aligne jamais sur ce concurrent précis, parce que l'enseigne ne se compare pas à lui.

Interrogé directement, personne ne les cite, parce qu'ils ne sont pas vécus comme des règles : ils sont vécus comme des évidences. Ils n'apparaissent qu'au moment où le moteur les enfreint, en réunion, avec la phrase « évidemment qu'on ne fait pas ça ».

4. Les intentions commerciales par catégorie

Une catégorie en conquête ne se pilote pas comme une catégorie en rentabilisation. L'une accepte de sacrifier de la marge pour gagner des parts, l'autre fait l'inverse. Cette intention change au fil de l'année, elle est décidée en comité, et elle est rarement traduite en paramètres dans l'outil. Le moteur optimise donc partout le même objectif, alors que l'entreprise poursuit des objectifs différents selon les rayons.

À quoi se voit un moteur privé de contexte

Les symptômes sont caractéristiques, et ils se distinguent nettement de ceux d'un problème de données.

• Les recommandations sont justes mais rejetées. Personne ne conteste le calcul, tout le monde refuse l'application. C'est la signature d'un déficit de contexte, pas d'un déficit de donnée.
• Le taux d'acceptation varie fortement d'une catégorie à l'autre, sans que la qualité des données varie. Les catégories qui acceptent sont celles dont le contexte a été transmis, souvent parce que leur responsable a participé au paramétrage.
• Les mêmes corrections manuelles reviennent chaque semaine. Chaque correction répétée est un morceau de contexte qui n'a pas été formalisé : l'équipe réinjecte à la main ce que le système ne sait pas.
• Les objections commencent par « évidemment ». C'est le marqueur le plus fiable du savoir tacite. Ce qui est évident pour l'équipe ne l'est pour aucun système.

Ce dernier point mérite d'être traité comme un outil de travail plutôt que comme une contrariété. Chaque fois qu'une équipe dit « évidemment », elle vient de révéler gratuitement une règle qu'elle n'aurait jamais pensé à énoncer. Il suffit de l'écrire.

Comment extraire un contexte qui vit dans des têtes

La méthode naïve consiste à demander aux équipes d'écrire leurs règles. Elle échoue à peu près toujours, pour une raison simple : on ne sait pas énoncer ce qu'on n'a jamais eu besoin de formuler. Trois approches fonctionnent mieux.

Partir des exceptions passées

Les corrections manuelles des douze derniers mois sont la matière première la plus riche de l'entreprise. Chacune est la trace d'un écart entre ce que le système a proposé et ce que l'équipe savait. Les classer par motif fait émerger les familles de contexte beaucoup plus efficacement qu'un atelier de rédaction.

Procéder par confrontation plutôt que par interrogation

Plutôt que demander « quelles sont vos règles ? », soumettre des propositions de prix et demander lesquelles sont inacceptables, puis pourquoi. Le refus fait parler là où la question ouverte laisse muet. C'est la même logique qu'une simulation : on révèle une politique en la mettant à l'épreuve de cas concrets.

Capturer au fil de l'eau, pas en une fois

Un contexte ne se collecte pas dans un atelier de deux jours. Il se dépose par petites touches, à chaque arbitrage, à condition que quelqu'un soit chargé de l'écrire sur le moment. C'est un travail de quelques minutes par semaine qui, au bout d'un an, vaut plus que n'importe quel chantier de formalisation.

Le point de vigilance : contexte n'est pas synonyme de règle figée

Transformer chaque élément de contexte en règle bloquante dans l'outil est le meilleur moyen de fabriquer le passif décrit dans notre article sur la dette de règles d'un moteur de pricing. Une bonne part du contexte doit rester une information affichée au moment de la décision plutôt qu'une contrainte qui s'impose silencieusement. L'écart entre les deux est considérable : l'une éclaire l'arbitrage humain, l'autre le remplace.

Pourquoi le contexte survit aux modèles

Les algorithmes de prévision et d'optimisation se renouvellent vite. Une approche qui faisait référence il y a trois ans est aujourd'hui dépassée, et celle d'aujourd'hui le sera dans trois ans. C'est une bonne nouvelle, et c'est aussi la raison pour laquelle il est risqué de faire du modèle le cœur de son investissement.

Le contexte, lui, ne se périme pas au même rythme. Les repères de prix d'une enseigne, ses contraintes fournisseurs, ses interdits commerciaux et ses intentions par catégorie évoluent par années, pas par versions. Une entreprise qui a formalisé ce socle peut changer de moteur sans repartir de zéro. Une entreprise qui ne l'a pas fait recommence l'apprentissage à chaque changement d'outil, et paie deux fois.

Ce que cela implique au moment de choisir

La question à poser à un éditeur n'est donc pas seulement « que sait faire votre modèle ? », mais aussi « où vit mon contexte dans votre solution, et qu'est-ce que j'en récupère si je pars ? ». Un contexte enfoui dans un paramétrage propriétaire est un contexte que vous avez constitué et que vous ne possédez pas vraiment. C'est l'objet de notre article sur la réversibilité d'une solution de pricing.

Formulé simplement : la donnée dit ce que vous avez vendu, le modèle dit ce qui pourrait marcher, et le contexte dit qui vous êtes. Le premier se rachète, le deuxième se remplace, le troisième se construit une fois.

FAQ