Référentiel Général d'Interopérabilité

From Coopernix
Revision as of 07:48, 24 September 2020 by Sysop (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Le RGI français correspond à une étude approfondie des conditions d'interopérabilité au sein d'une vaste agora. Il sert ici, avec la RFC 6852, d'introduction à l'approche d'une standardisation de l'interoperabilité au sein de ses "communautés globales" et si possible entre-elles. La "communauté globale" ici considérée est celle des Sciences et Recherches Hors Murs (SRHM).



1 CONTEXTE, DÉFINITIONS ET OBJECTIFS

1.1 Introduction

Direction Interministérielle du Numérique et du Système d’Information et de Communication de l’Etat

Référentiel Général d'Interopérabilité

Standardiser, s’aligner et se focaliser pour échanger efficacement

Version 2.0 – décembre 2015

Le présent document est une mise à jour de la version 1.0 du Référentiel Général d’Interopérabilité ou RGI, publiée par arrêté le 11 novembre 2009. Le présent document annule donc et remplace cette version 1.0.

Cette mise à jour répond à deux objectifs :

  • prendre en compte les évolutions technologiques et l’évolution des normes et standards depuis cette dernière version.
  • recentrer l’usage sur des normes et standards retenus sur les questions d’interopérabilité critiques aux « frontières », et au-delà des « frontières » des systèmes de chaque 1[1] ministère, administration, opérateur , ou collectivité. Les problèmes d’interopérabilité interne aux systèmes informatiques de ces organisations doivent en premier lieu être traités dans leurs propres cadres de cohérence technique (CCT), tout en veillant à appliquer au mieux les recommandations du présent cadre, conformément aux différentes dispositions législatives rappelées dans le chapitre 1.3 Cadre législatif du présent cadre.

Pour ce faire, cette nouvelle version introduit la notion de profil d’interopérabilité. Un profil d’interopérabilité regroupe un ensemble de standards et de recommandations autour de cas d’usage définis. Il s’agit de faciliter l’appropriation de ce référentiel, en se focalisant sur quelques grands usages clés. Il s’agit également de limiter les choix de standards dans un contexte donné.

Cette nouvelle version est le fruit d’un travail interministériel animé par la Direction Interministérielle des Systèmes d’Information et de Communication (DISIC) et réunissant des urbanistes et architectes des systèmes d’information de l’ensemble des ministères. Elle a fait l’objet d’un appel public à commentaires sur la période avril/mai 2015. Cet appel public a permit de mobiliser l’ensemble de l’écosystème et de recueillir un maximum d’avis et remarques : éditeurs, sociétés de services et intégrateurs, collectivités, opérateurs, administrations, collectivités, etc. Plusieurs versions préparatoires ont également circulé au sein des DSI (Direction des Systèmes d’Information) ministérielle. La validation finale par le Conseil des Systèmes d’Information et de Communication est engagée pour septembre 2015.

1.2 Remarques préalables et documents de référence

Cette nouvelle version s’inspire des meilleures pratiques dans une très grande variété de champs d’expertise présente sur le marché de la standardisation, de l’architecture technique, et plus globalement de l’urbanisation de système d’information (appelée aussi architecture d’entreprise). Elle ne souscrit donc à aucune méthode ni aucun outil propriétaire.

La démarche utilisée et les critères de sélections sont décrits ci-après.

Le présent RGI est un document technique qui s’adresse avant tout aux spécialistes en système d’information : chef de projet, architecte, urbaniste, concepteur, développeur, intégrateur. Il est donc fortement recommandé d’avoir une connaissance minimum des principes d’interopérabilité et notamment des documents identifiés ci-dessous :

  • Référentiel Général d’Interopérabilité, version 1.0, novembre 2009 qui deviendra obsolète à la validation officielle du présent document [2] ;
  • Cadre Commun d’Urbanisation du Système d’Information de l’État , version 1.0, novembre [3] 2012 ; appelé aussi « Cadre commun d’Architecture d’Entreprise applicable au système d’information de l’Etat et à sa transformation » ;
  • Cadre Commun d’Architecture des Référentiels de données, version 1.0, décembre 2013 [4] ;
  • Stratégie État Plateforme, novembre 2014 [5] ;

Par ailleurs, le présent document est l’un des quatre référentiels généraux qui s’appliquent réglementairement à l’ensemble des autorités administratives (cf. le paragraphe 1.3). Les trois autres sont :

  • Le Référentiel Général de Sécurité (RGS) [6]
  • Le Référentiel Général d'Accessibilité pour les Administrations (RGAA) [7]
  • Le Référentiel Général de Gestion des Archives (R2GA) [8]

De plus, la Charte Internet de l’ État (CIE) a pour objet de définir un ensemble de règles ergonomiques communes aux interfaces des sites Internet publics. [9]

Enfin, le Socle Interministériel de Logiciels Libres (SILL) sera particulièrement utile, a minima pour les tests d’interopérabilité. Il référence en effet des solutions de logiciels libres préconisées, en les organisant par cas d’usage. [10]

1.3 Cadre législatif

Le RGI résulte des dispositions de l’ordonnance n° ‍2005-1516 du 8 décembre 2005 et du décret n° 2007-284 du 2 mars 2007.

L’article 1 du chapitre Ier de l’ordonnance n° ‍2005-1516 introduit, entre autres, une définition de système d’information :

… Tout ensemble de moyens destinés à élaborer, traiter, stocker ou transmettre des informations faisant l'objet d'échanges par voie électronique entre autorités administratives et usagers ainsi qu'entre autorités administratives...

Le chapitre V précise les dispositions relatives à l’interopérabilité des services offerts par voie électronique. En particulier l’article 11 précise le cadre du RGI :

Un référentiel général d'interopérabilité fixe les règles techniques permettant d'assurer l'interopérabilité des systèmes d'information. Il détermine notamment les répertoires de données, les normes et les standards qui doivent être utilisés par les autorités administratives.

Comme son intitulé l’indique, cette ordonnance est relative aux échanges électroniques entre les usagers et les autorités administratives et entre les autorités administratives. Cette notion d’autorité administrative est également définie à l’article 1 du chapitre premier :

I. - Sont considérés comme autorités administratives au sens de la présente ordonnance les administrations de l’État, les collectivités territoriales, les établissements publics à caractère administratif, les organismes gérant des régimes de protection sociale relevant du code de la sécurité sociale et du code rural ou mentionnés aux articles L. 223-16 et L. 351-21 du code du travail et les autres organismes chargés de la gestion d'un service public administratif.

Enfin, le chapitre VI fixe quant à lui les conditions de mise en conformité et champ d’application.

I. - Les systèmes d'information existant à la date de publication du référentiel général de sécurité mentionné au I de l'article 9 sont mis en conformité avec celui-ci dans un délai de trois ans à compter de cette date. Les applications créées dans les six mois suivant la date de publication du référentiel sont mises en conformité avec celui-ci au plus tard douze mois après cette date.
II. - Les systèmes d'information existant à la date de publication du référentiel général d'interopérabilité mentionné à l'article 11 sont mis en conformité avec celui-ci dans un délai de trois ans à compter de cette date. Les applications créées dans les six mois suivant la date de publication du référentiel sont mises en conformité avec celui-ci au plus tard douze mois après cette date.

Les systèmes existants au moment de la publication se mettent en conformité dans les trois ans, les applications créées dans les six mois suivants au plus tard douze mois après.

L’ordonnance n° 2005-1516 traite des interactions entre les autorités administratives et les usagers et entre les autorités administratives afin de garantir le transfert et la prise en compte des informations échangées.

1.4 Définitions

« Interoperability is the ability of disparate and diverse organisations to interact towards mutually beneficial and agreed common goals, involving the sharing of information and knowledge between the organisations, through the business processes they support, by means of the exchange of data between their respective ICT systems. [11]»
L’interopérabilité est l’aptitude d’organisations disparates et diverses à interagir en vue de la réalisation d’objectifs communs mutuellement avantageux, arrêtés d’un commun accord, impliquant le partage d’informations et de connaissances entre ces organisations à travers les processus métiers qu’elles prennent en charge, grâce à l’échange de données entre leurs systèmes de TIC respectifs.

L’AFUL [12] et wikipedia s’accordent sur une version étendue de cette définition [13] :

L'interopérabilité est la capacité que possède un produit ou un système, dont les interfaces sont intégralement connues, à fonctionner avec d'autres produits ou systèmes existants ou futurs et ce sans restriction d'accès ou de mise en œuvre.

Nous retiendrons la définition de Wikipedia pour le RGI. La Commission Européenne définit également ce que doit être un cadre d’interopérabilité : un cadre de niveau Européen ou European Interoperability Framework (EIF), et un cadre national d’interopérabilité par États membres ou National Interoperability Framework (NIF) :

« An interoperability framework is an agreed approach to interoperability for organisations that wish to work together towards the joint delivery of public services. Within its scope of applicability, it specifies a set of common elements such as vocabulary, concepts, principles, policies, guidelines, recommendations, standards, specifications and practices. »

Un cadre d'interopérabilité est une approche concertée de l'interopérabilité pour les organisations qui souhaitent travailler ensemble à la délivrance conjointe de services publics. Au sein de son champ d'application, il spécifie un ensemble d'éléments communs tels que le vocabulaire, les concepts, les principes, les politiques, directives, recommandations, normes, spécifications et pratiques.

Le RGI correspond au NIF Français.

Plusieurs éléments importants sont à retenir dans ces définitions :

  • l’approche concertée entre les parties ;
  • le fait que les interfaces des systèmes par lesquelles les échanges sont réalisées soient intégralement connues et donc décrites d’un point de vue technique, sémantique, fonctionnel et opérationnel ;
  • la capacité à fonctionner avec d’autres systèmes sans restriction ;
  • le fait que l’interopérabilité ne soit pas qu’une question technique, mais touche également aux questions de vocabulaire , de concepts métiers, de principes d’architecture et d’organisation, de réglementation, de droit, de politiques.

L’interopérabilité réelle suppose donc que :

  • les interfaces des systèmes reposent sur des standards ouverts,
  • l’implémentation qui est faite de ce standard respecte le cas échéant un profil technique lorsque ceci est applicable,
  • l’implémentation soit testée vis-à-vis d’une implémentation de référence lorsque celle-ci est disponible,
  • les choix d’implémentation résultants soient dûment documentés ainsi que tous les écarts avec les points précédents.

Pour faciliter et alléger la lecture du document, et même si la langue française distingue les deux termes « standard » et « norme », le terme « standard » est utilisé par défaut dans l’ensemble du document en lieu et place de « norme et standard » (au singulier ou au pluriel).

1.5 Objectifs du RGI

Concevoir, mettre en place, opérer, et entretenir des organisations, des dispositifs, ou des systèmes qui soient interopérables, et cela à moindre coût, passe notamment par des choix communs de standards d’échange, des choix de sémantique commune. Mais un standard ne règle pas à lui seul les questions d’interopérabilité. De plus, parfois, la manière d’implémenter un standard peut également créer d’autres difficultés qui conduiront à réduire l’interopérabilité. Leurs spécifications ne peuvent pas prévoir tous les cas ou besoins d’implémentation, d’où l’absolue nécessité de retenir des standards qui ont fait leurs preuves, sans que cela obère l’évolution des systèmes concernés, la recherche et l’innovation.

Les choix d’assemblage de ces standards, les choix d’architecture mais aussi les choix de solutions (composants, logiciels, infrastructure) sont tout aussi importants. Le Référentiel Général d’Interopérabilité n’a pas l’objectif de définir les solutions à retenir. Il ne serait pas non plus efficace d’imposer une solution unique pour l’ensemble de l’écosystème public. Le RGI ne fait qu’identifier les standards incontournables, et les quelques assemblages clés, sous la forme de profils d’interopérabilité à retenir.

Le RGI est donc volontairement limitatif. L’objectif est bien de standardiser, c’est-à-dire principalement de faciliter les choix, et d’é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.

Le schéma ci-dessus illustre les 3 facettes à prendre en compte dans la conception, la mise en place et l’entretien de dispositifs interopérables. Il positionne la version 2.0 du RGI notamment par rapport à la version 1.0.

1.6 Démarche et partis pris

L’approche adoptée pour l’élaboration du RGI repose sur les principes suivants :

  • Co-construit : l’élaboration de ce document est le fruit d’un travail de concertation et de coopération entre les experts des différents ministères, opérateurs, et plus globalement des professionnels des systèmes d’information. Il a fait l’objet d’un appel public à commentaires.
  • Utile et facile à consulter : Le document proposé à la lecture se veut utile et facile à consulter. Il est focalisé sur l’essentiel, le bon sens, et la simplification.
  • État de l’art du web : Le document fait référence à des normes et standards reconnus dans le monde du web et plus généralement du numérique. Il s’appuie sur les travaux réalisés par les organismes de normalisation et de standardisation reconnus (ISO, IETF, UIT, W3C, OASIS, OIF...).
  • Méthode : Le référencement des normes et standards s’appuie sur des critères d’adoption explicités dans le document. Ces critères reposent sur la méthode d'évaluation des normes et standards élaborée par la Commission Européenne : CAMSS (Common Assessment Method for Standards and Specifications) pour les technologies de l’information.
  • Uniquement l’interopérabilité : Le périmètre du document est l’interopérabilité principalement technique et syntaxique ; le document n’est donc pas un cadre ou un manuel d’architecture des systèmes d’information, un référentiel d’analyse ou de développement, ni un recueil de solutions techniques.
  • Général : Le RGI concerne l’ensemble des autorités administratives, c’est-à-dire pour mémoire : les collectivités territoriales, tous les organismes publics (y compris la sphère sociale, santé et hospitalière) et les administrations de l’État (administrations centrales et leurs services déconcentrés et décentralisés).
  • Focalisé : Même si une partie significative du document constitue une liste importante de standards, l’objectif est de rester focalisé sur l’essentiel en matière d’interopérabilité entre systèmes d’information, entre applications, entre le poste d’un utilisateur (usager, agent, partenaire, tiers...) et les systèmes d’information des administrations. La notion de profil d’interopérabilité, introduite dans cette nouvelle version, permet de choisir les standards en fonction des cas d’usage, ou des sphères d’emplois, les plus répandus.

1.7 Critères d'adoption retenus

Un standard sélectionné pour le RGI, répond aux critères suivants :

  • Ouvert :La spécification fonctionnelle et technique du standard doit être complète, publique, sans restriction ni d’accès ni de mise en œuvre. La spécification est disponible à coût zéro, (voire à coût faible ou marginal sans toutefois limiter la réutilisation notamment dans des logiciels libres). Il est maintenu par une organisation sans but lucratif (organisme de standardisation, forum, consortium...). Ses évolutions se font sur la base d’un processus de décision transparent, ouvert, et accessible à toutes les parties intéressées. Un calendrier d’évolutions est publié et les parties intéressées sont informées de la teneur des prochaines versions. Les droits du standard sont sous sur une base libre de droits et compatible avec les logiciels libres et les logiciels propriétaires.
  • Pertinent : L’utilité, la nécessité et la simplicité de la mise en œuvre doit être clairement démontrées, reconnues et adoptées massivement par le marché.
  • Mature : Le standard, en plus d’être bien établi et soutenu par les infrastructures technologiques, a démontré sa fiabilité suite à son application dans un contexte réel d’utilisation, sans empêcher les innovations. Son expérimentation ou mise en œuvre pilote ne revêt qu’un caractère démonstratif. Les éléments de preuve doivent être publics, reproductibles sans restriction d’accès aucune. Le standard présente la stabilité nécessaire et les nouvelles versions doivent prendre en compte au moins les problématiques de compatibilité ascendante.
  • Indépendant : Le standard est indépendant de toute infrastructure technologique, logicielle ou bien matérielle d’un constructeur ou d’un éditeur. Son choix ne doit pas imposer des restrictions d’acquisition ou d’utilisation par l’organisme qui l’adopte. Par défaut, ils sont à même de supporter le multilinguisme.
  • Facile à déployer : Le déploiement du standard ne doit pas être contraignant et engendrer des coûts de déploiement supplémentaires en dehors des coûts (humains, organisationnels, matériels...) nécessaires ou induits par la mise en conformité des systèmes telle que rappelée dans le chapitre 1.3, ou ceux inhérents aux défauts ou à l’hétérogénéité des architectures en place.
  • Soutenu par l’industrie : Le standard doit être bien établi dans l’industrie pour son périmètre d’usage. Sa réputation dans le domaine auquel il se rattache doit être solide et démontrée. Les éléments de preuve, ouverts et non réfutables, doivent être disponibles. Des expertises, y compris scientifiques comme la recherche universitaire, autour de son implémentation et de sa maintenance sont proposées par de nombreux prestataires. Ce critère peut venir pondérer ou bien appuyer la maturité d’un standard.

Selon la maturité et l’écosystème du thème étudié, le poids des critères peut se révéler différent. Il faut également noter que la non satisfaction d’un critère n’est pas éliminatoire.

Ces critères imposent donc a minima que ces standards ouverts et interopérables soient implémentés dans des solutions logicielles libres, pour faciliter les tests, l’appropriation, et ne pas imposer de fait l’acquisition de solutions propriétaires coûteuses. Cela n’enlève en rien la liberté des autorités administratives de choisir des solutions éditeurs, mais ce n’est donc en aucune manière une contrainte.

1.8 Périmètre de l'interopérabilité

Le RGI traite des questions d’interopérabilité dans les différents cas illustrés dans le schéma ci- après. Le terme « Autorité Administrative » ou « AA » définit une organisation publique au sens large. Cela peut être une Administration générale, un service territorial déconcentré, un établissement public sous tutelle, une collectivité territoriale, un organisme de la protection sociale, ou de la sphère hospitalière :

Trois principaux cas sont identifiés :

  • Les échanges entre autorités administratives : A↔A ou encore symbolisé A2A.
  • Les échanges entre une autorité administrative et une entreprise (au sens large, une unité légale, que ce soit une entreprise, une personne physique, une association) : A↔B ou encore symbolisé A2B
  • Les échanges entre une autorité administrative et un citoyen : A ↔C ou encore symbolisé A2C

Pour leurs besoins internes, les autorités administratives restent libres du choix des normes, standards et pratiques à mettre en œuvre. Toutefois, il est souhaitable qu’elles suivent par défaut les recommandations du RGI.

Le référentiel d’interopérabilité français doit également s’intégrer dans le contexte européen, défini par les travaux de l’EIF, dont le périmètre est présenté par le schéma ci-dessus.

L’objectif de l’EIF est de favoriser le développement de services en ligne européens (EPS pour European Public Services), en facilitant la coopération entre les administrations des différents États Membres. Le cadre européen propose des recommandations et bonnes pratiques aux niveaux organisationnel, sémantique et technique.

La Commission Européenne recommande à tous les États Membres d’aligner leur cadre d’interopérabilité respectif sur le cadre européen EIF. Un observatoire des cadres nationaux NIFO (National Interoperability Framework Observatory) a été mis en place afin, entre autres, de faciliter cet alignement. Un état des lieux actualisé est en cours par la commission.

1.9 Les différents niveaux d'interopérabilité

Un échange réussi entre parties prenantes nécessite la prise en compte de différentes problématiques qui peuvent se décomposer en « niveaux d’interopérabilité ».

Le schéma ci-après, repris du modèle proposé dans l’EIF, présente quatre niveaux d’interopérabilité. Un cinquième niveau dit syntaxique ou « Syntaxic interoperability » est également identifié et permet de découpler dans le niveau technique, les questions de protocoles d’échanges, des questions de formats d’échanges.

À chaque niveau correspondent des standards et des principes sur lesquels les parties doivent s’aligner pour concevoir et opérer des échanges efficacement.

Niveau politique

Des visions partagées, des orientations et des stratégies convergentes favorisent la coopération, la communication et plus particulièrement les échanges entre les différentes parties prenantes, chacun à leur niveau d’activité.

Niveau juridique

Les échanges doivent se conformer :

  • au cadre légal dont dépendent les parties prenantes (droit national et international, propriété intellectuelle, confidentialité, etc.) ;
  • aux accords contractuels établis entre parties prenantes (modalités de l’échange, niveaux de services, etc.).

Niveau organisationnel

L’interopérabilité organisationnelle est liée aux organisations et aux processus notamment mis en œuvre pour favoriser et opérer les échanges. Elle concerne aussi les compétences et les connaissances associées au fonctionnement de ces organisations.

En termes d’organisation, il s’agit par exemple de définir les rôles et les responsabilités des personnes qui prennent part à l’échange au sein de leur entité. En termes de processus il s’agit de définir qui envoie la donnée, à quel moment, suite à quel événement... mais aussi comment sont partagés les rôles et les responsabilités entre les différentes parties prenantes. L’un des exemples des développements de l’interopérabilité opérationnelle est celui de l’OTAN dans le cadre des théâtres d’opérations communes regroupant plusieurs pays.

Niveau sémantique

La sémantique recouvre à la fois la signification des mots, le rapport entre le sens des mots (homonymie, synonymie, etc.), mais aussi le cycle de vie d’une information, ses règles d’agrégation ou de décomposition, etc. Le sens des mots varie selon les organisations, les métiers, les acteurs et les contextes, tant métiers que culturels. Toute collaboration entre entités demande une communication, au sens d’un échange d’informations. Pour cela, ces entités s'entendent sur la signification des données qu’elles échangent et sur le contexte de cet échange. Il est question ici de concept métier (exemple : une entreprise, un chiffre d’affaires, un revenu fiscal de référence, etc.).

Niveau technique : protocole d’échange et syntaxique

Le niveau technique concerne les questions relatives aux protocoles d’échanges de données, et à leurs formats, mais aussi les conditions et formats de « stockage » de ces données. Il est d’usage de séparer ce niveau en deux parties. Une partie « protocole d’échanges » pour tout ce qui touche aux transports des données, et donc au « tuyau » dans lequel les données circulent. Et une autre partie «syntaxe » pour tout ce qui concerne les formats techniques qui permettent de véhiculer les données (leur structure, leur codification...), indépendamment de leur sens qui lui est traité au niveau sémantique.

1.10 Version du document

Le présent document constitue la version 2 du Référentiel Général d’Interopérabilité.

Version Date Motif :

  • 1.0 (11/11/2009) Publication de l’Arrêté JORF n°0262 du 11 novembre 2009 diffusant officiellement la version 1.0 du RGI
  • 1.9 (24/09/2014) Version de travail partielle préfigurant la version 2.0 du RGI
  • 1.9.6 (23/01/2015) Première version complète de travail préfigurant la version 2.0 du RGI et mise en circulation auprès du réseau des architectes et urbanistes SI des ministères.
  • 1.9.7 15/03/2015) Version corrigée intégrant les premiers retours des ministères et d’un premier cercle d’opérateurs publics, soumise à appel public à commentaires.
  • 1.9.8 (01/06/2015) Projet intégrant les contributions de l’appel public à commentaires.
  • 1.9.9 (15/06/2015) Version intermédiaire diffusée aux DSI ministérielles
  • 1.9.10 31/07/2015) Projet final soumis aux commissions de validation

