RGI
Sommaire
- 1 1 CONTEXTE, DÉFINITIONS ET OBJECTIFS
- 1.1 1.1 Introduction
- 1.2 1.2 Remarques préalables et documents de référence
- 1.3 1.3 Cadre législatif
- 1.4 1.4 Définitions
- 1.5 1.5 Objectifs du RGI
- 1.6 1.6 Démarche et partis pris
- 1.7 1.7 Critères d'adoption retenus
- 1.8 1.8 Périmètre de l'interopérabilité
- 1.9 1.9 Les différents niveaux d'interopérabilité
- 1.10 1.10 Version du document
- 1.11 1.11 Évolutions du RGI
- 1.12 1.12 Conformité à cette nouvelle version du RGI
- 2 2 ORGANISATION DES EXIGENCES D’INTEROPÉRABILITÉ
- 3 3 INTEROPÉRABILITÉ TECHNIQUE
1 CONTEXTE, DÉFINITIONS ET OBJECTIFS[modifier]
1.1 Introduction[modifier]
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[modifier]
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[modifier]
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[modifier]
- « 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[modifier]
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[modifier]
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[modifier]
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é[modifier]
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é[modifier]
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[modifier]
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[modifier]
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[modifier]
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[modifier]
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[modifier]
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[modifier]
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[modifier]
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[modifier]
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.
- ↑ 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.
- ↑ http://references.modernisation.gouv.fr/sites/default/files/RGI_Version1 0.pdf
- ↑ http://references.modernisation.gouv.fr/sites/default/files/Cadre Commun d'Urbanisation du SI de l'Etat v1.0_0.pdf
- ↑ http://references.modernisation.gouv.fr/sites/default/files/Cadre Commun d'Architecture des Référentiel de données v1.0_0.pdf
- ↑ http://references.modernisation.gouv.fr/sites/default/files/Présentation Générale Stratégie Plateform.pdf
- ↑ http://references.modernisation.gouv.fr/securite ou http://www.ssi.gouv.fr/fr/reglementation-ssi/referentiel-general-de-securite/
- ↑ http://references.modernisation.gouv.fr/accessibilite-numerique
- ↑ http://references.modernisation.gouv.fr/sites/default/files/Referentiel%20General%20de%20Gestion%20des%20Archives%20R2GA%20-%20octobre%202013.pdf
- ↑ http://references.modernisation.gouv.fr/charte-internet-de-letat
- ↑ http://references.modernisation.gouv.fr/socle-logiciels-libres
- ↑ 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.
- ↑ AFUL : Association Francophone des Utilisateurs de Logiciels Libres.
- ↑ 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É[modifier]
2.1 Description des standards[modifier]
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[modifier]
À 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é[modifier]
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é[modifier]
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[modifier]
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[modifier]
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[modifier]
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[modifier]
3.1 Synthèse des standards retenus pour le niveau technique[modifier]
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[modifier]
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é.
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.
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é.
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.
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.
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.
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[modifier]
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.