Discussion :

[Stan Adkens]

France : le Sénat réclame à nouveau le « code source » de chaque projet de loi de finances
Mais, la requête semble encore impossible à satisfaire

Comme l’année dernière à la même période, le Sénat français a adopté cette année encore un amendement obligeant l’administration fiscale à dévoiler, pour chaque projet de loi de finances, le « code source » traduisant les réformes proposées par l’exécutif. Toutefois, comme ce fut le cas l’an dernier, le nouvel amendement pourrait être annulé par les députés sur avis du gouvernement.

En France, le principe de la communication des « documents administratifs » sur simple demande est déjà prévu depuis l’entrée en vigueur de la loi Numérique. Dans l’article 2 de cette loi, il est annoncé l’ouverture par défaut du code source des programmes utilisés par les administrations, avec une limite compréhensible. Cette communication au public peut être empêchée s’il y a un risque d’atteinte « à la sécurité des systèmes d’information des administrations ».

Toutefois, la mise en pratique de cette disposition relève pour l’instant des initiatives très ponctuelles, selon un communiqué du sénateur Vincent Éblé (PS), président de la commission des finances du Sénat, en décembre 2017 : « seules des initiatives très ponctuelles ont eu lieu en matière de mise à disposition d’algorithmes publics ».

En effet, en octobre 2016, l'Éducation nationale a communiqué une partie de l'algorithme admission post-bac. Longtemps réclamé par l’association Droits des Lycéens, l’algorithme qui répartit les lycéens qui viennent d’obtenir leur bac dans les universités, avait enfin été mis à disposition du public, mais en format papier, et le code source publié était partiel : seule la partie qui couvre la « génération automatique de classements aléatoires en production, pour les formations non sélectives » avait été publié.

En janvier 2017, la Direction générale des finances publiques (DGFiP) avait également rendu public le simulateur 2017 de l'impôt sur le revenu et avait mis son code source sur GitHub. En septembre dernier, sous la pression d'une association, Bercy a ouvert les codes sources des modèles économétriques Mésange, Opale et Saphir. Au cours du même mois, Bercy a, également, publié le code source du calculateur de la taxe d'habitation.

Selon le site Web du sénat français, le sénateur Vincent Éblé est revenu à la charge, lundi 10 décembre, comme l’an dernier pour soutenir encore une fois l’amendement de publication du « code source » de l’exécutif en matière de la loi de finances. Selon le sénateur socialiste ce manque de données ne permet pas aux parlementaires de « faire travailler leurs équipes sur un certain nombre de simulations », par exemple de mesurer l'incidence de la modification de tel ou tel paramètre d'une réforme fiscale.

L’amendement du sénateur a proposé, que le gouvernement publie, lors de la présentation annuelle du projet de loi de finances, un ensemble d’informations qui pourra permettre au législateur de débattre du budget en toute connaissance de cause.

L’amendement 2019 du sénateur Vincent Éblé prévoit la mise à la disposition du contribuable et du législateur, pour « chaque imposition de toute nature modifiée » :

• Des « données synthétiques » et « hypothèses retenues pour évaluer les conséquences économiques, financières, sociales et environnementales » de la réforme en question, ainsi que les « coûts et bénéfices financiers attendus » pour « chaque catégorie d’administrations publiques et de personnes physiques et morales intéressées, en indiquant la méthode de calcul retenue »;
• Du « code source » correspondant à « l’ensemble des dispositions législatives et réglementaires en vigueur pour cette imposition », assorti des « instructions et circulaires publiées par l’administration qui portent sur cette imposition »;
• Du « code source correspondant aux dispositions législatives proposées et, à titre facultatif, aux dispositions réglementaires, instructions et circulaires envisagées ».

L’amendement demande à ce que toutes ces données soient publiées « dans un standard ouvert, aisément réutilisable et exploitable par un système de traitement automatisé », conformément aux principes de l’Open Data, afin de permettre au contribuable d’exploiter ces information à des fins utiles, y compris pour des travaux de recherches.