1.11 Évolutions du RGI

Le Référentiel Général d’Interopérabilité doit pouvoir évoluer fréquemment, afin de s’adapter aux évolutions technologiques, aux évolutions des standards, aux besoins d’interopérabilité du système d’information de l’État, ou bien encore, aux exigences et recommandations de la commission européenne.

Cette présente version est disponible sur le site web suivante : http://references.modernisation.gouv.fr/interoperabilite

L’adresse courriel ci-dessous gérée par la Direction Interministérielle des Systèmes d’Information et de Communication (DISIC) est également accessible : rgi. sgmap @modernisation.gouv.fr

Cette adresse courriel permet de collecter toutes les remarques, critiques, questions et propositions d’évolutions du RGI. Une synthèse des questions pertinentes (sous forme de FAQ) et propositions d’évolution à l’étude sera régulièrement mise en place sur le site web du RGI.

La DISIC anime régulièrement des ateliers de travail interministériel sur l’interopérabilité, réunissant tous les experts du sujet des ministères et des principaux opérateurs de l’État. Un atelier par trimestre sera consacré aux études des propositions d’évolutions qui sont remontées par courriel. Cet atelier particulier est nommé « comité interministériel d’évolution du RGI ». Ce comité soumettra si nécessaire une proposition de nouvelle version du RGI à l’instance de gouvernance mise en place par la DISIC conformément à l’article 2 du décret n° 2014-87914.

1.12 Conformité à cette nouvelle version du RGI

Les autorités administratives sont toutes tenues de suivre les recommandations de la présente version du RGI. L’article 14 de l’ordonnance n° 2005-1516 du 8 décembre 2005 fixe les conditions et les délais de mise en conformité.

De plus tout projet lancé après la date de publication de la présente version doit se conformer à la présente version.

Les autorités administratives s'engagent à publier, vers la DISIC a minima, un bilan sommaire de conformité et une trajectoire de mise en conformité dans les 6 mois suivant la publication officielle de la présente version. Il s’agit d’être transparent sur le niveau de conformité et son évolution dans le temps.

Un guide de conformité et un outil d’auto-diagnostic seront également disponibles sur le site internet du RGI, pour faciliter ce bilan, la mise en place et le suivi de la trajectoire de conformité. Les modalités pratiques seront disponibles sur le site internet du RGI.

14 Décret n° 2014-879 du 1er août 2014 relatif au système d'information et de communication de l'Etat.

  1. Le terme opérateur, ici désigne tout organisme, quel que soit son statut juridique, sous la tutelle d’un ministère ayant des missions de services publics.
  2. http://references.modernisation.gouv.fr/sites/default/files/RGI_Version1 0.pdf
  3. http://references.modernisation.gouv.fr/sites/default/files/Cadre Commun d'Urbanisation du SI de l'Etat v1.0_0.pdf
  4. http://references.modernisation.gouv.fr/sites/default/files/Cadre Commun d'Architecture des Référentiel de données v1.0_0.pdf
  5. http://references.modernisation.gouv.fr/sites/default/files/Présentation Générale Stratégie Plateform.pdf
  6. http://references.modernisation.gouv.fr/securite ou http://www.ssi.gouv.fr/fr/reglementation-ssi/referentiel-general-de-securite/
  7. http://references.modernisation.gouv.fr/accessibilite-numerique
  8. http://references.modernisation.gouv.fr/sites/default/files/Referentiel%20General%20de%20Gestion%20des%20Archives%20R2GA%20-%20octobre%202013.pdf
  9. http://references.modernisation.gouv.fr/charte-internet-de-letat
  10. http://references.modernisation.gouv.fr/socle-logiciels-libres
  11. Article 2 of Decision No 922/2009/EC of the European Parliament and of the Council of 16 September 2009 on interoperability solutions for European public administrations (ISA) OJ L 260, 03.10.2009, p. 20.
  12. AFUL : Association Francophone des Utilisateurs de Logiciels Libres.
  13. Définition de l’Interopérabilité par le groupe de travail Interopérabilité de l’AFUL : http://definition-interoperabilite.info/

2 ORGANISATION DES EXIGENCES D’INTEROPÉRABILITÉ

2.1 Description des standards

Chaque standard identifié dans la présente version du RGI est présenté selon le modèle suivant  :

Niveau Catégorie Sous catégorie

Statut Sigle Nom du standard

Le lien vers la page Wikipedia, en français (en anglais si c’est la seule version disponible) du standard. Suivi d’un très court texte descriptif  : résumé extrait de Wikipedia au moment de la rédaction du présent document.

Organisme de Le nom et le lien vers les spécifications de référence du standard. standardisation

Les standards ont été sélectionnés selon les critères du chapitre 1.7. Plutôt que de « réinventer » une description résumée et propre au RGI de chaque standard, avec tous les risques que cela comporte, il a été choisi d’utiliser Wikipedia comme source documentaire pour la description synthétique du standard. Par construction, Wikipedia est totalement aligné sur la démarche d’élaboration du RGI, décrite au chapitre 1.6. Le contenu de Wikipedia va évoluer indépendamment du RGI, et donc le RGI sera, dans quelques cas, désynchronisé de Wikipedia. C’est en réalité une force pour l’utilisation des standards identifiés d’avoir des informations les plus « à l’état de l’art » possible. Et c’est la raison pour laquelle le lien vers la page Wikipedia a également été inséré en plus du résumé.

Le RGI ne contient volontairement pas d’aide ou de conseil à la mise en œuvre des standards retenus. Le lien vers Wikipedia et la description résumée provenant de Wikipedia ne remplacent évidemment pas les spécifications officielles de référence du standard produites et validées par les organismes de standardisation ou de normalisation. Le lien vers spécification de référence du standard est inclus également dans le cartouche de chaque standard.

De plus, les pages Wikipedia référencées contiennent la plupart du temps des aides précieuses pour la compréhension et l’application des standards. Le RGI étant un document applicable, le choix des pages en langue Française est naturel. Il faut toutefois souligner que les pages en anglais de Wikipedia sont dans la plupart des cas bien plus complètes, précises et évoluent plus rapidement.

Concernant le lien vers les spécifications de référence du standard. Le présent document n’a pas vocation à lister de manière exhaustive l’ensemble des documents de spécifications pour chaque standard. En effet, dans de nombreux cas, les spécifications se composent de plusieurs documents et d’annexes. Il existe toutefois toujours un document central ou chapeau. C’est l’url ou la référence de ce document qui est retenu pour chaque standard.

2.2 Statut et version

À chaque standard est associé un statut pour faciliter la prise en compte et la mise en conformité. Le statut permettra également de gérer la transition dans le temps d’une version du RGI à une autre, et d’une version de standard à une autre. Les statuts retenus sont les suivants  :

           Statut                                          Explication du statut
En observation  
Il s’agit d’un standard en émergence, ou dont la maturité, la mise en
                                œuvre et le soutien par la recherche et/ou l’industrie ne sont pas
                                totalement acquis. Son application est à prendre avec précaution, et
                                après une phase de tests et d’expérimentations qu’il conviendra de
                                partager avec la communauté. Dans le cas où les expérimentations
                                seraient probantes, il passerait dans une version suivante du RGI
                                 au statut « recommandé », dans le cas contraire il serait « retiré »
                                 du référentiel.
Recommandé  
Il s’agit d’un standard qui répond à tous les critères de sélection, et
                                 qui   est   aligné   avec   la   stratégie   de   transformation   et   de
                                 modernisation du système d’information et de communication de
                                 l’État. C’est un standard qui doit être respecté et appliqué par tous.
En fin de vie  
Il s’agit d’un standard en fin de vie, dont le soutien se terminent car
                                 d’autres standards de remplacement émergent. Son application est
                                 à prendre donc également avec précaution. Il est donc considéré
                                 « en sursis », mais si son retrait n’a pas encore été demandé dans
                                 tous les systèmes existants, il ne doit cependant pas être considéré
                                 comme « recommandé » pour tous les nouveaux projets.
Retiré  
Il s’agit d'un standard qui ne répond plus aux critères de sélection ni
                                 à la stratégie de transformation et de modernisation du SI de l’État.
                                 Un tel standard doit donc être retiré dans le cadre d’un plan de dé-
                                 commissionnement, rendu public, par les autorités administratives
                                 qui l’utilisent.
                                 Ce standard pouvait être présent dans la version précédente du
                                 RGI dans un statut en observation, recommandé, ou obligatoire et
                                 dont le retrait doit désormais être planifié.

Les standards sont dans de nombreux cas versionnés. La version ne sera généralement pas mentionnée, ou éventuellement une version a minima sera recommandée. Dans quelques cas où la version est jugée discriminante, elle sera explicitement identifiée avec le standard. Par exemple pour le standard SAML, la version 2 est une évolution majeure de la version 1, et présente des différences importantes pour les questions d’interopérabilité. Seule donc la version 2 (ou une version ultérieure) est recommandée.

Les standards qui ne sont pas listés dans le présent RGI ne peuvent pas être considéré comme « recommandé », ni même à « en observation ». Plus précisément, les standards reconnus utiles pour les questions d’interopérabilité, dans les conditions d’usages définis dans le présent document, sont ceux qui sont listés dans le RGI. Les autres standards, ceux qui ne sont pas cités, ne doivent donc pas être utilisés dans le cadre d’échanges (du périmètre couvert par le RGI).

Le présent RGI n’est donc pas un catalogue complet des standards informatiques sur lesquels un statut a été posé.

2.3 Les standards et la sécurité

Pour de nombreux standards, il existe une version équivalente sécurisée. Le présent RGI identifie parfois les deux versions, quand les deux versions présentent un intérêt pour l’interopérabilité. Le choix de la version, sécurisée ou non, dépend de l’analyse de sécurité. Quel que soit le type de projet ou d’évolution de tout ou partie d’un système d’information, il est rappelé que les autorités compétentes doivent réaliser une analyse de sécurité. Cette analyse dépend du contexte, du niveau de complexité, de criticité, du niveau de sensibilité des données. L’utilisation du RGS (cf. Remarques préalables et documents de référence) est une aide précieuse pour cette analyse, en plus d’être un document applicable par tous les acteurs.

La mise en place et l’utilisation de protocoles sécurisés, nécessite bien souvent d’utiliser des algorithmes de chiffrement avec des longueurs de clefs déterminées. Ces choix sont également à faire en fonction de l’analyse de sécurité, en se basant encore une fois sur le RGS.

Au regard de l’analyse de sécurité, le choix de la version non sécurisée d’un standard peut s’accompagner de mesures de sécurité complémentaires.

2.4 Le profil d’interopérabilité

En plus de la liste des standards retenus, le concept de profil d’interopérabilité est introduit dans cette nouvelle version du RGI. Un profil d’interopérabilité est un ensemble limité de standards à utiliser dans un contexte, un usage déterminé. L’objectif est de cadrer l’utilisation du RGI et d’éviter la prolifération de standards et de combinaison de standards pour un usage donné. La liste des standards du profil est volontairement limitative. Donc, dans le contexte d’usage du profil, aucun autre standard ne devra être utilisé. Et, en fonction des besoins, seule une partie des standards peut s’avérer nécessaire. Le chapitre 6 est consacré à ces profils.

Chaque profil est présenté selon le tableau ci-après.

Numéro Nom du Profil Numéro du profil prérequis

Statut Liste des standards du profil

Court texte descriptif du profil et de son contexte d’utilisation.

Organisme référent pour le profil

Les profils avec un statut de « recommandé » seront à privilégier sur les autres car ils sont alignés avec la stratégie « État plate-forme » et la nécessité de maîtriser la prolifération des choix technologiques, qui conduit à terme inexorablement à accroître la dette technique de l’État.

2.5 Organisation des standards

Les standards présentés sont organisés selon le découpage présenté dans le tableau ci-après pour l’interopérabilité technique et syntaxique. Ce découpage n’a pas la prétention d’être une classification parfaite des standards identifiés. C’est uniquement un moyen pratique d’organisation du document. Certains standards regroupent en réalité plusieurs des catégories ou sous- catégories. Ils sont positionnés dans ce cas dans la catégorie ou sous catégorie principale.

Niveau                      Catégorie                                   Sous catégorie
Technique                   Réseau
Technique                   Transport
Technique                   Session
Technique                   Application                                 Transfert
Technique                   Application                                 Exploitation
Technique                   Application                                 Accès
Technique                   Application                                 Multimédia
Technique                   Application                                 Messagerie
Technique                   Service                                     Identité & Authentification
Technique                   Service                                     Service web
Technique                   Service                                     Orchestration de services
Technique                   Service                                     Géospatial
Syntaxique                  Encodage                                    Caractère
Syntaxique                  Encodage                                    Compression
Syntaxique                  Document
Syntaxique                 Web
Syntaxique                 Structuration des données
Syntaxique                 Structuration des données                 Description d’API
Syntaxique                 Structuration des données                 Identifiant
Syntaxique                 Structuration des données                 Géospatial
Syntaxique                 Structuration des données                 Carnet d’adresse
Syntaxique                 Structuration des données                 Calendrier
Syntaxique                 Traitement de données structurées
Syntaxique                 Traitement de données structurées         Géospatial
Syntaxique                 Multimedia                                Conteneur vidéo
Syntaxique                 Multimedia                                Codec vidéo
Syntaxique                 Multimedia                                Conteneur audio
Syntaxique                 Multimedia                                Codec audio
Syntaxique                 Multimedia                                Image
Syntaxique                 Signature
Syntaxique                 Message de sécurité

2.6 Les organismes de standardisation

L’ensemble des standards retenus sont issus  :

 •   d’organismes de standardisation ou de normalisation internationaux reconnus,
 •   ou bien encore d’organismes publics qui ont produit des cadres normatifs.

Dans quelques cas d’exception, il s’agit de standards de fait spécifiés par une organisation privée. Le tableau ci-après les liste, avec le lien de leur site web.

Sigle Nom et lien

  • AFNOR  : Agence Française de Normalisation
  • AFS  : Archives Fédérales Suisse
  • BnF Bibliothèque national e de France
  • CEN  : Comité Européen de Normalisation
  • DSS  : Direction de la Sécurité Sociale
  • DISIC  : Direction Interministérielle des Systèmes d’Information et de Communication
  • ECMA  : European association for standardizing information and communication systems
  • ETSI  : European Telecommunications Standards Institute
  • IEEE  : Institute of Electrical and Electronics Engineers
  • IETF  : The Internet Engineering Task Force
  • ISO  : Organisation Internationale de Normalisation
  • OASIS  : Organization for the Advancement of Structured Information Standards
  • OGC  : Open Geospatial Consortium
  • OIF  : OpenID Foundation
  • SIAF  : Service Interministériel des Archive s de France
  • UIT  : Union internationale des télécommunications
  • W3C  : World Wide Web Consortium
  • Xiph  : Association à but non lucratif pour le développement de protocoles et logiciels libres

2.7 Actualisation des liens

L’ensemble des liens (URL) a été défini et accédé à la date de publication du présent document. Compte tenu de l’évolution permanente des contenus disponibles sur internet, leur disponibilité, leur complétude ou la qualité des informations mises à dispositions ne peuvent être garanties. Ces liens sont fournis à titre documentaire.


3 INTEROPÉRABILITÉ TECHNIQUE

3.1 Synthèse des standards retenus pour le niveau technique

Les protocoles en fin de vie ou retirés ne sont pas présents dans cette synthèse. Seul les protocoles recommandés ou en observation sont donc listés.

Niveau          Catégorie         Sous Catégorie        Standards

Technique       Réseau                                  IPv6, IPSec
Technique       Transport                               TCP,   UDP,   NTP,   RTP,   SRTP,   RTCP,   TLS
                                                       (SSL)
Technique       Session                                 SSH
Technique       Application       Transfert             HTTP,   HTTPS,   CORS,   FTP,   SFTP,   R66,
                                                       AMQP, AS2
Technique       Application       Exploitation          DNS, DNSSEC
Technique       Application       Accès                 LDAP, LDAPS
Technique       Application       Multimédia            RTSP, H.323, SIP, MGCP
Technique       Application       Messagerie            SMTP,     SMTPS,     S/MIME,     POP3,    POP3S,
                                                       IMAP4, IMAP4S, XMPP, XMPPS, WebRTC
Technique       Service           Identité &            OpenPGP,  SAMLv2.0,  Oauth   2.0,  Open   ID
                                 Authentification      Connect
Technique       Service           Service web           SOAPv1.2,  WSDL ,  UDDI,  MTOM, XOP,  WS-
                                                       Security, WS-Addressing, InterOPS
Technique       Service           Orchestration de      WS-BPEL , WS-CDL
                                 services
Technique       Service           Géospatial            WMS , WFS , TJS, WMTS, CSW, WCS , WPS ,

3.2 Listes des standards pour le niveau technique

3.2.1 Réseau

Technique Réseau

En fin de vie IPv4 Internet Protocol version 4

http://fr.wikipedia.org/wiki/IPv4 Internet Protocol est une famille de protocoles de communication de réseau informatique conçus pour être utilisés par Internet. Les protocoles IP sont au niveau 3 dans le modèle OSI. Les protocoles IP s'intègrent dans la suite des protocoles Internet et permettent un service d'adressage unique, codé sur 32 bits, pour l'ensemble des terminaux connectés.

IETF RFC 791, mise à jour par les RFC 1349, RFC 2474, RFC 6864

Technique Réseau

Recommandé IPv6 Internet Protocol version 6

http://fr.wikipedia.org/wiki/IPv6 Cette nouvelle version du protocole IP est recommandée car elle apporte de nombreuses améliorations, notamment  :

  •   la simplification du routage et des en-têtes des messages / Paquets
  •   l’adressage plus large  : espace d’adresse sur 128 bits au lieu de 32 bits pour IPv4  ;
  •   l’intégration de IPSec  ;
  •   l’amélioration de l’autoconfiguration des réseaux.

Il est donc fortement recommandé de  :

  •   retenir IPv6 qui est assez mature pour être déployé  ;
  •   vérifier avant tout nouveau déploiement de solution, que le soutien IPv6 est assuré et que
      l’interopérabilité avec IPv4 est fonctionnelle  ;
  •   envisager les scénarios de migration d’IPv4 vers IPv6.

IETF RFC 2460

Technique Réseau Sécurisation

Recommandé IPSec Internet Protocol Security

http://fr.wikipedia.org/wiki/Internet_Protocol_Security IPsec est un cadre de standards ouverts pour assurer des communications privées et protégées sur des réseaux IP, par l'utilisation des services de sécurité cryptographiques. IPsec se différencie des standards de sécurité antérieurs en n'étant pas limité à une seule méthode d'authentification ou d'algorithme et c'est la raison pour laquelle il est considéré comme un cadre de standards ouverts. De plus, IPsec opère à la couche réseau (couche 3 du modèle OSI) contrairement aux standards antérieurs qui opéraient à la couche application (couche 7 du modèle OSI), ce qui le rend indépendant des applications, et veut dire que les utilisateurs n'ont pas besoin de configurer chaque application aux standards IPsec

IETF RFC 4301 - 4309

3.2.2 Transport

Technique Transport

Recommandé TCP Transmission Control Protocol

http://fr.wikipedia.org/wiki/Transmission_Control_Protocol Dans le modèle Internet, aussi appelé modèle TCP/IP, TCP est situé au-dessus de IP. Dans le modèle OSI, il correspond à la couche transport, intermédiaire de la couche réseau et de la couche session. Le protocole TCP reste le meilleur composant permettant de fiabiliser les flux de type HTTP, SMTP et FTP.

IETF RFC 79 3, et ses misesà jour.

Technique Transport

Recommandé UDP User Datagram Protocol

