Beyond Reproducible Research: Building a Formal Representation of a Data Analysis

Cet article propose une représentation formelle des analyses de données qui, en externalisant leur construction logique, permet d'évaluer la qualité du raisonnement de l'analyste, de visualiser les liens logiques et d'analyser la sensibilité des hypothèses sans avoir besoin des données brutes.

L'essentiel

Voici une explication simple et imagée de l'article de Roger D. Peng, traduite en français pour un public général.

🌟 Le Concept de Base : De la "Recette" à la "Preuve"

Imaginez que vous êtes un chef cuisinier. Aujourd'hui, si vous voulez prouver que votre plat est délicieux, vous donnez simplement la recette (le code informatique) et les ingrédients (les données) à un ami. Vous dites : "Voici comment j'ai fait, essayez de refaire le plat, et vous verrez que c'est bon." C'est ce qu'on appelle la reproductibilité.

Mais Roger Peng dit : "Attendez une minute !"
Le problème, c'est que la recette ne dit pas pourquoi vous avez choisi ces ingrédients. Elle ne dit pas : "J'ai utilisé du sel parce que je savais que le plat serait trop fade sans ça" ou "J'ai coupé les oignons en petits morceaux pour qu'ils cuisent vite".

Si votre ami refait le plat et qu'il est mauvais, il ne saura pas si c'est à cause de la recette, d'un ingrédient périmé, ou d'une erreur de votre part. Il ne voit pas votre raisonnement.

L'idée de l'article : Au lieu de juste donner la recette, nous devrions construire un plan de construction logique, comme un dossier de police ou une preuve mathématique, où chaque affirmation est soutenue par des preuves explicites.

---

🏗️ L'Analogie du "Bâtiment de Verre"

Pour comprendre la méthode proposée, imaginons que faire une analyse de données, c'est construire un bâtiment en verre.

1. L'approche actuelle (Le Code Impératif)

Aujourd'hui, on nous donne une boîte remplie de briques (le code) et on nous dit : "Assemblez-les dans cet ordre, et vous obtiendrez une tour."

• Le problème : Si la tour s'effondre, on ne sait pas si c'est parce que les briques étaient cassées, ou parce que l'architecte a oublié de vérifier la solidité du sol. Le code montre ce qui a été fait, mais pas ce qu'on espérait.

2. L'approche de Peng (La Représentation Formelle)

Roger Peng propose de construire le bâtiment comme un système de vérification automatique.
Imaginez que chaque brique du bâtiment doit passer un test de qualité avant d'être posée.

• La brique "Moyenne" : Avant de dire "La moyenne est 4,6", on doit prouver qu'il n'y a pas de trous dans les données (pas de valeurs manquantes).
• La brique "Distribution" : On doit prouver qu'il n'y a pas de géants bizarres (valeurs aberrantes) qui faussent le résultat.

Dans ce système, on ne peut pas construire l'étage du haut (la conclusion) tant que les étages du bas (les prémisses) n'ont pas été validés par des tests automatiques.

---

🧩 Comment ça marche en pratique ? (Les "Classes" comme des Filtres)

L'auteur utilise un langage informatique (R) pour créer des "filtres" ou des "tamis".

Imaginons que vous voulez prouver que votre café est à la bonne température (disons 60°C).

