Découvrez comment les modèles causaux de Judea Pearl aident les équipes à expliquer le comportement des IA, déboguer les incidents et prendre des décisions produit plus claires, au‑delà des corrélations.
Une équipe remarque quelque chose d’“évident” dans son tableau de bord : les utilisateurs qui reçoivent plus de notifications reviennent plus souvent. Elle augmente donc le volume de notifications. Une semaine plus tard, la rétention baisse et les plaintes affluent. Que s’est‑il passé ?
Le motif initial était réel — mais trompeur. Les utilisateurs les plus engagés déclenchent naturellement plus de notifications (parce qu’ils utilisent davantage le produit), et ils reviennent aussi davantage. Les notifications n’avaient pas causé la rétention ; c’est l’engagement qui causait les deux. L’équipe a agi sur la base d’une corrélation et a involontairement créé une expérience pire.
La pensée causale, c’est l’habitude de se demander : qu’est‑ce qui cause quoi, et comment le savoir ? Au lieu de s’arrêter à « ces deux choses bougent ensemble », on essaie de séparer :
Ce n’est pas être sceptique envers les données — c’est être précis sur la question. « Les notifications corrèlent avec la rétention ? » n’est pas la même question que « Envoyer plus de notifications augmentera‑t‑il la rétention ? » La seconde est causale.
Ce billet se concentre sur trois domaines pratiques où la détection de motifs échoue souvent :
Ce n’est pas un tour mathématique lourd de l’inférence causale. Vous n’aurez pas besoin d’apprendre la notation du do‑calculus pour en tirer de la valeur. L’objectif est d’offrir des modèles mentaux et un workflow que votre équipe peut utiliser pour :
Si vous avez déjà déployé un changement qui « avait l’air bon dans les données » mais n’a pas fonctionné en réalité, la pensée causale est le chaînon manquant.
Judea Pearl est un informaticien et philosophe des sciences dont le travail a remanié la manière dont de nombreuses équipes considèrent les données, l’IA et la prise de décision. Avant sa révolution causale, une grande partie de « l’apprentissage à partir des données » en informatique se focalisait sur les associations statistiques : trouver des motifs, ajuster des modèles, prédire ce qui va arriver. Cette approche est puissante — mais elle échoue souvent dès que l’on pose une question produit ou ingénierie contenant le mot parce que.
L’apport central de Pearl a été de traiter la causalité comme un concept de première classe, pas comme une intuition vague superposée aux corrélations. Plutôt que de demander uniquement « quand X est élevé, Y est‑il aussi élevé ? », la pensée causale demande « si nous changeons X, Y changera‑t‑il ? » Cette différence paraît minime, mais elle sépare la prédiction de la prise de décision.
L’association répond à « ce qui tend à se produire ensemble ». La causalité vise à répondre « que se passerait‑il si nous intervenions ». Cela compte en informatique parce que beaucoup de décisions réelles sont des interventions : déployer une fonctionnalité, changer un classement, ajouter un garde‑fou, modifier un jeu d’entraînement ou ajuster une politique.
Pearl a rendu la causalité plus pratique en la cadrant comme un choix de modélisation plus des hypothèses explicites. On ne « découvre » pas la causalité automatiquement à partir des données en général ; on propose une histoire causale (souvent basée sur la connaissance du domaine) puis on utilise les données pour la tester, l’estimer et l’affiner.
Ces outils ont donné aux équipes un langage commun pour passer de la détection de motifs à la réponse claire et disciplinée aux questions causales.
La corrélation signifie que deux choses bougent ensemble : quand l’une augmente, l’autre a tendance à augmenter (ou diminuer). C’est extrêmement utile — surtout dans les équipes riches en données — parce que cela aide à la prédiction et à la détection.
Si les ventes de glaces montent quand la température augmente, un signal corrélé (la température) peut améliorer les prévisions. En produit et IA, les corrélations alimentent les modèles de classement (« montrer plus de ce que des utilisateurs similaires ont cliqué »), la détection d’anomalies (« cette métrique suit habituellement celle‑ci ») et les diagnostics rapides (« les erreurs montent quand la latence augmente »).
Le problème survient quand on traite la corrélation comme une réponse à une question différente : que se passe‑t‑il si nous changeons quelque chose intentionnellement ? C’est la causalité.
Une relation corrélée peut être entraînée par un troisième facteur qui affecte les deux variables. Changer X ne change pas nécessairement Y — parce que X n’était peut‑être pas la raison pour laquelle Y a bougé initialement.
Imaginez tracer la dépense marketing hebdomadaire contre les ventes hebdomadaires et observer une forte corrélation positive. Il est tentant de conclure « dépenser plus cause plus de ventes ».
Mais supposons que les deux augmentent pendant les fêtes. La saison (un confounder) pousse une demande plus élevée et déclenche aussi des budgets plus importants. Si vous augmentez la dépense pendant une semaine non saisonnière, les ventes peuvent peu monter — parce que la demande sous‑jacente n’est pas là.
Vous êtes dans le territoire causal quand vous vous surprenez à demander :
Quand le verbe est changer, lancer, retirer ou réduire, la corrélation est un indice de départ — pas la règle de décision.
Un diagramme causal — souvent dessiné comme un DAG (graphe orienté acyclique) — est un moyen simple de rendre visibles les hypothèses d’une équipe. Plutôt que d’argumenter en termes vagues (« c’est probablement le modèle » ou « peut‑être l’interface »), vous mettez l’histoire sur le papier.
Le but n’est pas la vérité parfaite ; c’est un brouillon partagé de « comment nous pensons que le système fonctionne » que tout le monde peut critiquer.
Supposons que vous évaluiez si un nouveau tutoriel d’onboarding (T) augmente l’activation (A).
Un réflexe analytique courant est de « contrôler toutes les variables disponibles ». En termes de DAG, cela peut signifier ajuster accidentellement :
Avec un DAG, vous ajustez des variables pour une raison — typiquement pour bloquer des chemins de confusion — plutôt que simplement parce qu’elles existent.
Commencez avec un tableau blanc et trois étapes :
Même un DAG approximatif aligne produit, data et ingénierie autour de la même question causale avant de lancer les chiffres.
Un grand changement dans la pensée causale de Judea Pearl est de séparer observer quelque chose et la changer.
Si vous observe que les utilisateurs qui activent les notifications retiennent mieux, vous avez appris un motif. Mais vous ne savez toujours pas si les notifications causent la rétention, ou si les utilisateurs engagés choisissent simplement d’activer les notifications.
Une intervention est différente : elle signifie que vous fixez activement une variable à une valeur et observez ce qui se passe ensuite. En termes produit, ce n’est pas « les utilisateurs ont choisi X », c’est « nous avons déployé X ».
Pearl étiquette souvent cette différence ainsi :
L’idée du « faire » est essentiellement de noter mentalement que vous brisez les raisons habituelles pour lesquelles une variable prend une valeur. Quand vous intervenez, les notifications ne sont pas ACTIVÉES parce que les utilisateurs engagés ont opté pour elles ; elles le sont parce que vous avez forcé le paramètre (ou incité). C’est là que les interventions aident à isoler la causalité.
La plupart des travaux produit réels ont une forme d’intervention :
Ces actions visent à changer des résultats, pas seulement à les décrire. La pensée causale garde la question honnête : « Si nous faisons cela, qu’est‑ce qui changera ? »
Vous ne pouvez pas interpréter une intervention (ni concevoir une bonne expérience) sans hypothèses sur ce qui influence quoi — votre diagramme causal, même informel. Par exemple, si la saisonnalité influence à la fois la dépense marketing et les inscriptions, « faire » un changement de dépense sans tenir compte de la saison peut encore vous induire en erreur. Les interventions sont puissantes, mais elles ne répondent aux questions causales que lorsque l’histoire causale sous‑jacente est au moins approximativement correcte.
Un contrefactuel est une forme particulière de question « que se serait‑il passé ? » : pour ce cas précis, qu’aurait‑il fallu pour obtenir un résultat différent ? Ce n’est pas « que se passe‑t‑il en moyenne ? » — c’est « ce résultat aurait‑il changé pour cette personne, ce ticket, cette transaction ? »
Les contrefactuels apparaissent chaque fois que quelqu’un demande comment obtenir un résultat différent :
Ces questions sont généralement au niveau utilisateur. Elles sont aussi assez concrètes pour guider des changements produit, des politiques et des explications.
Imaginez un modèle de crédit qui rejette une demande. Une explication basée sur la corrélation pourrait dire : « Faible épargne corrèle avec rejet. » Un contrefactuel demande :
Si l’épargne de l’emprunteur avait été supérieure de 3 000 $ (tout le reste inchangé), le modèle l’aurait‑il approuvé ?
Si la réponse est « oui », vous avez appris quelque chose d’actionnable : un changement plausible qui inverse la décision. Si la réponse est « non », vous évitez de donner un conseil trompeur comme « augmentez vos économies » quand le véritable obstacle est le ratio dette/revenu ou un historique d’emploi instable.
Les contrefactuels dépendent d’un modèle causal — une histoire sur la façon dont les variables s’influencent — pas seulement d’un jeu de données. Vous devez décider ce qui peut réellement changer, ce qui changerait en conséquence et ce qui doit rester fixe. Sans cette structure causale, les contrefactuels peuvent devenir des scénarios impossibles (« augmenter l’épargne sans changer le revenu ou les dépenses ») et produire des recommandations inutiles ou injustes.
Quand un modèle ML échoue en production, la cause racine n’est que rarement « l’algorithme a empiré ». Le plus souvent, quelque chose dans le système a changé : ce que vous collectez, comment les labels sont produits, ou le comportement des utilisateurs. La pensée causale vous aide à arrêter de deviner et à isoler ce changement qui a causé la dégradation.
Quelques coupables récurrents apparaissent chez les équipes :
Ces cas peuvent paraître « corrects » dans des tableaux de bord agrégés parce que la corrélation peut rester élevée même lorsque la raison pour laquelle le modèle est juste a changé.
Un simple diagramme causal (DAG) transforme le débogage en carte. Il vous oblige à vous demander : cette feature est‑elle une cause de l’étiquette, une conséquence, ou une conséquence de la façon dont nous la mesurons ?
Par exemple, si politique d’étiquetage → ingénierie des features → entrées du modèle, vous avez peut‑être construit une pipeline où le modèle prédit la politique plutôt que le phénomène sous‑jacent. Un DAG rend ce chemin visible pour que vous puissiez le bloquer (retirer la feature, changer l’instrumentation ou redéfinir l’étiquette).
Au lieu de seulement inspecter les prédictions, essayez des interventions contrôlées :
Beaucoup d’outils d’« explicabilité » répondent à une question étroite : Pourquoi le modèle a‑t‑il produit ce score ? Ils le font souvent en mettant en évidence des entrées influentes (importance des features, cartes de saillance, valeurs SHAP). Cela peut être utile — mais ce n’est pas la même chose que d’expliquer le système dans lequel le modèle s’insère.
Une explication de prédiction est locale et descriptive : « Ce prêt a été refusé principalement parce que les revenus sont faibles et l’utilisation du crédit est élevée. »
Une explication de système est causale et opérationnelle : « Si nous augmentions le revenu vérifié (ou réduisions l’utilisation) d’une manière correspondant à une vraie intervention, la décision changerait‑elle — et les résultats en aval s’amélioreraient‑ils ? »
La première aide à interpréter le comportement du modèle. La seconde aide à décider quoi faire.
La pensée causale relie les explications aux interventions. Plutôt que de demander quelles variables corrèlent avec le score, on demande quelles variables sont des leviers valides et quels effets elles produisent lorsqu’elles changent.
Un modèle causal vous oblige à être explicite sur :
Cela compte parce qu’une « feature importante » peut être un proxy — utile pour la prédiction, dangereuse pour l’action.
Les explications post‑hoc peuvent sembler convaincantes tout en restant purement corrélationnelles. Si « nombre de tickets support » prédit fortement le churn, un graphe d’importance peut tenter l’équipe de « réduire les tickets » en rendant l’accès au support plus difficile. Cette intervention peut augmenter le churn, car les tickets étaient un symptôme de problèmes produit — pas une cause.
Les explications basées sur la corrélation sont aussi fragiles lors des shifts de distribution : une fois le comportement utilisateur changé, les features mises en avant peuvent ne plus signifier la même chose.
Les explications causales gagnent en valeur quand les décisions ont des conséquences et de la responsabilité :
Quand vous devez agir, pas seulement interpréter, l’explication a besoin d’un socle causal.
Le test A/B est l’inférence causale sous sa forme la plus simple et pratique. Quand vous assignez aléatoirement des utilisateurs aux variantes A ou B, vous effectuez une intervention : vous ne vous contentez pas d’observer ce que les gens ont choisi, vous fixez ce qu’ils voient. En termes de Pearl, la randomisation rend réel le « do(variant = B) » — ainsi les différences d’issues peuvent crédiblement être attribuées au changement, pas à qui l’a reçu.
L’affectation aléatoire casse de nombreux liens cachés entre traits utilisateurs et exposition. Utilisateurs power, nouveaux utilisateurs, heure de la journée, type d’appareil — ces facteurs existent toujours, mais ils sont (en moyenne) équilibrés entre les groupes. Cet équilibre transforme un écart métrique en affirmation causale.
Même les meilleures équipes ne peuvent pas toujours mener des tests randomisés propres :
Dans ces cas, vous pouvez toujours penser causalement — mais vous devez être explicite sur les hypothèses et l’incertitude.
Options courantes : difference‑in‑differences (comparer les changements dans le temps entre groupes), régression sur discontinuité (utiliser une règle de coupure comme « seuls les utilisateurs au‑dessus du score X »), variables instrumentales (une poussée naturelle qui change l’exposition sans affecter directement le résultat), et matching/pondération pour rendre les groupes plus comparables. Chaque méthode échange la randomisation contre des hypothèses ; un diagramme causal peut vous aider à énoncer ces hypothèses clairement.
Avant de lancer un test (ou une étude observationnelle), notez : la métrique principale, les garde‑fous, la population cible, la durée et la règle de décision. La pré‑enregistrement n’éliminera pas le biais, mais réduit le metric‑shopping et rend les affirmations causales plus fiables — et plus faciles à débattre en équipe.
La plupart des débats produit ressemblent à : « la métrique X a bougé après que nous avons déployé Y — donc Y a marché. » La pensée causale reformule cela en une question plus nette : « Le changement Y a‑t‑il causé la variation de X, et dans quelle mesure ? » Ce basculement transforme les tableaux de bord de preuve en points de départ.
Changement de prix : au lieu de « Le revenu a augmenté après la hausse de prix ? », demandez :
Ajustement d’onboarding : au lieu de « Les nouveaux utilisateurs complètent davantage l’onboarding », demandez :
Changement de classement de recommandation : au lieu de « le CTR s’est amélioré », demandez :
Les tableaux de bord mélangent souvent « qui a reçu le changement » et « qui aurait bien réussi de toute façon ». Un exemple classique : vous déployez un nouveau flux d’onboarding, mais il n’est montré qu’aux utilisateurs sur la toute dernière version de l’app. Si les versions plus récentes sont adoptées par des utilisateurs plus engagés, votre graphique peut montrer une hausse due en partie (ou en totalité) à l’adoption de la version, pas à l’onboarding.
Autres confounders fréquents en analytique produit :
Une section PRD utile peut s’intituler littéralement « Questions causales », et inclure :
Si vous utilisez une boucle de construction rapide (surtout avec du développement assisté par LLM), cette section devient encore plus importante : elle empêche le « on peut livrer vite » de devenir « on a livré sans savoir ce que ça causait ». Les équipes qui utilisent Koder.ai intègrent souvent ces questions causales dès la phase de planification, puis implémentent rapidement des variantes activées par feature flags, avec snapshots/rollback pour garder l’expérimentation sûre quand les résultats (ou effets secondaires) surprennent.
Les PM définissent la décision et les critères de succès. Les data partners traduisent cela en estimations causales mesurables et vérifications de cohérence. L’ingénierie garantit que le changement est contrôlable (feature flags, logging d’exposition propre). Le support partage des signaux qualitatifs — les changements de prix « fonctionnent » souvent tout en augmentant silencieusement les annulations ou la charge de tickets. Quand tout le monde s’accorde sur la question causale, livrer devient apprendre — pas seulement déployer.
La pensée causale n’exige pas un déploiement de niveau doctorat. Traitez‑la comme une habitude d’équipe : écrivez votre histoire causale, mettez‑la à l’épreuve, puis laissez les données (et les expériences quand c’est possible) la confirmer ou la corriger.
Pour avancer, collectez quatre éléments en amont :
En pratique, la rapidité compte : plus vite vous transformez une question causale en changement contrôlé, moins vous perdez de temps à débattre de motifs ambigus. C’est une des raisons pour lesquelles des équipes adoptent des plateformes comme Koder.ai pour passer de « hypothèse + plan » à une implémentation instrumentée (web, backend ou mobile) en jours plutôt qu’en semaines — tout en gardant la rigueur via des rollouts par étapes et des rollbacks.
Si vous voulez un rappel sur les expériences, voyez /blog/ab-testing-basics. Pour les pièges courants dans les métriques produit qui imitent des « effets », voyez /blog/metrics-that-mislead.
La pensée causale est un déplacement de « qu’est‑ce qui tend à bouger ensemble ? » vers « qu’est‑ce qui changerait si nous agissions ? ». Ce déplacement — popularisé en informatique et statistiques par Judea Pearl — aide les équipes à éviter des récits convaincants qui ne résistent pas à des interventions réelles.
La corrélation est un indice, pas une réponse.
Les diagrammes causaux (DAG) rendent les hypothèses visibles et discutables.
Les interventions (« faire ») sont différentes des observations (« voir »).
Les contrefactuels aident à expliquer des cas individuels : « que se serait‑il passé si ceci avait été différent ? »
Un bon travail causal documente l’incertitude et les explications alternatives.
La causalité demande de la rigueur : des confounders cachés, des erreurs de mesure et des effets de sélection peuvent inverser des conclusions. L’antidote, c’est la transparence — notez les hypothèses, montrez les données utilisées et indiquez ce qui falsifierait votre affirmation.
Si vous voulez approfondir, parcourez les articles relatifs sur /blog et comparez les approches causales avec d’autres méthodes d’analytique et d’« explicabilité » pour voir où chacune aide — et où elle peut induire en erreur.
La corrélation vous aide à prédire ou détecter (par ex. « quand X augmente, Y augmente souvent aussi »). La causalité répond à une question de décision : « Si nous changeons X délibérément, Y changera-t-il ? »
Utilisez la corrélation pour les prévisions et la surveillance ; utilisez la pensée causale quand vous vous apprêtez à déployer un changement, définir une politique ou allouer un budget.
Parce que la corrélation peut être due à un facteur de confusion. Dans l’exemple des notifications, les utilisateurs très engagés génèrent/reçoivent plus de notifications et reviennent davantage.
Si vous augmentez le volume de notifications pour tout le monde, vous changez l’expérience (intervention) sans changer l’engagement sous-jacent — la rétention peut donc ne pas s’améliorer et peut même se détériorer.
Un DAG (graphe orienté acyclique) est un diagramme simple où :
Il est utile parce qu’il rend explicites les hypothèses, aidant les équipes à s’accorder sur quoi ajuster, quoi ne pas ajuster, et quel test répondrait réellement à la question.
Une erreur courante est de « contrôler tout », ce qui peut accidentellement ajuster des médiateurs ou des collideurs et biaiser le résultat.
« Voir » c’est observer ce qui s’est naturellement produit (les utilisateurs se sont inscrits, un score est élevé). « Faire » c’est fixer activement une variable (déployer une fonctionnalité, forcer un paramètre).
L’idée clé : une intervention rompt les causes habituelles pour lesquelles une variable prend une valeur, d’où sa capacité à révéler plus clairement la causalité que l’observation seule.
Un contrefactuel demande : pour ce cas précis, que serait-il advenu si nous avions fait autrement.
Il est utile pour :
Il requiert un modèle causal pour éviter des scénarios impossibles.
Concentrez-vous sur ce qui a changé en amont et sur ce que le modèle pourrait exploiter :
Une approche causale vous pousse à tester des interventions ciblées (ablation, perturbations) au lieu de courir après des mouvements métriques concomitants.
Pas nécessairement. L’importance d’une feature explique ce qui a influencé la prédiction, pas ce qu’il faut changer.
Une feature jugée « importante » peut être un proxy ou un symptôme (par ex. les tickets de support prédisent la churn). Intervenir sur le proxy (« réduire les tickets en compliquant l’accès au support ») peut se retourner contre vous. Les explications causales lient l’importance à des leviers valides et aux effets attendus sous intervention.
Les tests A/B randomisés sont préférables quand c’est faisable, mais vous pouvez avoir besoin d’alternatives lorsque :
Dans ces cas, envisagez des quasi‑expériences : difference-in-differences, regression discontinuity, variables instrumentales, ou appariement/pondération — en explicitant clairement les hypothèses.
Ajoutez une courte section qui force la clarté avant l’analyse :
Ceci maintient l’équipe alignée sur une question causale plutôt que sur un récit post‑hoc basé sur un tableau de bord.
