Le 14 juin dernier, l’INSEE et le ministère des Affaires sociales annonçaient fièrement l’ouverture du code source de leur modèle de simulation « Ines ». L'opération a toutefois fait grincer les dents de nombreux développeurs, en raison des conditions d’accès aux fameux fichiers... Explications.
Pour accéder au code source d’Ines, qui sert à établir des projections portant sur les prélèvements sociaux et autres prestations de type RSA ou allocations familiales, l’INSEE et la Direction des études du ministère des Affaires sociales et de la santé (DREES) demandent aux internautes intéressés de passer par une forge hébergée par l’association Adullact : « adullact.net/projects/ines-libre ». Après avoir créé un compte – passage obligé – et activé correctement celui-ci, l’utilisateur doit expressément demander à rejoindre le projet (lien sous la liste publique des membres du projet).
Une barrière qui a suscité incompréhension et irritations, exprimées notamment sur Twitter.
Ouvrir les sources tout en contrôlant qui les consultent et comment elles sont utilisées, ça ressemble beaucoup à de l'#OpenWashing @InseeFr
— Cyril Brulebois (@CyrilBrulebois) 15 juin 2016
« On voit clairement qu’il y a la volonté de partager, de jouer le jeu du libre. Sauf que leur démarche est maladroite : le fait qu'il faille l'autorisation de l'administrateur du projet pour accéder aux fichiers, c'est terriblement lourd... Même si globalement on ne peut pas qualifier ça de mauvaise intention » commente un développeur chevronné.
Une démarche « vaine et maladroite »
Comment expliquer ce choix pour le moins curieux, à l’heure où certaines administrations optent pour une ouverture davantage en ligne avec les bonnes pratiques de l’open source ? « Nous souhaitons notamment connaître la liste des personnes qui consultent notre projet sur cette plateforme », explique l’équipe en charge du modèle Ines. « Toutes les demandes reçues sont traitées dans un délai de l'ordre de quelques minutes en semaine, et elles sont toutes acceptées », insiste-t-on.
« C'est un peu idiot, parce qu'une fois que tu as accès au code source, tu peux très bien le cloner et le mettre dans un git public et tout le monde y aura accès... » soupire un autre spécialiste de l'informatique, également sollicité par nos soins. « Pour moi, c'est de la maladresse et en plus c'est vain ! »
Il n’aura d’ailleurs fallu que quelques jours avant qu’un développeur ayant eu accès au fameux code source, Emmanuel Raviart, prenne l’initiative de le mettre en ligne sur FramaGit (voir ici). « Disons que cette déportation est un pis aller temporaire, le temps que les problèmes techniques d'accès au code source d'Inès soient résolus » nous explique l’intéressé – qui fut tout particulièrement impliqué dans le développement d’OpenFisca, un logiciel libre de simulation similaire.
« L'ouverture au libre du modèle Ines s'effectue dans le cadre des licences CeCILL V2.1 et OdBL. Rien n'empêche n'importe quel utilisateur de réutiliser le code source comme il l'entend, en respectant ce cadre juridique » concède-t-on à la DRESS.
L’administration fait néanmoins valoir qu’avoir accès au code source d’Ines sans la documentation proposée (en complément) sur la forge de l’Adullact se révèle « en réalité contre productif en raison de la complexité d'un tel outil ». Mais pour notre premier expert, cet argument est « complètement bidon » : « Le fait qu’un code source soit mal ou pas documenté, ça n'a jamais été une raison pour encadrer ou limiter sa diffusion. Même si c'est très compliqué, abscons, obscur... c’est du code source ! »
L’administration invitée à suivre les bons exemples
S’il n’y au final rien de trop dramatique, certains ne voudraient pas que ce genre de situation se reproduise à l’avenir, l’heure étant à l’ouverture de plus en plus de codes sources « publics »... L’Association de promotion du logiciel libre (April), par la voix de son délégué général Frédéric Couchet, se félicite ainsi de « la volonté politique » ayant conduit à l’ouverture du modèle Ines, mais demande aux responsables publics de « faire attention à être bien accompagnés, pour éviter des maladresses qui pourraient finalement être contre-productives ».
Les « bonnes pratiques » déployées par la Direction interministérielle au numérique (DINSIC), notamment lors de la libération du code source du logiciel de calcul de l’impôt sur le revenu, seraient ainsi à suivre – avec des fichiers accessibles à tous, sans enregistrement préalable, sur GitHub.
Commentaires (21)
#1
C’est juste que c’est dur de se détacher des vielles habitudes :)
#2
La qualite du code est pas terrible
#3
Si l’on corrige le code, ils prendront cela en compte?
" />
#4
Ah. Quelle horreur!
" />
Des accents et des espaces dans les noms de fichiers
#5
Oh ça passe très bien maintenant avec Linux et Windows. On est au 21e siècle et on fonctionne à l’unicode maintenant !
#6
” avec des fichiers accessibles à tous, sans enregistrement préalable, sur GitHub.”
Ça serait tout de même mieux sur un site en français ! C’est même un minimum.
#7
Github c’est quand même la plateforme de prédilection pour déposer du code open-source hein… Si t’es dev et que tu comprends pas l’anglais, je te souhaite bon courage dans ta carrière 
" />
#8
Ils ont déjà été jusqu’à inventer un langage de script en Français, faut pas exagérer non plus.
Surtout pour ce qu’on y gagne en compréhension. C’est aussi imbitable que la feuille d’Impôt même la ou ils pouvaient renommer les variables ils ont mis des acronymes.
#9
C’est pas le problème c’est une question de principe.
#10
Quelle horreur ! Ca s’enregistre dans un répertoire nommé “Mes documents.”
" />
#11
Le jour où un français fera un truc mieux que github on en reparle. En attendant, GitHub marche super bien, et on est en 2016. La mondialisation on est pas en train de découvrir, à un moment faut appliquer.
#12
J’ai lâché Github pour Gitlab. Je préfère avoir le contrôle de mes repos, même si c’est open source, que tout refiler au ‘ricain.
#13
Du code en français je vais vomir…
Sinon utiliser des fichiers xls (et pas csv ou xslx) pour les paramètres, de l’obfuscation inutile, des variables qui ont aucun sens des tests refaits 70 fois dans une boucle.
Bref du code d’étudiant / chercheur, clairement pas un code que j’oserai mettre sur le net. Bon après ca utilise en plus un logiciel proprio derrière pour faire les analyses….
#14
Le code M est quand même vachement lisible pour de l’informatique de gestion.
Je m’attendais à un volume de règles plus conséquent, je suis un peu étonné de la taille de l’application
#15
Code M ? Machine code ?
Euh on en est loin là. C’est du language de script là (du SAS pour être précis), et je le redis très mal écrit.
[3615Mylife]
A chaque fois qu’on m’a dis ça le “c’est bien écrit pour de l’informatique de gestion”, j’ai en général du refaire les deux tiers du code pour éviter de bouffer des supers serveurs à 100% cpu juste pour faire des clotures de fin de mois.
[/3615Mylife]
Sinon si tu lis mon commentaire, il te faut un soft proprio pour le faire tourner. pour ca que ça pèse pas bien lourd.
#16
Langage M de la Dgfip : rien à voir avec l’autre.
" />
Et derrière c’est ‘ interprété ’ en python.
Sinon tu as un fichier readme pour bien commencer
#17
C’est à peu près le sens de ma remarque. :-)
#18
#19
Ouep mais dans ce cas-là on fait TOUT en français, un bout de l’un et un bout de l’autre c’est ignoble, et c’est casi tout le temps le cas du code crade, la rigueur ça commence par là, imo.
#20
Ah bah si t’as les moyens de les héberger c’est sûr. Après tout le monde n’a pas un serveur pour le faire :-) Ou l’envie de gérer les backups, la config, la sécurisation etc. etc.
De plus, si utilises la partie publique de github, tu refiles rien aux américains aux particuliers. C’est aussi le principe de github, avoir du code dispo pour tout le monde. Ça change pas grand chose que ce soit US ou FR du coup.
#21