Justice : le code source d’un logiciel, document administratif communicable au citoyen

Justice : le code source d’un logiciel, document administratif communicable au citoyen

Ça coule de source

Avatar de l'auteur
Xavier Berne

Publié dans

Droit

14/03/2016 5 minutes
32

Justice : le code source d’un logiciel, document administratif communicable au citoyen

Le code source d’un logiciel développé par les services de l’État est-il un « document administratif » comme un autre, dès lors communicable par principe au citoyen qui en fait la demande ? Oui, vient de répondre le tribunal administratif de Paris. Explications.

Après quasiment deux ans de procédure, le ministère des Finances s’est résolu à ouvrir le 1er avril prochain le code source de son logiciel de calcul de l’impôt sur le revenu. Cette décision découle des débats autour du projet de loi Numérique, mais aussi – et surtout – du bras de fer engagé par un étudiant en économie qui réclamait de Bercy la communication de ce fichier informatique, considéré à ses yeux comme un document administratif au sens de la loi « CADA » de 1978.

En vertu de ce texte, les autorités administratives (ministères, collectivités...) sont tenues de répondre à la requête du citoyen qui réclame un document produit par leurs soins, quel qu’en soit la forme ou le support : délibérations, statistiques, rapports, études... En pratique, ce droit connaît néanmoins de nombreuses limites. Les services de l’État n’ont par exemple pas à dévoiler des informations qui relèveraient du secret défense, des fichiers préparatoires « non achevés », etc.

Bercy communique son code source juste avant que la justice l’y oblige

Invité par cet étudiant à dévoiler le code source de son logiciel de calcul de l’impôt sur le revenu, la Direction générale des finances publiques (DGFiP) a tout d’abord fait la sourde oreille. Face au refus implicite de l’administration fiscale, ce citoyen a alors saisi la Commission d’accès aux documents administratifs, qui lui a donné raison en janvier 2015. Bercy ne s’étant cependant pas décidé à communiquer son code source, ce jeune homme s’est finalement tourné vers le tribunal administratif de Paris, lequel a rendu sa décision suite à une audience en date du 18 février dernier – soit quelques jours après que le ministère lui ait communiqué de son propre chef le fichier désiré...

bercy

Le jugement rendu par la juridiction s’avère néanmoins important : il vient confirmer que ce code source était bel et bien un document administratif « communicable » au citoyen, par principe. Cette décision pourrait donc s’étendre à de nombreux autres codes sources développés par l’administration...

La juridiction a effectivement écarté tous les arguments présentés par le gouvernement pour justifier l’opposition de la DGFiP. Premièrement, Bercy soutenait que les directives de 2003 et 2013 sur la réutilisation des informations du secteur public s’opposaient à la communication de programmes informatiques. « Mauvaise lecture », a répondu en substance le tribunal administratif. À ses yeux, « il ne résulte pas de ces directives, qui portent sur la réutilisation des données et laissent inchangées les dispositions du droit national relatives à l’accès aux documents administratifs, que les programmes informatiques devraient être systématiquement exclus du droit d’accès aux documents administratifs organisé par la loi du 17 juillet 1978 ». Autrement dit, la législation européenne n’empêche pas un État membre d’enjoindre ses administrations à ouvrir leurs codes sources.

Deuxièmement, le ministère des Finances affirmait que son calculateur d’impôts ne pouvait entrer dans le champ de la loi CADA dans la mesure où il s’agissait d’un document « non achevé ». Et pour cause, le fameux logiciel est en « perpétuelle évolution » vu qu’il y a des changements tous les ans... Le tribunal a ici levé cette barrière en retenant que « si les programmes informatiques ont vocation à évoluer au gré des mises à jour, chaque version du code source d’un même programme informatique revêt le caractère de document administratif achevé et peut être communiqué dans cet état ». La juridiction a souligné à cet égard qu'une décision inverse aurait « priv[é] le justiciable d’un droit effectif à la communication des documents administratifs ».

Chaque dernière version d'un logiciel public est « communicable »