http://fr.wikipedia.org/wiki/User_Datagram_Protocol UDP fait partie de la couche transport de la pile de protocole TCP/IP  : dans l'adaptation approximative de cette dernière au modèle OSI, il appartiendrait à la couche 4, comme TCP. Le rôle de ce protocole est de permettre la transmission de données de manière très simple entre deux entités, chacune étant définie par une adresse IP et un numéro de port. Contrairement au protocole TCP, il fonctionne sans négociation. La nature de UDP le rend utile pour transmettre rapidement de petites quantités de données, depuis un serveur vers de nombreux clients ou bien dans des cas où la perte d'un datagramme est moins gênante que l'attente de sa retransmission. Le DNS, la voix sur IP ou les jeux en ligne sont des utilisateurs typiques de ce protocole.

IETF RFC 768

Technique Transport

Recommandé NTP Network Time Protocol

http://fr.wikipedia.org/wiki/Network_Time_Protocol Le Protocole d'Heure Réseau (Network Time Protocol ou NTP) est un protocole qui permet de synchroniser, par réseau informatique, l'horloge locale d'ordinateurs sur un serveur d’heure de référence.

IETF RFC 5905

Technique Transport

Recommandé RTP Real-Time Transport Protocol

http://fr.wikipedia.org/wiki/Real-time_Transport_Protocol Real-Time Transport Protocol (RTP) est un protocole de communication informatique permettant le transport de données soumises à des contraintes de temps réel, tels que des flux média audio ou vidéo. RTP est à l'heure actuelle principalement utilisé comme transport de média pour les services de la voix sur IP ou de vidéo conférence, voire de streaming. En mode unidirectionnel, il est toujours associé avec un autre protocole de signalisation qui gère l'établissement de session et permet l'échange du numéro de port utilisé par les deux extrémités. On peut citer  :

  •   le protocole SIP pour les services de VoIP et de visioconférences ;
  •   le protocole H.323 pour les mêmes services (ancienne génération) ;
  •   le   protocole   RTSP   pour   le   streaming   bien   que   ce   dernier   possède   un   mode
      d'encapsulation TCP.

IETF RFC 3 550

Technique Transport

Recommandé SRTP Secure Real-time Transport Protocol

http://fr.wikipedia.org/wiki/Secure_Real-time_Transport_Protocol Version sécurisée du protocole RTP.

IETF RFC 3711 et sa mise à jour RFC 6904


Technique Transport

Recommandé RTCP Real-time Transport Control Protocol

http://fr.wikipedia.org/wiki/Real-time_Transport_Control_Protocol RTCP est un protocole de contrôle des flux RTP, permettant de véhiculer des informations basiques sur les participants d'une session, et sur la qualité de service. Il repose sur des transmissions périodiques de paquets de contrôle par tous les participants dans la session. Le RTCP est un protocole couplé au RTP.

IETF RFC 3 550

Technique Transport Sécurisation

Recommandé TLS (SSL) Transport Layer Security (TLS), et son prédécesseur

                                        Secure Sockets Layer (SSL)

http://fr.wikipedia.org/wiki/Transport_Layer_Security TLS et son prédécesseur SSL, sont des protocoles de sécurisation des échanges sur Internet. Le protocole SSL était développé à l'origine par Netscape. L'IETF, en a poursuivi le développement en le rebaptisant Transport Layer Security (TLS). On parle parfois de SSL/TLS pour désigner indifféremment SSL ou TLS. TLS (ou SSL) fonctionne suivant un mode client-serveur. Il permet de satisfaire aux objectifs de sécurité suivants :

  •   l'authentification du serveur ;
  •   la confidentialité des données échangées (ou session chiffrée) ;
  •   l'intégrité des données échangées ;
  •   de manière optionnelle, l'authentification du client (mais dans la réalité celle-ci est souvent
      assurée par le serveur).

La version 1.2 ou ultérieure doit être retenu pour ce standard. C’est la seule conforme au RGS.

IETF RFC 5246

3.2.3 Session

Technique Session

Recommandé SSH Secure Shell

http://fr.wikipedia.org/wiki/Secure_Shell SSH est à la fois un programme informatique et un protocole de communication sécurisé. Le protocole de connexion impose un échange de clés de chiffrement en début de connexion. Par la suite, tous les segments TCP sont authentifiés et chiffrés.

IETF RFC 4251, RFC 4252, RFC 4253, RFC 4254

3.2.4 Application

Technique Application Transfert

Recommandé HTTP Hypertext Transfer Protocol

http://fr.wikipedia.org/wiki/Hypertext_Transfer_Protocol HTTP est un protocole de communication client-serveur développé pour le web. HTTP est un protocole de la couche application qui utilise le protocole TCP comme couche de transport. La version 1.1 actualisée en 2014 est recommandée. Il convient de noter que la version 2 de HTTP est en cours de mise en place. Des premières implémentations sont d’ores et déjà disponibles. Même si l’’IETF précise que la version 2 est interopérable avec la version 1.1 pour faciliter son adoption, la version 2 n’est à ce stade pas recommandée. La version sécurisée HTTPS doit être privilégiée, en fonction des objectifs de sécurité.

IETF RFC 7230 à RFC 7237


Technique Application Transfert

Recommandé HTTPS HyperText Transfer Protocol Secure

http://fr.wikipedia.org/wiki/HyperText_Transfer_Protocol_Secure Version sécurisée du protocole HTTP sur le protocole TLS

IETF RFC 2818

Technique Application Transfert

Recommandé CORS Cross-origin resource sharing

http://en.wikipedia.org/wiki/Cross-origin_resource_sharing CORS est une spécification W3C, qui autorise les requêtes Cross-Domain. Elle permet de gérer les accès à une ressource sur un serveur, lié à un domaine, par un script provenant d’un serveur lié à un autre domaine. Il est à noter que cette spécification CORS n’est pas supportée par certaines anciennes versions de navigateurs web.

W3C W3C CORS Recommandation

Technique Application Transfert

Recommandé FTP File Transfer Protocol

http://fr.wikipedia.org/wiki/File_Transfer_Protocol FTP est un protocole de communication destiné à l'échange informatique de fichiers sur un réseau TCP/IP. Il permet, depuis un ordinateur, de copier des fichiers vers un autre ordinateur du réseau, ou encore de supprimer ou de modifier des fichiers sur cet ordinateur. Il faut noter que ce standard est à utiliser dans les cas où l’analyse de risque ne demande pas de sécurisation particulière.

IETF RFC 959, RFC 3659 et RFC 2640

Technique Application Transfert

Retiré FTPS File Transfer Protocol Secure

http://fr.wikipedia.org/wiki/File_Transfer_Protocol_Secure Le FTPS est un protocole de communication destiné à l'échange informatique de fichiers sur un réseau TCP/IP, variante du FTP sécurisé avec les protocoles TLS/SSL. Il permet au visiteur de vérifier l'identité du serveur auquel il accède grâce à un certificat d'authentification. Il permet également de chiffrer la communication. L’utilisation de ce standard n’est pas recommandé et son retrait est demandé au profit du SFTP. En effet, le protocole FTPS ne chiffre que le flux de données et non les enveloppes du flux. Certaines informations passent donc en claire (comme par exemple, le nom des fichiers). Le protocole SFTP lui utilise le protocole FTP dans un tunnel sécurisé SSH, où tout est chiffré.

IETF RFC 4217, RFC 2228 et RFC 2818


Technique Application Transfert

Recommandé SFTP Secure File Transfer Protocol ou SSH File Transfer Protocol

http://fr.wikipedia.org/wiki/Secure_File_Transfer_Protocol http://en.wikipedia.org/wiki/SSH_File_Transfer_Protocol SFTP est une variante du protocole FTP qui « tunnelise » la session à travers une connexion Secure Shell (protocole SSH) pour la sécuriser. Il ne doit donc pas être confondu avec le FTPS qui utilise le protocole TLS. SFTP est exceptionnellement placé « Recommandé » malgré le fait que ses spécifications ne sont pas considérées comme validées au niveau de l’IETF. Elles n’ont toutefois pas évoluées depuis 2006 d’une part, et d’autre part, ce protocole est préférable au FTPS considéré comme moins sécurisé.

IETF Pas de RFC. SSH File Transfer Protocol, Draft 13, July 2006

Technique Application Transfert

En fin de vie PeSIT Protocole d'Echanges pour un Système Interbancaire de

                                         Télécompensation

http://fr.wikipedia.org/wiki/PeSIT PeSIT est un protocole d'échange de fichiers entre systèmes informatiques reliés par une liaison de télécommunication, développé en France. Ce standard est positionné « en fin de vie», ou plus précisément, en sursis, car il n’est supporté que par une seule entreprise. Une alternative ouverte est actuellement en recherche. Son retrait n’est pas encore demandé, mais il n’est donc plus recommandé car propriétaire.

PeSIT http://www.pesit.com/

Technique Application Transfert

En fin de vie PRESTO 2.0 Protocole d’échange standard et ouvert de l’Administration

PRESTO est un protocole d’échange de fichiers défini par l’administration française pour ses besoins propres. Ce standard est positionné « en fin de vie», dans le sens ou une alternative ouverte et maintenue est actuellement en recherche. Son retrait n’est pas encore demandé, mais il n’est donc plus recommandé car non maintenu. Une évolution ouverte vers REST de ce standard permettrait de le repasser à « recommandé ». Les versions 1.0 et 1.1 doivent être considérées chacune comme « retirée » car s’appuyant sur des protocoles à proscrire d’un point de vue sécurité. Seule la version 2.0 (ou ultérieure) est recommandée.

SGMAP PRESTO 2.0

Technique Application Transfert

En observation R66 R66

http://fr.wikipedia.org/wiki/Waarp Le protocole R66 a été conçu pour permettre les fonctionnalités avancées d'un moniteur de transfert de fichiers dans un contexte de production sécurisée. Le protocole R66, et notamment son implémentation waarp, est une alternative ouverte à PeSIT. Mais sa maturité et son maintien ne sont pas jugés suffisants. Il est donc défini « en observation ».

Waarp R66 Protocol


Technique Application Transfert

En observation AMQP Advanced Message Queuing Protocol

http://fr.wikipedia.org/wiki/Advanced_Message_Queuing_Protocol AMQP est un protocole ouvert pour les systèmes de messagerie orientés intergiciel. Il standardise les échanges entre serveurs de messages en se basant sur les principes suivants : orienté message, utilisation de files d'attente, routage (point à point et par diffusion/abonnement), fiabilité et sécurité.

OASIS OASIS AMQP v1.0

Technique Application Transfert

Recommandé AS2 Applicability Statement 2

https://fr.wikipedia.org/wiki/Applicability_Statement_2 AS2 est une spécification décrivant une méthode de transport de données électroniques sécurisée et fiable au travers d'Internet, basée sur le protocole HTTP et le standard S/MIME.

Les données peuvent être en lien avec de l'EDI (Échange de données informatisé) mais peuvent très bien être de tout autre type. AS2 spécifie le mode de connexion, de livraison, de validation et d'acquittement des données. Ce mode de communication enveloppe le message qui est envoyé ensuite par Internet. La sécurité des communications est assurée par des certificats numériques et du chiffrement.

L'implémentation d'AS2 nécessite deux machines, un client et un serveur, reliés tous deux à Internet. Le client peut lui-même être un serveur pour recevoir des données. Le client envoie des données au serveur (trading partner), puis à réception, l'application envoie un acquittement (ou MDN - Message Disposition Notification) à l'émetteur.

IETF RFC 4130

Technique Application Exploitation

Recommandé DNS Domain Name System

http://fr.wikipedia.org/wiki/Domain_Name_System Le DNS est un service permettant de traduire un nom de domaine en informations de plusieurs types qui y sont associées, notamment en adresses IP de la machine portant ce nom.

IETF RFC 1034, RFC 1035, RFC 6895

Technique Application Exploitation

Recommandé DNSSEC Domain Name System Security Extensions

http://fr.wikipedia.org/wiki/Domain_Name_System_Security_Extensions DNSSEC est un protocole permettant de résoudre certains problèmes de sécurité liés au protocole DNS. Il permet de sécuriser les données envoyées par le DNS. Contrairement à d'autres protocoles comme SSL, il ne sécurise pas juste un canal de communication mais il protège les données, les enregistrements DNS, de bout en bout. Ainsi, il est efficace même lorsqu'un serveur intermédiaire trahit.

IETF R FC 4033, RFC 4034 et RFC 4035



Technique Application Accès

Recommandé LDAP Lightweight Directory Access Protocol

http://fr.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol LDAP est à l'origine un protocole permettant l'interrogation et la modification des services d'annuaire. Ce protocole repose sur TCP/IP. Il a cependant évolué pour représenter une norme pour les systèmes d'annuaires, incluant un modèle de données, un modèle de nommage, un modèle fonctionnel basé sur le protocole LDAP, un modèle de sécurité et un modèle de réplication. C'est une structure arborescente dont chacun des nœuds est constitué d'attributs associés à leurs valeurs.

IETF RFC 4510 (la principale)

Technique Application Accès

Recommandé LDAPS LDAP over SSL, ou, Secure LDAP

http://fr.wikipedia.org/wiki/Lightweight_Directory_Access_Protocol LDAPS est un protocole permettant de sécuriser le LDAP par l’utilisation du protocole TLS (SSL).

IETF RFC 4513

Technique Application Multimédia

Recommandé RTSP Real Time Streaming Protocol

http://fr.wikipedia.org/wiki/Real_Time_Streaming_Protocol RTSP est un protocole de communication de niveau applicatif (niveau 7 du modèle OSI) destiné aux systèmes de streaming média. Il permet de contrôler un serveur de média à distance, offrant des fonctionnalités typiques d'un lecteur vidéo telles que « lecture » et « pause », et permettant un accès en fonction de la position temporelle.

RTSP ne transporte pas les données elles-mêmes et doit être associé à un protocole de transport comme RTP

IETF RFC 2326

Technique Application Multimédia

Retiré H.320 H.320

https://fr.wikipedia.org/wiki/H.320 H.320 est un protocole pour la visiophonies à bande étroite sur le réseau RNIS. Les principaux protocoles appartenant à cette suite sont H.221, H.230, H.242, les codecs audio comme G.711 et vidéo comme H.261 et H.263. Il spécifie les caractéristiques techniques des systèmes et équipements de terminaux visiophoniques à bande étroite typiquement pour des services de visioconférence et de visiophonie Ce protocol est clairement à retirer au profit éventuellement du H.323 ou plutot du SIP..

UIT

Technique Application Multimédia

Recommandé H.323 H.323

http://fr.wikipedia.org/wiki/H.323 H.323 regroupe un ensemble de protocoles de communication de la voix, de l'image et de données sur IP. H.323 ressemble davantage à une association de plusieurs protocoles différents et qui peuvent être regroupés en trois catégories : la signalisation, la négociation de codec, et le transport de l'information. Le protocole SIP est recommandé.

UIT H.323 : Packet-based multimedia communications systems



Technique Application Multimédia

Recommandé SIP Session Initiation Protocol

http://fr.wikipedia.org/wiki/Session_Initiation_Protocol SIP est un protocole, de la couche applicative, de gestion de sessions souvent utilisé dans les télécommunications multimédia (son, image, etc.). SIP n'est pas seulement destiné à la VoIP mais aussi à de nombreuses autres applications telles que la visiophonie, la messagerie instantanée, la réalité virtuelle... Il se charge de l'authentification et de la localisation des multiples participants. Il se charge également de la négociation sur les types de média utilisables par les différents participants.

IETF RFC 3261, RFC 66 65

Technique Application Multimédia

Recommandé MGCP Media Gateway Control Protocol

http://fr.wikipedia.org/wiki/Media_Gateway_Control_Protocol MGCP est un protocole permettant de contrôler les passerelles multimédia (Media Gateways) qui assurent la conversion de la voix et de la vidéo entre les réseaux IP et le Réseau Téléphonique Commuté (RTC).

IETF RFC 3435

Technique Application Messagerie

Recommandé SMTP et SMTPS Simple Mail Transfer Protocol

http://fr.wikipedia.org/wiki/Simple_Mail_Transfer_Protocol SMTP, littéralement «  protocole simple de transfert de courrier  », est un protocole de communication utilisé pour transférer le courrier électronique (courriel) vers les serveurs de messagerie électronique. Le SMTPS n’est pas un standard en soi, mais une méthode pour sécuriser le protocole SMTP.

IETF RFC 5321

Technique Application Messagerie

Recommandé S/MIME Secure / Multipurpose Internet Mail Extensions

http://fr.wikipedia.org/wiki/S/MIME S/MIME est une norme de cryptographie et de signature numérique de courriel encapsulés en format MIME. Elle assure l'intégrité, l'authentification, la non-répudiation et la confidentialité des données.

IETF RFC 5750

Technique Application Messagerie

Recommandé POP3 Post Office Protocol

http://fr.wikipedia.org/wiki/Post_Office_Protocol POP est un protocole qui permet de récupérer les courriers électroniques situés sur un serveur de messagerie électronique. En règle générale (configuration par défaut) POP se connecte sur le serveur, récupère le courrier, efface le courrier sur le serveur et se déconnecte. Ce protocole a été réalisé en plusieurs versions respectivement POP1, POP2 et POP3. C'est POP3, ou Post Office Protocol Version 3 qui est utilisé de façon standard.

IETF RFC 1939



Technique Application Messagerie

Recommandé POP3S POP3 over SSL

http://fr.wikipedia.org/wiki/Post_Office_Protocol Version sécurisée du standard POP3 qui utilise le standard TLS (SSL).

IETF RFC 2595

Technique Application Messagerie

Recommandé IMAP4 Internet Message Access Protocol

http://fr.wikipedia.org/wiki/Internet_Message_Access_Protocol IMAP est un protocole qui permet de récupérer les courriers électroniques déposés sur des serveurs de messagerie. Son but est donc similaire à POP3, l'autre principal protocole de relève du courrier. Mais contrairement à ce dernier, il a été conçu pour permettre de laisser les messages sur le serveur.

IETF RFC 3501

Technique Application Messagerie

Recommandé IMAP4S IMAP over SSL

http://fr.wikipedia.org/wiki/Internet_Message_Access_Protocol Version sécurisée du standard IMAP qui utilise le standard TLS (SSL).

IETF RFC 2595

Technique Application Messagerie

Recommandé XMPP et XMPPS Extensible Messaging and Presence Protocol

http://fr.wikipedia.org/wiki/Extensible_Messaging_and_Presence_Protocol XMPP est un ensemble de protocoles standards ouverts pour la messagerie instantanée, et plus généralement une architecture décentralisée d’échange de données. XMPP est également un système de collaboration en quasi-temps-réel et d’échange multimédia via le protocole Jingle, dont la voix sur réseau IP (téléphonie sur Internet), la visioconférence et l’échange de fichiers sont des exemples d’applications. Il existe une version sécurisée de ces protocoles, XMPPS.

IETF RFC 6120, RFC 6121, RFC 6122, RFC 3922, RFC 3923

Technique Application Messagerie

En observation WebRTC Web Real-Time Communication

http://fr.wikipedia.org/wiki/WebRTC WebRTC est une API JavaScript actuellement au stade de brouillon (Draft) développée au sein du W3C et de l'IETF. C'est aussi un canevas logiciel avec des implémentations précoces dans différents navigateurs web pour permettre une communication en temps réel. Le but du WebRTC est de lier des applications comme la voix sur IP, le partage de fichiers en pair à pair en s'affranchissant des plugins propriétaires jusqu'alors nécessaires.

IETF Draft  : http://tools.ietf.org/wg/rtcweb/ W3C Draft  : http://www.w3.org/2011/04/webrtc/



3.2.5 Service

Technique Service Identité & Authentification

Recommandé OpenPGP OpenPGP Message Format

https://fr.wikipedia.org/wiki/OpenPGP OpenPGP est un format de cryptographie. Ce standard décrit le format des messages, signatures ou certificats que peuvent s'envoyer des logiciels comme GNU Privacy Guard. Ce n'est donc pas un logiciel, mais un format pour l'échange sécurisé de données, qui doit son nom au programme historique Pretty Good Privacy (PGP).

IETF RFC 4880

Technique Service Identité & Authentification

Recommandé SAMLv2.0 Security assertion markup language version 2

http://fr.wikipedia.org/wiki/Security_assertion_markup_language SAML est un protocole pour échanger des informations d’authentification et d’autorisation entre des parties, en particulier entre un fournisseur d’identité et un fournisseur de service. Basé sur le langage XML. SAML propose l'authentification unique (en anglais single sign-on ou SSO) sur le web. De cette manière, un utilisateur peut naviguer sur plusieurs sites différents en ne s'authentifiant qu'une seule fois. Dans la pratique SAML est une suite de spécifications. Le SAMLConform notamment décrit les modes opérationnels à destinations des implémentations de SAML 2.0. Il précise les exigences techniques pour la conformité SAML v2.0. Il convient sur ce type de standard d’être explicite sur les modes opérationnels et options retenus.

OASIS SAML specification

Technique Service Identité & Authentification

Recommandé Oauth 2.0 Open standard to authorization

http://en.wikipedia.org/wiki/OAuth OAuth est un protocole ouvert. Il permet d'autoriser un site web à utiliser l'API sécurisée d'un autre site web pour le compte d'un utilisateur. OAuth n'est pas un protocole d'authentification. OAuth permet aux utilisateurs de donner, à un site « consommateur », l'accès à des informations personnelles provenant d'un site «  fournisseur  » de service ou de données, ceci tout en protégeant le pseudonyme et le mot de passe des utilisateurs. Le protocole Oauth peut permettre différentes orchestrations entre les parties prenantes. Il convient de préciser de manière explicite les choix et options retenus sous peine de non interopérabilité des réalisations.

IETF R FC 6749, RFC 6750

