L'IA n'élimine pas les biais — elle les accélère

Les outils d'analytics IA (Amplitude AI, Mixpanel Spark, Google Analytics Intelligence) promettent de « découvrir automatiquement les insights » dans les données comportementales. Ils le font effectivement — mais ils découvrent aussi des patterns fallacieux avec la même confiance que les patterns réels. Les travaux de Sculley et al. (2015) chez Google ont documenté la « dette technique » des systèmes ML : les modèles qui fonctionnent sont maintenus ; les modèles qui produisent des résultats plausibles mais faux sont plus difficiles à détecter.

Le problème fondamental : les données comportementales ne sont pas objectives. Elles reflètent le design actuel de l'interface, pas les besoins réels de l'utilisateur. Si un bouton est mal placé et que 80 % des utilisateurs ne le voient pas, les analytics diront que « les utilisateurs ne sont pas intéressés par cette fonctionnalité ». L'IA analytics, entraînée sur ces données biaisées, produira des recommandations qui entérinent le problème au lieu de le résoudre.

Les designers qui s'appuient sur les insights IA sans comprendre les biais de données prennent des décisions erronées avec une confiance injustifiée. Comprendre les biais statistiques les plus courants n'est plus optionnel — c'est une compétence de design essentielle.

Le survivorship bias en UX analytics

Le survivorship bias est le biais le plus pernicieux en analytics produit. Vous analysez le comportement de vos utilisateurs actifs — ceux qui ont survécu à l'onboarding, qui continuent d'utiliser le produit, qui sont encore dans votre base. Vous n'analysez pas ceux qui sont partis. Et c'est précisément ceux qui sont partis qui contiennent les insights les plus précieux.

Exemple concret : votre analytics montre que les utilisateurs actifs passent en moyenne 12 minutes par session et complètent 3 tâches. Vous en concluez que le produit est bien conçu. Mais si 60 % des inscrits ont abandonné dans la première semaine (et ne sont donc pas dans vos « utilisateurs actifs »), votre produit a un problème massif que vos métriques d'utilisateurs actifs ne montrent pas.

La solution : mesurer systématiquement le taux de drop-off à chaque étape du parcours, y compris les étapes pré-inscription et post-inscription immédiat. Les cohortes d'abandon (pourquoi et quand les utilisateurs partent) sont plus informatives que les cohortes de rétention (quand les utilisateurs reviennent). L'IA analytics doit être entraînée à chercher les absences, pas seulement les présences.

Le paradoxe de Simpson dans les tests A/B

Le paradoxe de Simpson est un phénomène statistique où une tendance qui apparaît dans plusieurs groupes séparés s'inverse quand les groupes sont combinés. En UX, ça se manifeste dans les tests A/B segmentés. Exemple : la variante B surpasse A chez les utilisateurs mobile ET chez les utilisateurs desktop, mais A surpasse B dans le total combiné — parce que la répartition mobile/desktop est différente entre les groupes.

L'étude de Kohavi et al. (2020) chez Microsoft a documenté des dizaines de cas réels de paradoxe de Simpson dans les tests A/B de Bing et Office. L'IA analytics qui agrège les résultats sans segmentation adéquate produit des recommandations qui sont littéralement l'inverse de la bonne décision pour chaque segment d'utilisateurs.

La recommandation : ne jamais analyser un test A/B uniquement sur le total agrégé. Toujours segmenter par les variables confondantes connues (device, géographie, ancienneté, source d'acquisition). Et quand les segments montrent des résultats contradictoires, investiguer la cause plutôt que de faire confiance au total. L'IA analytics doit être configurée pour alerter automatiquement quand les segments divergent du total.

Goodhart's Law : quand la métrique devient l'objectif

La loi de Goodhart, reformulée par Strathern (1997), énonce : « Quand une mesure devient un objectif, elle cesse d'être une bonne mesure. » En UX, ce phénomène est omniprésent. Vous optimisez le taux de conversion ? Les équipes ajoutent des dark patterns qui augmentent la conversion à court terme et détruisent la confiance à long terme. Vous optimisez le NPS ? Les équipes harcèlent les utilisateurs satisfaits pour qu'ils répondent, gonflant artificiellement le score.

L'IA analytics accélère ce phénomène : les algorithmes d'optimisation trouvent les raccourcis les plus efficaces pour maximiser la métrique cible, y compris les raccourcis contre-productifs. Un algorithme de recommandation optimisé pour le temps passé recommandera du contenu addictif plutôt qu'utile. Un algorithme optimisé pour la conversion recommandera le parcours le plus manipulateur.

La solution proposée par Muller (2018) dans « The Tyranny of Metrics » : utiliser des « métriques de contrepoids ». Pour chaque métrique optimisée, surveiller une contre-métrique qui détecterait les effets pervers. Si vous optimisez la conversion, surveillez le taux de retour/remboursement. Si vous optimisez le temps passé, surveillez le regret post-session. Si vous optimisez le NPS, surveillez le churn à 90 jours.

Vers des analytics plus honnêtes

Les travaux de Kohavi, Tang et Xu (2020) dans « Trustworthy Online Controlled Experiments » proposent un cadre pour des analytics plus rigoureux. Premièrement, distinguer les métriques de santé (guardrails — ne doivent pas se dégrader) des métriques d'optimisation (qu'on cherche à améliorer). L'IA analytics doit alerter quand un guardrail se dégrade, même si la métrique d'optimisation s'améliore.

Deuxièmement, calculer systématiquement les intervalles de confiance, pas seulement les moyennes. « Le taux de conversion est de 3,2 % » est moins informatif que « Le taux de conversion est de 3,2 % ± 0,4 % (IC 95 %) ». La deuxième formulation révèle que la précision de la mesure est limitée — et que certaines « améliorations » de 0,1 % sont dans la marge d'erreur.

Troisièmement, pour chaque insight IA, se demander : « Quelle serait l'explication alternative la plus simple ? » Si l'IA dit « les utilisateurs préfèrent le bouton bleu au bouton vert », l'explication alternative pourrait être « le bouton bleu est plus gros » ou « le bouton bleu est mieux placé ». L'IA analytics est un outil de détection de patterns, pas de compréhension causale. La compréhension reste le travail du designer.