Résultat, « en l’absence de dispositions législatives ou réglementaires interdisant l’accès aux codes sources des programmes informatiques, le ministre des Finances et des comptes publics ne pouvait légalement refuser de communiquer le document demandé », conclut le tribunal administratif. Ce dernier a symboliquement annulé la décision de l’administration fiscale, tout en enjoignant Bercy à communiquer sous deux mois le code source de son logiciel de calcul de l’impôt sur le revenu des personnes physiques.

Le fameux fichier a été transmis au demandeur début février, et devrait être mis à la disposition de tous à partir du mois prochain grâce au travail de la mission Etalab (pour en savoir plus, voir notre article).

« Ce jugement, par lequel les juges renvoient Bercy à ses cours de droit, est très précieux car il servira de référence en cas d'affaires futures, réagit Frédéric Couchet, le délégué général de l’Association de promotion et de défense du logiciel libre (April). Espérons que cette règle de communication ne sera pas tuée dans l’œuf par l'amendement au projet de loi Numérique visant à créer une exception relative à la sécurité des systèmes d'information des administrations. » L’intéressé en profite pour remettre en cause la validité de certaines des analyses juridiques de Bercy, et plus précisément celle concernant l’utilisation des logiciels libres au sein de l’administration : « Nos doutes sur la qualité et la rigueur des arguments opposés ne s'en trouvent que renforcés. »

Écrit par Xavier Berne

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Bercy communique son code source juste avant que la justice l’y oblige

Chaque dernière version d'un logiciel public est « communicable »

Commentaires (32)


Et donc, il est écrit en quel langage ? Assembleur 360 ? COBOL ? PACBASE ? RPG ? Ça m’étonnerait que ce soit du JavaScript.


Vivement que le code source buggé sur logiciel Louvois d’attribution des paies de l’armée soit disponible. <img data-src=" />


franchement t’as pas envie de mettre le nez dedans à mon avis. <img data-src=" />

sans compter qu’il n’est pas produit par l’administration, donc ne constitue pas un document administratif.



par contre le code source des boites noires, on veut bien. <img data-src=" />








hellmut a écrit :



par contre le code source des boites noires, on veut bien. <img data-src=" />





if&nbsp; copainpolitocard

&nbsp;&nbsp; nologs = true



&nbsp;if&nbsp; PersonneDeL’opposition

&nbsp;&nbsp;&nbsp;&nbsp; PreparerFicheS()



L’image “Stock” avec V I R U S surligné en rouge :eek:


ah, et on veut bien aussi le code source de la PNIJ (même si c’est pareil que Louvois, pas dev par l’administration).

je suis d’ailleurs étonné qu’on ait pas d’actu à ce sujet sur NXI, c’est pourtant croustillant.<img data-src=" />


c’est bon t’es engagé par le gouvernement t’es un hacker, tu as découvert leur code secret. Prépares toi a rejoindre lélite de ce pays.

&nbsp;


C’est du&nbsp;langage M








Crysalide a écrit :



Vivement que le code source buggé sur logiciel Louvois d’attribution des paies de l’armée soit disponible. <img data-src=" />





<img data-src=" /><img data-src=" /><img data-src=" />









hellmut a écrit :



sans compter qu’il n’est pas produit par l’administration, donc ne constitue pas un document administratif.







t’es sûr de toi?

et pis, c’est pas si simple, il faut préciser ce que signifier “produit” ou “développé” par l’administration… Ce n’est pas parce que les pisseurs de code ne sont (peut-être?) pas fonctionnaires que Louvois n’est pas développé (conçu) par et pour l’administration.



Développer n’est pas coder. Développer, c’est d’abord rédiger des spécifications.





Sinon, je suis très curieux de savoir où tout ça va nous mener…. Quid par exemple lorsqu’un logiciel développé par une administration a une valeur marchande, en concurrence avec des logiciels du marché?

Bref, le droit doit être précisé….



les specs? ben les specs sont aussi des documents administratifs.

on parle bien de code source ici.



et sinon je doute fortement que l’armée ait rédigé les specs.

quand tu sous-traites tout ton SIRH à une boite privée, tu sous-traites aussi la spec à des consultants.

