L’État renouvelle son « référentiel général d’interopérabilité »

L’État renouvelle son « référentiel général d’interopérabilité »

Référentiel, mon mari !

Avatar de l'auteur
Xavier Berne

Publié dans

Droit

13/04/2015 5 minutes
22

L’État renouvelle son « référentiel général d’interopérabilité »

Le « référentiel général d’interopérabilité », qui s’applique depuis 2009 à toutes les administrations françaises, s’apprête à subir une refonte en bonne et due forme. La Direction interministérielle des systèmes d'information et de Communication (DISIC) a en effet lancé voilà plusieurs jours un appel à commentaires sur ce qui pourrait devenir la « V2 » de ce document normatif.

Les pouvoirs publics engagés dans une refonte du RGI

Introduit dans notre droit par une ordonnance de 2005, le référentiel général d’interopérabilité (RGI) n’a véritablement pris son envol que quatre ans plus tard, suite à un arrêté du Premier ministre d’alors, François Fillon. Cette sorte de guide pratique doit être respecté par toutes les « autorités administratives » du pays : ministères, collectivités territoriales, établissements publics, etc. L’objectif ? Que les échanges par voie électronique de l’administration (avec d’autres administrations, des particuliers, des entreprises...) soient facilités. En gros, l’idée est de faire en sorte que les mairies ne diffusent pas de documents en « .doc », le format propriétaire de Microsoft, dans la mesure où tous les usagers ne disposent pas de la suite Office.

Bien entendu, le champ d’application du RGI est extrêmement plus vaste que celui de la seule bureautique. Pour autant, il ne se concrétise pas par une liste énumérative des formats à adopter pour chaque type d’usage. « Le RGI ne fait qu’identifier les standards incontournables, et les quelques assemblages clés, sous la forme de profil d’interopérabilité, à retenir. Le RGI est donc volontairement limitatif, explique à cet égard la DISIC. L’objectif est bien de standardiser, c’est-à-dire, faciliter les choix, éviter la prolifération coûteuse de choix hétérogènes, sans imposer une solution unique, tout en appliquant le principe de subsidiarité. Le rôle de chaque autorité administrative est ainsi de s’aligner sur le RGI, avec un calendrier public, pour concevoir, mettre en place et entretenir des dispositifs interopérables. »

RGI

Depuis le 7 avril, une version 1.9.7 du RGI fait l’objet d’un appel public à commentaires (voir ici). Agents publics, informaticiens, spécialistes du numérique ou simples citoyens sont ainsi invités à laisser leurs avis sur ce nouveau texte, présenté comme ayant été « coconstruit avec les DSI des administrations centrales ».

Pour chaque standard référencé, la future version 2 du RGI donne trois « statuts » possibles :

  • « Recommandé » : le standard doit être respecté et appliqué.
  • « En observation » : considéré soit comme émergeant ou, au contraire, en fin de vie, ce standard doit être utilisé avec précaution.
  • « Retiré » : le standard doit être évité ou, s’il est utilisé, être abandonné.

Prenons quelques exemples. Du côté des standards techniques, l’IPV6 et l’IPSec sont recommandés s’agissant du réseau ; à l’inverse de l’IPV4, qui est considéré comme « en observation ». En matière de standards dits « syntaxiques », le célèbre format ZIP est également « en observation » et n’est donc pas recommandé. Plusieurs autres standards de compression sont en revanche plébiscités : Bzip2, Gzip, LMZA, etc.

RGI

Concernant l’édition de simples documents (tableurs, traitements de texte...), c’est l’ODF qui est préconisé dans la probable future version 2.0 du RGI, alors qu’il est aujourd’hui recommandé d’utiliser le langage XML – qui se décline souvent en OXML, le format lié à Microsoft et qui avait jadis suscité le courroux de l’April. Pour les documents non révisables, le PDF et PDF/A resteraient à privilégier.

La nouvelle version du RGI pourrait entrer en vigueur d’ici la rentrée prochaine

Du côté du multimédia, on retrouve à nouveau de célèbres noms : MKV, PNG, MP3, FLAC, ou iCal. On notera que dans cette catégorie, le MPEG-2 a été retiré au profit du MPEG-4, et que le TIFF et le GIF sont placés « en observation ».

Tous ces éléments sont bien entendus susceptibles d’être modifiés d’ici à ce que la version 2.0 du RGI soit publiée au Journal officiel, au travers d’un arrêté ministériel. Il faudra tout d’abord que l’appel à commentaires soit clos, c’est-à-dire le 15 mai prochain. « Le RGI ne sera vraisemblablement pas publié avant l’été, mais sûrement à la rentrée » nous indique la DISIC.

