De `simulation_finale_v2_matin.zip` à une industrialisation de ta recherche

Le 23 mai 2026, j’ai eu le plaisir d’animer une session pour les jeunes chercheurs (doctorants, postdocs) lors du colloque CSMA Junior 2026 à Giens (Var). L’objectif de cette rencontre était de parler ouvertement d’un sujet parfois tabou mais pourtant si universel : l’organisation – ou plutôt le chaos – logiciel dans la recherche en calcul scientifique et mécanique numérique.

L’exposé original s’intitulait « De simulation_finale_v2_matin.zip à une industrialisation de ta recherche ». Ce titre, c’est un clin d’œil à nos pires travers en thèse ou en postdoc. On a tous un jour perdu une journée entière (voir beaucoup plus) à se demander : « Comment j’ai généré cette courbe dans mon papier de l’an dernier ? ».

Pourtant, sortir de ce chaos ne demande pas de se transformer en ingénieur système ou en gourou du DevOps du jour au lendemain. C’est une démarche progressive, pragmatique, qui tient en une échelle de maturité de six niveaux.

L’industrialisation logicielle d’un workflow scientifique n’est pas une corvée d’ingénieur ennuyeuse. C’est une part intrinsèque du métier de chercheur dès lors qu’un prototype produit des résultats que l’on veut conserver, partager, refaire ou publier.

Car en réalité : Ce n’est pas le ZIP. C’est ce qu’il cache.

Les conséquences du “Research Chaos”

Lorsqu’on développe dans l’urgence d’une publication ou d’un rendu de projet, la désorganisation s’installe vite. Ce désordre a deux types de conséquences symétriques :

Scientifiques : Perte de temps à refaire ce qui tournait déjà, perte de connaissance au départ d’un membre de l’équipe, manque de capitalisation et figures impossibles à régénérer.
Humaines : Frustration, colère devant le terminal qui renvoie des erreurs cryptiques, déprime de voir son travail s’évaporer.

Ranger son code et son workflow, ce n’est pas uniquement pour la rigueur scientifique de l’éditeur ou des relecteurs, c’est avant tout pour soi et pour son propre confort de recherche. Chaque pipeline propre construit aujourd’hui devient un actif précieux pour demain.

Les 6 niveaux de maturité logicielle en recherche

Pour progresser sans se décourager, voici une grille de lecture réaliste. Identifiez où vous vous situez actuellement, et visez simplement le niveau supérieur.

Niveau 1 : Ne pas perdre l’historique (Git et commits propres)

Le premier symptôme du chaos, c’est le dossier encombré de fichiers du type run_v1.py, run_v2_modifs.py, run_final.py, simulation_finale_v2_matin.zip. Le problème de cette méthode, c’est qu’elle n’offre aucun historique fiable ni repère temporel.

Adopter Git est la première étape indispensable. Non pas comme un outil complexe de gestion de versions, mais comme un véritable assistant à la réflexion scientifique.

Considérez chaque commit comme une note dans votre journal de bord de recherche. Un bon commit documente un changement d’hypothèse physique, une correction de formule ou un nouveau paramètre. Par exemple :

feat: Ajout de la loi de comportement hyperélastique pour la poutre
fix: Correction du facteur de conversion d'unités (Pa vers MPa)
test: Ajout du cas de comparaison analytique

Ces messages précis traduisent l’évolution de votre démarche scientifique et vous libèrent de la charge mentale d’avoir à vous souvenir de chaque ligne modifiée.

Niveau 2 : Pouvoir relancer (README et commandes claires)

Le signal d’alarme de ce niveau est simple : devoir expliquer de vive voix à un collègue (ou à soi-même six mois plus tard) les huit commandes manuelles à exécuter dans le bon ordre pour lancer le script de post-traitement.

Le remède ? Rendre explicite ce qui est dans votre tête.

Un fichier README.md minimal mais rigoureux à la racine de votre projet doit faire office de carte au trésor. Il doit décrire sans ambiguïté :

Comment installer rapidement le projet.
La commande exacte pour lancer un calcul de test.
La méthode pas à pas pour régénérer la figure principale de votre article.

Niveau 3 : Reproduire l’environnement (Gestion des dépendances)

La douleur associée ici est le fameux : « Ça marche uniquement sur ma machine ». En calcul scientifique, on dépend d’un écosystème fragile : versions de Python, de bibliothèques (NumPy, SciPy), de compilateurs (gfortran, GCC), de solveurs externes (comme code_aster) ou de modules installés sur un cluster HPC.