Technique Service Identité & Authentification

Recommandé Open ID Connect Open ID Connect protocol

http://en.wikipedia.org/wiki/OpenID_Connect OpenId Connect s'appuie sur le standard Oauth 2,0 auquel il ajoute une couche d’identification. Il permet à un site web client de récupérer l'identité d'un utilisateur (ainsi que d'autres données types) en se basant sur les mécanismes d’authentification d'un serveur tiers au travers d'appels REST.

OpenID Open ID Connect protocol specification Foundation



Technique Service Service web

Recommandé SOAPv1.2 Simple Object Access Protocol

http://fr.wikipedia.org/wiki/SOAP SOAP (ancien acronyme de Simple Object Access Protocol) est un protocole de RPC (protocole réseau permettant de faire des appels de procédures sur un ordinateur distant à l'aide d'un serveur d'applications) orienté objet bâti sur XML. Il permet la transmission de messages entre objets distants, ce qui veut dire qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur. Le transfert se fait le plus souvent à l'aide du protocole HTTP, mais peut également se faire par un autre protocole, comme SMTP. La version 1.2 du protocole est recommandée.

W3C SOAP specification

Technique Service Service web

Recommandé WSDL Web Services Description Language

http://fr.wikipedia.org/wiki/Web_Services_Description_Language WSDL est une grammaire XML permettant de décrire un service web. Le WSDL décrit une interface publique d'accès à un service web, notamment dans le cadre d'architectures de type SOA (Service Oriented Architecture). C'est une description fondée sur le XML qui indique « comment communiquer pour utiliser le service ».

W3C Web Services Description Language

Technique Service Service web

Recommandé UDDI Universal Description Discovery and Integration

http://fr.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration UDDI est un annuaire de services fondé sur XML et plus particulièrement destiné aux services Web. Un annuaire UDDI permet de localiser sur le réseau le service Web recherché.

OAIS http://uddi.xml.org/wiki

Technique Service Service web

Recommandé MTOM Message Transmission Optimization Mechanism

http://fr.wikipedia.org/wiki/Message_Transmission_Optimization_Mechanism MTOM est une méthode d'envoi de données binaires par services Web. MTOM est habituellement utilisé avec XOP (XML-binary Optimized Packaging). Il est recommandé d’associer l’usage de MTOM au protocole SOAPv1.2.

W3C Message Transmission Optimization Mechanism

Technique Service Service web

Recommandé XOP XML-binary Optimized Packaging

http://en.wikipedia.org/wiki/XML-binary_Optimized_Packaging XOP est un mécanisme défini pour la sérialisation d'ensembles d'information XML (XML Information Sets) contenant des données binaires, ainsi que pour leur désérialisation en retour. Il est recommandé d’associer l’usage de XOP au protocole SOAPv1.2.

W3C XML-binary Optimized Packaging



Technique Service Service web

Recommandé WS-Security ou Web Services Security

                 WSS

http://fr.wikipedia.org/wiki/WS-Security WS-Security (Web Services Security) est un protocole de communications qui permet d'appliquer de la sécurité aux services web. Le protocole contient des spécifications sur la façon dont l'intégrité et la confidentialité peuvent être appliquées aux messages de services web. Le protocole WSS inclut des détails sur l'utilisation de SAML et Kerberos, et des formats de certificat comme X.509.

OASIS WSS technical specification

Technique Service Service web

Recommandé WS-Addressing Web Services Addressing

http://en.wikipedia.org/wiki/WS-Addressing WS-Addressing est une spécification de mécanismes de transport neutre qui permet à des services Web de communiquer des informations d'adressage. Deux parties le composent essentiellement : une structure pour communiquer une référence à un service Web final, et un ensemble de propriétés d'adressage de messages qui associent des informations d'adressage à un message particulier.

W3C WS-Adressing working group

Technique Service Service web

Recommandé InterOPS Interopérabilité entre Organismes de la Protection Sociale

http://fr.wikipedia.org/wiki/InterOPS InterOPS est un standard informatique d'interopérabilité, interne à l’administration, qui permet l'établissement d'un espace de confiance entre des organismes de la sphère sociale française, au travers des 3 modèles d'échanges suivants :

  •   InterOPS-A (Application à application) : échanges, en protocole "Web Services", effectués
      soit dans un contexte applicatif sans identification d'un utilisateur, soit dans un contexte
      où   un   utilisateur   d'un   organisme   client   atteint   les   applications   des   organismes
      fournisseurs au travers d’une application locale,
  •   InterOPS-P (Portail à portail) : accès d’un utilisateur d'un organisme client à l'application
      ou   au   service   d'un   organisme   fournisseur,   via   les   portails   web   respectifs   des   2
      organismes.
  •   InterOPS-S (Sphère de confiance) : accès d’un utilisateur à une sphère de confiance
      composée   d’organismes   jouant   le   rôle   d’opérateur   d’authentification   et/ou   le   rôle
      d’opérateur de service.

InterOPS est en réalité un assemblage de standards. Se référer au profil d’interopérabilité n°6. La version 2.0 ou supérieure est recommandée.

DSS Spécification du standard InterOPS



Technique Service Orchestration de services

Recommandé WS-BPEL Web Services Business Process Execution Language

http://fr.wikipedia.org/wiki/Business_Process_Execution_Language BPEL est un langage de programmation destiné à l'exécution des procédures d'entreprise. Le BPEL est issu des langages WSFL (Web Services Flow Language) et XLANG, et est dérivé du XML. Le BPEL vise à rendre possible le programming in the large . Les concepts de programming in the large et programming in the small distinguent deux aspects de l'écriture de procédures asynchrones à long terme qu'on voit généralement dans les procédures d'entreprise. La version 2.0 ou supérieure est recommandée.

OASIS OASIS Web Services Business Process Execution Language Version 2.0

Technique Service Orchestration de services

En observation WS-CDL Web Service Choreography Description Language

http://fr.wikipedia.org/wiki/Chor%C3%A9graphie_des_services_web_WS-* En informatique, la chorégraphie est une généralisation de l’approche par orchestration qui consiste à concevoir une coordination décentralisée des applications, dans laquelle il n’y a pas de machine privilégiée (serveur informatique) mais un réseau de machines interconnectées qui échangent des messages et effectuent des calculs.

W3C Web Service Choreography Description Language

Technique Service Géospatial

Recommandé WMS Web Map Service

http://fr.wikipedia.org/wiki/Web_Map_Service WMS est un protocole de communication standard qui permet d'obtenir des cartes de données géoréférencées à partir de différents serveurs de données. Cela permet de mettre en place un réseau de serveurs cartographiques à partir desquels des clients peuvent construire des cartes interactives.

OGC http://www.opengeospatial.org/standards/wms

Technique Service Géospatial

Recommandé WFS Web Feature Service

http://fr.wikipedia.org/wiki/Web_Feature_Service WFS permet, au moyen d'une URL formatée, d'interroger des serveurs cartographiques afin de manipuler des objets géographiques (lignes, points, polygones...). Il complète le WMS qui permet la production de cartes géoréférencées à partir de serveurs géographiques.

OGC http://www.opengeospatial.org/standards/wfs

Technique Service Géospatial

Recommandé TJS Table Joining Service

TJS défini une manière simple de décrire et d’échanger des données tabulaires contenant des informations sur des objets géographiques.

OGC TJS Specification



Technique Service Géospatial

Recommandé WMTS Web Map Tile Service

http://fr.wikipedia.org/wiki/Web_Map_Tile_Service WMTS est un service web standard qui permet d'obtenir des cartes géoréférencées tuilées à partir d'un serveur de données sur le réseau. Ce service est comparable au Web Map Service mais tandis que le WMS permet de faire des requêtes complexes (dont la reprojection ou la symbolisation de données vecteur) nécessitant une certaine puissance de calcul côté serveur, le WMTS met l'accent sur la performance et ne permet de requêter que des images précalculées (tuiles) appartenant à des dallages prédéfinis. Cela permet aux utilisateurs de construire des cartes interactives en ligne avec une bonne réactivité de l'IHM.

OGC http://www.opengeospatial.org/standards/wmts

Technique Service Géospatial

Recommandé CSW Catalog Service for the Web

http://en.wikipedia.org/wiki/Catalog_Service_for_the_Web CSW (Catalog Service for the Web, parfois nommé Catalog Service - Web) est un standard de publication d'un catalogue d'enregistrements géospatiaux en XML sur Internet (via HTTP). Le catalogue est constitué d'enregistrements qui décrivent des données géospatiales (par ex. KML), des services géospatiaux (par ex. WMS), et des ressources liées. CSW est une partie (ou "profil") du service de catalogue OGC, qui définit des interfaces communes pour la découverte, la navigation et la requête de métadonnées sur des données, des services, et d'autres ressources potentielles.

OGC O GC CSW Specification

Technique Service Géospatial

En observation WCS Web Coverage Service

http://fr.wikipedia.org/wiki/Web_Coverage_Service WCS est un standard fournissant une interface permettant d'effectuer des recherches internet sur des données cartographiées.

OGC http://www.opengeospatial.org/standards/wcs

Technique Service Géospatial

En observation WPS Web Processing Service

http://fr.wikipedia.org/wiki/Web_Process_Service WPS fournit des règles pour normaliser les appels de services de traitement des données géospatiales.

OGC http://www.opengeospatial.org/standards/wps



                                      4 INTEROPÉRABILITÉ SYNTAXIQUE



4.1 Synthèse des standards retenus pour le niveau syntaxique

Les standards retirés ou en fin de vie ne sont pas présents dans cette synthèse.

Niveau          Catégorie        Sous Catégorie        Standards

Syntaxique      Encodage         Caractère             UTF-8

Syntaxique      Encodage         Compression           Bzip2, gzip, ZIP, 7z, TAR

Syntaxique      Document                               ODF,    OOXML,       DocBook,     PDF,    PDF/A,
                                                      EPUB3

Syntaxique      Web                                    HTML,   CSS,   Internet   media   type,   ATOM,
                                                      APP, Javascript, CMIS

Syntaxique      Structuration                          XML,  EXI  XSD,  JSON,  OData,  LDIF,  RDF,
               des données                            OWL2,  SPARQL,  KML,  DOM,  SIARD,  XMI,
                                                      OAIS, SEDA

Syntaxique      Structuration     Description d’API    YAML, RAML
               des données

Syntaxique      Structuration     Identifiant          URI, ARK , ISNI
               des données

Syntaxique      Structuration    Géospatial            Shapefile,   GeoJSON,   GeoSpatial-Metadata,
               des données                            GML

Syntaxique      Structuration    Carnet d’adresse      vCard
               des données

Syntaxique      Structuration    Calendrier            iCalendar
               des données

Syntaxique      Traitement   de                        XSLT,    XPath,    XLink,   XQuery,     XInclude,
               données                                XPointer, XML Signature
               structurées

Syntaxique      Traitement   de  Géospatial            OpenLS, OWS Context, SLD
               données
               structurées

Syntaxique      Multimedia       Conteneur vidéo       MPEG-TS, MP4, MKV, WebM

Syntaxique      Multimedia       Codec vidéo           VP8 , VP9 , H.264, H.265

Syntaxique      Multimedia       Conteneur audio       OGG

Syntaxique      Multimedia       Codec audio           Opus, MP3, Vorbis, AAC , FLAC

Syntaxique      Multimedia        Image                GeoTIFF, PNG, JPEG, SVG

Syntaxique      Signature                              PAdES, XAdES, CAdES, ASIC

Syntaxique      Message       de                       IDMEF, IODEF
               sécurité


4.2 Liste des standards retenus pour le niveau syntaxique

4.2.1 Encodage

Syntaxique Encodage Caractère

Recommandé UTF-8 Universal Character Set Transformation Format - 8 bits

http://fr.wikipedia.org/wiki/UTF-8 UTF-8 est un codage de caractères informatiques conçu pour coder l’ensemble des caractères du « répertoire universel de caractères codés », initialement développé par l’ISO dans la norme internationale ISO/CEI 10646, ce codage est aujourd’hui totalement compatible avec le standard Unicode, en restant compatible avec la norme ASCII limitée à l’anglais « standard » (et quelques autres langues beaucoup moins fréquentes utilisant un jeu réduit de caractères. Les accents ne sont pas supportés par l’ASCII). Ce standard doit être utilisé pour tout échange de données structurées ou non. Le choix d’un encodage UTF-16 voire UTF-32 n’est interdit dans la mesure où ils sont bien UTF.

IETF RFC 3629 et ISO/CEI 10646

Syntaxique Encodage Compression

Recommandé Bzip2 Bzip2

http://fr.wikipedia.org/wiki/Bzip2 bzip2 est à la fois le nom d'un algorithme de compression de données et celui d'un logiciel libre

Bzip http://bzip.org/

Syntaxique Encodage Compression

Recommandé gzip GNU Zip

http://fr.wikipedia.org/wiki/Gzip gzip est à la fois un format de compression et le logiciel libre de compression qui a été créé pour remplacer le programme compress d'Unix.

IETF Spécifications du format gzip  :RFC 1950, RFC 1951 et RFC 1952

Syntaxique Encodage Compression

Recommandé ZIP ZIP

http://fr.wikipedia.org/wiki/ZIP_ (format_de_fichier) Le ZIP est un format conteneur de fichier permettant l’utilisation d'un seul fichier pour stocker plusieurs fichiers et la compression de données (diminution de l'espace occupé sur le support numérique) sans perte de qualité. On peut donc le comparer à la combinaison de tar (archivage) et gzip (compression) dans le cadre d'une archive compressée .tgz. Le format ZIP a un avantage sur les autres formats de compression qui le rend actuellement irremplaçable et le fait préférer dans certains cas  : il intègre un index de son contenu permettant d'extraire à la demande un item de l'archive sans devoir décompresser toute l'archive au préalable (avec donc un gain de temps et d'espace utilisé). Le format ODF correspond en réalité à une archive ZIP.

PKWARE Spécifications du format zip sur le site de pkware

Syntaxique Encodage Compression

Recommandé 7z Seven ZIP

http://fr.wikipedia.org/wiki/7z 7z est un format conteneur ayant une architecture ouverte.

7-zip 7z specification



Syntaxique Encodage Compression

Recommandé TAR Tape Archiver

http://fr.wikipedia.org/wiki/Tar_(informatique) TAR est à la fois un format et un logiciel permettant de contenir dans un seul fichier des fichiers standard des systèmes de type UNIX. Il a été créé dans les premières versions d'UNIX et standardisé par les normes POSIX.1-1988 puis POSIX.1-2001.

IEEE POSIX.1-2001

4.2.2 Document

Syntaxique Document

En fin de vie TXT Text File

http://fr.wikipedia.org/wiki/Fichier_texte En informatique, un fichier texte ou fichier texte brut ou fichier texte simple est un fichier dont le contenu représente uniquement une suite de caractères. Il utilise nécessairement une forme particulière de codage de caractère qui peut être une variante ou une extension du standard ASCII. Il n'existe aucune définition officielle, et les différentes interprétations de ce qu'est un fichier texte se partagent des propriétés essentielles. Ce format est retenu dans le RGI par exception. Il doit être évité car il n’est pas nécessairement interopérable d’une plate-forme à l’autre  ; le codage, par exemple, des retours chariots peut-être problématique. Lorsqu'on utilisera le format TXT il est recommandé de préciser l’encodage UTF-8 et le retour chariot. Il peut être utile de suivre la syntaxe Markdown/CommonMark. Le site http://commonmark.org/ standardise une syntaxe intuitive utilisant Unicode (avec de préférence un codage UTF-8), utilisée sur de nombreux sites web majeurs comme GitHub. Pour tout nouveau projet, il est par contre recommandé d’utiliser le standard XML ou JSON.

Aucun Absence de spécification précise

Syntaxique Document

Recommandé ODF Open Document Format for Office Applications

http://fr.wikipedia.org/wiki/OpenDocument OpenDocument est un format ouvert de données pour les applications bureautiques : traitements de texte, tableurs, présentations, diagrammes, dessins et base de données bureautique. OpenDocument est la désignation d'usage d'une norme dont l'appellation officielle est OASIS Open Document Format for Office Applications, également abrégée par le sigle ODF

OASIS Open Document Format for Office Applications Version 1.2 ISO ISO/IEC 26300-1:2015, ISO/IEC 26300-2:2015, ISO/IEC 26300-3:2015



Syntaxique Document

En observation OOXML Office Open XML strict

http://fr.wikipedia.org/wiki/Office_Open_XML Office Open XML est une norme ISO/CEI 29500 créée par Microsoft, destinée à répondre à la demande d’interopérabilité dans les environnements de bureautique. Ce format (dont les suffixes sont .docx, .xlsx, .pptx...) est utilisé à partir de Microsoft Office 2007, en remplacement des précédents formats Microsoft (reconnus à leurs suffixes tels que : .doc, .xls, .ppt), il est toutefois légèrement différent, pour ces versions d'office, de la norme ISO définitive, qui a tenu compte des remarques des membres de l'organisme normalisateur. Seule la suite Office à partir de la version 2013 est totalement compatible avec la norme (en lecture et en écriture). Le standard est conservé dans le RGI au statut « en observation ». Sa complexité, son manque d’ouverture (notamment dans la gouvernance de la norme) et le strict respect tardif de la norme par Microsoft même n’ont pas permis de réviser son statut. La version « transitionnal » de la norme n’est quant à elle pas recommandée. Pour des besoins d’échanges d’informations sous forme de tableaux qui notamment embarquerait du code, l’utilisation d’OOXML peut être une alternative. C’est toutefois une pratique à encadrer.

ISO ISO/CEI 29500  :2008-2012 ECMA ECMA-376 4th Edition - décembre 2012

Syntaxique Document

Recommandé DocBook DocBook schema

https://fr.wikipedia.org/wiki/DocBook DocBook est un langage de balisage sémantique pour la documentation technique. À l'origine prévu pour écrire de la documentation technique portée sur le domaine informatique (matériel et logiciel), il peut être utilisé pour n'importe quel type de documentation. En tant que langage sémantique DocBook permet à ses utilisateurs de créer du contenu sous une forme neutre vis-à-vis de la présentation qui ne fait que capturer la structure logique du contenu; contenu qui peut ensuite être publié dans une grande variété de formats, notamment HTML, XHTML, EPUB, PDF, pages de man, Web help et HTML Help, sans obliger les utilisateurs à faire des changements dans le contenu source. En d'autres mots, quand un document est écrit dans le format DocBook il devient facilement portable vers d'autres formats. Il résout ainsi le problème de reformatage en n'ayant à écrire qu'une seule fois à base de balises XML. Avantages  :

   •  Le format DocBook ne contient que des données et aucune information de mise en forme
   •  Le format DocBook est adapté aux traitements par lots
   •  Le format DocBook est lisible sans aucun outil spécifique
   •  Le format DocBook est extrêmement facile à exploiter
   •  De très nombreux outils savent exploiter le format DocBook (LibreOffice/OpenOffice, etc.)
   •  Le format DocBook est un format idéal pour l'archivage de par les points précédents

Pour toutes ces raisons DocBook s'est imposé comme le format standard pour la documentation logicielle (notamment dans la communauté Open Source) et commence à être utilisé dans l'industrie.

OASIS DocBook V5



Syntaxique Document

Recommandé PDF Portable Document Format

http://fr.wikipedia.org/wiki/Portable_Document_Format Le PDF est un langage de description de pages dont la spécificité est de préserver la mise en forme d’un fichier – polices d'écritures, images, objets graphiques, etc. – telle qu'elle a été définie par son auteur, et cela quels que soient le logiciel, le système d'exploitation et le matriel utilisés pour l’imprimer ou le visualiser. PDF faisant référence à une grande variété de formats, toutes leurs subtilités ne sont pas explicitées dans le présent document. La version 1.7 du standard est recommandé. Il faut noter que de nombreux logiciels produisent des PDF non strictement conformes à la norme et qui posent donc des problèmes d’interopérabilité. Par ailleurs, Les PDF incorporant des objets non-standard (animations swf par exemple), reposant sur des plugins, ou embarquant des contenus actifs, ou des scripts, ou encore du code exécutable, sont à proscrire.

ISO ISO 32000-1:2008

Syntaxique Document

Recommandé PDF/A Portable Document Format pour l’Archivage

http://fr.wikipedia.org/wiki/PDF/A-1 PDF/A-1 est une version standardisée du PDF. Son usage est très répandu pour conserver et échanger des documents numériques, sur le long terme. Le format PDF/A-1 est fidèle aux documents originaux  : les polices, les images, les objets graphiques et la mise en forme du fichier source sont préservés, quelles que soient l'application et la plate-forme utilisées pour le créer. D’autres versions du PDF/A ont été publiées, notamment les PDF/A-2 et PDF/A-3. L’usage du PDF/A-3 est fortement déconseillé, car il peut encapsuler des formats binaires non maîtrisés.

ISO ISO 19005-1:2005, ISO 19005-2:2011

Syntaxique Document

En observation EPUB3 Electronic Publication

http://fr.wikipedia.org/wiki/EPUB_%28format%29 EPUB est un format ouvert standardisé pour les livres numériques. EPUB est conçu pour faciliter la mise en page du contenu, le texte affiché étant ajusté pour le type d'appareil de lecture. Il est également conçu comme le seul format pouvant à la fois satisfaire les éditeurs pour leurs besoins internes et la distribution. Ce format englobe le standard Open eBook1. La dernière version standardisée, EPUB3, repose sur l'HTML5, ce qui ouvre la voie à de nombreuses extensions. Elle offre de nouvelles caractéristiques telles que la prise en charge de l'affichage de toutes les langues, un espace spécifique pour les métadonnées, un développement de l'interactivité permettant l'ajout de contenus enrichis (graphismes, typographies, multimédias).

