RGI, le Référentiel Général Inachevé
Par Jean-Marie Gouarné

Depuis le temps, on ne l'attendait plus, et finalement il est là : en chantier depuis trois ans, le Référentiel Général d'Interopérabilité est arrivé ! Avec un titre aussi ambitieux et après une aussi longue gestation, cette publication devrait être un jalon décisif dans le devenir des services de l'État en matière de systèmes  d'information. Hélas, en lisant ces 119 pages dont l'accouchement fut si douloureux, on reste sur sa faim et on comprend vite qu'on n'a fait que quelques pas sur la longue route de l'interopérabilité.

Dès l'introduction, on est d'ailleurs prévenu que le RGI n'interdit rien, n'est pas exhaustif, ne traite pas de l'architecture des systèmes d'information, ne préconise pas de solutions techniques. On lit aussi non seulement que le RGI n'a pas vocation à édicter des normes, mais encore qu'une norme doit émaner d'un organisme de normalisation et être « le fruit du consensus de l'ensemble des acteurs ». Le message est clair : le RGI ne dérangera personne.

Ce document (il faut tout de même lui rendre justice) a le mérite de présenter sous une forme synthétique et abordable une vue générale des problématiques d'interopérabilité des systèmes d'information. Mais il souffre d'un manque de rigueur sur de nombreux points, d'une politique d'esquive sur les sujets qui pourraient fâcher, voire de préjugés stratégiques inappropriés et de contradictions internes. Sans développer une analyse exhaustive qui n'aurait pas sa place ici, je propose quelques exemples qui montrent que cette version 1.0 du RGI n'est pas encore tout à fait ce qu'on attendait.

Langages de définition des échanges

En matière de spécification des échanges, le cadre méthodologique PRAXEME est présenté en parallèle avec le guide UML-XML de l'UN/CEFACT. Cependant, le chapitre consacré à ce sujet, très important pour la conduite des projets concernés par des impératifs d'interopérabilité, ne débouche sur aucune préconisation concrète. Les recommandations effectives se limitent aux grammaires et aux syntaxes de modélisation. Et encore, elles restent vagues : par exemple, le choix est ouvert entre BPMN et UML pour la description des processus, sans critère de sélection entre l'un et l'autre selon le type d'application.

Les considérations relatives aux langages de haut niveau, déjà timides à propos de la spécification des échanges, sont même absentes dans le domaine de l'interopérabilité des services. Le RGI, dans le domaine des services web, limite ses recommandations aux grammaires et aux syntaxes de base (SOAP, WSDL, UDDI, etc.), à quelques profils WS-I bien identifiés, et au protocole d'échange de l'administration française PRESTO. Tout cela est très constructif sur le plan strictement technique de l'interopérabilité, mais il manque encore une recommandation relative au problème (crucial) de l'orchestration des services. Aucune mention n'est faite des BPEL et autres langages de description exécutable des interactions au sein d'un ensemble organisé de services web. De sorte qu'il manque, sur ce point, un raccord entre les différentes couches (sémantique, syntaxique, technique) de l'interopérabilité. Simple oubli, ou attente d'une solution imposée par les fournisseurs ?

Structures XML

Pour définir la structure d'un document XML, le RGI recommande exclusivement le recours aux schémas XSD du W3C. Les auteurs semblent avoir oublié que le langage XSD,  parfaitement approprié aux structures complexes, ne peut que générer des surcoûts de développement et de traitement injustifiés pour les documents simples, et ils ont négligé la norme ISO/IEC 19757-2 (alias Relax NG), malgré l'hommage rendu par ailleurs aux « normes et standards reconnus ». XSD est dans bien des cas un marteau-pilon pour planter une punaise ; sa lourdeur dans les cas d'utilisation simples est de nature à inciter les acteurs à bouder l'utilisation des schémas XML, ou à s'en tenir aux rudimentaires DTD. Alors qu'il est, sur certains points, excessivement laxiste, le RGI devrait au moins accepter les deux standards de définition de schémas XML ; d'autant plus qu'il est toujours possible, si nécessaire et sans perte d'information, de convertir en XSD un schéma Relax NG.