Enfin, l’amendement demande que chaque année, soit élaborée et publiée une « annexe explicative contenant le code source traduisant, en langage informatique, chacune des dispositions du projet de loi de finances relatives à l’assiette ou au taux des impositions de toutes natures ».

Le sénateur Vincent Éblé est revenu sur l’annulation par les députés de son amendement de 2017. « L'Assemblée nous a enfermé dans une législation à tâtons, pour ne pas dire à l'aveugle, alors que nous, nous voulons légiférer (...) sans avoir forcément à solliciter de façon itérative l'administration fiscale pour leur demander des simulations qui nous permettent d'apprécier des dispositifs fiscaux qu'on nous propose de voter ou que nous-mêmes nous voulons infléchir. Je pense que c'est une modernisation de la façon de travailler qui serait bonne pour le Parlement, et donc bonne pour le pays. »

Cependant, le sénateur risque de se répéter en 2019, car bien que le rapporteur général du projet de loi de finances, Albéric de Montgolfier, ait donné un avis favorable à son l’initiative, le secrétaire d’État Olivier Dussopt, au nom de l’exécutif, s’y est quant à lui opposé. « … sur le principe, nous sommes évidemment plutôt d'accord », a-t-il d’abord déclaré, avant d’ajouter : « Mais il se trouve qu'au moment où nous publions la loi de finances, les codes sources ne sont pas encore développés. Donc matériellement, nous ne savons pas répondre à votre demande ».

L’année dernière, la publication n’avait pas été possible parce que le gouvernement avait trouvé l’amendement « irréaliste », car, non seulement, les mesures fiscales n’étaient pas encore transcrites en code informatiques avant l’adoption de la loi de finances 2017, mais aussi, la transcription pouvait prendre « six à neuf mois ».

L’Administrateur général des données et ex-dirigeant de la Direction interministérielle au numérique (DINSIC), Henri Verdier, lors d’une audition en mai par la commission des finances du Sénat, a insisté sur la nécessité d’accompagner les administrations « dans une culture de publication du code » : « Les gens du logiciel libre savent faire, ils connaissent les outils, ils savent documenter leurs codes. Ceux qui n'ont jamais travaillé ainsi, eux, sont un peu dépourvus. » Selon l’Administrateur général, il faudrait attendre « quelques années » avant que ce « travail d'éducation et d'accompagnement » porte ses fruits.

Source : Amendement, Comptes rendus de la commission des finances

Et vous ?

Qu’en pensez-vous ?
Quelle est votre opinion sur la mise en ligne du code source des programmes utilisés par les administrations ?

Lire aussi

France : le simulateur 2017 de l'impôt sur le revenu est mis en ligne par la DGFiP, son code source écrit en M est disponible sur GitHub
L'Éducation nationale envoie une partie de l'algorithme admission post-bac... sur format papier, Droit des lycéens demande de l'aide pour l'analyser
Bercy ouvre les codes sources des modèles économétriques Mésange, Opale et Saphir, sous la pression d'une association
Bercy publie le code source du calculateur de la taxe d'habitation, la DGFiP a choisi C comme langage, mais la qualité du code est remise en question
France : combien d'impôts ont payé les GAFA dans l'Hexagone en 2017 ? Facebook promet du changement au courant du premier semestre 2019

[ijk-ref]

(…)« Mais il se trouve qu'au moment où nous publions la loi de finances, les codes sources ne sont pas encore développés. Donc matériellement, nous ne savons pas répondre à votre demande ».

L’année dernière, la publication n’avait pas été possible parce que le gouvernement avait trouvé l’amendement « irréaliste », car, non seulement, les mesures fiscales n’étaient pas encore transcrites en code informatiques avant l’adoption de la loi de finances 2017, mais aussi, la transcription pouvait prendre « six à neuf mois ».

La solution est simple pourtant : ne PAS adopter de loi tant qu'elle n'est pas transcrite en code. Car à mon avis un texte de loi peut facilement être interprété de plusieurs façons. Contrairement à une version informatisée qui lui par définition n'a qu'un seul et unique sens.

