Repérer l'AI-washing dans les pitchs de fournisseurs
Une category manager chez un distributeur européen de taille moyenne m'a raconté un jour que son équipe avait payé une prime pour de l'« assortment optimization AI-powered », avant de découvrir que le guide d'implémentation du fournisseur lui-même renvoyait à une logique statique du type « si l'espace en rayon vaut X, alors délister le SKU sous Y % de rotation », écrite en 2015. Aucun modèle. Aucune donnée d'entraînement. Juste un moteur de règles rebadgé avec un nouveau deck. Cela arrive dans les logiciels FMCG (fast-moving consumer goods) plus souvent que les acheteurs ne l'imaginent, et cela consomme des budgets qui devraient aller vers des outils qui apprennent réellement des données.
Cette leçon vous donne cinq questions à poser dans n'importe quelle réunion fournisseur, avec un pitch réaliste de category management comme fil conducteur.
Pourquoi cela compte particulièrement en FMCG
Les logiciels de category management promettent d'optimiser les assortiments en rayon, les prix et les promotions grâce à l'« AI ». La catégorie est attractive pour l'AI-washing parce que :
- Distributeurs et industriels disposent de données réellement désordonnées et volumineuses (transactions point-of-sale, données de cartes de fidélité, planogrammes) qui *sonnent* comme le carburant idéal pour l'AI.
- Les acheteurs (category managers, responsables trade marketing) sont souvent non techniques, donc les affirmations vagues passent sans être contestées.
- La frontière entre un système à base de règles légitime (déterministe, logique codée par des humains) et un modèle de machine learning entraîné (un système qui apprend des patterns dans les données au lieu de suivre des règles pré-écrites) est facile à brouiller dans un pitch.
Les deux approches peuvent être utiles. Le problème surgit quand un moteur de règles est commercialisé avec le vocabulaire du ML pour justifier un prix premium ou échapper à l'examen.
Les cinq questions
1. « Sur quelles données ce modèle a-t-il été entraîné, et en quel volume ? »
Un modèle entraîné a besoin d'un dataset d'entraînement : des exemples historiques dont l'algorithme apprend les patterns. Une réponse légitime précise le volume, la période et la source : « 3 ans de données point-of-sale sur 40 000 SKU issus de 12 chaînes de distribution alimentaire européennes. » Un moteur de règles ne peut pas répondre de façon cohérente. Les réponses vagues (« notre connaissance sectorielle propriétaire ») sont un signal d'alerte.
Demandez un chiffre concret. S'ils disent « des millions de transactions » mais ne peuvent pas préciser à quoi ces transactions ont servi (entraînement ou simple stockage en base), insistez.
2. « Que se passe-t-il si vous lui soumettez une catégorie de produits qu'il n'a jamais vue ? »
Cela teste la généralisation, c'est-à-dire la capacité du modèle à gérer des situations nouvelles, pas seulement des règles mémorisées. Si le fournisseur dit que le système « applique les règles métier configurées » aux catégories inconnues (par exemple un distributeur qui lance un rayon d'alternatives végétales à la viande, sans historique de ventes), c'est le signe qu'une couche de règles fait le vrai travail, avec un mince habillage ML ailleurs.
Un véritable modèle doit se dégrader progressivement et produire une estimation probabiliste avec une incertitude assumée, pas une sortie confiante à base de règles déguisée en « prédiction ».
3. « Puis-je voir une matrice de confusion ou une métrique d'accuracy sur un test set mis de côté ? »
Un test set mis de côté (held-out) regroupe des données que le modèle n'a jamais vues pendant l'entraînement, utilisées pour vérifier qu'il généralise au lieu de mémoriser. Une matrice de confusion montre où les prédictions étaient justes ou fausses.
Si le fournisseur ne peut produire aucune métrique d'accuracy (precision, recall, erreur absolue moyenne pour les prévisions de demande) sur des données inédites, il n'y a probablement aucun modèle entraîné en cours d'évaluation. Les moteurs de règles n'ont pas d'« accuracy » en ce sens, parce qu'ils ne font pas de prédictions probabilistes : ils exécutent une logique.
Une introduction gratuite si vous voulez le vocabulaire avant la réunion : le glossaire du Machine Learning Crash Course de Google.
4. « À quelle fréquence le modèle est-il réentraîné, et sur quel déclencheur ? »
Les vrais systèmes de ML doivent être réentraînés à mesure que les comportements de consommation évoluent (exemple classique en FMCG : les achats de stockage massif liés à la pandémie en 2020 ont cassé de nombreux modèles de prévision de demande entraînés sur des données antérieures à 2020, forçant des réentraînements rapides dans tout le secteur, ce qui est bien documenté dans les études de cas d'analytics retail de cette période).
Si le système du fournisseur « se met à jour » uniquement quand ses ingénieurs modifient manuellement des seuils de règles, c'est de la maintenance de règles, pas du réentraînement de modèle. Demandez précisément : le réentraînement est-il automatisé, planifié, ou déclenché par une baisse de performance (ce qu'on appelle le « model drift », quand l'accuracy d'un modèle se dégrade parce que les patterns du monde réel ont changé depuis l'entraînement) ?
5. « Montrez-moi un cas où la recommandation du modèle a surpris votre propre équipe. »
C'est la question la plus tranchante. Les vrais systèmes de ML font parfois émerger des patterns non évidents : associer un snack premium à une catégorie adjacente inattendue sur la base de données réelles de co-achat, ou signaler une anomalie de prix régionale que les humains avaient manquée. Si toutes les sorties que le fournisseur vous montre correspondent exactement à ce qu'un category manager expérimenté recommanderait déjà, le système ne fait peut-être qu'automatiser l'intuition existante, ce qui a de la valeur, mais n'est pas de l'« optimisation AI-powered » au sens vendu.
Un indice technique rapide dans le deck lui-même
Regardez comment le fournisseur décrit le scoring d'assortiment. Les vrais outils d'assortiment basés sur du ML font généralement référence à quelque chose qui ressemble à un modèle de scoring ou de ranking pondéré avec des coefficients appris, pas à des seuils fixes. Une version honnête simplifiée pourrait ressembler à ce pseudocode, où les poids sont *appris des données* plutôt que codés en dur :
# Rules engine (hardcoded, not AI)
if sku.velocity < 0.5 and sku.margin < 0.15:
recommend_delist(sku)
# Modèle entraîné (poids appris à partir des données de ventes historiques)
score = model.predict(sku_features)
# model.predict() applique des coefficients appris pendant l'entraînement,
# et non des seuils écrits par des humains
if score < learned_threshold:
recommend_delist(sku)Si l'annexe technique du fournisseur ne montre que le premier pattern avec d'autres noms de variables, demandez pourquoi ils appellent cela de l'AI.
À quoi ressemble un usage légitime de l'AI en category management
Soyons justes : de vraies applications existent. Des modèles de prévision de demande utilisant du gradient boosting ou des architectures de réseaux de neurones sont employés par de grands acteurs CPG (consumer packaged goods) et par des distributeurs : Nestlé, Unilever, Walmart et Tesco ont tous parlé publiquement de machine learning dans des contextes de supply chain et de demand planning. Nielsen et Circana (ex-IRI) intègrent également des modèles statistiques et de ML dans leurs produits d'analytics retail, généralement avec plus de transparence méthodologique que les petites solutions ponctuelles de category management.
Le trait distinctif des fournisseurs légitimes : ils peuvent discuter d'architecture de modèle, de provenance des données d'entraînement et de métriques de validation avec fluidité et précision, parce qu'une vraie équipe data science a construit et maintient le produit.
Vérification des acquis
1. Quelle est la distinction fondamentale entre un moteur de règles et un modèle de machine learning entraîné, du point de vue de la détection de l'AI-washing ?
2. Pourquoi les logiciels de category management FMCG sont-ils particulièrement attractifs pour l'AI-washing ?
3. Un fournisseur affirme que son système utilise de l'« assortment optimization AI-powered ». Quelle question de relance teste le mieux s'il s'agit d'un vrai modèle entraîné ou d'un moteur de règles rebadgé ?
4. Sélectionnez TOUTES les réponses correctes expliquant pourquoi les systèmes à base de règles et les systèmes à base de ML ont tous deux des usages légitimes, alors que l'AI-washing reste un problème.
Sélectionnez toutes les réponses correctes.
5. Sélectionnez TOUTES les réponses correctes concernant ce qui constitue un signal d'alerte quand on interroge un fournisseur sur les données d'entraînement de son modèle.
Sélectionnez toutes les réponses correctes.
Checklist d'évaluation pratique pour les achats
Avant de signer un contrat, demandez par écrit :
- Une description des données d'entraînement (volume, source, fraîcheur)
- Au moins une métrique de validation sur des données mises de côté
- La cadence de réentraînement et le processus de monitoring du drift
- Un client référent prêt à discuter des performances réelles du modèle, pas seulement de sa satisfaction sur l'UI
Si un fournisseur résiste sur les quatre points, valorisez l'outil comme un moteur de règles (ce qui peut rester un bon achat : les moteurs de règles sont souvent moins chers, plus explicables et plus faciles à auditer que des modèles opaques) et négociez en conséquence. L'explicabilité compte particulièrement pour les allégations réglementées : les distributeurs européens qui utilisent des systèmes de pricing automatisés doivent pouvoir expliquer leur logique de prix au titre des principes généraux de protection du consommateur, même si aucune loi européenne spécifique à l'AI sur le pricing n'impose aujourd'hui la transparence des modèles à ce niveau de granularité.
🎬 [VIDEO: « How to Spot AI Washing » - youtube.com - cherchez du contenu explicatif récent issu de chaînes établies de formation en data science traitant des allégations marketing sur l'AI face à la substance technique]
Points clés
- La question de diagnostic centrale est de savoir si le système apprend des patterns dans les données (modèle entraîné) ou exécute une logique pré-écrite (moteur de règles) ; les deux sont légitimes, un seul mérite le qualificatif « AI-powered » pour décrire une capacité prédictive.
- Exigez des détails concrets sur les données d'entraînement, des métriques de validation sur données mises de côté et un processus de réentraînement documenté ; des réponses vagues ou évasives signalent un moteur de règles rebadgé.
- Testez la généralisation en interrogeant sur des catégories inconnues ou des cas limites ; les moteurs de règles échouent de façon prévisible, les vrais modèles se dégradent progressivement avec une incertitude quantifiable.
- Un usage légitime du ML en category management FMCG existe chez les grands acteurs (Nestlé, Unilever, Walmart, Tesco, Nielsen, Circana) et s'accompagne généralement d'une discussion technique fluide et précise, pas seulement d'un langage marketing.
- Les moteurs de règles ne sont pas sans valeur : ils sont souvent plus explicables et auditables, donc valorisez-les et évaluez-les honnêtement au lieu de payer une prime AI pour une logique qui n'en est pas.