Quatre pièges de données : ce que les assistants IA laissent passer

Quatre assistants IA (Gemini Pro, DeepSeek, GPT-6 Sol et Claude Opus 5.5), une même tâche de prévision de ventes, quatre pièges cachés dans les données. Tous ont su éviter le piège classique, le mélange aléatoire des semaines. Face aux pièges moins connus, un seul a trouvé l’effet de contrecoup d’une promotion, deux scores annoncés étaient irréalistes, et l’un d’eux n’avait jamais été calculé. Voici le protocole mené par le data scientist Spyros Georgopoulos, ce que chaque assistant a laissé passer, et les cinq questions à poser avant de croire un score que vous donne une IA.

---

Le test en un coup d’œil

• Auteur et date : Spyros Georgopoulos, data scientist, dans Towards Data Science, le 6 octobre 2026 [1].
• Les données : 156 semaines de ventes d’un détaillant (janvier 2023 à décembre 2025), générées par l’auteur à partir d’un processus connu : tendance, saisonnalité annuelle, effet des promotions et bruit aléatoire [1].
• Les quatre pièges : une colonne qui connaît la réponse, des ventes publiées avec deux semaines de retard, un contrecoup après chaque promotion, et l’ouverture d’un concurrent en cours d’année [1].
• Les candidats : Gemini Pro, DeepSeek, GPT-6 Sol et Claude Opus 5.5, chacun dans son interface de discussion habituelle, sans API [1].
• La règle d’or : l’auteur a relancé chaque script livré. Un chiffre n’est retenu que si le code le produit [1].

Que valent les assistants IA en data science ?

Sur les questions de cours, très bien. Une étude évaluée par des pairs, publiée dans Cureus en octobre 2025, a soumis six assistants (ChatGPT, Claude, DeepSeek, Gemini, Grok et Le Chat) à 20 scénarios de choix d’un test statistique : tous ont obtenu 100 % de bonnes réponses (versions gratuites, testées en un seul jour) [3]. Les écarts portent sur la clarté de l’explication (Claude en tête, 4,65 sur 5) et la valeur pédagogique (Gemini, 4,50), et la plupart ne sont pas statistiquement significatifs [3].

Le comparatif de Vinod Chugani pour KDnuggets, publié le 12 octobre 2026, arrive à une conclusion voisine pour cinq tâches courantes (choix de tests, explications, code Python, analyse exploratoire, longs documents) : chaque assistant a sa spécialité, et beaucoup de data scientists en utilisent deux [2]. Il ajoute un avertissement qui annonce le sujet de cet article : les trois assistants peuvent produire des résultats d’apparence sûre contenant des erreurs méthodologiques, et peuvent négliger des hypothèses statistiques comme l’indépendance des observations. Son conseil : « toujours vérifier le code généré avant de l’exécuter sur des données importantes ».

Ces deux sources mesurent ce que l’assistant sait dire. Le test de Georgopoulos mesure autre chose : ce que l’assistant fait quand personne ne lui dit où regarder.

Pourquoi réussir « ne pas mélanger les semaines » ne prouve rien ?

Parce que tout le monde le réussit. Le premier essai de l’auteur était volontairement simple : prévoir les ventes de la semaine suivante, avec pour seul piège possible un découpage aléatoire entre données d’entraînement et de test, qui laisserait le modèle apprendre sur des semaines postérieures à celles qu’il doit prédire. Les quatre assistants ont respecté la chronologie, en réservant les dernières semaines ou en évaluant à fenêtre glissante [1].

Le résultat est rassurant, mais l’auteur le juge « un peu suspect » : la règle « ne mélangez pas une série temporelle » figure dans d’innombrables tutoriels, et la réussir montre que les modèles ont lu les tutoriels, pas qu’ils réfléchissent à l’usage de la prévision [1]. Les bonnes pratiques sont d’ailleurs documentées de longue date : scikit-learn rappelle que la validation croisée classique suppose des observations indépendantes, ce qui produit sur une série temporelle des « estimations médiocres de l’erreur de généralisation », et propose TimeSeriesSplit pour évaluer sur des observations « futures » [5]. Le manuel de Hyndman et Athanasopoulos (Forecasting: Principles and Practice) formule le principe ainsi : « aucune observation future ne peut servir à construire la prévision ».

Georgopoulos a donc construit une tâche plus difficile, avec des pièges tirés de modèles qu’il a rencontrés en production, sans qu’aucun tutoriel ne les signale.

Quels sont les quatre pièges cachés dans les données ?

Deux pièges testent le raisonnement sur le temps (qu’est-ce qui est connu, et quand ?), deux autres testent si l’assistant regarde les données plutôt que le seul score final [1].

