# La vitrine et l'envers du décor : le document computationnel

Choix de l'outil : **Jupyter** (et Emacs/Org mode)


## Difficultés rencontrées lors d'une tentative de reproduction

- Manque d'informations (sources et données)
- Non explication des choix (protocoles expérimentaux, données conservées/conservées, méthodologie
  statistique, ...)
- Erreurs induites par les ordinateurs
    - outils à interface graphique pouvant cachant le fonctionnement interne
    - tableurs
    - outils complexes (boites noires) mal maîtrisés
    - bogue dans les programmes "maison"
- Manque de rigueur et d'organisation
    - non sauvegarde des données
    - pas de gestion de version (historique)
    - pas de manque de contrôle qualité
- Dimension culturelle et sociale
    - un article n'est qu'une version simplifiée

## Idées reçues sur le "tout public"

- Les faiblesses deviendront évidentes
    - ne pas pouvoir tricher ne devrait pas être un argument
- Quelqu'un peut trouver une erreur
    - tout le monde en fait
    - la correction des résultats est plus importante
    - tirer avantage à ma place (tirer avantage = des citations, montrer ce qu'on fait c'est se
      rendre visible)
    - les données sensibles n'ont pas besoin d'être partagées à "tout le monde" et/ou de façon
      "claire"

## Outils, formats, services

**Préférer le libre / open source**

- formats de fichiers : markdown, orgmode, CVS, HDF5, ... (rester simple)
- langage/outils de programmation : scilab, R, Python, ...
- plateforme de stockage : gitlab/github, framadrop, ...
- ne pas tomber dans le piège des outils *trop* intuitifs (tableurs, interfaces
  graphiques/interactives, ...)


## Principes
- Permettre une transparence la plus complète possible
- Une publication est la partie visible de l'iceberg.
- Avoir un seul document (explications, code, résultats)
- Inspection et ré-execution


<!-- vim: spelllang=fr
-->