Rappelons enfin que sur le terrain du droit, l’ordonnance de 2005 prévoit que tous les systèmes d'information existant à la date de publication du référentiel « sont mis en conformité avec celui-ci dans un délai de trois ans à compter de cette date ». Quant aux applications créées dans les six mois suivant la date de publication du référentiel, celles-ci doivent rentrer dans le rang « au plus tard douze mois après ». Aucune sanction n’est cependant prévue en cas de non-respect de ces règles.

Écrit par Xavier Berne

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Les pouvoirs publics engagés dans une refonte du RGI

La nouvelle version du RGI pourrait entrer en vigueur d’ici la rentrée prochaine

Commentaires (22)


TXT non interopérable … Comment dire … J’ai le droit de rire ?



Ceci dit, l’idée de base est bonne hein, faut juste pas sortir de telles énormités.


Souvent une belle galère d’ouvrir un txt créé sous un autre système à cause des différences de gestion des CR/LF.








Gilbert_Gosseyn a écrit :



TXT non interopérable … Comment dire … J’ai le droit de rire ?



Ceci dit, l’idée de base est bonne hein, faut juste pas sortir de telles énormités.





Leur justification est bonne



Rien que NotePad++ me propose l’ANSI, l’UTF-8 sans BOM, l’UTF8, l’UTF16BE et l’UTF16LE comme encodage, sans parler des problèmes de sauts de ligne.



Et c’est encore pire sur Intelij qui me propose une quarantaine de format d’encodage différent.



en gros sur des langues non accentuées et sans caractères spéciaux, oui ça passe



en pratique y’a tjs un pb <img data-src=" />


Voilà ce que j’ai écrit:



Bonjour,



La recommandation multimédia est globalement bonne, mais manque cruellement de précisions: un format de container, tel le MKV, ne suffit pas à recommander un format. Il faut associer format et codecs.



Ainsi MKV et Ogg (recommandés), peuvent recevoir de nombreux codecs, qu’il faut préciser.

Il est important de rappeler que les formats de sous-titres Ogg sont sous-spécifiés.

Attention, le lien wiki pour Ogg est faux!



Sur la partie codec Audio, il serait intéressant de rajouter Opus, qui a une spécification IETF et dont les performances sont bien meilleures que le MP3 ou le Vorbis, notamment dans la faible latence et le bas-débit.



