Ouverture des codes sources au sein du Département des outils d'aide à la décision

28 septembre 2022

A. L'Hôte, E. Jeangirard

Département des outils d'aide

à la décision - SIES - MESR

Notre situation

  • Nombreux projets interconnectés
  • Plusieurs contributeurs travaillant simultanément
    • sur différentes parties du code source
    • depuis des lieux différents (Mirabeau, Descartes, télétravail, prestataires)
  • De plus en plus de collaborations hors du MESR (établissements, ANR notamment)

Ce que l'on a mis en place

dataesr github
  • Chaque repo correspond à un module (le plus générique possible), pas à un projet
  • Une organisation github : https://github.com/dataesr avec :
    • 32 repos publics, 10 contributeurs
    • Mécanisme de validation avec pull request (PR) quand nécessaire
    • Github actions pour aider au développement continu (CI/CD)
    • Utilisation des issues pour suivre publiquement les bugs et les évolutions

Les bénéfices que nous en retirons

  • Utilisation de Github et ses outils ...
    • Travailler ensemble sur un même projet
    • Fluidifier les passations des compétences
    • Documentation et mémoire commune
  • ... avec des repo publics
    • Incitation à produire du code modulaire, lisible et sécurisé
    • Visibilité et reconnaissance du travail effectué
  • Et aussi ré-utilisation de code source ouverts par d'autres !

L'ouverture du code source n'est pas un processus binaire

mais révèle un continuum de possibilités :

  1. Fichiers sur un ordinateur personnel (pas d'ouverture)

  2. Fichiers partagés sur NAS

  3. Utilisation d'un outil de versionning (idéalement git)

  4. Plusieurs contributeurs internes sur un repo privé

  5. Repo publics avec uniquement des contributeurs internes

  6. Plusieurs contributeurs internes et externes

L'ouverture du code source n'est pas suffisante

dans une démarche de transparence et d'incitation à la ré-utilisation, mais doit s'accompagner d'efforts supplémentaires:

  • Ouverture des données

  • Conteneurisation du code pour facilité la reproductibilité

  • Mise à disposition de services (API, interfaces de démo)

  • Communication didactique et adaptée autour des méthodes et algorithmes utilisés

Retour d'expérience sur nos repos 'internes'

  • Plus facile de commencer directement avec un repo public : enjeu de sécurité et de modularité dès le début
  • Le code n'est pas et ne sera jamais parfait, la documentation non plus
  • Les outils techniques ne se substituent pas aux échanges humain, surtout à l'oral
  • Maîtrise inégale des outils parmi les agents, mais montée en compétence en fonction des besoins et usages respectifs

Retour d'expérience sur notre repo 'externe'

  • Au delà de la transparence et du partage, la création de valeur commune est coûteuse, et il faut se fixer des règles de fonctionnement
  • Attentes parfois différentes entre la communauté et nos besoins propres
  • Maintenance, correction de bug
  • Animation de la communauté

Nos points d'amélioration

  • Certains repos ne sont pas ouverts
  • D'autres contiennent du code mort : un seul commit sans plus de mise à jour
  • La documentation peut être améliorée : autour du code et à l'intérieur
Code source de la présentation ouvert sur https://github.com/dataesr/presentations
qui est un fork de la library open source reveal.js