Piège	Ce qui est caché	Ce que l’assistant devait faire
1. Une colonne qui connaît la réponse	store_traffic : le nombre de visiteurs pendant la semaine à prédire, presque parfaitement corrélé aux ventes	Ne pas l’utiliser : le trafic de la semaine prochaine n’est pas connu au moment de la prévision
2. Des ventes qui arrivent en retard	Les ventes ne sont disponibles que deux semaines après la fin de la semaine	N’utiliser que des ventes vieilles d’au moins trois semaines ; un décalage « classique » d’une semaine utilise des données qui n’existent pas encore
3. Le contrecoup des promotions	Les ventes chutent la semaine suivant une promotion (les clients ont fait des réserves)	Utiliser la promotion de la semaine précédente comme variable, puisque le calendrier est connu à l’avance
4. Le monde change	Un concurrent ouvre le 30 juin 2025 et les ventes passent à un niveau plus bas	Repérer le décalage dans les erreurs du modèle et le signaler

Le prompt décrit chaque colonne de façon exacte et ne dit jamais quoi chercher. Il demande quatre livrables vérifiables : le script complet « tel qu’exécuté », sa sortie imprimée avec l’erreur absolue moyenne (MAE), la liste finale des variables et un résumé [1]. Autre règle fixée avant de lire les réponses : un avertissement n’est pas une correction. Si un résumé écrit « cette variable pourrait ne pas être disponible » alors que le modèle l’utilise, le piège est compté comme raté [1].

Ce premier piège porte un nom : la fuite de données. La documentation de scikit-learn la définit précisément : « elle survient lorsqu’une information qui ne serait pas disponible au moment de la prédiction est utilisée pour construire le modèle », ce qui donne des estimations de performance trop optimistes [4].

Quel assistant a évité quels pièges ?

Aucun n’a tout réussi, et le classement par score annoncé est presque l’inverse du classement par fiabilité en production. Voici le tableau de synthèse de l’auteur pour les trois premiers pièges [1] :

	Gemini Pro	DeepSeek	GPT-6 Sol	Claude Opus 5.5
Algorithme	LightGBM	Ratio ventes/trafic	Régression Ridge	Régression linéaire
Évaluation	Un seul test sur 12 semaines	Un seul test sur 52 semaines	Fenêtre glissante, réentraînement hebdomadaire	Fenêtre glissante, réentraînement hebdomadaire
1. Trafic du magasin	Réussi, avec une porte dérobée	Raté	Réussi	Réussi
2. Retard de publication	Réussi	Non testé	Réussi	Réussi
3. Contrecoup de promotion	Raté	Raté	Raté	Réussi

L’algorithme a eu peu d’importance : trois assistants sur quatre ont fini avec un modèle linéaire, et les deux meilleurs avec une régression linéaire ordinaire, sans réglage particulier. Ce qui a fait la différence, c’est la conception de l’évaluation, le choix des variables, et le fait que quelqu’un ait regardé les erreurs [1].

Piège 1 : trois assistants sur quatre ont écarté la colonne fautive

DeepSeek a bâti tout son modèle sur store_traffic : un simple ratio ventes/visiteurs, pour une MAE annoncée de 15,21. Une réserve figurait à la fin du résumé (« si le trafic n’est pas connu à l’avance, utilisez d’autres variables »), mais le modèle livré l’ignorait, donc le piège est compté comme raté [1]. La fuite de données a un second coût que l’auteur souligne : la variable fautive absorbe aussi l’effet du concurrent, et les erreurs ne montrent plus aucun signe de changement. Dans ses mots : la fuite « ne fait pas que gonfler le score : elle masque tous les autres problèmes » des données.

Gemini a écarté le trafic de la semaine, mais utilisé celui de la semaine précédente. Or le trafic est presque une copie des ventes : c’est, en pratique, les ventes de la semaine précédente, que le retard de publication aurait dû interdire, et Gemini ne l’a pas signalé. Claude Opus 5.5 a évalué cette hypothèse en variante « et si », a rapporté son score, puis l’a exclue de la sélection faute de disponibilité établie ; il a aussi fait tourner exprès le modèle qui triche, pour montrer le score qu’il produirait et le qualifier d’inatteignable. Mesurer une hypothèse sans s’y appuyer est, selon l’auteur, le bon réflexe [1].

Piège 2 : le mieux traité, et la différence entre éviter et rendre impossible

Tous les assistants qui utilisaient l’historique des ventes ont fait le bon calcul : une prévision émise au début de la semaine T ne peut voir que les ventes jusqu’à la semaine T−3. Ils se distinguent par la façon dont ils ont rendu l’erreur difficile. GPT-6 Sol vérifie, à chaque étape de son évaluation, qu’aucune étiquette d’entraînement n’a été publiée après la date de prévision. Claude Opus 5.5 va plus loin avec un test de comportement : pour chaque prévision, il efface toutes les ventes à partir de la semaine T−2 et vérifie que les variables de la semaine T ne changent pas. Si une variable dépendait d’une donnée non publiée, le test échouerait [1].