1. L'affirmation (La Conclusion) : "Mon café est à 60°C."
2. Les preuves (Les Prémisses) : Pour que cette affirmation soit vraie, plusieurs choses doivent être vraies :
   • Prémisse A : Il n'y a pas de glace dans la tasse (pas de données manquantes).
   • Prémisse B : Le thermomètre n'est pas cassé (pas de valeurs infinies).
   • Prémisse C : Il n'y a pas de géant qui a jeté de l'eau bouillante dedans (pas d'outliers).

Dans la méthode de Peng, on crée un "tamis" pour chaque prémisse.

• Si le café passe le tamis "Pas de glace", il devient une "Tasse sans glace".
• Si cette "Tasse sans glace" passe le tamis "Pas de géant", elle devient une "Tasse valide".
• Si tout passe, alors on peut officiellement dire : "Le café est à 60°C".

Le génie de l'approche, c'est que si le tamis ne passe pas, le système refuse de construire l'affirmation. On ne peut pas mentir ou faire une erreur silencieuse.

---

🔍 Pourquoi est-ce mieux ? (Les 3 Super-Pouvoirs)

1. La lecture sans cuisson (Analyse Statique)

Normalement, pour vérifier si un code fonctionne, il faut le lancer sur les données (c'est comme cuisiner pour voir si c'est bon). C'est long et coûteux.
Avec la méthode de Peng, on peut lire le plan et dire : "Ah, ce plan dit que si la prémisse A est vraie, alors la conclusion est vraie." On peut vérifier la logique sans même avoir les données. C'est comme vérifier les plans d'un pont sans avoir besoin de construire le pont pour savoir s'il est solide.

2. La détection des erreurs silencieuses

Parfois, on mélange deux listes de données (comme deux listes de clients) et on pense que tout va bien, alors qu'en fait, on a perdu la moitié des clients parce que les noms étaient écrits différemment ("USA" vs "US").
Dans le système de Peng, on définit à l'avance : "Le résultat final doit avoir exactement 100 lignes." Si le code produit 50 lignes, le système crie "ALERTE !" avant même que vous ne regardiez le résultat. C'est comme un garde du corps qui vous dit : "Hé, ce résultat ne correspond pas à ce qu'on attendait !".

3. L'arbre de vérité (Visualisation)

L'article montre qu'on peut dessiner un arbre généalogique des preuves.

• Le sommet de l'arbre est votre conclusion ("Le médicament fonctionne").
• Les branches sont les preuves ("Pas d'effets secondaires", "Échantillon représentatif", "Mesures précises").
  Si une branche est cassée (une preuve est faible), on voit tout de suite que la conclusion est fragile. C'est comme un arbre de Noël : si vous enlevez une branche, l'arbre tient toujours, mais si vous enlevez le tronc, tout s'effondre.

---

🎯 En Résumé

Roger Peng nous dit : "Arrêtons de juste montrer comment on a fait les choses. Montrons pourquoi on pense que c'est vrai."

C'est comme passer d'une recette de cuisine (qui dit juste "mélangez A et B") à un dossier d'enquête (qui dit "A est vrai parce que B et C sont vérifiés, et B est vrai parce que D est vérifié").

Cela rend l'analyse plus transparente, plus facile à vérifier, et surtout, cela force le chercheur à réfléchir à ses propres hypothèses avant même de toucher aux données. C'est un pas de géant pour rendre la science plus fiable et moins sujette aux erreurs cachées.

Résumé technique

Voici un résumé technique détaillé de l'article « Beyond Reproducible Research: Building a Formal Representation of a Data Analysis » de Roger D. Peng.

1. Problématique

L'article identifie une lacune fondamentale dans l'approche actuelle de la reproductibilité en recherche computationnelle. Bien que la publication du code et des données permette de reproduire les résultats numériques, elle ne suffit pas à transmettre le raisonnement de l'analyste.

• Limites de la reproductibilité dynamique : Le code est souvent écrit de manière impérative (une séquence d'actions). Pour qu'un tiers comprenne pourquoi une affirmation est vraie, il doit exécuter le code sur les données. Cela pose plusieurs problèmes :
  • Le processus est coûteux en temps et en ressources.
  • Il nécessite l'accès aux données (problématique pour les données sensibles ou protégées).
  • Le code seul ne révèle pas les hypothèses, les attentes et les prémisses logiques de l'analyste. Un code qui s'exécute sans erreur n'implique pas nécessairement que l'analyse est correcte ou que les conclusions sont valides.
• Le besoin d'une représentation statique : Il existe un manque de formalisme pour représenter une analyse de données comme une construction logique (une série d'affirmations soutenues par des preuves), similaire à une preuve mathématique, plutôt que comme un simple programme informatique à exécuter.

2. Méthodologie

L'auteur propose un cadre conceptuel et une implémentation technique pour transformer les analyses de données en représentations formelles statiques.

Principes Fondamentaux

1. Les affirmations d'analyse de données comme définitions de classes : Au lieu de voir l'analyse comme une fonction qui prend des entrées et produit des sorties, chaque affirmation (ex: « La moyenne est 4,6 ») est définie comme une classe d'objets.
2. Vérification de validité : Une instance de cette classe n'est créée que si les conditions de validité (méthode validity) sont remplies. Si le code s'exécute sans erreur et crée l'objet, l'affirmation est considérée comme vraie, indépendamment de la visualisation des données brutes.
3. Prémisses comme extensions de classes : Les preuves soutenant une affirmation sont modélisées comme des classes de prémisses qui sont intégrées (slots) dans la classe principale. Cela crée une hiérarchie logique où une affirmation est vraie uniquement si toutes ses prémisses (et les prémisses de celles-ci) sont valides.
4. Approches directe et indirecte :
   • Directe : Identifier des faits qui impliquent directement la conclusion.
   • Indirecte : Identifier les conditions qui rendraient la conclusion fausse (hypothèses alternatives) et prouver que ces conditions ne sont pas réunies (ex: prouver l'absence de valeurs aberrantes pour valider une moyenne).

Implémentation Technique (R et S4)

L'auteur utilise le système de classes S4 du langage R pour concrétiser ce cadre :

• Définition de classes : Utilisation de setClass pour définir des objets valides uniquement si une condition statistique est remplie.
• Méthodes de validité : Utilisation de la fonction validity pour encoder les règles logiques (ex: absence de valeurs manquantes, absence d'outliers, distribution symétrique).
• Composition : Les classes principales contiennent des « slots » (emplacements) pour les objets des classes de prémisses, créant ainsi un arbre de dépendance logique.
• Visualisation : Utilisation de la structure hiérarchique des classes pour générer des arbres de décision (arbres de succès) visualisant les liens entre les prémisses et la conclusion.

3. Contributions Clés

1. Externalisation du raisonnement : Le cadre force l'analyste à expliciter ses hypothèses et ses attentes dans le code lui-même, rendant le processus de pensée transparent et vérifiable statiquement.
2. Analyse statique du code : Il devient possible d'évaluer la qualité et la logique d'une analyse sans exécuter le code sur les données réelles. On peut vérifier la structure logique des affirmations et de leurs preuves uniquement en inspectant les définitions de classes.
3. Détection d'erreurs silencieuses : Le système permet d'identifier des erreurs courantes (comme des problèmes de fusion de données due à des incohérences de formatage) en définissant à l'avance les propriétés attendues du résultat (nombre de lignes, colonnes, absence de NA). Si le résultat ne correspond pas à la classe définie, une erreur est levée immédiatement.
4. Analyse de sensibilité : En simulant des données avec des caractéristiques inattendues (outliers, non-linéarité), on peut tester si les prémisses définies sont suffisamment robustes pour « attraper » ces anomalies avant de conclure.
5. Visualisation de la structure logique : La proposition d'utiliser des arbres de prémisses (similaires aux arbres de défaillance inversés en ingénierie des systèmes) pour visualiser la chaîne de preuves soutenant une conclusion.

4. Résultats et Exemples

L'article illustre la méthode à travers plusieurs exemples concrets en R :

• Moyenne d'une colonne : Définition d'une classe mean_1st_col_df_is_4.6 soutenue par des prémisses telles que df_1st_col_no_missing (pas de valeurs manquantes), median_close_to_4.6 (distribution non décalée) et fivenum_no_outliers (pas d'outliers extrêmes). La création de l'objet final prouve que toutes ces conditions sont réunies.
• Fusion de données (Join) : Démonstration de comment définir une classe merged_dataset avec des contraintes strictes (nombre de lignes, colonnes, absence de NA). Cela permet de détecter immédiatement si une opération de fusion échoue silencieusement à cause d'incompatibilités de données (ex: "US" vs "USA").
• Régression Linéaire Simple : Construction d'une affirmation sur le coefficient de pente (1,79) soutenue par une hiérarchie de prémisses vérifiant l'absence de non-linéarité, l'absence d'outliers, et la validité visuelle des graphiques de résidus (via une validation interactive ou automatisée).

5. Signification et Impact

• Au-delà de la reproductibilité : Ce travail propose un changement de paradigme : passer d'une reproductibilité dynamique (exécuter le code) à une vérifiabilité statique (prouver la logique). Cela permet de valider la qualité d'une analyse même sans accès aux données brutes.
• Amélioration de la rigueur scientifique : En obligeant les analystes à formaliser leurs attentes et leurs preuves, le cadre réduit l'ambiguïté et favorise une communication plus claire des arguments statistiques.
• Lien avec d'autres domaines : L'auteur établit un parallèle intéressant avec le principe « propositions comme types » (Propositions as Types) en informatique théorique et avec les arbres de défaillance (Fault Trees) utilisés en ingénierie des systèmes, suggérant que les statistiques pourraient bénéficier de ces outils de modélisation de risque.
• Limites et perspectives : L'auteur reconnaît que l'implémentation actuelle (S4) est verbeuse et coûteuse en termes de code. Cependant, il suggère que l'objectif n'est pas d'améliorer la qualité intrinsèque de l'analyse par l'outil, mais de fournir une représentation transparente du raisonnement, ce qui est crucial pour l'évaluation par les pairs et l'amélioration future des pratiques statistiques.

En résumé, Roger D. Peng propose une architecture formelle pour transformer les analyses de données en preuves logiques vérifiables, comblant le fossé entre le code exécuté et le raisonnement humain qui sous-tend les conclusions scientifiques.