IDPF EPUB3 Specification ISO En cours (ISO/IEC TS30135-1 à 7)



4.2.3 Web

Syntaxique Web

Recommandé HTML Hypertext Markup Language

http://fr.wikipedia.org/wiki/Hypertext_Markup_Language HTML est le format de données conçu pour représenter les pages web. C’est un langage de balisage permettant d’écrire de l’hypertexte, d’où son nom. HTML permet également de structurer sémantiquement et de mettre en forme le contenu des pages, d’inclure des ressources multimédias dont des images, des formulaires de saisie, et des programmes informatiques. Il permet de créer des documents interopérables avec des équipements très variés de manière conforme aux exigences de l’accessibilité du web. Il est souvent utilisé conjointement avec des langages de programmation (JavaScript) et des formats de présentation (feuilles de style en cascade CSS). La version 5 de HTML est « recommandée ». La version 5.1 peut être considérée d’ores et déjà « en observation ».

W3C Spécification HTML5

Principe Web

Recommandé Navigateur web

Cette recommandation ne concerne pas un standard de protocole d’échange ou de format, mais porte sur un principe de construction et de mise en œuvre de services numériques. Globalement, les principes de constructions des services numériques de la sphère publique se basent avant tout sur les standards du web. La capacité des navigateurs web, utilisés par les usagers (particulier, professionnel, entreprise, associations) et les agents sur tout type d’équipements mobiles ou fixes, à respecter ces standards devient un élément critique. Il est donc recommandé de s’assurer de la compatibilité des services numériques en lignes avec les navigateurs web suivants (quelque soit la plateforme)  :

  •   Chrome version 35 ou supérieure
  •   Internet Explorer version 10 ou supérieure
  •   Firefox version 31 ou supérieure
  •   Safari version 7 ou supérieure

Syntaxique Web

Retiré XHTML Extensible HyperText Markup Language

http://fr.wikipedia.org/wiki/XHTML XHTML est un langage de balisage servant à écrire des pages pour le web. Conçu à l'origine comme le successeur de HTML, XHTML se fonde sur la syntaxe définie par XML. Le format HTML est recommandé en lieu et place du XHTML.

W3C S pécification XHTML

Syntaxique Web

Recommandé CSS Cascading Style Sheets

http://fr.wikipedia.org/wiki/Feuilles_de_style_en_cascade CSS est un langage informatique qui décrit la présentation des documents HTML et XML. La version 2.1 ou supérieure est à privilégier.

W3C Cascading Style Sheets Specification



Syntaxique Web

Recommandé Internet media type ou type MIME ou Internet media type

                MIME ou Content-type

http://en.wikipedia.org/wiki/Internet_media_type Un Internet media type, à l'origine appelé type MIME ou juste MIME ou encore Content-type, est un identifiant de format de données sur internet. Les identifiants étaient à l'origine définis dans la RFC 2046 pour leur utilisation dans les courriels à travers du SMTP mais ils ont été étendus à d'autres protocoles comme le HTTP ou le SIP.

IETF RFC 6838, RFC 4855

Syntaxique Web

Recommandé ATOM Atom Syndication format

http://fr.wikipedia.org/wiki/Atom Le Format de Syndication Atom est un format ouvert de document basé sur XML conçu pour la syndication de contenu périodique, tel que les blogs ou les sites d'actualités

IETF RFC 4287

Syntaxique Web

Recommandé APP ou AtomPub Atom Publishing Protocol

http://fr.wikipedia.org/wiki/Atom_Publishing_Protocol APP ou AtomPub est un protocole informatique de création, modification et destruction de ressources Web , typiquement au format Atom. Il est surtout utilisé dans le contexte des blogs mais peut servir à d'autres usages. AtomPub est une implémentation technique se voulant respectueuse du style d'architecture REST.

IETF RFC 5023

Syntaxique Web

Recommandé Javascript Javascript

http://fr.wikipedia.org/wiki/JavaScript JavaScript est un langage de programmation de scripts principalement employé dans les pages web interactives mais aussi pour les serveurs. C’est un langage orienté objet à prototype, c’est-à- dire que les bases du langage et ses principales interfaces sont fournies par des objets qui ne sont pas des instances de classes, mais qui sont chacun équipés de constructeurs permettant de créer leurs propriétés, et notamment une propriété de prototypage qui permet d’en créer des objets héritiers personnalisés. En outre, les fonctions sont des objets de première classe.

ECMA ECMA-262 ISO SO/CEI 16262



Syntaxique Web

Recommandé CMIS Content Management Interoperability Services

http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services CMIS est un protocole ouvert qui permet à différents gestionnaires de contenu (CMS) d'interopérer à travers internet. CMIS fournit un modèle de données commun couvrant les types de fichiers et répertoires avec des propriétés génériques pouvant être lues ou écrites. CMIS décrit aussi un système de gestion des droits d'accès, de contrôle de version et offre la possibilité de définir des relations génériques. Il dispose d'un ensemble de services pour modifier ou interroger le modèle de données et peut être utilisé par plusieurs protocoles comme SOAP et REST à l'aide de la convention Atom1. Le modèle est basé sur des architectures communes de systèmes de gestion de documents.

OASIS C MIS OASIS Specification Version 1.1

4.2.4 Structuration de données

Syntaxique Structuration de

                 données

Recommandé XML Extensible Markup Language

http://fr.wikipedia.org/wiki/Extensible_Markup_Language XML ou « langage de balisage extensible » est un langage informatique de balisage générique. Cette syntaxe est dite « extensible » car elle permet de définir différents espaces de noms, c'est- à-dire des langages avec chacun leur vocabulaire et leur grammaire, comme XHTML, XSLT, RSS, SVG… Elle est reconnaissable par son usage des chevrons (< >) encadrant les balises. L'objectif initial est de faciliter l'échange automatisé de contenus complexes (arbres, texte riche…) entre systèmes informatiques hétérogènes (interopérabilité). Avec ses outils et langages associés, une application XML respecte généralement certains principes :

  •   la structure d'un document XML est définie et peut-être validée par un schéma ;
  •   un document XML est entièrement transformable dans un autre document XML.

W3C W3C Recommendation: Extensible Markup Language (XML) 1.0 (Fifth Edition)

Syntaxique Structuration de

                 données

En observation EXI Efficient XML Interchange

http://en.wikipedia.org/wiki/Efficient_XML_Interchange EXI est un format XML binaire. Il permet de coder des documents XML dans un format de données binaire, au lieu de texte brut. L'utilisation d'un tel format XML binaire réduit généralement la verbosité de documents XML, et peut réduire ainsi le coût du parsing (par contre, la performance de l'écriture n’est généralement pas amélioré de façon similaire).

W3C EXI SpecificationEfficient XML Interchange (EXI) Format 1.0 (Second Edition)

Syntaxique Structuration de données

Recommandé XSD XML Schema Definition

http://fr.wikipedia.org/wiki/XML_Schema XML Schema est un langage de description de format de document XML permettant de définir la structure et le type de contenu d'un document XML. Cette définition permet notamment de vérifier la validité de ce document.

W3C http://www.w3.org/XML/Schema



Syntaxique Structuration de données

Recommandé JSON JavaScript Object Notation

http://fr.wikipedia.org/wiki/JavaScript_Object_Notation JSON est un format de données textuelles dérivé de la notation des objets du langage JavaScript. Le principal avantage de JSON est qu’il est simple à mettre en œuvre par un développeur tout en étant complet. Il présente plusieurs avantages, tels que :

  •   il est peu verbeux (XML simplifié), ce qui le rend lisible plus facilement que XMLaussi bien
      par un humain que par une machine ;
  •   il reste facile à apprendre, car sa syntaxe est réduite et non extensible (bien que ne
      souffrant que de peu de limitations) ;
  •   Ses types de données sont connus et simples à décrire.

IETF RFC 7159

Syntaxique Structuration de données

Recommandé OData Open Data Protocol

http://en.wikipedia.org/wiki/Open_Data_Protocol OData est un protocol ouvert qui permet la création et la consommation d’API REST interopérable, de manière simple et standard. Odatat permet aux fournisseurs de données d’exposés sur le web de façon simple, sécurisée et interopérable toutes données (base de données relationnelles, systèmes de fichiers, CMS, sites webs traditionnels, sites collaboratifs...). Il fournit également un accès à l’information depuis un large éventail d’applications, des services, de magasins/stockages de données. Ce standard constitue une extension natuelle des technologies du web  : HTTP, URI, Service RESTful, JSON... Il favorise le mashup de données et les applications composites.

OASIS OData version 4.0 protocol (part 1 à part 3)

Syntaxique Structuration de données

Recommandé LDIF LDAP Data Interchange Format

http://fr.wikipedia.org/wiki/LDAP_Data_Interchange_Format LDIF est un format standardisé d'échange de données, qui permet la représentation des données contenues dans un annuaire LDAP. Il permet également la représentation d'opérations sur les données de l'annuaire (ajout, suppression, modification).

IETF RFC 2849

Syntaxique Structuration de données

En fin de vie DSML Directory Service Markup Language

http://fr.wikipedia.org/wiki/LDAP_Data_Interchange_Format Le Directory Service Markup Language (DSML) est une représentation du contenu d'un annuaire LDAP, permettant l'interrogation et la modification des services d'annuaire dans un réseau informatique.

OASIS



Syntaxique Structuration de données

En fin de vie* CSV Comma-separated values

http://fr.wikipedia.org/wiki/Comma-separated_values CSV est un format informatique d’échange de données ouvert représentant des données tabulaires sous forme de valeurs séparées par des virgules. D’autres variantes de séparateur de champ peuvent être utilisées, notamment lorsque la virgule est un élément signifiant d’une donnée. L’utilisation des séparateurs de champs doit donc être utilisée avec circonspection et adaptée au contexte sous peine de rendre le fichier inexploitable. Ce format est retenu dans le RGI par exception. Il doit être évité car il n’est pas nécessairement interopérable d’une plateforme à l’autre, la spécification précisant uniquement le format des fins de ligne mais ne précisant pas l'encodage à utiliser pour le texte en lui-même et pour les séparateurs (la RFC mentionne uniquement un encodage US-ASCII).

Note importante  : Le standard CSV est au statut recommandé uniquement pour les échanges entre application et utilisateur. Pour tous les autres cas, il est considéré en « fin de vie ». Le standard XML est à privilégier pour les échanges entre applications ou systèmes, qui n’impliquent donc pas d’utilisateurs.

IETF RFC 4180

Syntaxique Structuration de données

Recommandé RDF Resource Description Framework

http://fr.wikipedia.org/wiki/Resource_Description_Framework RDF est un modèle de graphe destiné à décrire de façon formelle les ressources Web et leurs métadonnées, de façon à permettre le traitement automatique de telles descriptions.

W3C Spécifications RDF

Syntaxique Structuration de données

Recommandé OWL2 Web Ontology Language

http://fr.wikipedia.org/wiki/Web_Ontology_Language OWL est un langage de représentation des connaissances construit sur le modèle de données de RDF. Il fournit les moyens pour définir des ontologies web structurées. En pratique, le langage OWL est conçu comme une extension de RDF. OWL est destiné à la description de classes au travers de caractéristiques des instances de cette classe et de types de propriétés. De ce fait, il est plus expressif que RDF, auxquels certains reprochent une insuffisance d'expressivité due à la seule définition des relations entre objets par des assertions. OWL apporte aussi une meilleure intégration, une évolution, un partage et une inférence plus facile des ontologies.

W3C OWL2 specification

Syntaxique Structuration de données

En observation SPARQL SPARQL Protocol and RDF Query Language

SPARQL est un langage de requête et un protocole qui permet de rechercher, d'ajouter, de modifier ou de supprimer des données RDF disponibles à travers Internet. SPARQL est l'équivalent de SQL pour le web. Il permet d’accéder aux données du Web des données. Cela signifie qu'en théorie, on pourrait accéder à toutes les données du Web avec ce standard. L'ambition du W3C est d'offrir une interopérabilité non pas seulement aux niveaux des services, comme avec les services Web, mais aussi aux niveaux des données structurées ou non qui sont disponibles à travers l'Internet. La version 1.1 est à privilégier.

W3C SPARQL version 1.1 specification



Syntaxique Structuration de données

En observation KML Keyhole Markup Language

http://fr.wikipedia.org/wiki/Keyhole_Markup_Language KML est une notation XML destinée à la visualisation et l’annotation de données géographiques pour des navigateurs de type map ou earth sur internet. La visualisation n’inclut pas seulement la présentation graphique de données en 2D ou 3D sur le globe, mais aussi le contrôle par l’utilisateur de la navigation (où il va ? Et où il regarde).

OGC KML Implementation specification

Syntaxique Structuration de données

Recommandé DOM Document Object Model

http://fr.wikipedia.org/wiki/Document_Object_Model DOM est un standard du W3C qui décrit une interface indépendante de tout langage de programmation et de toute plate-forme, permettant à des programmes informatiques et à des scripts d'accéder ou de mettre à jour le contenu, la structure ou le style de documents XML et HTML. Le document peut ensuite être traité et les résultats de ces traitements peuvent être réincorporés dans le document tel qu'il sera présenté.

W3C DOM Level 3 specification

Syntaxique Structuration de données

En observation SIARD Software Independent Archiving of Relational Databases

http://www.bar.admin.ch/dienstleistungen/00823/01911/index.html?lang=fr Le standard SIARD est un format de fichier ouvert pour l'archivage des contenus de bases de données relationnelles. Le SIARD est développé par les Archives Fédérales Suisses (AFS), et est actuellement utilisé par plus d’une cinquantaine d’États. Il s’agit d’une description normative d’un format de fichier servant à la conservation à long terme de bases de données relationnelles. Le format SIARD repose notamment sur les normes ISO Unicode et XML et les normes industrielles SQL1999 et ZIP. L’utilisation de normes reconnues internationalement a pour but de garantir la conservation à long terme et l’accès au modèle très répandu de bases de données relationnelles.

AFS SIARD Formatspezifikation

Syntaxique Structuration de données

Recommandé XMI XML Metadata Interchange

http://fr.wikipedia.org/wiki/XML_Metadata_Interchange XML Metadata Interchange (XMI) est un standard pour l'échange d'informations de métadonnées UML basé sur XML. La version 2.0 ou supérieure est recommandée.

OMG OMG XMI Specification ISO ISO 19503



Syntaxique Structuration de données

Recommandé OAIS Open Archival Information System

http://fr.wikipedia.org/wiki/Open_Archival_Information_System L'Open Archival Information System ou OAIS (Système ouvert d'archivage d'information) est un modèle conceptuel destiné à la gestion, à l'archivage et à la préservation à long terme de documents et de données numériques. Le modèle OAIS constitue une référence décrivant dans les grandes lignes les fonctions, les responsabilités et l’organisation d’un système qui voudrait préserver de l’information, en particulier des données numériques, sur le long terme, pour en garantir l'accès à une communauté d'utilisateurs identifiés. Le long terme est défini comme suffisamment long pour être soumis à l’impact des évolutions technologiques.

ISO ISO 14721:2012 AFNOR NF Z 42-013

Syntaxique Structuration de données

Recommandé SEDA Standard d'échange de données pour l'archivage

http://www.archivesdefrance.culture.gouv.fr/seda/ Le standard d'échange de données pour l'archivage modélise les différentes transactions (transfert, modification, élimination, communication et restitution) qui peuvent avoir lieu entre des acteurs (service d’archives, service producteur, service versant, autorité de contrôle, utilisateur) dans le cadre de l'archivage de données. Le SEDA a fait l’objet d’une normalisation à l’AFNOR qui a abouti à la norme NF Z 44022 Modélisation des échanges de données pour l’archivage.

SIAF https://references.modernisation.gouv.fr/archivage-numerique AFNOR NF Z 44022

Syntaxique Structuration de données Description d’API

En observation YAML YAML Ain't Markup Language ou encore

                                        Yet Another Markup Language

http://fr.wikipedia.org/wiki/YAML YAML est un format de représentation de données par sérialisation Unicode. Il reprend des concepts d'autres langages comme XML, ou encore du format de message électronique tel que documenté par RFC 2822. L'idée de fond de YAML est que toute donnée peut être représentée par une combinaison de listes, tableaux (de hachage) et données scalaires. YAML décrit ces formes de données (les représentations YAML), ainsi qu'une syntaxe pour présenter ces données sous la forme d'un flux de caractères (le flux YAML). La syntaxe YAML se distingue de JSON par le fait qu'il se veut plus facilement lisible par une personne. Il se distingue du XML par le fait qu'il s'intéresse d'abord à la sérialisation de données, et moins à la documentation.

YAML YAML Version 1.2

Syntaxique Structuration de données Description d’API

En observation RAML RESTful API Modeling Language

http://en.wikipedia.org/wiki/RAML_%28software%29 RAML est un langage basé sur YAML pour décrire des API RESTful. Il fournit toutes les informations nécessaires pour décrire des API RESTful ou presque-RESTful. RAML est capable de décrire les API qui ne respectent pas toutes les contraintes de REST (d’où le qualificatif « presque-RESTful »). Il encourage la réutilisation, permet la découverte et le partage de modèle, et vise à l'émergence fondé sur le mérite des meilleures pratiques.

RAML RAML Specification Workgroup



Syntaxique Structuration de données Identifiant

Recommandé URI (UDI) Uniform Resource Identifier

http://fr.wikipedia.org/wiki/Uniform_Resource_Identifier URI définit une syntaxe permettant de construire un identifiant d’une ressource sur un réseau (par exemple une ressource Web) physique ou abstraite, sous la forme d’une courte chaîne de caractères.

IETF RFC 3986

Syntaxique Structuration de données Identifiant

En observation ARK Archival Resource Key

http://fr.wikipedia.org/wiki/Archival_Resource_Key ARK est un système d'identifiants basé sur la norme URI assurant opacité, extensibilité et indépendance, c'est-à-dire les critères nécessaires pour garantir l'identification d'une ressource sur le long terme. Les ARK peuvent désigner des objets de n'importe quel type : textuels, images, logiciels, sites web, aussi bien que des objets physiques, comme des livres, des statues, et même des concepts immatériels.

Une identification pérenne est nécessaire car les protocoles d'accès aux objets (par exemple HTTP ou FTP), aussi bien que les sites d'hébergement, sont sujets à modification.

Un ARK contient une partie imperméable aux changements, et une partie flexible, qui désigne une forme de l'objet, ou un mode d'accès à celui-ci. L'idée est de créer un nom suffisamment stable pour être associé de façon permanente à un objet spécifique, et permettre ainsi d’agir sur l’objet identifié.

BnF ARK CDL ARK Identifiers

Syntaxique Structuration de données Identifiant

En observation ISNI International Standard Name Identifier

http://fr.wikipedia.org/wiki/International_Standard_Name_Identifier L'identifiant ISNI (International Standard Name Identifier) est un identifiant international, normalisé, qui permet d'identifier de façon unique et pérenne des personnes et des organismes.

L’identification internationale, unique, pérenne et fiable que propose l'ISNI est indispensable à l’échange et à la diffusion des données entre différents secteurs. Elle permet le dialogue des différentes briques logicielles qui composent des systèmes d'information très hétérogènes.

Gérés par une agence internationale, les identifiants ISNI (International Standard Name Identifier) présentent toutes les caractéristiques nécessaires : ils sont normalisés (ISO 27729), internationaux, uniques et pérennes. Le système s'est imposé rapidement à l'échelle internationale, avec actuellement près de 9 millions d'entités identifiées dans la base de données. La France participe activement à sa définition, sa gouvernance et sa diffusion, notamment par le biais de la BnF, agence d'enregistrement.

BnF ISNI ISO ISO 27729



Syntaxique Structuration de données Géospatial

Recommandé Shapefile ou SHP fichier de formes

http://fr.wikipedia.org/wiki/Shapefile Le shapefile (SHP) est un format de fichier issu du monde des Systèmes d'Informations Géographiques (ou SIG). Ce format est un standard de facto, largement utilisé par un grand nombre de logiciels libres comme propriétaires

ESRI Shapefile technical description

Syntaxique Structuration de données Géospatial

Recommandé GeoJSON Geographic JSON

http://fr.wikipedia.org/wiki/GeoJSON GeoJSON est un format ouvert d'encodage d'ensemble de données géospatiales simples utilisant la norme JSON (JavaScript Object Notation).

Domaine GeoJSON Format Specification public

Syntaxique Structuration de données Géospatial

Recommandé GeoSpatial- Geographic Information - Metadata

                Metadata

http://fr.wikipedia.org/wiki/ISO_19115 http://en.wikipedia.org/wiki/Geospatial_metadata Ensemble de standards de référence pour la gestion de métadonnées associées aux objets qui ont une extension géographique implicite ou explicite. Utilisés dans la gestion de catalogue de ressources.

ISO ISO 19115 norme chapeau

                 ISO 19110, ISO 19119, ISO 19139

Syntaxique Structuration de données

Recommandé GML Geography Markup Language

http://fr.wikipedia.org/wiki/Geography_Markup_Language GML est un langage dérivé du XML pour encoder, manipuler et échanger des données géographiques. Le GML consiste en un ensemble de schémas XML qui définissent un format ouvert pour l'échange de données géographiques et permettent de construire des modèles de données spécifiques pour des domaines spécialisés, comme l'urbanisme, l'hydrologie ou la géologie. Le GML est interopérable avec toutes les spécifications OpenGIS de l'OGC telles que Web Map Service (WMS) ou Web Feature Service (WFS).