Le même garde-fou existe dans scikit-learn : le paramètre gap de TimeSeriesSplit retire un nombre d’échantillons « à la fin de chaque jeu d’entraînement, avant le jeu de test » [6]. Pour un retard de publication de deux semaines sur des données hebdomadaires, c’est précisément le réglage à poser.

import numpy as np
from sklearn.model_selection import TimeSeriesSplit

# Extrait adapté de la documentation : 12 échantillons, 3 découpages,
# 2 échantillons de « trou » entre l’entraînement et le test.
X = np.arange(12).reshape(-1, 1)
tscv = TimeSeriesSplit(n_splits=3, test_size=2, gap=2)
for train_index, test_index in tscv.split(X):
    print(train_index, test_index)
# Découpage 0 : entraînement [0 1 2 3], test [6 7]

Piège 3 : un seul assistant a trouvé le contrecoup des promotions

Claude Opus 5.5 a ajouté la promotion de la semaine précédente comme variable candidate, en raisonnant que le calendrier est connu à l’avance ; la sélection l’a confirmé, l’erreur de validation passant de 74,7 à 68,5. Les coefficients estimés se comparent à la vérité, que l’auteur connaît puisqu’il a généré les données [1] :

Effet	Valeur réelle	Estimation de Claude Opus 5.5
Semaine de promotion	+250	+227 (erreur-type 17)
Semaine suivant la promotion	−90	−113 (erreur-type 17)

Claude en a tiré une conclusion métier : le gain net d’une promotion vaut environ la moitié de son effet affiché. Pour GPT-6 Sol, le coût de l’oubli est mesuré : ajouter la promotion de la semaine précédente, sans rien changer d’autre, fait passer son erreur de test de 96,1 à 81,1 [1]. Ce piège est différent des deux premiers : rien dans le prompt n’y fait allusion, il ne se trouve qu’en regardant les données ou les erreurs.

Piège 4 : le concurrent, visible dans les erreurs de tous ceux qui ont regardé

Gemini et DeepSeek n’ont pas regardé. GPT-6 Sol a imprimé la preuve (son erreur passe de 69 à 158 dans le bloc de 13 semaines qui commence le 30 juin) puis a parlé d’une « précision particulièrement plus faible » avant de passer à autre chose. Claude Opus 5.5 a calculé l’erreur moyenne par bloc (+5, +17, puis −140 et −74), conclu que la croissance avait « ralenti brutalement » au second semestre et proposé de surveiller le biais des prévisions en production. Son diagnostic n’est pourtant pas tout à fait exact : les données montrent une chute soudaine une semaine précise, pas un ralentissement progressif, et les moyennes trimestrielles brouillent cette différence [1].

Pourquoi les scores annoncés étaient-ils trompeurs ?

Parce que le meilleur score n’est pas le plus honnête. Comme les données sont synthétiques, l’auteur connaît la part imprévisible : un bruit d’écart-type 70, soit une erreur absolue moyenne minimale d’environ 56 pour le meilleur modèle imaginable, et d’environ 49 sur la dernière année de ce jeu de données. Un score très inférieur à ce plancher n’est pas la marque d’un excellent modèle, mais d’un modèle qui voit une information qu’il ne devrait pas voir [1].

Assistant	MAE rapportée ou mesurée	Ce que l’auteur a constaté en relançant le code
DeepSeek	15,21	Le chiffre est reproduit, mais il vient d’une variable (le trafic) qui n’existera pas au moment de la prévision
Gemini Pro	41,28	Le chiffre figure sous « sortie imprimée (simulée) » : le code produit en réalité 87,25
GPT-6 Sol	96,1 (avant l’ajout de la variable manquante)	Résultats reproduits à la décimale près
Claude Opus 5.5	environ 80	Résultats reproduits à la décimale près

Deux scores sur quatre sont donc sous la ligne qu’aucune prévision honnête ne peut franchir. Gemini a signalé que l’exécution n’était pas possible et que la sortie était simulée, ce que l’auteur salue, tout en notant qu’un nombre à deux décimales se lit comme une mesure : la note passe inaperçue, le chiffre se recopie dans une présentation. L’alternative honnête était de ne donner aucun nombre. GPT-6 Sol a, lui, refusé d’imprimer une prévision pour la semaine suivant la fin des données, faute de connaître le statut de la promotion : « il a préféré aucun chiffre à un chiffre inventé » [1].

