Connexion
Abonnez-vous

L’ouverture du code source d’Ines fait grincer des dents

Le monstre du Loch Ines

L'ouverture du code source d'Ines fait grincer des dents

Le 06 juillet 2016 à 15h10

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.

« 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 ! »

ines adullact

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)

Vous devez être abonné pour pouvoir commenter.

Abonnez-vous
votre avatar

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.

votre avatar







Xaelias a écrit :



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.





Si l’INSEE et le ministère des Affaires sociales n’ont pas les moyens d’avoir un serveur… Bha, on est mal barré.







Xaelias a écrit :



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.





Si ça change quelque chose. Les issues, le wiki, eux ne sont pas facilement « backuppable », il faut que tu face entièrement confiance pour Github tout ce qui n’est pas git. En tout cas, c’est une des raisons qui fait que dans ma boîte on est passé sur un Gitlab. Puis c’est hyper simple à maintenir : ça se fait via le gestionnaire de paquets. Puis je suis désolé, stocker tout le « savoir » dans un seul pays, pour moi ce n’est pas une bonne chose.


votre avatar

Ah. Quelle horreur!

Des accents et des espaces dans les noms de fichiers&nbsp;<img data-src=" />

votre avatar

Oh ça passe très bien maintenant avec Linux et Windows. On est au 21e siècle et on fonctionne à l’unicode maintenant !

votre avatar

avec des&nbsp;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.

votre avatar

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&nbsp;<img data-src=" />

votre avatar

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.

votre avatar

C’est pas le problème c’est une question de principe.

votre avatar

Quelle horreur ! Ca s’enregistre dans un répertoire nommé “Mes documents.” <img data-src=" />

votre avatar

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.

votre avatar

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.

votre avatar

Du code en français je vais vomir…

&nbsp;

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….

votre avatar

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

votre avatar

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.



&nbsp;[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]



&nbsp;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.

votre avatar

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 <img data-src=" />

votre avatar

C’est à peu près le sens de ma remarque. :-)

votre avatar







XMalek a écrit :



Du code en français je vais vomir…







Pour du franco-français, perso que ça soit en français c’est parfois beaucoup mieux. Parce que quand tu es sur des règles de gestions spécifique à la France où il faut chercher une traduction qui n’existe pas ou qui ne n’aura de toute façon pas le même sens… Dans le cadre d’un code internationale, c’est évident qu’en français ça ne passera pas. Perso, mes scripts perso, je me fais pas chier à les coder en anglais.


votre avatar

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.

votre avatar

C’est juste que c’est dur de se détacher des vielles habitudes :)

votre avatar

La qualite du code est pas terrible

votre avatar

Si l’on corrige le code, ils prendront cela en compte? <img data-src=" />

L’ouverture du code source d’Ines fait grincer des dents

  • Une démarche « vaine et maladroite »

  • L’administration invitée à suivre les bons exemples

Fermer