OGC Schémas GML

Syntaxique Structuration de données Carnet d’adresses

Recommandé vCard Visit Card

http://fr.wikipedia.org/wiki/VCard vCard est un format standard ouvert d'échange de données personnelles. Il est utilisé par la plupart des  : logiciels de carnet d’adresses (y compris dans les appareils mobiles), de courriel, de messagerie instantanée.

IETF RFC 6350 , RFC6868



Syntaxique Structuration de données Calendrier

Recommandé iCalendar ou iCal Internet Calendaring and Scheduling

http://fr.wikipedia.org/wiki/ICalendar iCalendar est un standard pour les échanges de données de calendrier. Connu aussi sous le nom d'iCal, il définit la structuration des données dans un fichier de type événement de calendrier.

IETF RFC 5545, RFC6868

4.2.5 Traitement de données structurées

Syntaxique Traitement de données structurées

Recommandé XSLT Extensible Stylesheet Language Transformations

http://fr.wikipedia.org/wiki/Extensible_Stylesheet_Language_Transformations XSLT est un langage de transformation XML de type fonctionnel. Il permet notamment de transformer un document XML dans un autre format, tel PDF ou encore HTML pour être affiché comme une page web.

W3C XSL Transformations

Syntaxique Traitement de données structurées

Recommandé XPath Xpath

http://fr.wikipedia.org/wiki/XPath XPath est un langage (non XML) permettant de localiser une portion d'un document XML.

W3C XML Path Language

Syntaxique Traitement de données structurées

Recommandé XLink XLink

http://fr.wikipedia.org/wiki/XLink XLink permet de créer des liens entre fichiers XML ou portions de fichiers XML (grâce à XPointer). Contrairement aux liens entre fichiers HTML, XLink permet de créer des liens liant plus de deux fichiers.

W3C XML Linking Language

Syntaxique Traitement de données structurées

Recommandé XQuery XQuery

http://fr.wikipedia.org/wiki/XQuery XQuery est un langage de requête informatique permettant non seulement d'extraire des informations d'un document XML, ou d'une collection de documents XML, mais également d'effectuer des calculs complexes à partir des informations extraites et de reconstruire de nouveaux documents ou fragments XML.

W3C XML Query Language

Syntaxique Traitement de données structurées

Recommandé XInclude XInclude

http://en.wikipedia.org/wiki/XInclude Xinclude est un langage permettant d'inclure des fragments de documents XML dans un document XML.

W3C XML Inclusions



Syntaxique Traitement de données structurées

Recommandé XPointer XPointer

http://fr.wikipedia.org/wiki/XPointer XPointer permet de désigner un fragment de document XML en ligne, c'est-à-dire lui-même désigné par une URL. XPointer utilise la syntaxe XPath, enrichie d'options permettant de désigner des portions de document (range).

W3C Xpointer Framework

Syntaxique Traitement de données structurées

Recommandé XML Signature ou XML Signature

                XMLDsig ou
                XML-Dsig ou
                XML-Sig

http://fr.wikipedia.org/wiki/XML_Signature XML Signature (aussi nommé XMLDsig, XML-DSig, XML-Sig) est une recommandation du W3C destinée à permettre l'utilisation de signatures numériques dans les documents XML. Tout comme les techniques générales de cryptographie à clé publique qu'elle met en œuvre, elle permet d'assurer l'authentification, l'intégrité et par voie de conséquence la non-répudiation des données signées, mais en tirant profit de la souplesse offerte par le langage XML.

W3C XML Signature Syntax and Processing

Syntaxique Traitement de données structurées Geospatial

En observation OpenLS Open Location Service

http://www.opengeospatial.org/standards/ols OpenLS spécifie les interfaces dans les procédures de géocodage.

OGC O pen Location Service specification

Syntaxique Traitement de données structurées Geospatial

En observation OWS Context OGC Web Services Context Document

http://www.opengeospatial.org/standards/owc Cette norme décrit les cas d'utilisation, les exigences et le modèle conceptuel pour la norme de codage de contexte OWS. L'objectif de cette norme est de fournir un modèle de base, qui est étendu et codé comme défini dans les extensions à cette norme. Un « document de contexte » spécifie un ensemble de services entièrement configuré qui peut être échangé (avec une interprétation uniforme) entre les clients supportant la norme. Le OWS Context a été créé pour permettre l'échange d'un ensemble de ressources d'information configurées entre des applications, principalement comme un ensemble de services. OWS Context est développé aussi pour du contenu en ligne. L'objectif est de facliter des usages comme la distribution de résultats de recherche, l'échange d'un ensemble de ressources telles que l'OGC Web Feature Services (WFS), Web Map Service (WMS), Web Map Tile Service (WMTS), Web Covergae Service (WCS) et d'autres dans une « image commune des opérations ».

OGC OWS Context documents



Syntaxique Traitement de données structurées Geospatial

Recommandé SLD Styled Layer Descriptor

http://fr.wikipedia.org/wiki/Descripteur_de_style_de_couche SLD est un schéma XML afin de décrire le style, l’apparence, des couches de carte. Il est capable de traiter des données vectorielles et Raster. Une utilisation typique des SLD est destinée aux Web Map Service(WMS) pour que ces derniers puissent interpréter efficacement une couche de données spécifique.

OGC OGC SLD implementation specification

4.2.6 Multimédia – formats et codec audio et vidéo

Les premiers standards concernent les formats ou conteneur vidéo. Il s’agit de format de fichier pouvant contenir divers types de données  : flux vidéo et/ou audio (compressés à l’aide de codec), des sous-titres, des éléments de chapitrage, ainsi que d’autres métadonnées. 4 formats conteneurs ont été identifiés. Les standards correspondant aux codecs retenus sont ensuite listés avec les restrictions de combinaison entre formats et codecs.

Syntaxique Multimédia Conteneur Vidéo

Recommandé MPEG-TS Moving Picture Expert Group – Transport Stream

                                         MPEG-2 partie 1

https://fr.wikipedia.org/wiki/MPEG_Transport_Stream Le protocole MPEG-TS définit les aspects de transport à travers des réseaux pour la télévision numérique. Son but premier est de permettre le multiplexage de vidéo et d'audio, afin de synchroniser le tout. Un flux MPEG-TS peut comprendre plusieurs programmes audio/vidéo, ainsi que des données de description de programmes et de service.

MPEG-TS comprend des fonctionnalités de correction d'erreur pour le transport sur média non- sûr, et est largement utilisé pour la télévision numérique terrestre, par câble ou par satellite. Notamment, les standards de diffusion DVB et l'ATSC font appel à MPEG-TS. C'est un équivalent au Program Stream, protocole visant lui les médias dit sûrs, comme le DVD.

ISO ISO/CEI 13818-1

Syntaxique Multimédia Conteneur Vidéo

Recommandé MP4 Moving Picture Expert Group – 4 part 14 (ainsi que part 1)

https://fr.wikipedia.org/wiki/MPEG-4_Part_14 MP4 est une partie de la norme MPEG-4 spécifiant un format conteneur pour encapsuler des données de type multimédia (audio ou vidéo essentiellement). L'extension de nom de fichier généralement associée à ce format est « .mp4 ». La description du format MP4 a d'abord été spécifiée en s'inspirant du format de fichier QuickTime (tel qu'il était spécifié en 2001), et intégrée dans la mise à jour de la « Part 1 » de MPEG-4 publiée en 2001 (dont le nom précis est ISO/CEI 14496-1:2001). En 2003, une mise à jour des spécifications est intégrée dans la « Part 14 ». La part 14 est donc une évolution de la part 1.

ISO ISO/CEI 14496-14



Syntaxique Multimédia Conteneur Vidéo

Recommandé MKV Matroska, Matriochka ou poupée russe

http://fr.wikipedia.org/wiki/Matroska MKV est un format de fichier multimédia, multiplate-forme et ouvert. Le format MKV est un conteneur vidéo, il peut regrouper au sein d'un même fichier plusieurs pistes vidéo et audio ainsi que des sous-titres et des chapitres. MKV n'est donc pas un codec mais un format conteneur pouvant contenir des flux encodés avec les codecs

Matroska http://www.matroska.org/

Syntaxique Multimédia Conteneur Vidéo

En observation WebM WebM

http://fr.wikipedia.org/wiki/WebM WebM est un format multimédia ouvert principalement destiné à un usage sur le web. Il est basé sur un conteneur dérivé de Matroska, et regroupe des flux vidéos encodés en VP8 et des flux audios encodés en Vorbis1. Ce format fait partie des formats vidéos proposés pour la balise <video> de HTML5. Il est amené à remplacer le premier format ouvert proposé, Theora, et fait concurrence au format H.264. Depuis juillet 2013, le format WebM est capable d'embarquer les successeurs audio et vidéo respectifs de VP8 & Vorbis que sont VP9 et Opus. Ce format de conteneur doit être utilisé avec les combinaisons de codecs suivantes  :

  •   VP8 et Vorbis
  •   VP9 et Opus, ou, VP9 et Vorbis

Format ouvert WebM Container Guidelines

Syntaxique Multimédia Codec Vidéo

Recommandé VP8

https://fr.wikipedia.org/wiki/VP9 VP8 était le dernier codec vidéo de On2 Technologies qui a remplacé VP7, son prédécesseur. Il a été annoncé le 13 septembre 2008. Réalisé à l'origine dans un format propriétaire, il a été racheté par Google qui en a fait un format ouvert le 19 mai 2010 dans le cadre du projet WebM.

IETF RFC 6386 Google

Syntaxique Multimédia Codec Vidéo

En observation VP9 Next Gen Open Video, ou, VP Next, ou VP9

https://fr.wikipedia.org/wiki/VP9 VP9 est un codec vidéo ouvert et sans redevance développé par Google. Au début, au cours de son développement, VP9 a été successivement nommé Next Gen Open Video (NGOV) et VP- Next. VP9 est le successeur de VP8 (créé par On2 avant que Google ne rachète l'entreprise). Chromium, Chrome, Firefox, et Opera supportent le format vidéo VP9 dans l'élément HTML5 video.

Google VP9



Syntaxique Multimédia Codec Vidéo

Recommandé H.264 ou MPEG-4 H.264, ou MPEG-4 AVC (Advanced Video Coding)

                AVC, ou encore
                AVC

http://fr.wikipedia.org/wiki/H.264 H.264, ou MPEG-4 AVC (Advanced Video Coding), ou MPEG-4 Part 10, est une norme de codage vidéo adapté aux différents besoins de l'industrie (vidéophonie, streaming, télévision, mobile).

ISO ISO/CEI 14496-10 UIT UIT-T H.264

Syntaxique Multimédia Codec Vidéo

En observation H.265 ou HEVC H.265, ou High Efficiency Video Coding

http://fr.wikipedia.org/wiki/H.265/HEVC HEVC, ou H.265 est une norme de codage vidéo finalisée depuis janvier 2013, devant succéder au H.264/MPEG-4 AVC (Advanced Video Coding). Ses applications concernent aussi bien la compression des vidéos en très haute définition (2K, 4K, 8K...) que la diminution du débit de transmission sur réseau pour les vidéos en définition standard avec des applications pour la vidéo sur mobile et pour l'extension de l'éligibilité aux services audiovisuels (TV, VoD...) des abonnés aux réseaux fixes (ADSL...).

ISO ISO/IEC 23008- 2 UIT UIT-T H.265

Syntaxique Multimédia Conteneur Audio

Recommandé OGG OGG

http://fr.wikipedia.org/wiki/Ogg OGG est un format de fichier multimedia conteneur. Il peut contenir des pistes audio, vidéo et texte (sous-titres). Il peut y avoir plusieurs pistes de chaque type pour, par exemple, proposer des médias multilingues. Ce format de conteneur est tout particulièrement à utiliser avec le codec audio Vorbis.

Xiph http://www.xiph.org/

Syntaxique Multimédia Audio

En observation Opus Opus Interactive Audio Codec

https://fr.wikipedia.org/wiki/Opus_Interactive_Audio_Codec Opus (à l'origine Harmony) est un format ouvert de compression audio avec pertes, libre de redevances, développé par l'IIETF dans le but d'être utilisé par des applications interactives sur Internet. Opus est la proposition, en format standard, acceptée dans la compétition codec de l'IETF pour un « nouvel Internet à large bande audio », actuellement en développement par le groupe de travail IETF codec. Il est basé sur deux propositions standards, initialement séparées, de la Fondation Xiph.org et Skype Technologies  : respectivement le codec CELT, à faible temps de latence, et le codec SILK, orienté sur la communication à distance. Ce codec audio peut-être utilisé dans les conteneurs vidéo et audio suivant  : MPEG-TS, MP4, OGG, MKV.

IETF RFC 6716



Syntaxique Multimédia Audio

Recommandé MP3 MPEG-1/2 Audio Layer 3

http://fr.wikipedia.org/wiki/MPEG-1/2_Audio_Layer_3 MP3 est la spécification sonore du standard MPEG-1/MPEG-2. MP3 est un format de compression audio capable de réduire significativement la quantité de données nécessaire pour restituer de l'audio, mais qui, pour l'auditeur, ressemble à une reproduction du son original non compressé  : avec une bonne compression la différence de qualité devenant difficilement perceptible. Alors que la lecture du format MP3 est possible sans restriction, la génération de fichiers au format MP3 est soumise à des restrictions de mise en œuvre  : L'algorithme « MPEG-1 Layer 3 » décrit dans les standards fran ISO/CEI IS 11172-3 et ISO/CEI IS 13818-3 est soumis à des redevances (droits commerciaux). Ce codec est à éviter dans les formats conteneurs MPEG-TS et MP4. Il à privilégier dans les fichiers audio standalone.

IETF RFC 3003, RFC 5219

Syntaxique Multimédia Audio

Recommandé Vorbis Vorbis

http://fr.wikipedia.org/wiki/Vorbis Vorbis est un algorithme de compression et de décompression audio numérique plus performant sur le plan de la qualité et du taux de compression que le format MP3, mais moins populaire que ce dernier. Ce codec audio est recommandé avec les formats conteneurs VP8 ou VP9.

Xiph Vorbis

Syntaxique Multimédia Audio

Recommandé AAC Advanced Audio Coding

https://fr.wikipedia.org/wiki/Advanced_Audio_Coding AAC est un codec audio avec perte de données ayant pour but d’offrir un meilleur rapport qualité sur débit binaire que le format plus ancien MPEG-1/2 Audio Layer 3 (plus connu sous le nom de MP3). Le AAC, est une extension du MPEG-2 (ISO/IEC 13818-7) et a été amélioré avec l'avènement du MPEG-4 Version 1, 2 et 3 (ISO/IEC 14496-3) ; Il fait donc partie des extensions MPEG-2 Partie 7 et MPEG-4 Partie 3. Le codec AAC est à privilégier avec le format conteneur MP4 (il est d’ailleurs bien souvent le codec par défaut pour ce conteneur).

ISO ISO/IEC 13818-7 et ISO/IEC 14496-3

Syntaxique Multimédia Audio

Recommandé FLAC Free Lossless Audio Codec

http://fr.wikipedia.org/wiki/Free_Lossless_Audio_Codec FLAC est un codec libre de compression audio sans perte. À l’inverse de codecs tels que MP3 ou Vorbis, il n’enlève aucune information du flux audio. Cette qualité maximale a pour conséquence une quantité d'information plus élevée.

Xiph FLAC Specification

4.2.7 Multimédia – Image



Syntaxique Multimédia Image

Recommandé TIFF Tagged Image File Format

http://fr.wikipedia.org/wiki/Tagged_Image_File_Format TIFF est un format de fichier pour image numérique. Il s'agit d'un format de conteneur (ou encapsulation), à la manière de « avi » ou « zip », c'est-à-dire pouvant contenir des données de formats arbitraires.

Domaine TIFF specification public

Syntaxique Multimédia Image

Recommandé GeoTIFF Geographical Tagged Image File Format

http://fr.wikipedia.org/wiki/GeoTIFF Le GeoTIFF est un standard du domaine public permettant d'ajouter des informations de géoréférencement à une image TIFF (projection, système de coordonnées, datation, ...). L'enregistrement des métadonnées de géoréférencement utilise la possibilité offerte par le format TIFF de pouvoir définir de l'information additionnelle sous forme de tags spécifiques. Le format TIFF définit nativement un certain nombre de tags (voir les Métadonnées TIFF).

L’objectif des spécifications du GeoTIFF consiste à permettre de décrire toute information cartographique associée à une image TIFF provenant d’un système d’imagerie satellite, de photographie aérienne scannée, de cartes scannées, de modèle d’élévation digital, ou du résultat d’analyse géographique.

Domaine GeoTIFF format specification public

Syntaxique Multimédia Image

Recommandé PNG Portable Network Graphics

http://fr.wikipedia.org/wiki/Portable_Network_Graphics PNG est un format ouvert d’images numériques, non destructeur spécialement adapté pour publier des images simples comprenant des aplats de couleurs.

IETF RFC 2083

Syntaxique Multimédia Image

Recommandé JPEG Joint Photographic Experts Group

http://fr.wikipedia.org/wiki/JPEG JPEG est une norme qui définit le format d'enregistrement et l'algorithme de décodage pour une représentation numérique compressée d'une image fixe. JPEG normalise uniquement l’algorithme et le format de décodage. Le processus d'encodage quant à lui est laissé libre à la compétition des industriels et des universitaires. La seule contrainte est que l’image produite doit pouvoir être décodée par un décodeur respectant le standard.

ISO ISO/CEI 10918-1 ITU-T ITU-T Recommendation T.81 www.jpeg.org JPEG Specification



Syntaxique Multimédia Image

En fin de vie JPEG 2000 Joint Photographic Experts Group 2000

http://fr.wikipedia.org/wiki/JPEG_2000 JPEG 2000 est une norme de compression d’images. Elle est capable de travailler avec ou sans perte, utilisant une transformée en ondelettes (méthode d’analyse mathématique du signal). Les performances de JPEG 2000 en compression avec et sans perte sont supérieures à celle de la méthode de compression JPEG ISO/CEI 10918-1. On obtient donc des fichiers d’un poids inférieur pour une qualité d’image égale. De plus, les contours nets et contrastés sont mieux rendus.

JPEG normalise uniquement l'algorithme et le format de décodage. La méthode d'encodage est laissée libre à la concurrence des industriels ou universitaires, du moment que l'image produite est décodable par un décodeur standard. Outre ses performances en compression, JPEG 2000 apporte une multitude de nouvelles caractéristiques telles la scalabilité, les régions d’intérêt, la résistance aux erreurs de transmission, le codage sans pertes, la polyvalence de l’organisation des données, ainsi que les diverses extensions visant une application (interactivité, sécurité, sans fil, etc.) qui font l’intérêt de cette norme. Par ses fonctionnalités avancées, sa capacité à gérer les images de grande taille, ainsi que d’excellentes performances à haut débit, JPEG 2000 s'adresse aux professionnels de l’image, mais n'a pour l'instant que peu d'applications grand public.

ISO ISO/CEI 15444-1 UIT-T ITU-T Recommendation T.800 www.jpeg.org JPEG 2000 Specification

Syntaxique Multimédia Image

En fin de vie GIF Graphics Interchange Format

http://fr.wikipedia.org/wiki/Graphics_Interchange_Format GIF est un format d'image numérique.

W3C GIF Specification

Syntaxique Multimédia Image

Recommandé SVG Scalable Vector Graphics

http://fr.wikipedia.org/wiki/Scalable_Vector_Graphics SVG est un format de données conçu pour décrire des ensembles de graphiques vectoriels et basé sur XML.

W3C Scalable Vector Graphics

4.2.8 Signature

Syntaxique Signature

Recommandé PAdES PDF Advanced Electronic Signature

http://fr.wikipedia.org/wiki/PAdES PAdES est un ensemble de restrictions et d’extensions au format PDF et ISO 32000-1 pour permettre la signature électronique de document PDF.

ETSI PADES Baseline Profile



Syntaxique Signature

Recommandé XAdES XML Advanced Electronic Signatures

http://en.wikipedia.org/wiki/XAdES XAdES est un ensemble d'extensions à la recommandation XML-DSig qui permet la signature électronique avancée de document XML. XAdES définit six profils différents  : XAdES Basic, XAdES-T, XAdES-C, XAdES-X, XadES-X-L et XAdES-A. Le profil utilisé et attendu lors de la mise en place d’échange doit absolument être explicité par les différentes parties.

ETSI XAdES Baseline Profile

Syntaxique Signature

Recommandé CAdES CMS Advanced Electronic Signatures

http://en.wikipedia.org/wiki/CAdES_%28computing%29 CAdES est un ensemble d'extensions pour Cryptographic Message Syntax (CMS) pour la signature électronique avancée de données.

ETSI CadES Baseline Profile

Syntaxique Signature

Recommandé ASIC Associated Signature Containers

ASIC permet l'utilisation de structures de conteneurs pour associer des signatures CadES ou WadES détachées ou des jetons d'horodatage, avec un ou plusieurs objets signés à laquelle elles s’appliquent.

ETSI Associated Signature Containers

4.2.9 Message de sécurité

Syntaxique Message de sécurité

Recommandé IDMEF Intrusion Detection Message Exchange Format