donc non, l’armée n’a sans doute (je ne peux être catégorique faute de preuve, mais bon) rien fait au niveau de la production de Louvois.

ils ont fait sans doute un peu de maitrise d’oeuvre (à priori c’est la DGA qui s’en est occupée suite à la débâcle) et des tests métier (qui ont du être rondement menés vu le bordel). ^^


Comment dire ce soft est une belle chiasse … et je sais de quoi je parle. Les différents corps armés se livrent une guerre sans merci. Les généraux, veulent chacun leur référentiel alors même que l’armée dispose d’une entité pour cela. L’information est donc éparpillée,non standardisé etc. une vraie catastrophe industrielle que notre armée, tu n’imaginesmême pas le niveau de bordel qui y règne. Des fichiers incomplets des erreurs dans les matricules, ou sinon un même matricule pour plusieurs personnes etc.



L’échec de&nbsp;Louvoi n’est que la partie visible du niveau de désorganisation interne de l’armée

&nbsp;

C’est tout simplement pitoyable








Tiebor a écrit :



Développer n’est pas coder. Développer, c’est d’abord rédiger des spécifications.







“Quand on est payé pour livrer un programme, la priorité c’est de pondre du code.”



3ème axiome fondamental de la théorie de la sous-traitance.



D’après ce que j’avais compris, l’échec de Louvoi est principalement lié au code réalisé par l’armée (donc les ESN sont contentes, pas de pénalités possibles), l’armée faisant en interne la partie la plus sensible.


Tu dois être environ la 43ème personne à faire cette blague sur ce site.

Au bout d’un moment, les commentaires de comptoir là où ils n’ont pas lieu d’être, c’est lourd. Y’a déjà les news sur le FBI, Cazeneuve et la NSA pour ça.


ah OK.



donc on peut avoir le code source siouplait?

lol. <img data-src=" />


le seul moyen c’est de mettre les specs dans les livrables.

seulement si personne les lit en face (et que ça se sait)…








Alpha Centauri a écrit :



D’après ce que j’avais compris, l’échec de Louvoi est principalement lié au code réalisé par l’armée (donc les ESN sont contentes, pas de pénalités possibles), l’armée faisant en interne la partie la plus sensible.





Pour être plus précis, l’armée a développé le noyau et le système de calcul. L’ESN appelée en renfort avait pour mission de faire l’habillage “client léger” et la mise en musique pour l’exploitation. Elle n’avait pas accès à ce noyau de calcul autrement que par les fichiers en entrée et en sortie.



&nbsp;









taxalot a écrit :



Tu dois être environ la 43ème personne à faire cette blague sur ce site.

Au bout d’un moment, les commentaires de comptoir là où ils n’ont pas lieu d’être, c’est lourd. Y’a déjà les news sur le FBI, Cazeneuve et la NSA pour ça.





Ca parle boite noire, ces boites noires ne fonctionnent pas sans logiciel donc il y a bien un code source.

De plus sur cette actu il n’ya pas il me semble surabondance de cette vanne.

Tu t’es levé du mauvais pied ce matin? Détend toi. <img data-src=" />



Voilà pourquoi tu ne seras jamais mon sous-traitant ! <img data-src=" />










hellmut a écrit :



les specs? ben les specs sont aussi des documents administratifs.



j’en sais rien. Peut-être. Et? Tu disais que Louvois n’est pas un doc adm. Je réponds que le ministère a peut-être fait les specs. Tu réponds que les specs sont des doc adm….. difficile de te suivre, mais j’ai l’impression que tu vas dans mon sens. <img data-src=" />







hellmut a écrit :



on parle bien de code source ici.



oui oui… et?







hellmut a écrit :



et sinon je doute fortement que l’armée ait rédigé les specs.



J’en sais rien.







hellmut a écrit :



quand tu sous-traites tout ton SIRH à une boite privée, tu sous-traites aussi la spec à des consultants.

donc non, l’armée n’a sans doute (je ne peux être catégorique faute de preuve, mais bon) rien fait au niveau de la production de Louvois.





Faux.