Sur un sujet connexe, à savoir la transformation des documents XML, le texte recommande XSLT et XPath, bizarrement placés sur le même plan alors que le second est un langage de navigation (éventuellement utilisable dans une transformation XSLT mais d'usage plus général) et non un langage de transformation. Mais surtout XSLT est un langage de traitement, et donc une solution logicielle. Sa recommandation sans nuance est un peu simpliste ; dans la pratique, vouloir à tout prix traiter en XSLT toutes les transformations de documents XML, y compris celles qui relèvent manifestement d'une logique procédurale, peut conduire à des aberrations. D'autre part, sans même entrer dans le débat technique, cette recommandation déroge au principe de non-ingérence dans les solutions techniques pourtant affiché au départ. Le fait que telle ou telle administration utilise XSLT ou autre chose pour reformater des structures XML est une question indépendante de celle des échanges entre partenaires ; la seule chose qui compte est le résultat de la transformation, et non le logiciel qui a servi à l'exécuter. Cette préconisation est donc une dissonance parmi d'autres dans un RGI qui, par ailleurs, s'interdit (presque) de prendre position sur les langages de programmation.

Navigateurs Web

Mais c'est dans la section intitulée « Navigateurs Web » que le document va le plus loin dans la dérogation à sa propre règle de non-préconisation de solutions. Cette section recommande en effet que les services en ligne soient compatibles avec trois logiciels nommément désignés (Internet Explorer, Firefox et Safari). Pour rester politiquement correct et donc ne pas oublier le thème de l'accessibilité, le navigateur libre en mode texte Lynx est ajouté à la liste, mais la compatibilité Lynx, allez savoir pourquoi, est conseillée au lieu d'être recommandée. Cette liste de logiciels est à la fois déplacée et insuffisante. Déplacée parce qu'elle se situe sur le terrain des solutions techniques (parmi lesquelles elle opère une sélection arbitraire) et non sur celui des formats, des syntaxes et des protocoles applicables aux contenus échangés. Insuffisante parce qu'elle ignore la problématique des extensions et autres « plug-ins » toujours susceptibles de créer des adhérences indésirables entre le navigateur et la plate-forme ou d'imposer à l'internaute la mise en œuvre d'un composant propriétaire dans l'environnement du navigateur.

Au sujet des scripts associés aux documents en ligne, la recommandation porte non pas sur un langage, mais sur les langages conformes à la norme ECMAScript (alias ECMA-262). Bel exemple de non-choix ! En n'allant pas au-delà de la spécification (théorique) commune, on ne prend pas position entre les deux dialectes ECMAScript, à savoir le JScript pratiqué de préférence dans certains environnements propriétaires et le JavaScript supporté par presque tout le monde. Mieux : la recommandation ne précise pas de numéro de version et semble oublier que le standard ECMA-262 a été décliné en trois éditions validées (la troisième correspondant à Internet Explorer 6), et que si la quatrième édition n'est pas sortie en 2008, c'est justement parce que le devenir d'ECMAScript est au coeur d'une controverse politique majeure entre les acteurs du web. Controverse que les auteurs du RGI ne devraient pas ignorer. En restant sur l'ECMAScript et sa liste fermée de navigateurs, le RGI en fait trop et trop peu ; il s'aventure sur le terrain des choix techniques mais s'arrête en chemin sans fournir de recommandation opérationnelle.

Polices, images et sons

Après avoir nettement (et à juste titre) pris position en faveur de l'encodage Unicode UTF-8, le document part dans le flou le plus complet à propos du vieux problème des polices de caractères : il est en effet « recommandé d'utiliser des polices de caractères supportées nativement par toutes les plates-formes » (sic). Mais que signifie techniquement la notion de police supportée nativement par une plate-forme ? Et que veut-on dire par « toutes les plates-formes » ? Le créateur d'un document doit-il faire enquête pour s'assurer que toutes les polices qu'il utilise sont bien disponibles sur la totalité des stations de travail, imprimantes, netbooks, téléphones et assistants personnels commercialisés au cours des dix dernières années ? Si les rédacteurs du RGI ne sont pas en mesure de fournir une liste des polices recommandées dans les administrations, quel utilisateur saura obtenir cette liste ? Et s'il s'avère techniquement ou politiquement impossible de promouvoir un référentiel général des polices de caractères agréées, à quoi bon exprimer une recommandation sans contenu ?

Pour les images numériques, aussitôt après une recommandation (peu contraignante mais assez claire) en faveur des formats GIF, PNG, JPEG, TIFF ou DNG, les choses se gâtent avec une petite phrase ambiguë indiquant que « afin de pouvoir modifier une image, les fichiers originaux de création de cette image doivent être conservés », mais ne donnant aucun détail sur les formats de conservation. Est-ce à dire que, si une image est réputée susceptible de modification ultérieure, l'administration est encouragée à l'archiver dans le format, éventuellement propriétaire, du logiciel ayant servi à la créer, et qui n'existera probablement plus dans 10 ans ?

La question des contenus sonores compressés est expédiée selon la logique de la reconnaissance passive des (mauvaises) habitudes acquises. Ainsi, parmi les formats de compression disponibles sur le marché, c'est le MP3 et lui seul (avec son horizon juridiquement et techniquement limité) qui est choisi au détriment des formats libres de la fondation Xiph (OGG Vorbis, FLAC et SPEEX), qui n'obtiennent que le statut « en observation », comme s'il y avait encore un doute à leur sujet.

Archives compressées

Dans le domaine de la compression de fichiers, la recommandation est simple : ce sera le zip de PKWARE, un point c'est tout. La bonne nouvelle, c'est évidemment qu'un choix est fait et qu'il est clair. La mauvaise, c'est, encore une fois, la priorité donné aux habitudes, la normalisation des routines de la bureautique des années 1990, sans véritable démarche critique et rationnelle. Certes, les rédacteurs démontrent qu'ils connaissent l'existence de solutions alternatives ; mais curieusement ils se bornent à citer les formats 7z, rar et rk. C'est-à-dire que, parmi tous les formats de compression de la planète, les auteurs du RGI semblent n'avoir examiné que les formats propriétaires. Le format libre bzip2 et son prédécesseur gzip, largement installés et disponibles pour toutes les plates-formes (à travers des logiciels de compression libres ou propriétaires) ne sont ni recommandés, ni « en observation », ni même simplement cités, ce qui donne à penser qu'ils ne sont même pas connus des experts ayant réalisé le document.

Le problème va au-delà du choix d'un algorithme de compression, car le zip n'est pas seulement un format de compression, c'est aussi un format d'archive. Une archive zip (comme une archive rar ou tar) peut héberger toutes sortes de contenus, compressés ou non. La compression proprement dite est assurée par l'algorithme deflate (RFC 1951) qui est libre et qui est également exploité par gzip. Un utilisateur peut très bien, par exemple, conditionner dans une archive zip un contenu compressé en bzip2 (généralement plus efficace que deflate) ; mais il peut tout aussi bien opter pour un format d'archive non-zip pour contenir des données compressées par deflate (c'est-à-dire par zip, en tant qu'algorithme de compression).

Sur ce point, le RGI gagnerait d'une part en évitant la confusion entre formats d'archives et formats de compression, et d'autre part en élargissant sa vision au monde des standards effectivement pratiqués depuis longtemps dans les systèmes d'information, au lieu de s'en tenir à une approche grand public.

Documents bureautiques

Sur le terrain des formats de documents révisables, le RGI s'en tient à l'abstentionnisme officiel de la France inauguré en 2007 et 2008 par l'AFNOR. Les deux standards Open Document Format (ISO/IEC 26300) et Office Open XML (ISO/IEC 29500), dont aucun n'a d'ailleurs encore été admis au rang de norme française, restent « en observation ». En les

citant, les rédacteurs du RGI ont peut-être seulement voulu s'assurer qu'on ne leur  reprochera pas d'avoir oublié quelque chose. Toujours est-il que l'évocation de ces standards est totalement inopérante d'un point de vue pratique. Curieusement, pourtant, deux logiciels de conversion ODF/OOXML sont explicitement cités... mais que font dans le RGI des outils de conversion entre deux formats dont aucun n'est recommandé ? D'autant plus que ce texte n'était pas censé préconiser des solutions logicielles.

Le plus ennuyeux de l'histoire, c'est que, tout en éliminant de fait les deux standards, le RGI ne préconise strictement rien de concret pour la conservation et l'échange des documents révisables pour maintenant, et que le paysage des formats de documents révisables normalisés n'a guère de chances de s'améliorer à moyen terme. L'utilité de ce chapitre est donc nulle.

La situation est plus saine pour ce qui concerne les documents dits non révisables, puisque le règne du PDF est considéré ici comme un acquis. Pourtant, le RGI recèle un facteur de risque qui découle très logiquement de la distinction (chère à la DGME) entre format d'échange et format d'archivage. Il est regrettable que des distinctions aussi raffinées n'aient pas été faites dans d'autres domaines que celui-ci. Tandis que le PDF 1.4 (PDF/A) est très logiquement désigné pour l'archivage, c'est le PDF 1.7 qui est recommandé pour l'échange. Tout cela est parfaitement rationnel dans un monde théorique où chaque document, dès sa naissance, est affecté du statut définitif de document à archiver ou de document à échanger. Les auteurs du RGI ont sans doute soupçonné que le monde réel n'était pas aussi simple, car ils ont précisé dans une remarque que, si un document déjà archivé en PDF/A devait être par la suite échangé, il ne serait pas  nécessaire de le convertir en PDF 1.7, ce qui revient à admettre que, après tout, le PDF/A n'est pas totalement rédhibitoire comme format d'échange.

Mais le pire est passé sous silence : le RGI ne donne aucune indication pour le cas d'utilisation le plus banal et le plus incontournable de tous, à savoir celui du document qui doit être archivé après avoir été échangé. Le document archivé doit être strictement identique au document transmis ; or il est impossible de garantir une conversion sans perte de PDF 1.7 en PDF 1.4 ; ce qui signifie concrètement qu'il faudra bien archiver du PDF 1.7. De sorte que chacune des deux versions de PDF préconisées devra pouvoir être utilisée indifféremment pour l'échange et pour l'archivage. Ce qui signifie que la recommandation n'est pas complète ou, si on se place à plus haut niveau, que la distinction intellectuelle entre formats d'échange et formats d'archivage n'est pas encore maîtrisée dans tous ses aspects pratiques.

Une réflexion inaboutie

Ces quelques exemples sont des symptômes parmi d'autres des défauts majeurs de cette version, anecdotique, imprécise et indécise. Là où des choix sont attendus, le RGI ne choisit pas ; là où il choisit, il méconnaît les problématiques de mise en œuvre ou encore se borne à compiler des pratiques (bonnes ou mauvaises) qui n'ont pas besoin de référentiel pour perdurer. Tout en fournissant sur certains points des détails techniques hors de propos, il reste évasif sur des sujets fondamentaux. Malgré la longue attente qui a précédé la publication, certains détails du texte évoquent une rédaction hâtive : j'en veux pour preuves le glossaire qui (page 113) définit ODF comme « Open Office Format », ou encore la section 3.1.7 sur le format graphique X3D dont la plus grande partie comporte une similitude frappante avec l'article de Wikipédia sur le même sujet (lu le 20 juin 2009). En bref, le contenu n'est pas à la hauteur du titre.

Mais rien n'est perdu. N'oublions pas qu'il s'agit d'une version 1.0. De plus, cette version est qualifiée (selon une formule ambiguë à l'image du document lui-même) de « projet final pour avis ». Espérons que le substantif « projet » pèsera plus lourd que l'adjectif « final » et que les « avis » pertinents seront écoutés...