https://fr.wikipedia.org/wiki/Intrusion_Detection_Message_Exchange_Format Utilisé dans le cadre de la sécurité informatique, IDMEF est un format de données qui sert à échanger des rapports d'incidents entre les logiciels de détection d'intrusion, de prévention d'intrusion et de collecte d'informations de sécurité et les logiciels qui doivent interagir avec eux. Les messages IDMEF sont conçus pour pouvoir être traités facilement automatiquement.

La RFC décrit un format et des procédures d'échange entre des sondes de détection d'intrusion et des outils de management qui consolident et corrèlent ces informations. Ce type de format est indispensable pour pouvoir comparer des informations émanant de différents outils et différents éditeurs autour d'une structure commune. Un objet IDMEF contient des dates (création, détection, etc.), une description de la source (IP, process, service, etc.), une description de la cible, une classification... Environ une centaine de champs sont disponibles.

IETF RFC 4765, RFC 4766



Syntaxique Message de sécurité

Recommandé IODEF

IODEF définit un format de partage d'information entre équipe de centres de sécurité. Un objet IODEF décrit fonctionnellement un incident de sécurité et peut inclure des objets IDMEF qui en décrivent l'aspect "technique".

IETF RFC 5070



                                      5 INTEROPÉRABILITÉ SÉMANTIQUE



5.1 Définitions des concepts

Le présent chapitre donne la définition à retenir par tous pour les principaux concepts liés à l’interopérabilité.

         Terme / Concept                                                   Définition
Agent Un agent désigne une personne agissant au nom ou pour le
                                            compte d’une autorité administrative.
Autorité Administrative L’ordonnance de 2005 considère comme autorités
                                            administratives les administrations de l’État, les collectivités
                                            territoriales,     les     établissements     publics     à     caractère
                                            administratif,   les   organismes   gérant   des   régimes   de
                                            protection sociale relevant du code de la sécurité sociale et
                                            du code rural ou mentionnés aux articles L. 223-16 et L.
                                            351-21 du code du travail et les autres organismes chargés
                                            de la gestion d'un service public administratif.
                                            Une autorité administrative est donc une organisation dont
                                            l’existence   juridique   et   ses   missions   de   services   publics
                                            administratifs sont définies dans la loi. Elle peut être une
                                            administration de l’État, un service déconcentré de l’État,
                                            une organisation décentralisée (appelée encore « opérateur
                                            de   l’État »),   une   collectivité   territoriale   ou   l’un   de   ses
                                            établissements.
Donnée Une donnée est une description élémentaire de nature
                                            numérique,   représentée   sous   forme   codée,   d’une   réalité
                                            (chose,   événement,   mesure,   transaction,   etc.)   en   vue
                                            d'être  :
                                                 •   collectée, enregistrée,
                                                 •   traitée, manipulée, transformée,
                                                 •   conservée, archivée,
                                                 •   échangée, diffusée, communiquée.
                                             Il peut être question de donnée structurée, semi-structurée
                                            ou non-structurée.
Données de référence Parmi les données collectées, traitées, manipulées, ou
                                            échangées au sein du système d’information des services
                                            publics, certaines ont des caractéristiques particulières, au
                                            nombre   de   cinq.   Il   est   question   alors   de   données   de
                                            référence. Les cinq caractéristiques sont les suivantes :
                                                 •    1) ces données sont utilisées fréquemment par un
                                                     grand   nombre   d’acteurs   internes   ou   externes
                                                      (organisations, métiers, processus, applications…).
                                                 •   2) la qualité de ces données est critique pour un
                                                     grand   nombre   de   processus.   Elle   conditionne
                                                     directement     l’efficacité     et     l’efficience     de     ces
                                                      processus,   et   donc   plus   globalement   impacte   le
                                                      pilotage de l’action publique.
                                                 •   3)   la   sémantique   de   ces   données,   c’est-à-dire   la
                                                     formalisation du sens et de la signification de ces
                                                     données, est partagée et relativement stable dans le
                                                     temps. L’unicité et la richesse sémantique de ces
                                                     données     est     recherchée     pour     simplifier     les
                                                      processus,   optimiser   leurs   exécutions,   et   apporter
                                                      plus de valeur aux bénéficiaires de ces processus.


                                                 La portée de ces données, c’est-à-dire la couverture
                                                 d’usage de ces données, est également un critère
                                                 clé dans leurs utilisations, et des incompréhensions
                                                 sur   cette   portée   peuvent   impacter   également
                                                 l’efficacité   des   processus.   Il   faut   noter   qu’une
                                                 sémantique stable ne signifie pas qu’une donnée est
                                                 stable.   Certaines   données   de   référence   varient
                                                 beaucoup et souvent dans le temps.
                                             •   4) Ces données ont une durée de vie qui va au-delà
                                                 des processus opérationnels qui l’utilisent. De fait,
                                                 les   données   de   contextualisation   qui   leur   sont
                                                 associées,   c’est-à-dire   leurs   métadonnées,   sont
                                                 critiques.
                                             •   5) La facilité d’accès, la disponibilité de ces données
                                                 et  la  rigueur  de  leur   administration sont  critiques.
                                                 Elles conditionnent l’efficacité et l’efficience globale
                                                 des   solutions   mises   en   place   pour   utiliser   ou
                                                 exploiter ces données : depuis n’importe où, tout le
                                                 temps, et quel que soit le dispositif technique qui en
                                                 a besoin. L’identification des données de référence
                                                 est un sujet particulièrement sensible et conditionne
                                                 l’efficacité des échanges et de l’exploitation de ces
                                                 données        (identifiant    unique       et    partagé).
                                                 L’interopérabilité   des   dispositifs   d’accès   à   ces
                                                 données est une condition de succès.
Fournisseur d’identité - Fournisseur d’authentification  
             Un fournisseur d’identité est une autorité administrative, ou
           encore une entreprise privée, qui à la capacité à fournir une
                                         identité vérifiée d’une personne ou d’une unité légale, avec
                                         un     moyen     d’authentification     permettant     de     valider
                                         l’authenticité de la personne ou unité légale qui souhaite
                                         accéder   à   un   service.   Le   mode   d’authentification   peut
                                         prendre différentes  formes,  dont  le niveau de  preuve de
                                         l’authenticité peut varier selon les besoins de sécurisation et
                                         de confiance.
                                         Les     deux     fonctionnalités     peuvent     être     séparées  :
                                         Fournisseur        d’Identité      simple       et     Fournisseur
                                         d’Authentification   simple.   Dans   ce   cas,   le   Fournisseur
                                         d’authentification   assure   uniquement   l’authenticité   de   la
                                         personne qui se connecte, par rapport à une identité qui elle
                                         est fournie par un Fournisseur d’Identité simple.
Fournisseur de données  
Un fournisseur de données est une autorité administrative,
                                         ou une entreprise privée, détenteur de données  d’intérêt
                                         pour l’écosystème public, au titre de ses missions, et qu’il
                                         met à disposition sous la forme d’API.
                                         Par exemple  : la DGFiP pour le revenu fiscal de référence.
Fournisseur de données contextualisées ou agrégateurs de données ou encore hub de données  
             Un   fournisseur   de   données   contextualisées   joue   un   rôle
        « d’intermédiation » entre un ou plusieurs fournisseurs de
         données   et   un   ou   plusieurs   fournisseurs   de   services
                                         publics, dans le but de  ;
                                             •   éviter la multiplicité des liens directs entre tous les
                                                 fournisseurs   potentiels   de   données,   et   tous   les
                                                 fournisseurs de services,


                                              •    permettre aux fournisseurs de données d’exposer de
                                                   manière  relativement   « standardisée »  et   « brute »
                                                   les   informations   dont   ils   disposent   sans   être
                                                   dépendants   de   tous   les   besoins   potentiels   des
                                                   fournisseurs de services souvent  conditionnés par
                                                   une   réglementation   rigoureuse   « du   droit   à   en
                                                   connaître »,
                                              •    consolider   ou  filtrer   des   informations   de   plusieurs
                                                   sources,
                                              •    favoriser     l’émergence       rapide     de     nouveaux
                                                   usages/services   numériques   s’appuyant   sur   des
                                                   données déjà mises à disposition,
                                              •    faciliter   le   suivi   par   l’usager   des   informations
                                                   diffusées   ou   échangées,   quelles   que   soient   les
                                                   interactions « utilisées ».
                                              •    À   ce   titre,   il   doit   assumer   « la   délégation   de
                                                   confiance »    du(es)     fournisseur(s)    de    données
                                                   d’origine   quant   à   la   bonne   transmission   des
                                                   informations et au respect des conditions d’accès à
                                                   cette information.
Fournisseur de service  
Un fournisseur de service est une autorité administrative, ou
                                          une   entreprise   privée,   apte   à   délivrer   ou   à   opérer   un
                                          service,   avec   une   composante   numérique,   de   manière
                                          directe ou indirecte au profit des usagers.
                                          Par exemple  : une mairie, qui  rend des services pour la
                                          petite enfance.
Personne  
Une personne est un unique être humain titulaire de droits
                                          et d'obligations caractérisé par une identité civile. Le terme
                                          « individu »   est   également   utilisé   pour   désigner   une
                                          personne
                                          Note   :   Une   personne   n'est   pas   nécessairement   une
                                          "personne physique" dans le sens « unité légale » exerçant
                                          une activité économique.
                                          UN/CEFACT definition : An individual human being.
Service  
Un service est un ensemble de prestations mises à
                                          disposition par un acteur (une personne ou un groupe de
                                          personnes), appelé fournisseur, dans le but de produire un
                                          effet pour le bénéfice d’un autre acteur, appelé client, selon
                                          des conditions prédéfinies d’exercice des prestations.
                                          Un service se définit donc par un ou plusieurs  :
                                              •    fournisseur du service  ;
                                              •    contrat   qui   définit   les   conditions   d’exercice   du
                                                   service par le fournisseur  ;
                                              •    produit qui est le résultat des prestations réalisées
                                                   par le fournisseur pour le client  ;
                                              •    interface   qui   définit   les   moyens   par   lesquels   le
                                                   service est rendu.
Unité légale ou Entité légale ou encore Entreprise 
                            Une unité légale est une organisation qui a une existence
                           juridique légale, et dotée de droits et devoirs. Une unité
                     légale peut être  :
                                              •    une   « personne   morale »,   dont   l'existence   est
                                                   reconnue par la loi indépendamment des personnes
          ou des institutions qui la possèdent ou qui en sont
                                                   membres. Une personne morale peut désigner donc
                                                   une   entreprise   de   droit   privé,   mais   aussi   une
                                                   association   ou   encore   une   organisation   de   droit
                                                   public  ;
                                               •   une      « personne       physique »       appelée       aussi
                                                   « entreprise individuelle » qui en tant qu’indépendant
                                                   exerce une activité économique.
Utilisateur  
Un utilisateur désigne une personne qui utilise une ou
                                          plusieurs   applications   informatiques   d’une   ou   plusieurs
                                          autorités   administratives.   Il   peut   être   interne   à   l’autorité
                                          administrative,   un   agent,   ou   externe  :   un   partenaire,   un
                                          usager, un fournisseur, etc.
                                           Un utilisateur peut agir pour son propre compte ou pour le
                                          compte   d’une   unité   légale   ou   bien   encore   d’une   autre
                                          personne.
Usager  
Un usager désigne une personne ou une unité légale
                                          utilisatrice   et/ou   bénéficiaire   d’un   ou   plusieurs   services
                                          publics.
                                           Dans   la   segmentation   des   usagers,   il   est   souvent   fait
                                          distinction entre Personne, Entreprise, et Association.

5.2 Modélisation

Deux standards sont identifiés concernant les travaux de modélisation (quelque soit le niveau de modélisation  : organisation, métier, processus, fonctionnel, applicatif ou encore infrastructure...).

Sémantique Modélisation

Recommandé UML Unified Modeling Language

http://fr.wikipedia.org/wiki/UML_%28informatique%29 UML est un langage de modélisation unifié, à base de notation graphique standardisée. Il est utilisé en développement logiciel, et en conception orientée objet. Ce n’est pas une méthode de modélisation. Il est recommandé d’utiliser la modélisation comme outil de conception et de partage  : pour modéliser des processus, des activités, des données ou des échanges. Il est recommandé d’utiliser la version 2.4 ou supérieure de UML pour ces travaux de modélisation.

OMG OMG Unified Modeling Language specification

Sémantique Modélisation

Recommandé BPMN Business Process Model and Notation

http://fr.wikipedia.org/wiki/Business_Process_Model_and_Notation Le Business Process Model and Notation (BPMN) est une notation graphique standardisée pour modéliser des procédures d'entreprise ou des processus métier. La version 2.0 est recommandée.

OMG OMG BPMN specification



5.3 Description des formats pivots

Il s’agit de décrire sous forme de format pivot (sémantique + syntaxe) les principaux objets métiers transverses échangés entre les autorités administratives et les usagers et entre les autorités administratives elles-mêmes.

Le présent paragraphe est un élément important pour l’interopérabilité mais son contenu est par nature évolutif dans les phases de mise en place, précis, dépendant éventuellement de nombreux autres standards. Il est donc difficile d’intégrer tous les éléments nécessaires dans un chapitre d’un document comme celui-ci. Il sera intégré au site web du RGI sous forme de ressources et de liens, notamment sous forme de schémas XML ou JSON réutilisables. Le présent document référence l’espace numérique où seront listés et décrits tous les formats pivots applicables dans tous les échanges.

À titre d’illustration, le premier format pivot est intégré dans le présent document.

Les travaux de l’ADULLACT15 sur les formats pivots serviront de point de départ à l’enrichissement

de ce chapitre. Les travaux ISA de la commission européenne e-Government Core Vocabularies est également une référence en la matière.

5.3.1 Identité pivot d’une personne

Sémantique Personne

Recommandé IdpPERS Identité Pivot d’une Personne

L’identité pivot décrit la sémantique et le format à utiliser pour tous les échanges concernant les données d’identité qui caractérisent une personne et permettent de l’identifier

DISIC Le présent RGI

La notion d’identité numérique est au cœur de la problématique d’interopérabilité des systèmes d’information de l’écosystème public. La présente version du RGI introduit la définition d’un point de vue sémantique et syntaxique, de l’identité pivot qui devrait être partagée par tous les fournisseurs (d’identité, de services ou de données). Il s’agit du minimum d’informations échangées (minimum set of data) concernant l’identité d’une personne.

15 https://formats-pivots.adullact.net/


                                                                   Acteur

                                                                 Personne

                                                        +Nom de naissance: Nom[1]
                            Sexe                        +Nom d'usage: Nom[0..1]
                                           1     0..*   +Prénoms: Nom[1..*]
                        +Code: Code[1]
                                                        +Date de naissance: Date[1]
                        +Nom: Nom[1]
                                                        +Date de décès: Date[0..1]

                                                          *     *             *
                                              +Nationalité      +Pays de naissance
                                                       *     1          0..1     Lieu de naissance

                                                    Pays                         Commune

                                             +Code Pays: code[1]       +Code commune: Code[1]
                                             +Nom: Nom[1]              +Nom: Nom[1]

1

                                                                            Division territoriale
                                                                      1..*
                                                                          +Code: Code[1]           0..*
                                                 organise territorialement +Nom: Nom[1]

                                                                        *

                                               Type de division      1                       0..1
                                                  territoriale
                                                                                            organise territorialement
                                            +Nom: Nom[1]                Commune
                                                                        Canton
                                                                        Arrondissement
                                                                        Département
                                                                        Région

                                         Modèle UML de l’Identité Pivot d’une Personne

Le modèle UML ci-dessous présente les concepts concernés par l’identité d’une personne.

Définitions  :


Personne  
cf. 5.1
                                                    En   complément  :   Une   personne   se   caractérise   par   un
                                                    ensemble d'informations qui caractérise son état civil  : son
                                                    sexe,   sa   localisation   de   naissance   qui   se   compose
                                                    principalement du pays de naissance, et pour les personnes
                                                    nées en France, du département et de la commune (qui
                                                    sont des éléments de division du territoire français).
Pays  
constituant une entité géographique et humaine.
                                                    Il faut noter que les notions de Pays, de Nation et d’État
                                                    peuvent sensiblement différer. Le Pays est une désignation
                                                    géographique, une Nation désigne un peuple, alors qu'un
                                                    État désigne les institutions fonctionnant sur un territoire.
                                                    Le   Code   Géographique   (COG)   de   l'INSEE   identifie   et
                                                    codifie la liste des pays, reconnus par la France.
                                                    Il faut également noter l'existence de la norme ISO 3166-2
                                                    qui codifie au niveau international l'ensemble des pays.
Division territoriale  
Une division territoriale est un découpage du territoire d'un
                                                   pays. Dans le cas de la France, les divisions territoriales
                                                   peuvent          jouter       plusieurs         rôles  :       circonscriptions
                                                   administratives (lieux d'intervention de l’État à travers ses
                                                   services   déconcentrés),   circonscription   électorale   (cadre
                                                   dans   lequel   se   tient   un   scrutin),   collectivités   territoriales
                                                   (territoires   dotés   de   la   personnalité   juridique   et   qui
                                                   s'administrent librement).
                                                   Si   l'on   prend   le   périmètre   de   la   France   métropolitaine,
                                                   l'organisation   territoriale   du   territoire   est   la   suivante  :
                                                   Régions,   départements,   cantons,   communes.   Il   existe
                                                   également   des   regroupements   de   divisions   territoriales  :
                                                   l'inter-région,     ou     les     intercommunalités     (métropole,
                                                   communauté     urbaine,     communauté     d'agglomérations,
                                                   communauté de communes).
Sexe  
Ensemble des caractéristiques anatomiques et des
                                                   éléments fonctionnels distinguant le mâle de la femelle.
Format pivot d'échange  

Le schéma ci-après synthétise le format pivot retenu pour l’identité d’une personne.

                                                       Identité Pivot Personne
                                            +Identifiant: Id[1]
                                            +Nom de naissance: Nom[1]
                                            +Nom d'usage: Nom[0..1]
                                            +Prénoms: Nom[1..*]
                                            +Sexe: Code ISO5218[1]
                                            +Date de naissance: Date ISO8601[1]
                                            +Pays de naissance: Code INSEE[1]
                                            +Lieu de naissance: Code INSEE[0..1]
                                            +Adresse email de contact: EmailAdress[0..1]
                                            +Adresse postale de contact: PostaleAdress[0..1]
                                            +Numéro de téléphone de contact: PhoneAdress[0..1]

Le tableau ci-dessous établit la correspondance avec les attributs du format pivot du règlement Européen eIDAS16, le Minimum Data Set (MDS).

                                                                                                                  Norme et
                             Obligat

Nom du champ Format nomenclature de

                             oire
                                                                                                                  référence

Identifiant de la Oui Identifiant univoque de la personne dans le cadre eIDAS UTF-8 personne Identifiant unique de la personne dans le cadre de Fournisseur

                                        de service Français.

eIDAS MDS Attributes : String Unique Identifier

Nom de naissance Oui String UTF-8

                                        Au moins 1 lettre de l'alphabet.