D’après ce que j’ai lu (sans approfondir le sujet), le coeur de Louvois (et ce qui a posé le plus de problèmes) est le moteur qui calcule les soldes, lequel a été développé par le ministère ! ( sur la base d’un logiciel de l’armée de l’air )

Donc, oui, l’armée a participé au développement de l’éco-système Louvois.

Et pour le reste, oui, certaines specs ont été sous-traitées à une assistance à maitrise d’ouvrage… et alors? ça change quoi au fond?








Zut, mon edit du message précédent n’a pas marché.



Je disais donc:




  1. tu affirmes donc des choses, tout en précisant ne pas être catégorique, alors même que les “preuves” qui te font défaut sont publiques et facilement accessibles (rapport parlementaire, rapport Cour des comptes, articles divers….)



  2. (certaines) specs seraient sous-traitées… et alors, ça change quoi au fond? qu’entends tu exactement par “sous-traiter” ? cette question renvoie en fait à ma question initiale: que signifie “développer” ?








Alpha Centauri a écrit :



D’après ce que j’avais compris, l’échec de Louvoi est principalement lié au code réalisé par l’armée (donc les ESN sont contentes, pas de pénalités possibles), l’armée faisant en interne la partie la plus sensible.







+1









hellmut a écrit :



le seul moyen c’est de mettre les specs dans les livrables.

seulement si personne les lit en face (et que ça se sait)…







gné? mais comment tu fais pour mettre les specs dans les livrables?



Je vais chez ma boulangère et je lui donne 1.20€, sans rien dire.

Elle me donne un pain au chocolat en échange.

Mais moi je voulais un croissant !

“j’en sais rien, mais vous m’avez confié les specs” - me répond-elle.

“ah oui, zut….”



j’entend par livrable ce que tu livres au client, ce qui est dans le contrat.

si les specs ne sont pas dans les livrables, tu n’es pas obligé d’en faire, ou de bien les faire, puisque ça reste à usage interne. c’est ce que voulait dire 127.0.0.1.









Tiebor a écrit :



Je disais donc:




  1. tu affirmes donc des choses, tout en précisant ne pas être catégorique, alors même que les “preuves” qui te font défaut sont publiques et facilement accessibles (rapport parlementaire, rapport Cour des comptes, articles divers….)





    je n’affirme rien, je suppose fortement, et je le dis.

    désolé, jsuis au taf, je vais pas passer 4h à chercher des preuves, quand bien même “facilement accessibles”.





  2. (certaines) specs seraient sous-traitées… et alors, ça change quoi au fond? qu’entends tu exactement par “sous-traiter” ? cette question renvoie en fait à ma question initiale: que signifie “développer” ?



    ben si c’est pas l’administration qui pond le “document”, ce document n’est donc pas administratif, donc non communicable. quant à la signification de développer, ce n’est pas la question. le sujet c’est que le code source est considéré comme un document administratif, ce qui n’était clairement pas évident.







    Tiebor a écrit :



    j’en sais rien. Peut-être. Et? Tu disais que Louvois n’est pas un doc adm. Je réponds que le ministère a peut-être fait les specs. Tu réponds que les specs sont des doc adm….. difficile de te suivre, mais j’ai l’impression que tu vas dans mon sens. <img data-src=" />





    les specs sont par défaut des documents administratifs, puisque ce sont des documents. dont la question ne se pose pas.

    dans l’article on parle du code source du logiciel. des specs c’est pas du code source, même si un paquet de neuneus foutent du code dans les specs. <img data-src=" />



L’Administration va finir par louer des progiciels d’entreprises privées, avec ce type de décision. Car cela peut aller loin, comme demander le code source de la gestion d’une centrale nucléaire (EDF) par exemple, ou le métro automatique parisien (RATP). Il y a dedans des choses plus que sensibles.

Quant à cet étudiant, quelles peuvent être ses motivations ? Maintenant, il est dans le collimateur des services de police et de renseignement. Il pense pouvoir prouver des anomalies l’autorisant à demander des remboursements d’impôts ?


En tout cas, c’est du bon vieux COBOL qui tourne sous Z/OS d’IBM. Avec certainement une base DB2.