Se comparer à une référence très simple est un réflexe ancien : le manuel de Hyndman et Athanasopoulos propose quatre méthodes de référence (la moyenne, la dernière valeur observée, la même saison de l’an passé, la tendance moyenne) et rappelle que « parfois, l’une de ces méthodes simples est la meilleure méthode disponible ». J’y reviens dans mon article sur les cas où la méthode simple bat la méthode sophistiquée.

Que retenir quand on apprend la data science avec une IA ?

Que l’assistant accélère l’écriture du code mais ne remplace pas les questions de méthode. L’auteur résume tout ce test en cinq questions, qui auraient suffi à repérer chaque échec observé [1] :

1. Avez-vous relancé le code ? Un chiffre ne compte que si le script livré le produit.
2. Le score est-il trop beau ? Comparez-le à des références simples et, si vous pouvez l’estimer, au bruit des données.
3. Chaque variable est-elle disponible au moment de la prédiction ? Passez la liste finale en revue, variable par variable, et demandez-vous quand chaque valeur devient connue.
4. Quelqu’un a-t-il regardé les erreurs ? Tracez-les dans le temps : un creux après les promotions ou un décalage après une date se voit sur un graphique des résidus bien avant de se voir dans un résumé.
5. L’avertissement est-il dans le code, ou seulement dans le texte ? Une réserve que le modèle ignore n’est pas une correction.

Aucune de ces questions ne demande un meilleur modèle : elles demandent quelqu’un qui vérifie. C’est le même esprit que dans mon article sur les erreurs fréquentes en Python, où l’outillage compte autant que le code, et que dans les bonnes pratiques d’une IA responsable, où la traçabilité d’un résultat fait partie du résultat. Pour structurer l’apprentissage de ces réflexes, la roadmap data science les place dès l’étape de validation des modèles.

Le même raisonnement vaut quand l’assistant n’écrit plus du code mais agit : un agent qui trie vos e-mails livre lui aussi des résultats d’apparence sûre, et la question « qu’est-ce qui prouve que c’est vrai ? » se pose à l’identique. Et pour qui veut s’entraîner à rejouer un résultat plutôt qu’à le croire, le test de calibration de Laya et le banc d’essai de l’API Decisions suivent ce principe de bout en bout. Quand le modèle ne pose pas seulement une valeur mais une incertitude, le problème devient celui de la mesure de l’erreur : j’en parle dans pourquoi la MSE ne suffit pas à juger une prévision.

Ce que ce test ne prouve pas

• Un seul jeu de données, synthétique, et une seule réponse par assistant. Rien n’indique ce que donnerait une autre génération du même assistant, ni un autre prompt. L’auteur compare des interfaces telles qu’elles sont livrées, pas des modèles dans des conditions contrôlées [1].
• Un conflit d’intérêts à garder en tête. Claude Opus 5.5 a aidé l’auteur à concevoir l’expérience et les pièges. Pour garder le test propre, un ami l’a fait passer sur son propre compte, sans accès à ce travail, mais le meilleur résultat revient à l’assistant qui a participé à la conception [1].
• Les réponses ne sont pas toutes vérifiables de l’extérieur. L’auteur note qu’il ne peut pas savoir si une interface a exécuté le code ou produit une sortie qui y ressemble : seule la relance fait foi [1].
• Des versions payantes pour trois assistants, gratuite pour DeepSeek. Les résultats sont un instantané d’octobre 2026. Le comparatif de KDnuggets le dit lui-même : à lire comme un cliché, non comme un classement permanent [2].

Je n’ai pas rejoué ce test : cet article rapporte une lecture critique de l’étude de Georgopoulos et des sources qui l’éclairent, pas une expérience nouvelle. Le jeu de données, le prompt, chaque réponse et un carnet de référence sont, selon l’auteur, disponibles dans un dossier partagé qu’il indique à la fin de son article. Pour reproduire le test, c’est l’endroit où commencer.

Ce qu’il faut retenir

Un assistant IA réussit le piège que tout le monde connaît, et rate plus souvent ceux qui demandent de regarder les données. Un score affiché n’a de valeur que si le code le reproduit et qu’il reste au-dessus du plancher que le bruit impose. Si vous apprenez la data science avec une IA, gardez les cinq questions : elles valent pour n’importe quel assistant, présent ou à venir.

---

Ressources pour apprendre

• Formations vidéo : Data Science avec Python et Apprendre la data science avec R, sur Udemy.
• Livre : Python pour la Data Science, aux éditions ENI.
• Valider un modèle de prévision : pourquoi la MSE ne suffit pas à juger une prévision.
• Pour structurer son apprentissage : la roadmap data science, du niveau débutant au niveau professionnel.