eIDAS MDS Attributes : Constitué de : Family Name at Birth • lettres de l'alphabet latin en majuscules ou

                                                   minuscules ou accentuées,
                                             •     caractères spéciaux : espace, tiret, apostrophe.
                                        Type INSEE : ChaineFrancaisOfficielType
                                        [A-Za-zÀÂÄÇÉÈÊËÎÏÔÖÙÛÜŸàâäçéèêëîïôöùûüÿÆŒæœ \-']*

Prénoms Oui String UTF-8

                                        Au moins 1 lettre de l'alphabet.

eIDAS MDS Attributes : Constitué de : First Names at Birth • lettres de l'alphabet latin en majuscules ou

                                                   minuscules ou accentuées,

16 Identification électronique et les services de confiance pour les transactions électronique au sein du marché intérieur



                                                                                                              Norme et
                           Obligat

Nom du champ Format nomenclature de

                           oire
                                                                                                              référence
                                            •    caractères spéciaux : tiret, apostrophe
                                       Les différents prénoms doivent être séparés par le caractère
                                       point virgule « ; ».
                                       Type INSEE : ChaineFrancaisOfficielType
                                       [A-Za-zÀÂÄÇÉÈÊËÎÏÔÖÙÛÜŸàâäçéèêëîïôöùûüÿÆŒæœ \-']*

Sexe Oui Code Sexe international ISO 5218

                                       0 = inconnu

eIDAS MDS Attributes : 1= homme Gender 2 = femme

                                       3 et 4 utilisés par l'INSEE pour les immatriculations en cours
                                       de personnes étrangères
                                       (\d{1})
                                       Note : une correspondance avec le Code Sexe INSEE est
                                       possible avec masculin=M et féminin=F.
                                        Type INSEE  : SexeType
                                       M|F

Date de naissance Oui Date ISO 8601,

                                       AAAA-MM-JJ                                                             format étendu

eIDAS MDS Attributes : Type INSEE  : DateType Date of Birth (\d{4})-(\d{2})-(\d{2})

Pays de naissance Oui Code du Pays de naissance ISO 3166-2 ISO 3166-2

                                        Type INSEE  : CodePaysIsoType

eIDAS MDS Attributes : [A-Z]{2} Place of Birth

                                       Note : Une correspondance avec le Code du Pays du COG                  COG de l'INSEE
                                        Type INSEE  : CodePaysouTerritoireEtrangerType
                                       99[0-9]{3}

Lieu de naissance Oui Code de la Commune du COG COG de l'INSEE

                                        Type INSEE  : CodeCommuneType

eIDAS MDS Attributes : (([0-8][0-9AB])|(9[0-8AB]))[0-9]{3} Place of Birth

Nom d'usage Non String

                                       Au moins 1 lettre de l'alphabet.

eIDAS MDS Attributes : Constitué de : Current Family Name • lettres de l'alphabet latin en majuscules ou

                                                 minuscules ou accentuées,
                                            •    caractères spéciaux : espace, tiret, apostrophe.
                                       Type INSEE : ChaineFrancaisOfficielType
                                       [A-Za-zÀÂÄÇÉÈÊËÎÏÔÖÙÛÜŸàâäçéèêëîïôöùûüÿÆŒæœ \-']*

Adresse courriel de Non Adresse courriel RFC 3696 contact

Adresse postale de Non Adresse postale contact Type INSEE : AdressePostaleType

eIDAS MDS Attributes : Current Address

Adresse téléphonique Non Numéro de téléphone E.123 de contact Norme E.123 de l’ITU



                                           6 PROFILS D’INTEROPÉRABILITÉ



6.1 Introduction

Un profil d’interopérabilité est un ensemble limité de standards, un groupe de spécification à utiliser dans un contexte opérationnel, un usage déterminé. L’objectif est d’aider aux choix de standard, cadrer l’utilisation des standards et éviter leur prolifération pour un usage donné. La liste des standards retenus pour un profil donné est donc volontairement limitative et correspond à un ensemble cohérent de fonctionnalités, de recommandations d’emploi à appliquer. Ce chapitre constitue une première version d’identification et de définition des profils . Il a vocation à être corrigé, complété et précisé dans le temps notamment sur les recommandations d’emplois des standards retenus  : version, compatibilité entre standard, options à retenir, restrictions d’usage, points clés de mise en œuvre.

Dans le contexte d’usage du profil, le choix des standards doit s’effectuer parmi la liste proposée.

6.2 Synthèse des profils

Les profils retenus sont résumés dans le tableau ci-après.

n°     Pré-            Nom du Profil                                   Standards
     requis

P1    aucun    Fondations Etat Plateforme         IPv4/ IPv6, TCP, HTTPS, CORS, TLS, URI, JSON,
                                                 OData,   Internet   media   type,   SFTP,   Javascript,
                                                 HTML, ATOM, CSS, Oauth 2.0, Open ID Connect,
                                                 CMIS,        RDF,      SPARQL,         PDF,       JPEG,
                                                 WebM+VP9+Opus, RAML

P2    P1       Web service SOAP                   SOAPv1.2, WSDL , MTOM, XOP, XML, XSD, UDDI,
                                                 SAMLv2.0,      WS-Security,     WS-Addressing,      XML
                                                 Signature

P3    P1       Communication                      H.323, SIP, MGCP, XMPP, MKV, MP4, H.264, VP8,
              interpersonnelle et                OGG, MP3, Vorbis, SVG, ZIP, 7z, SMTPS, POP3S,
              Bureautique                        IMAP4S, iCal, vCard, PDF, ODF, EPUB3

P4    P1       Archivage                          SEDA, OAIS, PDF/A, ODF, XML, SIARD, ZIP, TAR,
                                                 FLAC, MIME

P5    P1       Géomatique                         GML,   KML,  WFS ,   WMS,  WCS ,   WPS,  WMTS ,
                                                 CSW,   GeoJSON,   ATOM,   Shapefile,   GeoJSON,
                                                 GeoSpatial-Metadata,       OpenLS,     OWS   Context,
                                                 GeoTIFF, JPEG 2000

P6    P2       Interopérabilité des               InterOPS
              Organismes de la Protection
              Sociale

P7    P1       Orchestration                      WS-BPEL , WS-CDL

P8             Conception de système              UML, BPMN, XMI

P9    P1       Signature électronique             PAdES, XAdES, CAdES, ASIC


6.3 Description des profils

P1                 Fondations Etat Plateforme                                                        aucun

Recommandé         IPv4/ IPv6, TCP, HTTPS, CORS, TLS, URI, JSON, OData, Internet media type,
                  SFTP, Javascript, HTML, ATOM, CSS, Oauth 2.0, Open ID Connect, CMIS, RDF,
                  SPARQL, PDF, JPEG, WebM+VP9+Opus, RAML

Le profil « Fondations Etat Plateforme » constitue le socle de base en matière d’interopérabilité
pour tous les échanges de type A2C, A2B et A2A. Il concerne plus particulièrement les échanges
entre  : les usagers, les « fournisseurs de services », les « fournisseurs de données », et la brique
mutualisée « FranceConnect » tels que définis dans la stratégie Etat Plateforme17.

Le style d’architecture à retenir est REST  -  Representational State Transfer. Ce n’est  ni un
protocole ni un format, mais un ensemble de règles d’architecture. Ce style d’architecture doit
respecter 6 contraintes suivantes  :
   •   Client-serveur : les responsabilités sont séparées entre le client et le serveur. L'interface
       utilisateur   est   séparée   de   celle  du  stockage   des  données.   Cela   permet   à  ces  deux
       interfaces d'évoluer indépendamment.
   •   Sans état : chaque requête d'un client vers un serveur doit contenir toute l'information
       nécessaire pour permettre au serveur de comprendre la requête, sans avoir à dépendre
       d'un contexte conservé sur le serveur. Cela libère de nombreuses interactions entre le
       client  et le serveur, mais oblige  le client  à conserver localement  toutes  les données
       nécessaires au bon déroulement d’une requête sur un serveur.
   •   Mise en cache : le serveur envoie une réponse qui donne l'information sur la propension
       de cette réponse à être mise en cache, comme la fraîcheur, sa date de création, si elle
       doit être conservée dans le futur. Cela permet à des serveurs mandataires de décharger
       les contraintes sur le serveur et aux clients de ne pas faire de requêtes inutiles. Cela
       permet également d'améliorer l'extensibilité des serveurs.
   •   Une interface uniforme : cette contrainte agit selon 4 règles essentielles.
            •   L'identification des ressources : chaque ressource est identifiée unitairement
            •   La manipulation des ressources à travers des représentations : les ressources ont
                des représentations définies.
            •   Un message auto-descriptif : les messages expliquent leur nature. Par exemple, si
                une   représentation   en   HTML   est   codée   en   UTF-8,   le   message   contient
                l'information nécessaire pour dire que c'est le cas.
            •   Hypermédia   comme   moteur   d'état   de   l'application   :   chaque   accès   aux   états
                suivants de l'application est décrit dans le message courant.
   •   Un système hiérarchisé par couches : les états de l'application sont identifiés par des
       ressources individuelles. Toute l'information n'est pas envoyée dans une seule ressource
       unique. Les requêtes/réponses entre le client et le serveur augmentent et donc peuvent
       faire baisser la performance d'où l'importance de la mise en cache, etc. Le bénéfice est
       que cela rend beaucoup plus flexible l'évolution du système.
   •   Code-On-Demand (facultatif) : la possibilité pour les clients d’exécuter des scripts obtenus
       depuis le serveur. Cela permet d'éviter que le traitement ne se fasse que du côté serveur
       et permet donc de  faire évoluer les fonctionnalités du client au cours du temps. En
       revanche   cela   réduit   la   visibilité   de   l'organisation   des   ressources.   Un   état   devient
       dépendant du client et non plus du serveur ce qui contredit la règle 2. Il faut donc être
       prudent en utilisant cette contrainte.

Les termes REST et RESTful sont devenus des termes marketing pour rendre les services plus
attractifs. Bien souvent, les services Web se réclamant de REST ne le sont pas. Tout au plus, ils
appliquent le protocole HTTP de manière un peu plus conventionnelle. La communauté Web
attachée aux principes de REST et la nature hypermedia des applications a décidé d'utiliser
dorénavant le terme HATEOAS, qui est une abréviation pour Hypermedia as the Engine of

17  Se référer à la présentation de la stratégie Etat Plateforme disponible sur le site  :
http://references.modernisation.gouv.fr/strategie-du-si-de-letat




P1                Fondations Etat Plateforme                                                  aucun

Application State.

La gestion des identités et des accès doit être mise en place par le protocole Open ID Connect
(surcouche à Oauth 2.0).

Ce profil n’a pas la prétention de couvrir tous les cas d’échanges. Les échanges entre systèmes
nécessitant  une  gestion  de  type transactionnelle  avec  des  structures  de  données  complexe
pourraient nécessiter des mécanismes complémentaires à ce profil (notamment le profil P2, ou
dans la sphère de la « protection sociale » le profil P6).

Direction Interministérielle des Systèmes d’Information et de Communication (DISIC)

P2                Web service SOAP                                                            P1

Recommandé        SOAPv1.2,  WSDL ,  MTOM,  XOP,  XML,  XSD,  UDDI,  SAMLv2.0,  WS-Security,
                 WS-Addressing , XML Signature, PRESTO 2.0

Le profil « Web service SOAP » est un profil à la fois alternatif et complémentaire pour les
mêmes types d’échanges que le profil Fondations Etat Plateforme. Ce profil est à retenir dans les
cas où des investissements préalables à la sortie de cette version 2 du RGI ont été réalisés
autour d’architectures de services SOAP. En l’absence d’investissement préalable c’est le profil
n°1 Fondations Etat Plateforme qui est recommandé, car plus simple dans sa mise en œuvre.
Toutefois, la réalisation d'échanges qui nécessitent une gestion transactionnelle (notamment de
type transaction longue par exemple) nécessitera d'utiliser ce profil.

Direction Interministérielle des Systèmes d’Information et de Communication (DISIC)

P3                Communication interpersonnelle et Bureautique                               P1

Recommandé        H.323,  SIP,  MGCP,  XMPP,  MKV,  MP4,  H.264,  VP8,  OGG,  MP3,  Vorbis,  SVG,
                 ZIP, 7z, SMTPS, POP3S, IMAP4S, iCal, vCard, PDF, ODF, EPUB3

Ce profil regroupe tous les cas d’échange entre personnes (entre agents, entre usager et agent)
de type messagerie, messagerie instantanée, audio ou visio conférence, etc.
Ce profil porte également l’interopérabilité des échanges de documents entre personnes, ou
entre systèmes et personnes. Les formats PDF et ODF doivent être considérés comme des
formats pivots, le premier, PDF, pour les documents non modifiables, et le second, ODF, pour les
documents modifiables.
Ces choix n’imposent rien en termes de choix de logiciels de bureautique, mais uniquement sur
les fonctions de conversion intégrées aux outils de travail collaboratif (fonction de conversion à la
volée lors de l’insertion ou la récupération d’une pièce jointe dans un mail par exemple, ou à
l’insertion d’un document dans un outil de partage, dans un réseau social d’entreprise, etc.).

Direction Interministérielle des Systèmes d’Information et de Communication (DISIC)




P4                 Archivage                                                                          P1

Recommandé         SEDA, OAIS, PDF/A, ODF, XML, SIARD, ZIP, TAR, FLAC, MIME

L’archivage numérique nécessite de prendre en compte les problématiques d’interopérabilité sur
le moyen voire long terme et peut, dans certain cas, aller en contradiction avec les besoins de
l’interopérabilité  immédiate.   Il  repose  sur   une  modélisation  conceptuelle  partagée  au  niveau
internationale (OAIS).

D’un   point   de   vue   technique,   cette   interopérabilité   repose   sur   la   prise   en   compte   des
caractéristiques   des   supports   physiques   permettant   la   conservation   des   données,   leur
surveillance   et   leur   migration   sur   d’autres   supports  ;   elle   concerne   aussi   la   réplication   des
données/documents sur des sites distants.

D’un   point   de   vue   syntaxique,   cette   interopérabilité   repose   sur   la   prise   en   compte   des
caractéristiques de formats de documents/données et leur capacité à être prise en charge sur le
moyen et le long terme.
On distingue trois catégories de formats dans le contexte de l’archivage numérique  :
   •   des formats de gestion et d’échange, pour les besoins d’interopérabilité immédiate avec
       des systèmes d’archivage  : SEDA, ZIP, TAR, XML, JSON, CSV  ;
   •   des formats de diffusion/consultation, non pérennisables à long terme, mais utiles pour
       des besoins à court terme  : JPEG, MP3  ;
   •   des formats de conservation, considérés comme une garantie sur le moyen voire le long
       terme  :  MIME,  TIFF,  PDF/A,  FLAC,  ODF  (pour conservation d’éléments dynamiques ou
       de calcul au-delà de la nature graphique du PDF, type tableur), SVG, CSV, JSON, XML,
       MP4.   Les   formats  SIARD  et  JPEG   2000  sont   en   observation.   Cette   liste   est   non
       exhaustive et susceptible de modifications en fonction de l’état de l’art.

Pour les documents devant être conservés sur le long terme et enregistrés a posteriori dans un
format   de   conservation,   il   est   conseillé   de   conserver   également   une   copie   dans   le   format
d’origine. Certains formats utilisés peuvent être des conteneurs qui acceptent des contenus avec
différents   codages.   Sans   pouvoir   préciser   tous   ces   codages,   il   est   important   d'en   avoir
conscience pour permettre d'effectuer des contrôles.

Ce profil précise plusieurs versions de format traduisant une grande variabilité cachée derrière
les noms employés. Il est important de bien distinguer ces versions pour garantir un archivage
pérenne. Des aides (recommandations, jeux d’essais, outils, etc.) pour la gestion des formats et
leur   migration  dans  le  temps  seront   proposés  sous  l’autorité   du   Comité   interministériel   aux
Archives de France (CIAF).

Service Interministériel des Archives de France (SIAF), au nom du Comité Interministériel aux
Archives de France (CIAF)

P5                 Géomatique                                                                         P1

Recommandé         GML,   KML,   WFS ,   WMS,   WCS ,   WPS,   WMTS ,   CSW,   GeoJSON,   ATOM,
                  Shapefile,  GeoJSON,  GeoSpatial-Metadata,  OpenLS,  OWS Context,  GeoTIFF,
                  JPEG 2000, SLD

L’information géographique présente une part importante des échanges entre les administrations.
Le besoin de localiser des événements, des données, des activités, des objets est croissant pour
une meilleure étude de l’impact des politiques publiques.
Le présent profil identifie les principaux standards recommandés en la matière.

Conseil National de l’Information Géographique (CNIG), en particulier la commission données




P6                InterOPS ou                                                                    P2
                 Interopérabilité des Organismes de la Protection Sociale

Recommandé         InterOPS

Le profil InterOPS repose sur le standard InterOPS, qui s’appuie lui-même sur le profil « Web
service SOAP » défini par la Direction de la Sécurité Sociale, et géré par le GIP MDS pour les
échanges   internes   à   la   sphère   Protection   &   Sécurité   Sociale.   Il   est   recommandé   dans   ce
périmètre d’échange.

GIP Modernisation des Déclarations Sociales (GIP MDS)

P7                Orchestration                                                                  P2

Recommandé        WS-BPEL , WS-CDL

Le profil Orchestration repose sur le profil « Fondations Etat Plateforme ». Il le complète avec les
standards nécessaires à l’orchestration de l’exécution de services distribués.

Direction Interministérielle des Systèmes d’Information et de Communication (DISIC)

P8                Conception de système                                                          P1

Recommandé         UML, BPMN, XMI

La transformation du système d’information de l’Etat nécessite la coopération d’un grand nombre
d’acteurs intervenant dans la définition, la conception, mais aussi la réalisation, l’intégration et
l’exploitation de système. Le besoin d’échange entre ces acteurs d’éléments de conception est
donc   critique   dans   la   réussite   des   projets   de   transformation.   Il   s’agit   dans   bien   des   cas
d’éléments   de   modélisation   (processus,   données,   échanges,   architecture,   etc.).   Le   profil
« Conception de système » identifie les standards recommandés pour ces échanges.

Direction Interministérielle des Systèmes d’Information et de Communication (DISIC)

P9                Signature électronique                                                         P1

Recommandé         PAdES, XAdES, CAdES, ASIC

Ensemble des standards définissant les formats de signature électronique.

Direction Interministérielle des Systèmes d’Information et de Communication (DISIC)


                                                                              7 ANNEXES



7.1 Tableaux de synthèses des standards

7.1.1 technique

Niveau          Catégorie        Sous Catégorie       Standards

Technique       Réseau                                IPv6, IPSec

Technique       Transport                             TCP,   UDP,   NTP,   RTP,   SRTP,   RTCP,   TLS
                                                     (SSL)

Technique       Session                               SSH

Technique       Application      Transfert            HTTP,   HTTPS,   CORS,   FTP,   SFTP,   R66,
                                                     AMQP, AS2

Technique       Application      Exploitation         DNS, DNSSEC

Technique       Application      Accès                LDAP, LDAPS

Technique       Application      Multimédia           RTSP, H.323, SIP, MGCP

Technique       Application      Messagerie           SMTP,    SMTPS,     S/MIME,    POP3,    POP3S,
                                                     IMAP4, IMAP4S, XMPP, XMPPS, WebRTC

Technique       Service          Identité &           OpenPGP,  SAMLv2.0,  Oauth   2.0,  Open   ID
                                Authentification     Connect

Technique       Service          Service web          SOAPv1.2,  WSDL ,  UDDI,  MTOM, XOP,  WS-
                                                     Security, WS-Addressing, InterOPS

Technique       Service          Orchestration de     WS-BPEL , WS-CDL
                                services

Technique       Service          Géospatial           WMS , WFS , TJS, WMTS, CSW, WCS , WPS ,

7.1.2    Syntaxique

Niveau          Catégorie        Sous Catégorie       Standards

Syntaxique      Encodage         Caractère            UTF-8

Syntaxique      Encodage         Compression          Bzip2, gzip, ZIP, 7z, TAR

Syntaxique      Document                              ODF,    OOXML,      DocBook,     PDF,    PDF/A,
                                                     EPUB3

Syntaxique      Web                                   HTML,   CSS,   Internet   media   type,   ATOM,
                                                     APP, Javascript, CMIS

Syntaxique      Structuration                         XML,  EXI  XSD,  JSON,  OData,  LDIF,  RDF,
               des données                           OWL2,  SPARQL,  KML,  DOM,  SIARD,  XMI,
                                                     OAIS, SEDA

Syntaxique      Structuration    Description d’API    YAML, RAML
               des données

Syntaxique      Structuration    Identifiant          URI, ARK , ISNI
               des données

Syntaxique      Structuration    Géospatial           Shapefile,   GeoJSON,   GeoSpatial-Metadata,
               des données                           GML

Syntaxique      Structuration    Carnet d’adresse     vCard
               des données

Syntaxique      Structuration    Calendrier           iCalendar
               des données




Niveau          Catégorie        Sous Catégorie       Standards

Syntaxique      Traitement   de                       XSLT,     XPath,    XLink,   XQuery,    XInclude,
               données                               XPointer, XML Signature
               structurées

Syntaxique      Traitement   de  Géospatial           OpenLS, OWS Context, SLD
               données
               structurées

Syntaxique      Multimedia       Conteneur vidéo       MPEG-TS, MP4, MKV, WebM

Syntaxique      Multimedia       Codec vidéo          VP8 , VP9 , H.264, H.265

Syntaxique      Multimedia       Conteneur audio      OGG

Syntaxique      Multimedia       Codec audio          Opus, MP3, Vorbis, AAC , FLAC

Syntaxique      Multimedia       Image                GeoTIFF, PNG, JPEG, SVG

Syntaxique      Signature                              PAdES, XAdES, CAdES, ASIC

Syntaxique      Message      de                        IDMEF, IODEF
               sécurité

7.1.3 Profil

n° Pré- Nom du Profil Standards

    requis

P1 aucun Fondations Etat Plateforme IPv4/ IPv6, TCP, HTTPS, CORS, TLS, URI, JSON,

                                               OData,   Internet   media   type,   SFTP,   Javascript,
                                               HTML, ATOM, CSS, Oauth 2.0, Open ID Connect,
                                               CMIS,        RDF,      SPARQL,         PDF,      JPEG,
                                               WebM+VP9+Opus, RAML

P2 P1 Web service SOAP SOAPv1.2, WSDL , MTOM, XOP, XML, XSD, UDDI,

                                               SAMLv2.0,      WS-Security,    WS-Addressing,      XML
                                               Signature

P3 P1 Communication H.323, SIP, MGCP, XMPP, MKV, MP4, H.264, VP8,

             interpersonnelle et               OGG, MP3, Vorbis, SVG, ZIP, 7z, SMTPS, POP3S,
             Bureautique                       IMAP4S, iCal, vCard, PDF, ODF, EPUB3

P4 P1 Archivage SEDA, OAIS, PDF/A, ODF, XML, SIARD, ZIP, TAR,

                                               FLAC, MIME

P5 P1 Géomatique GML, KML, WFS , WMS, WCS , WPS, WMTS ,

                                               CSW,   GeoJSON,   ATOM,   Shapefile,   GeoJSON,
                                               GeoSpatial-Metadata,       OpenLS,     OWS   Context,
                                               GeoTIFF, JPEG 2000

P6 P2 Interopérabilité des InterOPS

             Organismes de la Protection
             Sociale

P7 P1 Orchestration WS-BPEL , WS-CDL

P8 Conception de système UML, BPMN, XMI

P9 P1 Signature électronique PAdES, XAdES, CAdES, ASIC </pre>

7.2 Suivi des évolutions

Suite aux nouvelles orientations du RGI, un certain nombre de normes et standards ne sont plus couverts dans cette version. Il s’agit essentiellement d’éléments couvrant des besoins spécifiques à un contexte propre à un ministère ou étant devenu obsolètes.