hellmut a écrit :



j’entend par livrable ce que tu livres au client, ce qui est dans le contrat.

si les specs ne sont pas dans les livrables, tu n’es pas obligé d’en faire, ou de bien les faire, puisque ça reste à usage interne. c’est ce que voulait dire 127.0.0.1.





Je dis justement l’inverse: c’est au client de faire les specs, sinon il faut pas se plaindre que le produit ne répond pas au besoin. (le client peut sous-traiter les specs à une AMOA, ça revient au même)







hellmut a écrit :



je n’affirme rien, je suppose fortement, et je le dis.





Une supposition n’est jamais neutre ;-)

Et quand bien même, tu ne supposais pas dans le post auquel je répondais initialement.







hellmut a écrit :



ben si c’est pas l’administration qui pond le “document”, ce document n’est donc pas administratif, donc non communicable





et là, tu supposes ou tu affirmes?

non parce que la loi de 1978, article 1er, dit que les documents communicables sont tous les documents “produits ou reçus” par l’administration.

Personnellement, je ne sais pas, mais je n’irais pas supposer que les spec ne sont pas des doc communicables. Si le code source l’est, alors personnellement j’estime que les specs le sont a fortiori.

(sans compter, je me répète, qu’il n’est pas exclu que l’administration est “pondu” une partie des spec….)







hellmut a écrit :



quant à la signification de développer, ce n’est pas la question.





Je vois bien qu’on ne se comprend pas. Donc je reprend mon raisonnement (qui est sans doute contestable, une fois qu’on l’a compris) :




  1. tu dis: l’administration n’a pas “produit” Louvois.

  2. je ne sais pas ce que tu entends pas “produire”, mais je précise:

    2.1 il n’est pas impossible que l’administration est contribué au développement de Louvois, notamment par le biais des specs (et c’est pour ça que je dis que les specs font partie intégrante du développement d’un logiciel)

    2.2 en tout état de cause, même s’il s’avérait que Louvois n’a pas été produit PAR l’administration, il a en tout cas été produit POUR l’administration. Et donc ça revient peut-être au même? Ce n’est pas une affirmation, mais c’est mon avis.







    hellmut a écrit :



    les specs sont par défaut des documents administratifs, puisque ce sont des documents.





    Encore une fois, j’ai du mal à te suivre. Si je te comprends bien: si les specs ne sont pas “pondues” par l’administration, ce ne sont pas des documents administratifs, mais si elles sont rédigées par l’administration, ce sont des documents administratifs?

    Si tu dis ça, alors, d’une part, tu reconnais que l’administration peut rédiger des specs, et d’autre part, je pense que tu te trompes.







    hellmut a écrit :



    dans l’article on parle du code source du logiciel. des specs c’est pas du code source





    Oui, et l’article ne parle pas de Louvois, mais justement d’un logiciel développé par l’administration!

    (par ailleurs, comme dit + haut, je pense que si le code source est communicable, alors les specs aussi, a fortiori. C’est même plus légitime)



    Bref, j’arrête là. Ne crois pas que je veuille polémiquer. Mais j’aime être être précis et j’aime l’INPACTitude.





mais moi aussi j’aime l’INpactitude.

seulement j’ai pas trop le temps de fouiller. ^^



tout dépend si on considère que ce qui est produit pour l’administration (donc pas PAR l’administration) est aussi un doc administratif.

si l’article premier de la loi de 78 le dit, alors tout le code de louvois devrait être communicable, effectivement (hors infos sensibles).


Voici son témoignage :



https://forum.etalab.gouv.fr/t/howto-obtenir-dune-administration-lacces-a-un-cod…



A la base, il voulait le code source des impôts dans le cadre d’un stage au Secrétariat Général de Modernisation de l’Action Publique.


+1








hellmut a écrit :



…sans compter qu’il n’est pas produit par l’administration, donc ne constitue pas un document administratif.



par contre le code source des boites noires, on veut bien. <img data-src=" />





Sauf que [url=http://www​.qosmos.com/ Qosmos] est un sous-traitant, même argument donc pour la classification du code source.