Le "six à neuf mois" j'ai bien l'impression qu'il ne veut rien dire d'autre "on ajustera les chiffres des prélèvements au dernier moment… rien à péter du texte de loi on lui fait dire ce que l'on veut"

Ce qui justement devrait être tout à fait illégal d'où la réclamation du sénat allant dans le bon sens.

[Angelsafrania]

Il serait bien que tous logiciels développés pour ou par l'administration/gouvernement soit obligatoirement mis à disposition en "open source".
Bon après on va me dire "oui, mais les systèmes de guidage laser des missiles ils ont pas a être disponible publiquement".
Pour répondre à cela il faut mettre une exception pour la défense (comme à chaque fois d'ailleurs).

Ça permettrais à chacun d'aller voir les erreurs et incohérence du code pondu par des société privé avec notre argent. De proposer des corrections, de bannir certaine entreprise qui écrivent du code de merde.

Mais bon si on doit mettre à jour toutes les conneries déjà faite actuellement et mise en production, l'état français va avoir beaucoup de travail pour tout assainir et corriger (sans parler du fait que certain codes sont potentiellement volontairement malveillants / faux / erronés).

C'est un peu la même chose qu'on veux que le timide développement de l'open data au niveau institution.

Mais bon pour le moment c'est juste une discussion entre érudit et ça le restera certainement toujours.

[Supernul]

Je reprends la même citation que ijk-ref :

(…)« Mais il se trouve qu'au moment où nous publions la loi de finances, les codes sources ne sont pas encore développés. Donc matériellement, nous ne savons pas répondre à votre demande ».

L’année dernière, la publication n’avait pas été possible parce que le gouvernement avait trouvé l’amendement « irréaliste », car, non seulement, les mesures fiscales n’étaient pas encore transcrites en code informatiques avant l’adoption de la loi de finances 2017, mais aussi, la transcription pouvait prendre « six à neuf mois ».

Donc le gouvernement est en train de dire qu'il produit une loi de finance au pifomètre en se basant sur des postures idéologiques dont les effets ne sont pas vérifiés en amonts ? Hummm ... Je caricature mais ... Heuresement que la plupart sont des technocrates et non des pures politiciens.

Mais la non publication des codes ou leur publication partielle en dit autant voire plus que le code lui-même.

[walfrat]

Bof, des spécifications technique devraient suffire à savoir comment chaque élément d'un loi serait retranscrite.

Qu'il faut 6 à 9 mois pour retranscrire une loi dans un code qui fonctionnel en production cela ne me choque pas.

Le temps d'allouer le budget de spécifier, de concevoir, de développer, et surtout de valider point par point que tout les cas possibles sont pris en compte, de déployer, de revalider point par point tout les cas possibles.

Sinon vous pourriez demander une preuve de concept plus rapidement permettant de mesurer les impacts d'une loi, mais ne vous attendez pas à ce que le code source lui soit alors d'une grande qualité ou documenté.

Pour ceux qui gueule trop vite sur le code de merde, souvenez-vous de ce dernier projet où on a pris vos chiffrage et on les a taillé en deux car le client "n'avait pas le budget pour faire de la qualité". Le code de merde n'est qu'un symptôme causé par un ou plusieurs dysfonctionnement dans la chaîne.

[ijk-ref]

Bof, des spécifications technique devraient suffire à savoir comment chaque élément d'un loi serait retranscrite.

Ces spécifications technique existent-elles à la publication de la loi ?

[Pythalex]

El famoso code source HTML.

[koala01]

Sinon vous pourriez demander une preuve de concept plus rapidement permettant de mesurer les impacts d'une loi, mais ne vous attendez pas à ce que le code source lui soit alors d'une grande qualité ou documenté.

Ah bon

Tu aurais justifié le fait de ne pas demander de preuve du concept par le fait qu'elle risquait fort de n'être -- au mieux -- qu'une évaluation "à la grosse louche" parce qu'on risque d'oublier tel décime qui aurait du être pris en compte, de prendre en compte tel autre décime qui n'aurait pas du l'être, ou de se tromper quant à la valeur d'un coefficient quelconque, j'aurais pu être d'accord avec toi.

Mais la mise au point d'une preuve de concept ne suffit absolument pas à justifier l'écriture de code propre et intelligemment commenté!

Car soyons clairs : cela ne demande pas plus de temps d'écrire du code clair et correct que d'écrire du code imbuvable. J'aurais personnellement tendance à dire que cela en demande même moins.

Et, à titre personnel, je ne comprendrai qu'un développeur puisse estimer que la qualité de son code puisse être dégradée "parce qu'il ne fait que fournir une preuve de concept" qu'à une seule condition: s'il n'a jamais vécu une situation dans laquelle on lui demandait une POC pour lui dire par la suite que "ben, ca fonctionne comme cela, pourquoi devrait on le refaire " (donc, une situation dans laquelle son POC se retrouve en production "tel quel").

Autant dire que je ne l'accepterai que si c'est a toute première preuve de concept qu'on lui demande de fournir... Car n'importe qui ayant déjà eu à en fournir saura par expérience qu'elle risque de finir telle quelle en production

Pour ceux qui gueule trop vite sur le code de merde, souvenez-vous de ce dernier projet où on a pris vos chiffrage et on les a taillé en deux car le client "n'avait pas le budget pour faire de la qualité". Le code de merde n'est qu'un symptôme causé par un ou plusieurs dysfonctionnement dans la chaîne.

Tu n'as certes pas tort sur ce point.

Mais je refuse de considérer une preuve de concept mise en production comme l'une des raisons valables à ce "code de merde"!

[Citoyen-MDR]

Les nommés Supernul et Ijk-ref devaient être très fatigués pour avoir aussi peu réfléchi lorsqu'ils ont écrits leurs commentaires sur la disponibilité du code source aligné sur les lois. Je suppose qu'ils sont énormément plus réfléchis pour écrire du code.

Parce qu'en tant qu'informaticien mais avant tout en tant que citoyen, je leur signale quand même que leurs messages vont à l'encontre du principe fondamental de toute démocratie, qui est aussi le fondement de leur statut d'électeurs : une loi n'existe (et n'est donc applicable) qu'à partir du moment ou elle a été votée par une assemblée qui l'a discutée, acceptée et éventuellement amendée (et donc qui ne l'a pas rejetée).

C'est le principe à partir duquel s'explique l'indisponibilité des sources au moment du vote d'une loi, mais aussi la qualité médiocre du code, ce que je vais maintenant démontrer.

Je leur rappelle que la définition d'une tyrannie, ce sont des décisions "du seul fait du prince", c'est-à-dire de son caprice, que nul n'est autorisé à discuter.
Le pouvoir de refuser (vote de rejet) ou d'adoucir (amendements) a été confié à des assemblées de citoyens (démocratie directe difficile à mettre en pratique*) ou de leurs représentants élus à durée déterminée en conseils ou parlements représentatifs pour les collectivités plus nombreuses (Assemblée Nationale et Sénat constitient pour la République Française), pour éviter précisément les dérives extrêmes à la Daesh, à la Khaddafi ou à la Staline ou à la Franco.

En conséquence, avant le vote d'une loi, il n'existe qu'un projet de loi, c'est-à-dire légalement et constitutionnellement "du vent", mais très souvent une orientation quand même assez précise mais non encore stabilisée, donc au mieux une hypothèse de travail pour un développeur.

Il est dès lors évidents que la maîtrise d'ouvrage des services informatiques de la DGFiP ne peut rédiger des spécifications fonctionnelles définitives qu'après le vote (la loi étant elle-même une spécification précise du moteur de calcul de l'impôt, dans sa rédaction juridique, mais illisible par des développeurs **). Les développeurs ne peuvent adapter leur code que dans un second temps, lequel nécessite ensuite des tests très lourds, parce qu'il ne vous aura pas échappé que le législateur (nos élus) ne manque pas d'imagination et qu'il a prévu et accumulé dans le temps d'innombrables mesures qui rendent le Code général des impôts extrêmement complexe (au niveau mondial, la complexité des réglementations fiscales est en général fonction du niveau de démocratie et, dans une tyrannie, on a souvent des mesures beaucoup plus simples, mais aussi énormément plus incohérentes et injustes, du fait précisément de l'impossibilité de remettre en cause le "caprice du prince").

Dans un tel contexte, il va sans dire que les lois fiscales devant être appliquées dans les logiciels dans des délais très contraints, les développeurs chargés du moteur de calcul de l'impôt sur le revenu travaillent forcément sur les 2 critères ultra-prioritaires de "qualité" suivant : (1) fournir à temps un code qui (2) calcule correctement des impôts. Dans un tel contexte qui s'oppose aux pratiques "industrielles", les autres qualités qu'on peut attendre d'un code bien écrit sont tous sauf bloquants pour la mise en production (cohérence de nommage des variables, commentaires dans le code etc. logiquement signalés comme problématiques dans d'autres commentaires sur ce moteur de calcul).

Que dire des autres absurdités ? "Voter une loi à condition que le code source soit déjà disponible" ? Cela impliquerait soit que les lois fiscales soient votées au moins un an avant leur année de mise en application, ce qui restreindrait de fait la capacité d'adaptation des politiques au contexte socio-économique, soit que les administrations seraient en mesure d'appliquer une loi à l'instant-même où elle est soumise au vote, ce que les Français n'ont pas vu depuis l'ère nazie et l'Europe de l'Est depuis l'ère soviétique.
Quand une administration s'est mise en état de mettre en œuvre une mesure le jour où elle est soumise au vote, c'est qu'elle travaille indépendamment du Parlement, donc que le vote du Parlement n'est pas un vote, mais juste un enregistrement (on parle alors de Parlement croupion, ce qui était par exemple le cas dans les régimes de modèle bolchevique). Dans une logique extrême d'économie financière, on pourrait alors carrément le supprimer, l'une des premières mesures d'ailleurs du régime nazi en 1933...
Et non, l'administration fiscale n'utilise pas ce délai pour modifier des taux et des formules de calculs différents de ce que le législateur a voté. Ce serait extrêmement idiot car cela annulerait l'impôt pour toute personne qui en contesterait la légalité devant un tribunal ! Vous pouvez être sûr que ce qui est mis en production est conçu pour éviter ça et donc pour être rigoureusement fidèle à la loi telle que le Parlement l'a votée.

C'est donc une très bonne chose que les administrations ne travaillent que lorsque les parlementaires ont tranché les lois après les avoir débattues dans un cadre public.

Confrères développeurs, est-ce que vous ne percevez pas que ce débat parlementaire en matière de définition de la législation partage une logique commune avec les pratiques de tests par la maîtrise d'ouvrage et de pear review en matière de développement ?
La différence, c'est que la législation a un impact beaucoup plus important sur la vie des gens. Son processus de validation est donc beaucoup plus scruté, public***, et beaucoup plus lourd que pour du code et ceux qui sont chargés de la mettre en œuvre la législation (les administrations) ne peuvent être autorisés à travailler qu'en fonction de lois votées.

En espérant avoir été assez clair ...

---

* C'est possible dans des collectivités locales (on en voit en Suisse), mais on ne peut réunir tout un peuple en permanence...

** A vrai dire, le Code général des impôts est difficile à lire même pour les fiscalistes eux-mêmes, raison pour laquelle l'administration fiscale tient à jour, un guide pratique ("Précis de fiscalité", également consultable par tout un chacun dans la partie Documentation sur le portail impots.gouv.fr) pour son travail quotidien, qui présente sa reformulation opérationnelle de la législation courante et qui constitue déjà une forme de spécification plus lisible (mais le fondement légal reste le Code général de Impôts).

*** Le débat parlementaire n'est en aucun cas confidentiel et les critiques de l'opposition parlementaires sont souvent les premiers qui portent auprès du grand public (via les média) les inconvénients des projets de lois.