Il n’y a pas d’outil magique unique, mais plutôt une collection de solutions adaptées à chaque contexte :

En pur Python : Privilégiez des outils ultra-rapides et modernes comme uv (par Astral), combiné à un fichier standardisé pyproject.toml pour verrouiller vos versions de bibliothèques.
En Fortran/C++ scientifique : Tournez-vous vers Conda, Pixi ou Spack qui gèrent très bien les dépendances de bas niveau et les variantes de compilation.
Sur cluster ou pour diffusion : Les conteneurs comme Docker (pour votre machine) ou Apptainer / Singularity (très populaires en HPC pour s’affranchir des privilèges root) permettent d’embarquer tout votre système avec vous.

Niveau 4 : Vérifier (Les tests comme filet de sécurité)

C’est la peur de modifier le code de peur de « casser » un résultat obtenu il y a trois mois. Pour s’affranchir de cette angoisse, il faut poser des filets de sécurité automatique : les tests.

« On ne teste pas du code pour le plaisir de coder. On teste pour acheter de la confiance dans les résultats scientifiques. »

En calcul numérique, ces tests peuvent prendre des formes très élégantes et concrètes :

La solution analytique : Comparer votre sortie numérique à une solution exacte connue (par exemple sur un cas simple de poutre en traction élastique).
La non-régression : Sauvegarder les résultats d’une simulation stable dans un fichier de référence (reference.ref.csv). Votre test exécute le code, génère un nouveau CSV et compare les valeurs avec une tolérance numérique rigoureuse via np.testing.assert_allclose.
Les invariants physiques : Vérifier des ordres de grandeur ou des principes de conservation (conservation de la masse, énergie positive, etc.).

⚠️ Vérification ≠ Validation

C’est une distinction conceptuelle fondamentale en calcul scientifique :

La Vérification répond à la question : « Résout-on correctement les équations mathématiques ? ». C’est une affaire de bugs, d’implémentation et de convergence numérique. C’est l’objectif de vos tests unitaires et de non-régression.
La Validation répond à la question : « Le modèle mathématique choisi représente-t-il fidèlement la physique ? ». C’est une confrontation aux données expérimentales et aux domaines de validité.

Pour avancer sereinement, l’automatisation de la vérification est un prérequis non négociable. Des frameworks comme pytest se chargent de découvrir et d’exécuter ces vérifications de manière totalement transparente.

Niveau 5 : Orchestrer (L’automatisation avec des workflows)

À ce stade, vous commencez à réaliser des études paramétriques ou des étapes successives de pré-traitement, calcul et post-traitement. Lancer chaque étape à la main devient fastidieux et source d’erreurs d’inattention.

La solution consiste à utiliser un outil d’orchestration de tâches qui va matérialiser votre pipeline sous forme de DAG (Graphe Orienté Acyclique). Un outil comme Snakemake (très implanté en science) ou de simples fichiers GNU Make vous permettent de décrire les relations de cause à effet : « Pour produire cette figure, j’ai besoin de ce CSV d’agrégation, qui lui-même nécessite d’avoir lancé 10 simulations RVE avec différentes tailles de mailles ».

Grâce à un système intelligent de vérification des dates de modification des fichiers (timestamps), l’orchestrateur ne recalcule que ce qui a changé. Si vous modifiez uniquement le script de tracé, Snakemake ne relancera pas les 10 heures de calcul sous-jacentes, il régénérera instantanément la figure finale.

Niveau 6 : S’assurer que ça dure (L’intégration continue CI/CD)

Le niveau ultime consiste à déléguer complètement la surveillance à un serveur tiers. Grâce aux plateformes comme GitHub Actions ou GitLab CI, chaque fois que vous poussez votre code (git push), une machine virtuelle neutre s’initialise à la volée.

Elle installe votre environnement propre (uv sync), exécute l’intégralité de vos tests (pytest), et valide que vos pipelines de calcul (Snakemake) tournent sans erreur. Si vous avez introduit une régression par inadvertance, vous recevez immédiatement une alerte par mail.

Conclusion : Une marche après l’autre

L’industrialisation de votre recherche n’est pas un objectif où tout doit être parfait immédiatement. C’est un voyage progressif.

Si vous appliquez aujourd’hui de manière systématique Git (Niveau 1) et un README clair (Niveau 2), vous aurez déjà accompli 80% du chemin pour vous épargner des maux de tête et garantir la pérennité de vos travaux. Les outils modernes comme uv ou Snakemake sont là pour vous aider à automatiser le reste, libérant ainsi votre esprit pour ce qui compte vraiment : les idées.