Sur la partie format, il est fort dommageable de recommander MPEG-4 dans son ensemble, qui comprend de très nombreuses choses, que peu de gens/industriels supportent. Notamment, la partie Audio (AAC) a de très nombreux sous-codecs et profils (43 en datehttp://en.wikipedia.org/wiki/MPEG-4_Part_3#Audio_Profiles), qui sont tous bien différents les uns des autres. De même MPEG-4 Part 6, Part 11, 13 ou 20, sont anecdotiques.



Il serait donc une bonne idée de spécifier uniquement les parties supportés (part 12/part 10 et part 14), ce qui a été fait sur les codecs vidéos, notamment.



Enfin, il serait probablement bien de spécifier un format de sous-titres, pour l’accessibilité.



Bien cordialement,


Pour le format TXT, je propose d’utiliser l’Art ASCII pour dessiner des lettres accentuées sans avoir à se préoccuper de l’encodage.



<img data-src=" />


<img data-src=" />


Joli et très pertinent!



&lt;rant&gt;

Ce qui me fait froncer les sourcils, perso, c’est cette horreur verbeuse qu’on appelle XML. Pour des données tabulaires, du CSV ou du json seraient plus compacts, donc plus gentils avec le réseau, donc avec l’Univers. Après, pour ce qui est de l’encodage (et ça vaut aussi pour le txt), autant définir UTF-8 sans BOM et s’y tenir (à charge du très ouvert consorstium Unicode de maintenir la compatibilité vers l’arrière) &lt;/rant&gt;








fzn a écrit :



Ce qui me fait froncer les sourcils, perso, c’est cette horreur verbeuse qu’on appelle XML. Pour des données tabulaires, du CSV ou du json seraient plus compacts, donc plus gentils avec le réseau,





Mais absolument pas descriptive.

Si tu ne sais pas quel est exactement le document CSV ou JSON que tu lis, il est souvent impossible d’en déduire toutes les informations.

Le XML a l’avantage d’être auto descriptif et il t’es difficile de confondre 2 structure de données en plus de tous les outils déjà existant XSL/XSLT/XPath/…

A chacun ses avantages mais le XML a encore toutes les raisons d’exister.



C’est prévu pour quand que la politique soit interopérable avec la volonté du peuple?&nbsp;<img data-src=" />








Inny a écrit :



Souvent une belle galère d’ouvrir un txt créé sous un autre système à cause des différences de gestion des CR/LF.





Notepad ++ (et ses équivalents) n’a aucun problème hein.



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


C’est toit qui sort des énormités , oui un fichier TXT n’est pas un standard (codage etc) …

Il faut juste avoir bosser sur Unix ET Windows pour s’en rendre compte … visiblement tu as du en loupé un !


CE n’est pas parc-que notepad++ n’ pas de problème qu’il s’agit d’un format standard.


Si ça ne peut être ouvert que par une catégorie spécifique d’éditeurs de texte, ce n’est pas interopérable. CQFD. <img data-src=" />


CSV/json avec renvoi vers un DTD-like alors ?


Exactement. Mais à mon sens, c’est encore plus large dans la justification. Un fichier XML, Json, CSV, du code source, des logs (et tant d’autres) sont aussi des fichiers « texte », au sens de conteneur d’un format de données non binaire.

&nbsp;Le classique fichier « .txt » contenant un « texte » au sens linguistique n’est finalement que très minoritaire.


Ça ne palis pas à tous les manques ça serais pas mal, le problème c’est que ça n’existe pas a ma connaissance.








Inny a écrit :



Souvent une belle galère d’ouvrir un txt créé sous un autre système à cause des différences de gestion des CR/LF.






Il ne faut pas exagérer, même sous un vieux Windows XP, on peut ouvrir un fichier à la Unix (LF seul) avec wordpad. Et sous Linux c'est transparent pour l'édition (ne serait-ce qu'avec vi/vim).     



&nbsp;





Eone a écrit :



Leur justification est bonne




 Rien que NotePad++ me propose l'ANSI, l'UTF-8 sans BOM, l'UTF8, l'UTF16BE et l'UTF16LE comme -en- codage, sans parler des problèmes de sauts de ligne.       






 Et c'est encore pire sur Intelij qui me propose une quarantaine de format -d'encodage- de codage différent.







<img data-src=" />

Le document officiel utilise le terme correct de codage (pas d’anglicisme).

Notepad++ se débrouille bien avec les fichiers “normaux” en Latin-1 ou UTF-8 (sans BOM, par pitié).







jb18v a écrit :



en gros sur des langues non accentuées et sans caractères spéciaux, oui ça passe




en pratique y'a tjs un pb <img data-src=">







Non, en Latin-1 (= ISO-8859-1), qui est de l’ASCII étendu européen, ça a toujours bien fonctionné, déjà sur mon Amiga à la fin des années 80.







MdMax a écrit :



Pour le format TXT, je propose d’utiliser l’Art ASCII pour dessiner des lettres accentuées sans avoir à se préoccuper -de l’encodage- du codage.



<img data-src=" />





du codage, stp (cf ma remarque un peu plus haut).

<img data-src=" />









fzn a écrit :



Joli et très pertinent!





Ce qui me fait froncer les sourcils, perso, c’est cette horreur verbeuse qu’on appelle XML. Pour des données tabulaires, du CSV ou du json seraient plus compacts, donc plus gentils avec le réseau, donc avec l’Univers. Après, pour ce qui est -de- -l’encodage- du codage (et ça vaut aussi pour le txt), autant définir UTF-8 sans BOM et s’y tenir (à charge du très ouvert consorstium Unicode de maintenir la compatibilité vers l’arrière)





pour ce qui est du codage, stp.

&nbsp;





Mimoza a écrit :



Mais absolument pas descriptive.

Si tu ne sais pas quel est exactement le document CSV ou JSON que tu lis, il est souvent impossible d’en déduire toutes les informations.

Le XML a l’avantage d’être auto descriptif et il t’es difficile de confondre 2 structure de données en plus de tous les outils déjà existant XSL/XSLT/XPath/…

A chacun ses avantages mais le XML a encore toutes les raisons d’exister.





Il me semble qu’on peut transformer du XML en JSON et inversement, mais je t’accorde que le XML est un peu plus “puissant”. Pour le CSV il existe la forme où la première ligne donne le nom des champs, ça peut suffire dans un certain nombre de cas.









ledufakademy a écrit :



C’est toit qui sort des énormités , oui un fichier TXT n’est pas un standard (codage etc) …

Il faut juste avoir bosser sur Unix ET Windows pour s’en rendre compte … visiblement tu as du en loupé un !





Le TXT répond à plusieurs standards, en pratique soit Latin-1 (ou Latin-9 petite variante), soit UTF-8. Je ne vois jamais d’autres formats (ou codages, pour être précis). Unix/Linux gère bien les fichiers issus de DOS, sauf exception.







Inny a écrit :



Si ça ne peut être ouvert que par une catégorie spécifique d’éditeurs de texte, ce n’est pas interopérable. CQFD. <img data-src=" />





Non non, heureusement on n’a pas attendu Notepad++ pour ouvrir des fichiers textes.



XML =&gt; JSON = OK

JSON =&gt; XML = KO impossible de reconstruire exactement tous les tags donc ça donne un XML invalide. Après tu peut toujours le faire si tu connais parfaitement le shéma JSON qui rentre.



Pour le CSV ce n’est pas une forme standard d’avoir une entête descriptive, mais il est vrai que c’est relativement répendu.