RGI - Version1 0

Rfrentiel Gnral dInteroprabilit RGI
Version 1.0
DGME RGI Version 1.0 12-05-2009
Page 1/119
Organiisatiion du document Organ sat on du document

Avant-propos Lavant-propos introduit la problmatique de linteroprabilit et prsente les bnfices attendus du RGI. Il s'adresse en priorit aux dcideurs et responsables des autorits administratives. Cadre dinteroprabilit Le cadre dinteroprabilit prsente le contexte qui a amen laborer le RGI, ainsi que les principes adopts pour la conception et le primtre de ce document. Il sadresse aux directions et aux matrises douvrage des autorits administratives uvrant dans les domaines de l'organisation et des systmes dinformation. Guide dinteroprabilit Le guide dinteroprabilit fixe dabord les rgles dinteroprabilit auxquelles les autorits administratives doivent se conformer, puis prsente les normes, standards et bonnes pratiques favorisant linteroprabilit des changes. Il sadresse plus particulirement aux chefs de projet, architectes et dveloppeurs travaillant sur des projets relatifs ladministration lectronique.
Page 2/119
Avant-propos Avant-propos
Le RGI (Rfrentiel Gnral dInteroprabilit) a pour objectif de guider les autorits administratives dans ladoption de normes, standards et bonnes pratiques, afin de favoriser linteroprabilit de leurs systmes dinformation.
Le dfaut dinteroprabilit
Cest souvent un dfaut dinteroprabilit des systmes qui met le mieux en vidence le concept et lintrt de linteroprabilit. Un voyage Londres permet de constater que linterface des appareils lectriques franais ninteropre pas avec linterface du rseau lectrique anglais. Il y a quelques annes, un voyage en Espagne tait loccasion de raliser que linterface des locomotives franaises ninteroprait pas avec linterface des voies ferres espagnoles car lcartement des roues et des voies tait diffrent. Le dfaut dinteroprabilit existe aussi dans le monde des systmes dinformation. Le 23 septembre 1999, la sonde Mars Climate Orbiter fut dtruite cause d'une erreur de navigation pendant sa mise en orbite autour de Mars. Son entre dans latmosphre martienne, prvue une altitude de 140-150 km, a finalement eu lieu seulement 57 km de la surface, entranant sa destruction par les turbulences et les frottements atmosphriques. L'enqute a mis en vidence que certains paramtres avaient t calculs par un soustraitant de la NASA en units de mesure anglo-saxonnes (livre.seconde) et transmises telles quelles l'quipe de navigation, qui attendait ces donnes en units du systme mtrique (newton.seconde). Mars Climate Orbiter tait l'une des deux sondes spatiales du programme dtude mtorologique Mars Surveyor, dont le budget slevait 328 millions de dollars.
Comment rsoudre un dfaut dinteroprabilit ?

Pour que des systmes interoprent, leurs interfaces doivent tre normalises. Lorsque de nombreux acteurs sont impliqus pour dfinir et caractriser les interfaces entre systmes, il est important dadopter une approche normative. Cette approche permet par exemple de dfinir le format dune prise de courant, lcartement des rails dune voie de chemin de fer, une unit de mesure, etc.
Un rfrentiel dinteroprabilit pour les systmes dinformation

A linstar de nombreux autres pays, pour favoriser les changes dinformation avec les autorits administratives, lEtat franais a souhait rfrencer un certain nombre de normes et standards. Le RGI rpond cet objectif. Il rsulte des dispositions de lordonnance n 2005-1516 du 8 dcembre 2005 relative aux changes lectroniques entre les usagers et les autorits administratives et entre les autorits administratives par laquelle le lgislateur a souhait donner aux autorits administratives un cadre de rfrence en la matire.
Page 3/119
Un nombre volontairement limit de normes et de standards sont poss sous forme de rgles et constituent donc un tronc commun technique sur lequel les autorits administratives doivent saligner, selon les dispositions prvues par larticle 11 de lordonnance n 2005-1516 du 8 dcembre 2005. Le nombre de rgles du RGI est rduit afin de limiter limpact de la mise en conformit des SI (Systmes dInformation). Au-del du rfrencement de ces rgles qui font largement consensus, le RGI a galement pour but de guider les autorits administratives en mettant en lumire : des normes et standards qui sont le reflet de bonnes pratiques dinteroprabilit mais qui ne sont pas encore adopts par lensemble des parties prenantes ; ces normes et standards font lobjet de recommandations ; des normes et des standards qui disposent dun fort potentiel en terme dinteroprabilit mais qui, pour un dficit de maturit ou dadoption par le march, ne sont pas encore ligibles au rang de recommandations; ces normes et standards sont alors placs en observation . Portant sur des technologies en volution constante, le RGI est un document vivant et qui connaitra des actualisations rgulires. La prsente version expose ltat actuel des questions dinteroprabilit une date donne. Cette premire version du RGI, et tout particulirement le guide dinteroprabilit, sont destins appuyer les autorits administratives dans leurs choix techniques afin de dvelopper linteroprabilit. Cependant la mise en conformit des changes dinformation aux normes, standards et bonnes pratiques recommands ou placs en observation reste lentire discrtion de chaque autorit administrative.
Les dix bnfices attendus du RGI

1 - Amliorer la qualit des services fournis aux administrs En permettant la mise en uvre de services transverses et interactifs, linteroprabilit des SI simpose comme un acclrateur du dveloppement de ladministration lectronique. Cette volution vers une administration modernise permet de rpondre aux exigences croissantes des citoyens en termes de qualit de service, c'est--dire un accs simplifi via diffrents canaux, un traitement individualis et une rduction du cloisonnement administratif. 2 - Promouvoir les services en ligne en rduisant les dlais de mise en uvre Ladoption de normes et standards communs au sein de ladministration acclre les phases de conception et dintgration tout en favorisant la rutilisation de composants. La rduction des dlais lie la standardisation des changes permet dacclrer la mise en uvre de services en lignes entre administrations. 3 - Matriser les cots de dveloppement et de maintenance Le dfaut dinteroprabilit a un cot : le cot de lincomprhension entre agents nutilisant pas les mmes termes pour dsigner les mmes choses, le cot de
Page 4/119
transformations smantiques pour que deux administrations parlent le mme langage, le cot de mise en place de plateformes dchanges pour transporter mais aussi transformer les flux entre SI, le cot de dveloppement dinterfaces entre applications, le cot de maintenance des paramtrages et des dveloppements, etc. Le RGI propose une smantique commune lensemble des changes entre administrations et des "connexions" logicielles communes pour lensemble des SI de lEtat. Il permet aussi de matriser les cots de dveloppement et de maintenance des SI. 4 - Favoriser l'interoprabilit des systmes dinformation en respectant lautonomie des acteurs Le RGI dfinit un cadre de recommandations rfrenant des normes et standards qui favorisent l'interoprabilit au sein des SI de l'administration. Ces recommandations constituent les objectifs atteindre pour favoriser l'interoprabilit. Les moyens d'y parvenir sont la discrtion des responsables des SI de l'administration, en fonction de leurs propres enjeux, de leur planning et du rapport entre le cot de mise en uvre et les bnfices attendus. 5 - Contribuer louverture des systmes dinformation dans leur cosystme (relations avec les citoyens et les entreprises et avec dautres organismes publics) Dans un contexte marqu par lintensification des relations en ligne entre les services de lEtat et les citoyens, par le besoin damliorer la qualit des services et la performance des administrations, et par lmergence de nouveaux services rendus par Internet au public, les SI doivent adapter leurs propres capacits douverture et dchanges. Il ne sagit plus tant, aujourdhui, de refondre les SI, que damliorer leurs changes en dveloppant leur interoprabilit, cest--dire leur capacit fonctionner avec dautres systmes. 6 - Adopter un langage et une smantique communs lors des changes dinformation Lutilisation dun langage commun, dune terminologie commune et de procdures communes aux diffrents acteurs (usagers, administrations) aide ceux-ci mieux se comprendre, mieux communiquer et mieux changer. Dans le domaine de linteroprabilit, cette recherche dun langage commun concerne uniquement les donnes changes entre systmes ; les donnes internes un systme ne sont pas concernes par linteroprabilit. Linteroprabilit smantique est le rsultat dun accord entre les diffrents acteurs dun processus. Ils adhrent un langage commun dans un primtre mtier prdfini. 7 - Diffuser les bonnes pratiques entre administrations europennes et converger vers un cadre dinteroprabilit commun Prs d'une quinzaine de pays europens ont dj dvelopp ou sont en train de dvelopper leur cadre d'interoprabilit. La Commission europenne dveloppe galement le cadre d'interoprabilit EIF (European Interoperability Framework) pour les applications transfrontalires.
Page 5/119
Travailler en coordination avec les autres Etats membres et en conformit avec lEIF permet dlaborer des services administratifs transfrontaliers. Le panel doffres de services est potentiellement vaste : la dlivrance de permis de travail, permis de sjour, certificats de naissance, diplmes universitaires et visas ; les dclarations dimpts, de marchandises sous douane et de TVA ; ou encore l'enregistrement de marques, de brevets, etc. Ces services s'adressent aux citoyens et aux entreprises dun mme Etat, aux citoyens et aux entreprises dun autre Etat membre de lUnion Europenne, aux administrations dun mme Etat ou encore aux administrations dun autre Etat membre de lUnion Europenne. 8 - Favoriser lintgration et guider les administrations dans leurs choix de solutions Ladoption dun cadre dinteroprabilit permet une administration de potentiellement intgrer son SI sans couture et sans interfaces compliques au SI de toute autre administration ayant adopt les mmes "connecteurs". La conformit un ensemble de normes et de standards rfrencs dans le RGI peut sexprimer sous la forme de besoins dans un cahier des charges et constituer un lment de dcision lors du choix dune solution applicative ou technique. 9 - Garantir la neutralit de ladministration en sappuyant sur des normes et standards Ladministration doit sassurer que les solutions et/ou les produits quelle acquiert sont slectionns au cours dun processus garantissant la libre concurrence. En outre, il est important que les choix de ladministration puissent se porter sur les meilleurs produits et services correspondant ses besoins spcifiques du moment, tout en la laissant libre de ses choix futurs. Cest pourquoi les normes et les standards prconiss dans le RGI ne concernent que les changes entre SI ou applications et nimposent aucune solution technique. En effet, lorsquune administration change des documents avec une autre administration, des entreprises ou des citoyens, cet change doit reposer sur un minimum de connectivit sans rendre obligatoire lutilisation dun produit logiciel ou matriel. 10 - Favoriser la standardisation et linnovation La rfrence des normes et standards externes permet aux partenaires d'un change daller au-del de simples arrangements bilatraux, de rutiliser des spcifications existantes et donc de limiter les cots lis la ralisation de solutions spcifiques. La stratgie europenne pour la croissance et lemploi prcise quune standardisation forte et dynamique est un des instruments pour encourager linnovation. Elle considre la standardisation comme dintrt public, en particulier lorsque la scurit, la sant, lenvironnement et les performances sont en jeux (cf. EIF).
Page 6/119
Prcisions importantes
Le RGI ne cre pas de normes Le RGI est un rfrentiel ; il rfrence des normes et standards reconnus et sappuie pour cela sur les travaux des organismes de normalisation. Le RGI ne traite pas de larchitecture dun SI Le primtre du RGI concerne les capacits dun SI changer avec dautres SI et ne couvre ni larchitecture dun SI, ni son fonctionnement interne. Le RGI ne fixe pas de rgles relatives des solutions Les rgles du RGI concernent le recours des normes, standards ou bonnes pratiques destins amliorer linteroprabilit des SI. Le RGI ne prconise pas de solutions logicielles ou techniques. Le RGI nest pas exhaustif dans ses prconisations Le RGI prconise un certain nombre de normes, standards et bonnes pratiques rpondant en priorit aux besoins actuels des utilisateurs. Aucune norme, ni aucun standard nest interdit, ni dconseill.
Page 7/119
Partie 1 : Cadre dinteroprabilit
Page 8/119
Sommaiire du cadre diinteroprabiilliit Somma re du cadre d nteroprab t

Cadre
1 - CONTEXTE ET ENVIRONNEMENT ......................................................................................................... 10
2 - DEMARCHE DELABORATION................................................................................................................ 11
3 - DOMAINES DINTEROPERABILITE........................................................................................................ 15
4 - PRESENTATION DES NIVEAUX DINTEROPERABILITE.................................................................. 17
5 - EVOLUTION DU DOCUMENT................................................................................................................... 20
6 - MODALITES DAPPLICATION DU RGI .................................................................................................. 21
Page 9/119
1.. Contexte et enviironnement 1 Contexte et env ronnement

Cadre
1.1. Ladministration en ligne

Le dveloppement de ladministration en ligne a profondment modifi les relations entre les usagers, les agents publics et les autorits administratives. Pour accompagner ce dveloppement, les autorits administratives doivent proposer un environnement de travail interoprable, favorisant la collaboration. Cet environnement doit galement garantir les lments suivants : Protection de la vie prive, Respect de lanonymat, Egalit daccs aux services, Transparence de ladministration, Droits daccs aux donnes nominatives et aux services, Disponibilit des services, Authenticit et opposabilit des actes dmatrialiss.
Tous ces lments contribuent apporter la confiance ncessaire au dveloppement de ladministration lectronique, au sein des administrations, entre les administrations et les entreprises, ainsi quentre les administrations et les citoyens. Afin dassurer les changes entre les diffrents acteurs de ladministration lectronique, il est ncessaire pour ces derniers dadopter un langage commun. Le RGI a t labor pour rpondre cette proccupation.
1.2. Cadre lgislatif

Le RGI rsulte des dispositions de lordonnance n 2005-1516 du 8 dcembre 2005 et du dcret n 2007-284 du 2 mars 2007. Lordonnance n 2005-1516 est relative aux changes lectroniques entre les usagers et les autorits administratives et entre les autorits administratives. Elle sinscrit dans une dmarche globale de modernisation de lEtat et plus prcisment dans une logique de simplification des dmarches des usagers et de facilitation de laccs de ces derniers aux services publics. Larticle 11 de cette ordonnance introduit la notion de Rfrentiel Gnral dInteroprabilit : Lobjet du RGI est de fixer les rgles techniques permettant dassurer linteroprabilit de tout ensemble de moyens destins laborer, traiter, stocker ou transmettre des informations faisant lobjet dchanges par voie lectronique entre autorits administratives et usagers ainsi quentre autorits administratives . Larticle 14 fixe quant lui les conditions de mise en conformit. Les systmes existants au moment de la publication se mettent en conformit dans les trois ans, les applications cres dans les six mois suivants au plus tard douze mois aprs.
Page 10/119
2.. Dmarche dllaboratiion 2 Dmarche d aborat on

Cadre
2.1. Dmarche et partis pris

Lapproche adopte pour llaboration du RGI repose sur les principes suivants : Le document propos la lecture se veut utile et facile consulter ; Le document fait rfrence des normes et standards reconnus ; il sappuie sur les travaux raliss par les organismes de normalisation ; Le rfrencement des normes et standards est appuy sur des critres dadoption explicits dans le document ; ces critres reposent sur la mthode d'valuation des normes et standards labore par la Commission Europenne : CAMSS (Common Assessment Method for Standards and Specifications) ; Le primtre du document est linteroprabilit ; le document nest pas un recueil de solutions techniques, ni un manuel darchitecture, ni un guide dimplmentation ; Le RGI concerne lensemble des autorits administratives, cest--dire les collectivits locales, les organismes publics et les services de lEtat; aussi, le niveau dexigence traduit dans les rgles du RGI doit tre adapt lensemble des autorits administratives.
Page 11/119
2.2. Dmarche de slection des normes et standards

2.2.1. Normes et standards
Pour la comprhension du RGI les dfinitions suivantes de norme et standard sont utiliser. Standard : modle de rfrence adopt par l'usage d'un groupe de personnes. Norme : document de rfrence fixant les conditions dans lesquelles une opration est ralise, un objet excut, un produit labor, avec deux caractristiques fondamentales : maner des organismes officiels de normalisation (les organismes sont prsents dans le chapitre 2.3), tre la fois le fruit du consensus de l'ensemble des acteurs et le rsultat du transfert du savoir-faire de ces acteurs.
Cadre
2.2.2. Critres dadoption retenus

Les normes et standards prsents ont t slectionns selon leur pertinence par rapport aux trois critres ci-dessous, issus de la mthode d'valuation CAMSS : Ouverture Les spcifications techniques de la norme ou du standard sont publiques et sans restriction d'accs ni de mise en uvre, La norme ou le standard a t adopt par un organisme de normalisation.
En effet, il est souhaitable quune norme ou un standard soit ouvert et puisse tre implment par une multitude de solutions logicielles. Louverture permet ainsi de garantir lindpendance vis--vis des fournisseurs et de laisser le choix de leurs outils aux parties prenantes. La libre disponibilit des spcifications permet, de plus, dassurer un accs long terme aux donnes. Potentiel dvolution Les spcifications voluent dans les temps, avec lajout de nouvelles fonctionnalits, Un calendrier dvolutions est publi et les utilisateurs sont informs de la teneur des prochaines versions, La norme ou le standard prsente la stabilit ncessaire et les nouvelles versions doivent prendre en compte au moins les problmatiques de compatibilit ascendante.
Les normes et standards doivent voluer afin de proposer des fonctionnalits adaptes aux besoins des utilisateurs, tout en garantissant des mcanismes natifs de compatibilit entre leurs diffrentes versions, afin dassurer linteroprabilit entre leurs utilisateurs.
Page 12/119
Adoption par le march La norme ou le standard dispose dune part de march significative, La norme ou le standard est implment par plusieurs diteurs logiciels, De lexpertise autour de limplmentation et de la maintenance sont proposes par de nombreux prestataires, Du fait de sa maturit, de nombreux supports daide limplmentation et la maintenance sont disponibles et les meilleures pratiques sont identifies.
Cadre
Ladoption par le march reflte la fois lindustrialisation de la norme ou du standard, son taux dadoption par les utilisateurs et la facilit disposer dassistance. Selon la maturit et lcosystme des domaines et thmes tudis, le poids des critres peut se rvler diffrent. Il faut galement noter que la non-adhrence un critre nest pas liminatoire. Le RGI cherche faire preuve de pragmatisme et propose pour chaque thme spcifique une liste de normes et standards rpondant au mieux aux critres.
Page 13/119
2.3. Organismes de normalisation

Les organismes de normalisation sont des entits qui travaillent ltablissement et au maintien de normes et dont les membres peuvent tre des personnes publiques ou prives. Les organisations officielles mondiales de normalisation sont : ISO : Organisation Internationale de Normalisation, CEI : Commission Electrotechnique Internationale, UIT : Union Internationale des Tlcommunications, UN/CEFACT : United Nations Centre for Trade Facilitation and Electronic Business ou centre de facilitation du commerce et des transactions lectroniques, ETSI : European Telecommunications Standards Institute ou Institut europen des normes de tlcommunication. En dehors des technologies de linformation et de la communication, une partie importante de la normalisation mondiale est organise autour des structures ISO et CEI, qui fonctionnent sur le principe de dlgations nationales. Pour participer leurs activits les acteurs conomiques des pays doivent disposer dune organisation nationale de normalisation, canal incontournable pour porter les positions des acteurs nationaux (privs ou publics). Le fonctionnement de cette organisation est souvent plac sous la tutelle de l'tat, comme cest le cas pour lAFNOR (Association Franaise de NORmalisation) en France. Au niveau communautaire, le CEN (Comit Europen de Normalisation) et le CENELEC (Comit Europen de Normalisation ELECtrotechnique) fonctionnent selon le modle des dlgations nationales de lISO et la CEI, dont ils constituent souvent un relais. Le domaine des technologies de linformation et de la communication concerne toutes les organisations mais relve principalement de lUIT, du CEFACT et de lETSI. Ce dernier est aussi, conjointement avec le CEN et le CENELEC une des trois organisations reconnues par lUnion europenne. Pour fonctionner, le CEN et le CENELEC sappuient principalement sur les tats, tandis que lETSI sappuie directement sur ses membres qui peuvent tre des acteurs privs ou publics. Le Ministre de lEconomie de lIndustrie et des Entreprises (MEIE) invite tous les acteurs concerns des concertations sur une base de runions rgulires. En pratique limplication directe des acteurs privs y est importante. En complment des organisations officielles, le secteur des technologies de linformation et des tlcommunications se caractrise par un foisonnement dorganismes qui contribuent lvolution des standards. Les principaux organismes menant des travaux relatifs aux changes lectroniques sont les suivants : OASIS : Organization for the Advancement of Structured Information Standards, W3C : World Wide Web Consortium, IETF : Internet Engineering Task Force, ECMA : European Computer Manufacturers Association, OMG : Object Management Group, WS-I : Web Services Interoperability Organisation.
DGME RGI Version 1.0 12-05-2009 Page 14/119
Cadre
3.. Domaiines diinteroprabiilliit 3 Doma nes d nteroprab t

Cadre
3.1. Primtre de linteroprabilit

Le RGI traite de linteroprabilit entre : Les autorits administratives : A <-> A, Une autorit administrative et une entreprise : A <-> B, Une autorit administrative et un citoyen : A <-> C.
Note : A recouvre la notion dautorit administrative B (Business) recouvre la notion dentreprise C recouvre la notion de citoyen
Citoyen Citoyen
->B A<
Entreprise Entreprise
A<->C
Autorit Autorit administrative administrative 11
A<->A
Autorit Autorit administrative administrative 22
Figure 1 : Primtre du RGI Pour leurs besoins internes, les autorits administratives restent libres du choix des normes, standards et pratiques mettre en uvre. Le cadre franais dinteroprabilit doit galement sintgrer dans le contexte europen, dfini par les travaux de lEIF, dont le primtre est prsent Figure 2.
EIF Entreprise Entreprise europenne europenne RGI
Citoyen Citoyen
A<->C
->B A<
Entreprise Entreprise
A<
>B
>C A<-
Citoyen Citoyen europen europen
Autorit Autorit Administrative Administrative 11
A<->A
Autorit Autorit Administrative Administrative 22
A<->A
Administration Administration europenne europenne
Figure 2 : Primtre europen
Page 15/119
Lobjectif de lEIF est de favoriser le dveloppement de services en ligne europens (EPS pour European Public Services), en facilitant la coopration entre les administrations des diffrents Etats Membres. Le cadre europen propose des recommandations et bonnes pratiques aux niveaux organisationnel, smantique et technique. La Commission Europenne recommande tous les Etats Membres daligner leur cadre dinteroprabilit respectif sur le cadre europen EIF. Un observatoire des cadres nationaux NIFO (National Interoperability Framework Observatory) a t mis en place afin, entre autres, de faciliter cet alignement.
Cadre
3.2. Typologie des acteurs concerns

Diffrents types dacteurs prennent part aux changes couverts par le primtre du RGI : Le terme usager recouvre les notions : o o dusager - citoyen, personne physique, dusager - entreprise, personne morale,
Lagent public, personne physique agissant au nom dune autorit administrative, Le SI dune entreprise, entit technique, Le SI dune autorit administrative, entit technique.
Page 16/119
4.. Prsentatiion des niiveaux diinteroprabiilliit 4 Prsentat on des n veaux d nteroprab t

Cadre
4.1. Les diffrents niveaux dinteroprabilit

Un change russi entre parties prenantes ncessite la prise en compte de diffrents niveaux dinteroprabilit. Le schma prsent en Figure 3 sinspire du modle propos dans lEIF. Il est constitu de six niveaux :
Niveau politique Niveau juridique
Partie Prenante A
Niveau organisationnel Niveau smantique Niveau syntaxique Niveau technique
Partie Prenante B
Figure 3 : Les six niveaux dinteroprabilit Niveau politique Des visions partages et des stratgies convergentes favorisent les changes entre parties prenantes. Niveau juridique Les changes doivent se conformer : o au cadre lgal dont dpendent les parties prenantes (droit national et international, proprit intellectuelle, confidentialit, etc.) ; o aux accords contractuels tablis entre parties prenantes (modalits de lchange, niveaux de services, etc.). Niveau organisationnel Linteroprabilit organisationnelle est lie aux organisations et aux moyens mis en uvre pour favoriser les changes. En termes dorganisation, il sagit par exemple de dfinir les rles et les responsabilits des personnes au sein de leur entit qui prennent part lchange. En termes de moyens, il sagit de mettre en place les ressources, notamment informatiques, qui vont sous-tendre les changes.
Page 17/119
Niveau smantique La smantique recouvre la fois la signification des mots et le rapport entre le sens des mots (homonymie, synonymie, etc.). Le sens des mots varie selon les organisations, les mtiers, les acteurs et les contextes. Toute collaboration entre entits demande une communication, au sens changes dinformations. Pour cela, ces entits s'entendent sur la signification des donnes quelles changent. Niveau syntaxique La syntaxe traduit le sens en symboles. Il y a entre la smantique et la syntaxe le mme rapport qu'entre le fond et la forme. Niveau technique Le niveau technique vhicule les informations dfinies au niveau smantique et mises en forme au niveau syntaxique.
Cadre
4.2. Les niveaux dinteroprabilit traits par le RGI

Il nest pas du ressort du RGI de traiter de linteroprabilit politique, juridique ou organisationnelle. Le primtre de linteroprabilit couvert par le RGI stend de la comprhension entre les acteurs qui changent jusqu la mise en uvre technique qui permet aux systmes de communiquer entre eux. Il concerne donc (voir Figure 4) : Linteroprabilit smantique : savoir se comprendre , Linteroprabilit syntaxique : savoir communiquer , Linteroprabilit technique : pouvoir communiquer .
Interoprabilit Interoprabilit Smantique Smantique
RGI
Interoprabilit Interoprabilit Technique Technique Interoprabilit Interoprabilit Syntaxique Syntaxique
Figure 4 : Les trois niveaux dinteroprabilit du RGI
Pour ces trois niveaux dinteroprabilit, le RGI propose un certain nombre de normes, standards et pratiques qui peuvent tre privilgis lors des changes dinformation, afin que les diffrentes parties prenantes des changes puissent lire, manipuler et conserver ces informations.
Page 18/119
4.2.1. Les domaines de linteroprabilit smantique

Cadre
Dans le RGI, linteroprabilit smantique est divise en trois domaines : La conception des changes Il sagit de dcrire les concepts de lchange et une dmarche gnrique permettant d'analyser les changes. Les mthodes et les langages de spcification Le RGI recommande mthodes et langages permettant de formaliser les changes. Les ressources smantiques pouvant tre rutilises Le RGI rpertorie les ressources smantiques susceptibles dtre utilises lors de la conception des changes.
4.2.2. Les domaines de linteroprabilit syntaxique

Linteroprabilit syntaxique concerne la faon dont sont codes et formates les donnes. Dans le RGI, elle est divise en deux domaines : Les formats lmentaires Les formats lmentaires incluent les formats pour le son, la photo, limage anime et le codage des caractres. Les formats composites Les formats composites sont des agrgats de plusieurs objets et incluent par exemple, les documents bureautiques ou les formats de compression de fichiers.
4.2.3. Les domaines de linteroprabilit technique

Le RGI regroupe les normes et standards techniques selon quatre grands domaines : La prsentation La prsentation traite des technologies de navigation et de restitution. Le multimdia Le multimdia traite des technologies de communication entre humains, notamment de la messagerie et de la tlphonie. Les services web Les services web traitent des technologies dchanges entre SI. Linfrastructure Linfrastructure traite des technologies lmentaires ncessaires aux changes, notamment des protocoles rseau.
Page 19/119
5.. Evollutiion du document 5 Evo ut on du document

Cadre
Les conditions dlaboration, dapprobation, de modification et de publication du RGI sont fixes par dcret. Ceci se traduit notamment par : la publication du document sur un site Web public, afin quil soit consultable par tous, des mises jour rgulires, afin de tenir compte des volutions des technologies et des usages des autorits administratives.
Page 20/119
6.. Modalliits dapplliicatiion du RGII 6 Moda ts d app cat on du RG

Cadre
A linstar de nombreux autres pays, pour favoriser les changes dinformation avec les autorits administratives, lEtat franais a souhait rfrencer un certain nombre de normes et standards. Le RGI rpond cette proccupation. Il rsulte des dispositions de lordonnance n 2005-1516 du 8 dcembre 2005 relative aux changes lectroniques entre les usagers et les autorits administratives et entre les autorits administratives . Les normes et les standards exprims sous forme de rgles constituent un tronc commun technique minimal sur lequel les autorits administratives doivent saligner, selon les dispositions prvues par larticle 11 de lordonnance. Au-del du rfrencement de ces rgles qui font largement consensus, le RGI a galement pour objectif de guider les autorits administratives en mettant en lumire : des normes et standards qui sont le reflet de bonnes pratiques dinteroprabilit mais qui ne sont pas encore adopts par lensemble des parties prenantes ; ces normes et standards font lobjet de recommandations ; des normes et des standards qui disposent dun fort potentiel en terme dinteroprabilit mais qui, pour un dficit de maturit ou dadoption par le march, ne sont pas encore ligibles au rang de recommandations; ces normes et standards sont placs en observation .
Le nombre de rgles reprises dans le tronc commun technique minimal est volontairement rduit afin de limiter limpact de la mise en conformit des SI. Ces rgles peuvent tre consultes sur les fiches thmatiques suivantes : Fiches thmatiques concernant la messagerie : les protocoles de messagerie, page 75 la reprsentation des messages et des pices jointes, page 76 la scurisation de la messagerie, page 77 laccs aux botes aux lettres lectroniques, page 78 Fiche thmatique concernant les profils de Services Web, page 91 Fiches thmatiques concernant linfrastructure : les annuaires LDAP, page 95 le service de noms de domaine, page 98 le protocole rseau, page101 les protocoles de transport, page 102 le protocole client-serveur, page 103 les meilleures pratiques HTTP, page 105 le service de scurisation des changes, page 108 lHorodatage et synchronisation, page 110
Cas particulier faisant lobjet dun accord bilatral : Si deux entits ont choisi, dun commun accord lutilisation dun protocole ou dun format pour un change limit elles-mmes, elles pourront continuer changer selon ces modalits, tant que ce choix naffecte pas les changes avec dautres acteurs.
Page 21/119
Partie 2 : Guide dinteroprabilit
Page 22/119
Sommaiire du guiide diinteroprabiilliit Somma re du gu de d nteroprab t
1 - STRUCTURE DU GUIDE DINTEROPERABILITE ................................................................................ 24
2 - INTEROPERABILITE SEMANTIQUE ...................................................................................................... 27
3 - INTEROPERABILITE SYNTAXIQUE ....................................................................................................... 50
4 - INTEROPERABILITE TECHNIQUE.......................................................................................................... 70
5 - GLOSSAIRE ............................................................................................................................................... 111
6 - GESTION DES VERSIONS...................................................................................................................... 117
SOMMAIRE DETAILLE .................................................................................................................................. 118
Page 23/119
1.. Structure du guiide diinteroprabiilliit 1 Structure du gu de d nteroprab t

1.1. Guide dinteroprabilit
Le guide dinteroprabilit est compos de fiches thmatiques, prsentes selon les trois niveaux dinteroprabilit traits par le RGI : Smantique, Syntaxique, Technique.
Les chapitres ddis chaque niveau reprennent les domaines introduits prcdemment, ces derniers regroupant plusieurs thmes connexes.
Cliquez sur les domaines afin de les consulter
Smantique
Concepts
Mthodes et langages
Ressources
Syntaxique
Formats lmentaires
Formats composites
Technique
Prsentation
Multimdia Messagerie Tlphonie
Services Web
Infrastructure
Annuaires Technologies
Page 24/119
1.2. Prsentation des rgles dinteroprabilit

Les rgles dinteroprabilit sont prsentes de la manire suivante :
Figure 5 : Reprsentation des rgles RGI
Les normes, standards ou bonnes pratiques faisant lobjet de recommandations ou tant mis en observation reprennent cette charte de prsentation, tout en adoptant des codes couleurs diffrents. Dans le cas de bonnes pratiques, les organismes de normalisation et les liens vers les spcifications ne sont pas indiqus. Des liens vers des problmatiques connexes peuvent galement tre proposs dans certains chapitres du guide dinteroprabilit. Exemple : Concernant la scurisation des communications changes, XMPP utilise le protocole TLS. Ce protocole est dtaill au chapitre 4.4.2.8 Service de scurisation des changes
Page 25/119
1.3. Liste des normes et standards rfrencs

Cliquez sur les normes et standards afin de consulter le(s) thme(s) associ(s)
A B C D E F G H I J L M N O P R S
Atom Publishing Basic Security Profile BPMN CGM CSS DNG ESMTP FTP G.711A GIF HTML G.722 GSM 06.10 G.723.1 G.729 CSV DNS ESMTP STARTTLS DNSsec
DCF77 ECMAScript Flac

G.168 G.729.A H.323 iLBC IPv6 JPEG LDAP MDC
DSML
HTTP
IMAP4
HTTP POST IPsec IPv4
ID-WSF
JSON LDIF MIME NTP Ogg-Vorbis PDF/A PRESTO RTCP RTP ( 1 | 2 ) SCTP Speex RTSP SFTP SSL SIP Open XML PDF/X OpenDWG PNG Polices dcriture literal MP3 ( 1 | 2 ) MPEG-2 MPEG-4
Navigateurs
ODF PDF 1.7 ( 1 | 2 | 3 ) POP3 RSS S/MIME SMTP SVG
SAML
SOAP
T U W X Z
TCP UDDI UTF-8 WAV WS-Security X3D XML Schema ZIP
TDF UDP
TIFF UML
TLS UN/CEFACT UTC
WSDL
WS-I Attachments
WS-I Basic Profile
WSRP
XHTML XMPP
XMI XPath
XML ( 1 | 2 ) XSLT
Page 26/119
2.. IInteroprabiilliit smantiique 2 nteroprab t smant que

2.1. Introduction
Smantique
La smantique est une branche de la linguistique qui tudie le sens des mots. Le mot smantique a t invent au XIXme sicle par le linguiste franais Michel Bral, auteur du premier trait de smantique. La smantique recouvre la fois la signification des mots et le rapport entre le sens des mots (homonymie, synonymie, ). Toute collaboration entre entits demande une communication, au sens changes dinformations. Pour cela, ces entits s'entendent sur la signification des donnes quelles changent. Linteroprabilit smantique caractrise la capacit saccorder sur : le contexte de lchange, le processus de lchange, le sens et la structuration de linformation change.
Niveau politique Niveau juridique Niveau organisationnel

Partie prenante A Partie prenante B
Niveau smantique Niveau syntaxique Niveau technique
Figure 6 : le niveau smantique traite du sens de linformation Le niveau smantique traite du sens des informations (voir Figure 6) et se distingue en cela du niveau syntaxique relatif la faon dont les donnes sont codes et formates. Le sens des mots varie selon les organisations, les mtiers, les acteurs et les contextes. Lorsque deux parties prenantes (expditeur, destinataire) dcident dchanger, elles sexposent des conflits dordre smantique. Leurs consquences, de diffrentes natures, peuvent tre importantes comme celles financires rvles sur le projet Mars Climate Orbiter, cit en avant-propos.
Page 27/119
Voici quelques exemples courants de conflits smantiques : Lexpditeur et destinataire de l'change utilisent des identifiants diffrents pour dsigner le mme produit (synonymie); lidentifiant du produit expdi correspond chez le destinataire lidentifiant dun autre produit (homonymie); lexpditeur consent une rduction des frais denvoi en France et considre que le mot France recouvre la France mtropolitaine alors que le destinataire considre que le mot France intgre les DOM et les TOM; pour catgoriser les produits vendus, lexpditeur utilise une table de codes diffrente de celle du destinataire ; sans indication de la devise, lexpditeur pense mettre un montant en dollars alors que le montant est attendu par le destinataire en euros.
Smantique
Lanticipation de ces conflits est du ressort des parties prenantes de lchange. Ils doivent tre pris en compte de prfrence ds la conception des changes et non au moment de la mise en uvre technique. Pour que les systmes dinformation soient interoprables, les noms, attributs, valeurs, listes de codes qui entrent dans le primtre de leur collaboration, doivent tre harmoniss. L'tude de l'interoprabilit smantique doit donc dbuter par une ontologie partage, c'est-dire une entente entre les parties prenantes sur les concepts manipuls et leurs liens. Ce document: prsente la conception des changes, dcrit les mthodes de spcifications et les langages indique les ressources smantiques rutiliser.
Page 28/119
2.2. Conception des changes

Cette partie prsente les concepts relatifs aux changes et une dmarche gnrique pour concevoir ces changes.
Smantique
2.2.1. Les concepts de base lis aux changes

Une dfinition aboutie d'un change passe par l'tude de son contexte, de son processus, des acteurs impliqus et des objets qui "circulent" d'un acteur lautre. Le contexte Le contexte dicte son sens au mot. Par exemple, une personne est dsigne comme un "patient" ou un "agent", selon quelle est perue dans un contexte "sant" ou "administration". Le processus Selon ISO 9000, un processus est un ensemble d'activits corrles ou interactives qui transforme des lments d'entre en lments de sortie . Il peut tre considr comme un ensemble organis d'activits, dclench par un vnement. Il utilise des ressources (personnel, quipement, matriels et machines, matire premire et informations) pour transformer des objets en entre en objets en sortie. Les processus mettant en uvre des changes de donnes entre parties prenantes sont appels processus d'changes ou encore processus collaboratifs. L'acteur Un acteur est une organisation ou une personne implique en tant que partie prenante dans un processus d'change. L'objet ou classe d'objets On nomme objet la reprsentation de ce qui est partag par les parties prenantes dans un contexte donn. Par exemple, dans un contexte dchange dinformations fiscales, "foyer fiscal" ou "contribuable" peuvent tre des objets. L'objet peut tre matriel (un produit reu ou expdi) ou immatriel (un compte bancaire, une commande). Un objet est identifiable, caractris par des proprits (prnom, code postal,) et des liens avec dautres objets. Une classe est une abstraction d'objets ayant des caractristiques communes. Une classe est dcrite par : une dfinition ; un nom dduit de sa dfinition ; des attributs; par exemple, la classe "Produit" peut possder les attributs "Couleur", " Poids", "Texture", etc. Ces attributs sont caractriss par des types (code, montant, texte, etc.) ; des relations avec d'autres classes; cette caractristique apporte une information complmentaire, par exemple, la classe "Produit" peuvent tre associes les classes "Fournisseur" et "Point de vente".
Page 29/119
2.2.2. Une dmarche gnrique de conception des changes

Ce chapitre prsente, dans les grandes lignes, une dmarche gnrique permettant de concevoir les changes dinformations entre parties prenantes jusqu' la transformation syntaxique.
Smantique
La dmarche couvre seulement les exigences fonctionnelles lies aux changes. Elle ne prend pas en compte les exigences non fonctionnelles telles que les volumes, la frquence et les aspects de scurit de ces changes. Elle ne couvre pas larchitecture de la solution (intgration dans le systme dinformation, technologies utilises), ni son implmentation (dveloppement, tests, etc). Cette formalisation des changes dinformations sappuie sur des langages de modlisation. Quel que soit le modle prsent dans la suite du document, il ne se rsume jamais un dessin. La smantique du modle est apporte par les descriptions textuelles des lments modliss. Elles doivent tre claires et partages par les parties prenantes de l'change. Et quel que soit le mode de formalisation choisi, il est recommand de dfinir et rpertorier dans un glossaire, tous les termes utiliss au fur et mesure de l'avancement dans la dmarche.
Recommand
Construire un glossaire
Il est RECOMMAND de dfinir et rpertorier, dans un glossaire, tous les termes utiliss.
Cette dmarche gnrique comprend quatre phases : Phase 1 : modliser les processus collaboratifs, y compris les acteurs impliqus et les changes, Phase 2 : modliser les classes dobjets impliques dans lchange, Phase 3 : modliser les informations changes, Phase 4 : dcrire les formats dchanges.
Page 30/119
Phase 1 : modliser les processus collaboratifs Cette modlisation sert dcrire les processus collaboratifs, les acteurs impliqus et les changes entre ces acteurs.
Smantique
Recommand
Modliser les processus collaboratifs
Il est RECOMMAND de modliser les processus collaboratifs mettre en uvre pour changer linformation.
Les processus collaboratifs peuvent tre formaliss textuellement et graphiquement par des diagrammes de processus. Les diagrammes de cas dutilisation (Figure 7) sont appropris pour identifier les processus collaboratifs et les acteurs impliqus ou parties prenantes.
Acteur 2
Acteur 1
Cas dutilisation 1
Acteur 3
Figure 7 Exemple de diagramme de cas dutilisation Les diagrammes de description de processus BPMN (Business Process Modeling Notation) ou les diagrammes d'activits dont un exemple est prsent en figure 8, permettent de dcrire un processus collaboratif. Ces diagrammes montrent pour chaque acteur, l'enchanement des activits mettant ou recevant un change dinformations.
Acteur 1
Acteur 2 Acteur 3
Activit 1
Activit 2
Activit 3
Activit 4
Activit 6
Activit 5
Figure 8 : Exemple de diagramme dactivits
Page 31/119
Phase 2 : modliser les classes dobjets impliques dans lchange La phase 1 a permis d'identifier et de dcrire les changes entre les acteurs. Il s'agit maintenant d'identifier et de dfinir les informations que ces changes transportent. La formalisation de ces informations en classes d'objets permet de bien rpondre cette exigence. Les spcifications, reprsentes par les modles conceptuels, essaient de reflter au maximum la terminologie de contexte mtier. Diffrents langages graphiques et textuels permettent de dcrire les classes ce niveau, comme par exemple un modle entit-relation ou un modle de classes UML (voir Figure 9). Recommand Modliser les classes dobjets impliques dans lchange
Smantique
Il est RECOMMAND de modliser les informations de l'change sous la forme de classes d'objets.
C la s s e 1
C la s s e 2
1 ..*
1 . .1 *
C la s s e 3
1 0 ..*
C la s s e 4
C la s s e 5
C la s s e 6
Figure 9 : Diagramme de classes UML
Page 32/119
Phase 3 : modliser les informations changes Cette phase consiste : driver le modle dinformations changes partir du modle des classes dobjets impliques dans lchange dfini en phase 2, rutiliser, en les adaptant au contexte par des rgles de nommage, des composants smantiques pralablement mutualiss ou normaliss. Ce modle, neutre par rapport la syntaxe, c'est--dire au format de l'change, dcrit pour chacune des informations de l'change : sa dfinition, son nom, dduit de sa dfinition, son type, comme par exemple un code, un texte, une image, un montant, etc. et si son type est un code, la liste de codes dont il est issu comme par exemple, la liste des codes ISO 3166 des pays ou la NAF (Nomenclature des Activits Franaises). Recommand Modliser les informations changes
Smantique
Il est RECOMMAND de modliser les informations changes.
Phase 4 : dcrire les formats dchanges Cette phase constitue l'articulation entre le niveau smantique et le niveau syntaxique. Elle est prsente au niveau smantique afin de fluidifier le propos. Elle consiste traduire le modle dinformations changes en un message. Ce message contient lensemble des donnes changer. Il est bti selon une syntaxe (ou format dchange) commune aux parties prenantes de lchange, par exemple un message XML. Lors de lchange, il est possible dassocier au message une description de ses donnes. Lorsque cette description n'est pas transmise avec le message, elle peut tre prcise dans une convention entre les parties prenantes. Recommand Gnrer le format dchange partir du modle dinformations changes Il est RECOMMAND de gnrer le format dchange partir du modle dinformations changes.
Page 33/119
Vue synthtique de la dmarche gnrique de conception des changes Le tableau prsent en Figure 10 associe les modles et les rgles dcrites aux phases de la dmarche gnrique de conception des changes. Dmarche gnrique
Modliser les processus collaboratifs Modliser les classes dobjets impliques dans lchange
Modles et rgles
Modles de processus
Smantique
Modles de classes dobjets
Modliser les informations changes
Rgles de drivation des diagrammes de classes en modles dinformations Rutilisation en les adaptant au contexte des composants smantiques pralablement mutualiss ou normaliss
Dcrire les formats dchanges
Traduction des modles dinformations changes dans une syntaxe commune aux parties prenantes
Figure 10 : Dmarche gnrique de conception des changes (synthse)
Page 34/119
2.3. Mthodes de spcification et langages

2.3.1. Mthodes de spcification
A la dmarche gnrique de conception des changes prsente ci-dessus, il est possible dassocier des mthodes de spcifications. Ces mthodes peuvent soit porter spcifiquement sur les changes comme les mthodes UN/CEFACT, soit inclure la rflexion sur les changes dans une spcification plus globale des SI comme la mthode Praxeme. 2.3.1.1. La mthode Praxeme Praxeme est une mthode de modlisation dentreprise et de conception de SI. Elle considre laspect smantique d'un systme comme le plus fondamental de son cadre architectural. Ce cadre est appel topologie du systme , voir Figure 11.
Smantique
Figure 11 : Topologie du systme Praxeme La mthode Praxeme est une mthode dite d'entreprise , car elle est destine couvrir tous les aspects dune entreprise (terme employ pour dsigner de manire gnrale toute organisation), depuis sa stratgie jusquau dveloppement de son SI. Elle couvre notamment au travers de son point de vue dit smantique la modlisation des concepts manipuls par lentreprise et au travers de son point de vue dit pragmatique la modlisation des processus dentreprise. Praxeme est une mthode publique. Elle est base sur les standards UML et MDA (Model Driven Architecture) de lOMG (Object Management Group). Les lments de la mthode ainsi que les modles daspects ou de domaines rencontrs de manire rcurrente dans les SI sont publis en franais et en anglais. Praxeme nest pas spcifiquement destine aux changes, ni linteroprabilit. Elle ne couvre quen partie les tapes de la dmarche gnrique de description des changes. Mais elle est cite pour sa capacit rpondre au besoin de modlisation des processus, des acteurs et des objets mtier.
Page 35/119
2.3.1.2. Les mthodes de l'UN/CEFACT Avec laide de nombreuses institutions et en sappuyant sur des spcifications mthodologiques de lUN/CEFACT, un guide ddi la dmatrialisation des changes pour amliorer linteroprabilit des SI a t labor. Appel actuellement "Guide UML-XML", un nom refltant mieux son objet lui sera attribu lors de sa prochaine mise jour. Le but de ce guide est d'aider les matrises d'ouvrage et matrises d'uvre des projets modliser les changes et gnrer les formats techniques des donnes changes. Sa lecture requiert seulement une connaissance de base des concepts UML, de la modlisation et du langage XML. Une connaissance approfondie des spcifications techniques sousjacentes n'est pas indispensable. Ce guide regroupe quatre approches UMM (UN/CEFACT Modeling Methodology), drivation du diagramme de classes, CCTS (Core Component Technical Specifications) et XML NDR (XML Naming and Design Rules). Lapproche UMM dfinit les modles UML et la documentation associe produire pour modliser les exigences mtier d'un processus collaboratif. Elle sert dcrire les changes, concevoir les modles dinformations sur lesquels les partenaires doivent s'accorder afin de collaborer. Elle correspond aux deux premires phases de la dmarche gnrique (voir tableau en Figure 12). Lapproche Drivation des diagrammes de classes permet de transformer la structure dun modle conceptuel en une structure hirarchique adapte lchange dinformations. Lapproche CCTS dcrit une mthode pour identifier (notamment partir dune structure hirarchique adapte lchange dinformations) un ensemble commun de briques smantiques rutiliser en les adaptant au contexte. La spcification CCTS est une norme ISO (comit technique TC154: Processes, data elements and documents in commerce, industry and administration). Lapproche Drivation des diagrammes de classes et la CCTS correspondent la troisime phase de la dmarche gnrique (voir tableau en Figure 12). Lapproche XML NDR dfinit des rgles de nommage et de conception des messages XML (donnes et schmas). Elle a pour objectif de transformer un modle de donnes changes, description smantique de lchange, en un message dont la syntaxe puisse tre reconnue par les parties prenantes de lchange. Le schma gnr est un schma XML UN/CEFACT. Cette approche correspond la quatrime phase de la dmarche gnrique (voir tableau en Figure 12).
Smantique
Page 36/119
Le tableau en Figure 12, prsente les mthodes de lUN/CEFACT couvrant les phases de la dmarche gnrique. Dmarche gnrique
Modles et rgles
Modles de processus
Mthodes UN/CEFACT
Smantique
UMM Modles de classes dobjets
Modliser les informations changes
Rgles de drivation des diagrammes de classes en modles dinformations Rutilisation, en les adaptant au contexte des composants smantiques pralablement mutualiss ou normaliss CCTS
Dcrire les formats dchangs
Traduction des modles dinformations changes dans une syntaxe commune aux parties prenantes
XML NDR
Figure 12 : Couverture de la dmarche gnrique par les mthodes de lUN/CEFACT
2.3.2. Des langages pour dcrire les changes

Ce chapitre dcrit les langages de spcification pouvant tre utiliss pour dcrire les changes. 2.3.2.1. Le langage UML UML (Unified Modeling Language), est un langage de modlisation graphique permettant de spcifier, visualiser et documenter les systmes dinformation. UML est issu des notations de modlisation proposes par les mthodes objet les plus reconnues. Personnalisable par ses notations et support par une offre doutils importante, il est devenu un standard de fait en informatique. Sa version standard initiale 1.1 fut adopte par lOMG en novembre 1997. LISO a adopt sa version 1.4.2 comme standard (ISO/IEC 19501:2005) en 2005. Actuellement (fvrier 2009) la version 2.1.2 d'UML est le rsultat du travail et des recommandations manant la fois des experts en mthodologie et des praticiens du monde entier.
Page 37/119
UML permet de modliser, entre autres: les acteurs et processus collaboratifs entre organismes ou systmes, laide de diagrammes de cas dutilisation, les processus collaboratifs et leurs changes, laide de diagrammes dactivits, diagrammes dinteractions (collaborations et squences) et diagrammes dtatstransitions, les informations changes, laide de diagrammes de classes, les systmes composants et leurs interfaces, laide de diagrammes de composants. La modlisation en UML est facilite par lutilisation dun outil logiciel de modlisation supportant cette notation. Il est souhaitable que cet outil supporte la fois la dernire version dUML (ou au moins la version 1.4.2 qui est galement reconnue comme un standard ISO) et la dernire version du standard dchange de mtadonnes XMI. XMI permet d'exporter ou d'importer des spcifications crites en UML vers ou depuis d'autres outils logiciels de modlisation UML. 2.3.2.2. La notation BPMN BPMN (Business Process Modeling Notation), notation de modlisation des processus (mtier), est une initiative du BPMI (Business Process Management Initiative) maintenue au sein de l'OMG depuis 2005. BPMN permet de modliser les acteurs et les processus. Le langage est graphique et articul notamment autour des concepts dactivit, dvnement, de flots de contrle et de flots de messages. La notation BPMN est supporte par de nombreux outils du march.
Smantique
Recommand
UML / BPMN
ISO/OMG
Il est RECOMMAND dutiliser les langages de modlisation UML et/ou BPMN pour reprsenter et modliser les processus collaboratifs. Il est RECOMMAND dutiliser le langage de modlisation UML pour modliser les autres concepts de l'change (les acteurs, les objets).
2.3.2.3. Le langage OCL Pour complter la modlisation en UML, il est parfois appropri dutiliser le langage OCL. OCL (Object Constraint Language) permet notamment dexprimer des assertions (typiquement des conditions invariantes), spcifier des oprations ou des actions modifiant ltat des objets dun diagramme de classes UML. OCL est un standard de lOMG.
Page 38/119
2.3.2.4. Des langages pour dcrire des messages 2.3.2.4.1. Le langage XML Les modles dinformations changes peuvent tre traduits en diffrents langages, notamment le langage XML. Dans un document XML, il est possible de dfinir la fois les donnes et la structure de ce document. Cette structure, appele schma peut tre dcrite dans un langage de dfinition de schma. 2.3.2.4.2. La syntaxe XSD La syntaxe XSD (XML Schema Definition) permet de dcrire la structure et le contenu dun document XML et de vrifier la validit des donnes qui le composent. Recommand XSD W3C
Smantique
Il est RECOMMAND dutiliser des schmas XSD pour dcrire le contenu et la structure d'un document XML.
Dans la pratique, il existe de nombreuses constructions de schmas XSD comme : les schmas standards de lUN/CEFACT, les schmas lis des pratiques sectorielles comme le schma HL7 dans le domaine de la sant, les schmas XSD ad hoc non standards ou encore appels "propritaires". Des partenaires peuvent avoir spcifi un modle dinformations commun pour leur change et avoir recours des techniques de construction diffrentes de leurs documents XML (schmas XSD construits diffremment) ou encore utiliser des syntaxes diffrentes. Dans ce cas, ils ont recours une technique de transformation de document XML en utilisant XSLT (Extensible Stylesheet Language Transformations). Dans certains cas, cette solution peut se rvler pratique court terme. Pour des raisons de maintenance et d'volutivit, il est cependant recommand aux parties prenantes de rutiliser les standards existants et de s'entendre sur une mme construction syntaxique. 2.3.2.4.3. Autres syntaxes Il existe dautres syntaxes non XML permettant lchange de donnes, dont les deux suivantes antrieures XML sont trs largement rpandues: UN/EDIFACT Sous l'autorit des Nations Unies, EDIFACT (United Nations/Electronic Data Interchange For Administration, Commerce and Transport) repose sur une syntaxe (norme ISO 9735), des rpertoires de donnes et des guides pour les changes de donnes structures entre systmes d'information indpendants ; ASC X12 L'ASC X12 (Standards Committee X12) accrdit par l'ANSI (American National Standards Institute) a galement dfini de nombreux standards lis lchange de documents lectroniques ; il existe de nombreuses tables de correspondance entre les changes X12 et EDIFACT.
Page 39/119
2.3.2.5. Synthse des langages et des syntaxes utiliser Le tableau en Figure 13, prsente les modles ou rgles ainsi que les notations ou langages couvrant les phases de la dmarche gnrique.
Smantique
Dmarche gnrique
Modliser les processus collaboratifs
Modles ou rgles
Modles de processus
Notations ou langages
Diagramme de cas dutilisation UML Diagramme dactivits UML Diagramme dtats UML Diagramme dinteractions UML Diagramme de processus BPMN
Modliser les classes dobjets impliques dans lchange
Modles de classes dobjets
Rgles de drivation des diagrammes de classes en modles dinformations Modliser les informations changes Rutilisation, en les adaptant au contexte, des composants smantiques pralablement mutualiss ou normaliss Traduction des modles dinformations changes dans une syntaxe commune aux parties prenantes
Diagramme de classes UML OCL
Dcrire les formats dchangs
Constructions de dfinitions de schmas partir du langage XML: o Schmas UN/CEFACT o Schmas sectoriels (HL7,) o Schmas ad hoc, o Etc. EDIFACT ANSI ASC X12 Etc.
Figure 13 : Les modles ou rgles ainsi que les notations ou langages pour dcrire les changes
Page 40/119
2.4. Rutilisation des ressources smantiques

Assurer linteroprabilit smantique suppose des efforts de mutualisation de systmes communs didentification, de sorte quun mme objet, une mme information ou une mme valeur puisse toujours correspondre un mme concept ou une mme caractristique. Cela peut tre le cas, par exemple, du code identifiant une commune ou de la situation familiale dune personne. Cette interoprabilit smantique est fonde sur la mutualisation de ressources smantiques constitues notamment de modles dcrivant la structure de l'information, de rpertoires didentification ou dimmatriculation, de bases de donnes de rfrence, de simples listes de valeurs ou de nomenclatures. A titre dexemple, la figure 14 prsente un extrait de la description de la classe gnrique Personne de la bibliothque MDC (Modle de Donnes Communes), voir 2.4.1.5. DGME.
Classe Personne Un individu titulaire de droits et d'obligations caractris par une identit civile constitue de l'ensemble des lments d'tat civil Attributs : Identifiant Identifiant unique prenne de la personne. Nom Famille Nom de famille selon les dispositions de la loi n 2002-304 du 4 mars 2002 relative au nom de famille: Prnom Usuel La notion de prnom usuel est prvue par l'article 57 du code civil qui dfinit le contenu de l'acte de naissance. Ministre de la Justice: " Tout prnom inscrit dans l'acte de naissance peut tre choisi comme prnom usuel". Le prnom usuel est donc celui des prnoms indiqus dans l'acte de naissance dont il est fait usage dans la vie courante. Sexe Sexe de la personne. Liste de codes associe provenant de la norme ISO 5218 1977 (E) : 1 = Masculin ; 2 = Fminin ; 9 = Indtermin ou non spcifi Situation Familiale Situation familiale de la personne. Liste de codes associe : 01 : clibataire ; 02 : mari ; 03 : divorc ; 04 : spar ; 05 : veuf, veuve ; 06 : vie maritale ; 07 : PACS ; 90 : non connue
Smantique
Figure 14 : Extrait de la classe gnrique Personne du MDC Ces ressources peuvent tre centralises et mutualises par des institutions telles que des administrations ou des organismes de normalisation. Elles peuvent tre trs gnrales et utiles l'ensemble des changes de l'administration ou bien trs centres sur un secteur donn. Un premier ensemble de ressources est constitu par les rfrentiels nationaux et les listes de codes et nomenclatures officielles.
2.4.1. Ressources communes aux changes

Les ressources cites dans ce document ne sont pas exhaustives; celles des institutions suivantes sont donnes titre dexemple.
Page 41/119
2.4.1.1. Insee LInsee gre : les principaux rpertoires dans le domaine conomique, social et spatial, notamment les rpertoires de donnes RNIP (Rpertoire National dIdentification des Personnes Physiques), RNIAM (Rpertoire National Inter-rgimes des bnficiaires de lAssurance Maladie) ou SIRENE (Systme Informatis du Rpertoire National des Entreprises et des Etablissements) et les principales nomenclatures franaises telles que : COG (Code Officiel Gographique), APE (Activits principales des Entreprises et tablissements) et NAF (Nomenclature des Activits Franaises), etc. Les dfinitions des concepts les plus souvent utiliss dans les tudes; les schmas XML permettant de reprsenter des donnes didentification et de classification. 2.4.1.2. Eurostat Eurostat met disposition un serveur de nomenclatures appel RAMON. Diverses listes de codes et nomenclatures concernant les biens, les activits conomiques et les statistiques au niveau europen y sont accessibles. 2.4.1.3. ISO LISO normalise notamment des types de donnes comme la reprsentation de la date et de lheure (ISO 8601), des listes de codes comme la liste des noms et codes de pays (ISO 3166), des codes pour la reprsentation des noms de langues (ISO 639-1) ou encore des codes de reprsentation des sexes humains (ISO 5218). Les ressources ISO sont gnralement payantes. Nanmoins, certaines ressources ISO sont disponibles gratuitement. 2.4.1.4. UN/CEFACT L'UN/CEFACT met disposition un ensemble important de recommandations (normes et standards) dont les ressources suivantes : Les spcifications fonctionnelles bases sur les modles UML (BRS Business Requirement Specifications), les spcifications techniques bases sur les diagrammes de classes hirarchiques (RSM - Requirement Specification Mapping) et les schmas XSD des changes de donnes standardiss; La bibliothque des composants communs (CCL - Core Component Library) contenant la fois des composants gnriques neutres contextualiser (CC - Core components) et des composants contextualiss aux changes (BIEs - Business Information Entities) et les descriptions de types de donnes; Les rpertoires EDIFACT; Des listes de codes et des nomenclatures. 2.4.1.5. DGME La DGME, en collaboration avec lensemble des ministres, dveloppe la ressource MDC (Modle de Donnes Communes). Le MDC dfinit plusieurs dizaines de concepts, sous la forme de classes d'objets, communs toutes les administrations comme, par exemple, "Personne", "Organisation" ou "Adresse". Ces concepts peuvent tre vus comme des
Smantique
Page 42/119
constantes intersectorielles susceptibles dtre rutilises dans de nombreux formulaires et procdures administratives. Prsent sous forme dun dictionnaire de structures de donnes changeables, le MDC doit permettre llaboration et la diffusion dune terminologie commune aux SI de ladministration. Le MDC respecte les normes et standards de lUN/CEFACT. Il a pour origine la bibliothque de composants communs de l'UN/CEFACT (UN/CEFACT CCL). Ces composants sont traduits au fil de l'eau et adapts au contexte de ladministration franaise. Des acteurs de diffrents secteurs professionnels de l'administration contribuent llaboration commune et la mise jour rgulire du MDC. Le MDC sadresse aux matrises douvrage et aux matrises duvre en charge de projets lis aux changes de donnes. La rutilisation des classes d'objets du MDC permet de rduire les ambiguts smantiques sur les donnes changes. Les modles, dfinitions et nommages de donnes du MDC sont destins faciliter llaboration des schmas XML dchanges entre SI. Recommand Rutiliser les ressources smantiques
Smantique
Il est RECOMMAND lors de la conception des changes de rutiliser des ressources smantiques existantes.
2.4.1.6. SEMIC.EU SEMIC.EU (Semantic Interoperability Centre Europe) est un service europen fournit par la Commission europenne dans le cadre du programme IDABC (Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens) qui valorise les ressources smantiques des administrations. Ce rpertoire permet aux administrations europennes dy dposer des mthodes et outils ainsi que des concepts, des modles de donnes et des listes de codes afin de les rendre visibles aux autres administrations pour rutilisation. Cette mise en commun permet de favoriser linteroprabilit smantique.
Page 43/119
Une synthse des ressources Gnrales ou sectorielles, ces ressources sont de nature diffrente. Le tableau en Figure 15 prsente les types de ressources rutilisables chaque phase de la dmarche gnrique. Dmarche gnrique
Types de ressources rutilisables

Diagrammes dactivits
Smantique
Description
Des modles de processus collaboratifs et de classes dobjets
Diagramme de classes
Diagrammes de classes
Des diagrammes de classes des informations changes Classes d'objets avec leurs attributs
Modliser les donnes changes
Classes d'objets mutualises Types de donnes
Types de donnes associes aux attributs des classes d'objets (ex.: une date, un montant, etc.) Des listes de valeurs associes une donne (exemple : code NAF) Des schmas XML reprenant la description des donnes (exemple : ladresse client) Des schmas XML reprenant la liste des valeurs possibles associe une donne (exemple : la liste des codes pays)
Listes de codes, nomenclatures XSD donnes Dcrire les formats dchangs
XSD valeurs
Figure 15 : Les types de ressources rutilisables
Prcisions sur les listes numres Une liste numre dsigne une liste finie de codes (numriques, alphanumriques, mnmoniques) faisant autorit et servant de rfrence une discipline donne. Les codes sont utiliss pour mmoriser et transmettre linformation dcrite sans ambigut lorsque la liste est identifie. On distingue deux types de listes de codes numres : la liste de valeurs : elle se prsente sous forme dune liste de codes auxquels correspondent des libells (exemple : la liste des codes pays) ; la nomenclature : elle se prsente sous forme dune liste de codes induisant une classification sous-jacente, une taxonomie prtablie; par exemple, dans la nomenclature combine servant identifier les produits, le code "0603 11 00" dsigne les "Roses et leurs boutons, frais, coups, pour bouquets ou pour ornements" ; dans ce code, le premier groupe de deux caractres "06" dsigne les "plantes vivantes et produits de la floriculture", le second groupe de deux caractres "03" dsigne le groupe des "fleurs et boutons de fleurs, coups, pour bouquets ou
Page 44/119
pour ornements, frais, schs, blanchis, teints, imprgns ou autrement prpars" et le dernier groupe "11 00" dsigne les "roses". Prcisions sur les conflits entre listes numres Une des principales difficults en matire dinteroprabilit smantique provient de lexistence de multiples listes numres concurrentes locales voire spcifiques des applications. Pour chaque donne ou attribut correspondant une notion de type numrable, la liste de codes qui sert donner une valeur normalise linformation changer est : soit une liste de codes unique, impose aux parties prenantes en amont des changes, soit une liste de codes dclare commune pour lchange; dans ce cas, chacune des parties prenantes conserve en interne sa propre liste de codes et prend en charge, en entre et sortie, les transcodages ou transpositions dans le langage commun de toutes les valeurs affectes aux donnes. Les principes de classement et de construction des codifications ne sont pas toujours explicites, documents ou connus. Cest alors au niveau des tables de transcodage qu'apparaissent les difficults principales. Ces tables doivent tre conues pour accepter le niveau le plus fin dinformation. Ce travail est souvent fastidieux et des suites dapproximations gnrent souvent une perte dinformation. La proccupation dinteroprabilit suggre de recourir des listes de codes bien tablies et dusage courant.
Smantique
Page 45/119
2.4.2. Ressources pour larchivage

2.4.2.1. La ncessit de larchivage numrique Le cycle de vie Tout systme dinformation, ds sa mise en uvre, doit intgrer les problmatiques lies au cycle de vie de linformation, notamment aux dures de conservation des documents et des donnes. Cette dmarche inclut : la mise en uvre dun archivage intermdiaire, si les dures de conservation sont longues, llimination rglementaire, si la conservation dun document nest pas justifie, le versement dans les services publics darchives. Il est ncessaire que les modalits mises en place permettent de garantir que chaque document archiv reste lisible et intelligible, imputable un auteur identifi, fiable et intgre jusquau terme du dlai durant lequel des droits y affrant peuvent exister. Recommand Grer le cycle de vie des informations
Smantique
Afin de grer le cycle de vie de linformation, il est RECOMMAND que tout systme dinformation mette en uvre les fonctionnalits lies aux dures de conservation des documents/donnes.
Linteroprabilit Larchivage numrique ncessite une interoprabilit dans le temps des systmes de collecte, conservation et consultation. Dun point de vue technique, cette interoprabilit repose sur la prise en compte des caractristiques des supports physiques permettant la conservation des donnes, leur surveillance et leur migration sur dautres supports. Elle concerne aussi la rplication des donnes/documents sur des sites distants. Les recommandations couvrant ces aspects sont disponibles sur le site de la DAF (Direction des Archives de France). Dun point de vue syntaxique, cette interoprabilit repose sur la prise en compte des caractristiques de formats de documents/donnes permettant la conservation des donnes. Les documents numriques doivent tre enregistrs sur des formats prennes, si possible, ds leur production. A dfaut, ils devront tre convertis dans un format prenne des fins de conservation. Dun point de vue smantique, cette interoprabilit implique de prendre en compte: le contexte de larchivage, le processus darchivage, le sens et la structuration des informations archiver.
Page 46/119
2.4.2.2. Le contexte de larchivage Cadre lgislatif Les obligations lgales en matire de gestion fiscale, comptable ou sociale imposent souvent aux administrations et aux entreprises de conserver des documents sur de longues priodes. Le code du patrimoine dfinit les archives comme l'ensemble des documents, quels que soient leur date, leur lieu de conservation, leur forme et leur support, produits ou reus par toute personne physique ou morale et par tout service ou organisme public ou priv dans l'exercice de leur activit (article L. 211-1). Les archives publiques sont les documents qui procdent de l'activit de l'tat, des collectivits territoriales (article L 211-4). Les rgles de gestion des documents d'archives publiques au long de leur cycle de vie sont dfinies par le dcret n 79-1037 du 3 dcembre 1979 modifi par le dcret n 2006-1828 du 23 dcembre 2006. Pour plus dinformations sur le cadre lgislatif rgissant larchivage, diverses sources peuvent tre consultes : le code du patrimoine, les circulaires de la DAF, Les recommandations de la CNIL, Une synthse des enjeux juridiques. Politique darchivage et systme darchivage lectronique (SAE) La politique d'archivage dfinit les exigences minimales, en termes juridiques, fonctionnels, oprationnels, techniques et de scurit, qu'une autorit d'archivage doit respecter afin que l'archivage lectronique mis en place soit considr comme fiable. Le document Politique et pratique darchivage dcrit les concepts de politique darchivage et de dclaration des pratiques darchivage. Le records management dfinit lorganisation et la gestion de linformation notamment la cration, la rception, la conservation, lutilisation et le sort final des documents darchives. Il dcrit aussi les mthodes de fixation et de prservation de la preuve lies la forme des documents. Moreq2 est un document de rfrence en matire dorganisation de larchivage. Fond sur la norme ISO 15489, le modle dfinit des exigences gnriques pour un systme lectronique de gestion des archives et des logiciels de records management en particulier. Pour mettre en uvre un systme darchivage lectronique, OAIS (Modle de rfrence pour un systme ouvert d'archivage, bas sur la norme ISO 14721) dfinit un vocabulaire et un ensemble de concepts permettant d'apprhender de faon globale et complte, la question de l'archivage long terme des donnes sous forme numrique. Recommand Mettre en uvre un systme darchivage lectronique
Smantique
Pour mettre en oeuvre un systme darchivage lectronique, il est RECOMMAND de se conformer au modle OAIS et de dfinir une organisation et une politique de larchivage.
Page 47/119
2.4.2.3. Le processus darchivage Le SEDA (Standard dEchange de Donnes pour lArchivage) vise faciliter linteroprabilit entre le systme dinformation dun service darchives et les systmes dinformation de ses partenaires (producteurs, utilisateurs...). Il dfinit la forme du dialogue ainsi que la forme des messages changs pour les cinq principaux cas dutilisation darchivage - le transfert, la communication, la modification darchives, llimination et la restitution. Le standard SEDA permet de dcrire la structure organisationnelle des contenus de donnes changs (comme un bordereau de versement par exemple). Il est gnrique et adaptable tous types de documents et de donnes, lectroniques ou papier. Aussi, lors de la prise en compte dun processus dans la chane de larchivage, un profil darchivage doit tre tabli pour prciser les rgles de description spcifiques aux types de documents ou donnes verss. Recommand SEDA DAF
Smantique
Pour mettre en place un processus darchivage, il est RECOMMAND que les services publics darchives et leurs partenaires se rfrent au Standard dEchanges de Donnes pour lArchivage .
2.4.2.4. Le sens et la structuration de linformation archive Un document numrique archiv est accessible grce la description de son contenu. Les donnes servant dfinir ou dcrire une autre donne, un document par exemple, sont appeles mtadonnes. Il existe plusieurs types de mtadonnes pour dcrire un document numrique. Les mtadonnes descriptives sont les mtadonnes qui permettent d'identifier, classifier, hirarchiser l'information contenue dans l'objet numrique. Elles ont t normalises et sont les suivantes: Pour les documents darchives, les normes tablies par lICA (Comit International des Archives) sont les normes ISAd(G) (General International Standard on Archival Description), ISAAR(CFP) (International Standard Archival Authority Record for Corporate Bodies, Persons, and Families), ISDF (International Standard for Describing Functions) et ISDIAH (International Standard for Describing Institutions with Archival Holdings). Elles sont consultables sur les sites de la DAF et de lICA ; Le Dublin Core, devenu norme ISO 15836 en 2003, est un schma gnrique et simple de mtadonnes; il s'appuie sur des lments de description formels (titre, auteur, diteur), intellectuels (sujet, description, langue, etc.) et relatifs la proprit intellectuelle ; Les mtadonnes de structure servent dcrire les liens entre des lments qui ont du sens pour l'utilisateur (numro de page, de plage audio, titre de chapitre, d'article, etc.) et le mode denregistrement des objets numriques (rpertoire, support, etc.). Les formats de mtadonnes METS (Metadata Encoding and Transmission Standard) ou XFDU (XML Formatted Data Unit) sont de bons exemples.
Page 48/119
Les mtadonnes techniques permettent d'identifier et de caractriser les formats de reprsentation de l'information ou formats de donnes. Le dictionnaire PREMIS est, dans ce domaine, un outil trs prcis. Il vise tablir, partir du modle OAIS, une liste des mtadonnes gres dans le processus de conservation numrique. Les mtadonnes administratives sont les mtadonnes qui servent grer la vie de l'objet numrique. Elles regroupent les mtadonnes de contexte, de provenance, d'intgrit et de gestion des droits ainsi que les mtadonnes permettant l'identification univoque et prenne des objets archivs. Concernant ce type de mtadonnes, le choix d'un type d'identifiant est stratgique. Cet identifiant doit rsister l'preuve du temps, aux volutions de classement intellectuel des contenus, aux changements d'organisation physique des donnes et tre indpendant des systmes et des organisations. L'IPTC (International Press Telecommunications Council) est un consortium regroupant des entreprises et des organisations actives dans le monde de la presse. L'IPTC a dfini un standard informatique pour le stockage des mtadonnes descriptives (titre, auteur, etc.) et administratives (copyright, etc.) relatives aux images de presse, l'IPTC Core. Ce standard est utilis en particulier dans les fichiers JPEG et TIFF. Plus gnralement, on peut caractriser un document ds sa cration et tout au long de son cycle de vie par son identifiant, un titre (intitul), un statut (document de travail/document valid/document prim), au moins une date (qui selon le contexte peut tre une date de cration du document, darchivage,), une classification (rattachement un dossier/rpertoire), sa dure de conservation, le producteur du document et le service auquel il appartient. Recommand Caractriser un document par ses mtadonnes
Smantique
il est RECOMMANDE quun document soit caractris, ds sa cration et tout au long de son cycle de vie, par au moins un identifiant, un titre, un statut, une date, une classification, une dure de conservation, un producteur et le service auquel il appartient.
Page 49/119
3.. IInteroprabiilliit syntaxiique 3 nteroprab t syntax que

Linteroprabilit syntaxique concerne la faon dont sont codes et formates les donnes. Dans le RGI, elle est divise en deux domaines : Les formats lmentaires Les formats lmentaires incluent les formats pour le son, la photo, limage anime et le codage des caractres. Les formats composites Les formats composites, agrgats de plusieurs objets incluent, par exemple, les documents bureautiques et les formats de compression de fichiers.
Syntaxique
Niveau politique Niveau juridique Niveau organisationnel

Niveau smantique Niveau syntaxique Niveau technique
Figure 16 : Le niveau syntaxique traite du formatage de linformation
Page 50/119
3.1. Formats lmentaires

3.1.1. Codage des caractres
UTF-8 (UCS transformation format 8 bits) est un format de codage de caractres dfini pour les caractres UNICODE. Cest une extension du code ASCII utilisant le bit de poids fort. Chaque caractre est cod sur une suite de un quatre octets. Initialement, UTF-8 tait dcrit dans la RFC 3629 et dfini dans le rapport technique 17 de la norme UNICODE. Il fait maintenant partie intgrante de la norme UNICODE dans son chapitre 3 Conformance , approuv galement par lISO, lIETF et la plupart des organismes de normalisation. LIETF requiert que UTF-8 soit support par les protocoles de communication du rseau Internet changeant du texte. L'utilisation du format UTF-8 facilite la fois la maintenance et l'accessibilit des sites Web. Les principaux navigateurs du march prennent en charge la recommandation UTF-8 depuis 1998. Recommand UTF-8 IETF
Syntaxique
Il est RECOMMAND d'utiliser la transformation UTF-8 pour lencodage des caractres.
Mme si le RGI ne sapplique quaux interfaces dchanges, il est important de noter que le choix dUTF-8 sur lensemble de la chane de traitement des caractres (couches de persistance, applicative, de prsentation et dchanges) permet damliorer linteroprabilit.
Page 51/119
3.1.2. Polices d'criture

On appelle police d'criture un ensemble de reprsentations visuelles de caractres d'une mme famille. Cet ensemble regroupe tous les corps et graisses dont le style est coordonn afin de former un alphabet. On appelle fonte de caractres un ensemble de reprsentations visuelles de caractres, d'une mme famille, de mme style (italique par exemple), corps et graisse.
Syntaxique
Recommand
Polices libres
W3C
Pour la mise forme lectronique de donnes changes, il est RECOMMAND d'utiliser des polices de caractres supportes nativement par toutes les plates-formes.
Exemple de polices : Arial, Courier, Times New Roman, Verdana. Remarque : les polices ne faisant pas lobjet de procdures de normalisation, des diffrences de rendu peuvent apparatre selon les implmentations et les outils.
Page 52/119
3.1.3. Formats dimage

Les formats dimage ouverts et supports nativement dans la majorit des navigateurs et systmes informatiques sont les suivants : GIF (Graphic Interchange Format) : particulirement adapt pour les images de 256 couleurs ou moins, pour les images ncessitant une couche de transparence et pour les animations simples ; PNG (Portable Network Graphics) : dfini par la norme ISO 15948, il supporte 16 millions de couleurs, la transparence et peut galement convenir pour des images photographiques ; JPEG (Joint Photographic Experts Group) : dfini par la norme ISO 10918, il trs utilis pour la photographie numrique ; il permet un haut niveau de compression (de lordre de 1/40) qui convient particulirement la compression de photographies TIFF (Tagged Image File Format) : format de fichier graphique bitmap, adapt pour les images de tailles importantes et de haute qualit ; DNG (Digital Negative) : format driv de TIFF qui enregistre les signaux bruts des appareils photographiques. Le choix du format utilis dpend : De la qualit de limage souhaite, De la taille du fichier cible, Du type dusage (affichage, impression, change, conservation, etc.). Les caractristiques de limage doivent tre adaptes aux besoins du destinataire. Ainsi, une image de 256 couleurs avec une couche de transparence, peut utiliser les formats PNG-8 ou GIF, le choix final pouvant dpendre de la taille du fichier image. Recommand Formats dimage
Syntaxique
Pour les images numriques, il est RECOMMAND de choisir parmi les formats GIF, PNG, JPEG, TIFF ou DNG.
Remarque : afin de pouvoir modifier une image, les fichiers originaux de cration de cette image doivent tre conservs.
Page 53/119
3.1.4. Formats de squence sonore

MP3 est l'abrviation de MPEG-1 Audio Layer 3, la spcification sonore du format MPEG-1, du MPEG (Moving Picture Experts Group). MP3 (ISO 11172-3) est un algorithme de compression capable de rduire fortement la quantit de donnes ncessaires la restitution dun son monophonique ou strophonique. Pour loreille humaine, la perte de donnes due la compression altre peu la qualit de lenregistrement sonore. Recommand MP3 ISO
Syntaxique
Il est RECOMMAND d'utiliser le format MP3 pour lchange, la diffusion et la conservation des squences sonores de qualit ordinaire.
En observation
Ogg- Vorbis
Xiph
De conception moderne, lalgorithme de compression Vorbis, qui est encapsul la plupart du temps dans le format ouvert Ogg, offre un son de bonne qualit et un excellent taux de compression. Malgr une adoption croissante, ce format est aujourdhui moins utilis que le format MP3. Le format WAV, bas sur le format RIFF (Resource Interchange File Format), permet de restituer des fichiers sonores sans perte de donnes . A lorigine, il est le format des fichiers sonores du systme d'exploitation Windows. Il a t dvelopp par les socits Microsoft et IBM. Il est maintenant largi d'autres plates-formes comme GNU/Linux par exemple. Le format WAV peut tre utilis avec un codage PCM (Pulse Code Modulation) cest--dire sans compression, les fichiers rsultants sont de haute qualit sonore mais volumineux. Le format BWF, moins rpandu ce jour, permet dassocier des mta-donnes aux fichiers WAV. Recommand WAV IBM & Microsoft
Il est RECOMMAND d'utiliser le format WAV avec un codage PCM, pour lchange, la diffusion et la conservation des squences sonores de haute qualit.
En observation
FLAC
Xiph
FLAC est un format de compression audio sans perte. Il nenlve aucune information du flux audio, tout en rduisant la taille des fichiers. Ses spcifications sont libres et il est disponible sur toutes les plateformes. Si sa maturit est croissante, il manque aujourdhui dadoption par le march.
Concernant les formats audio utiliss dans le cadre de la tlphonie sur IP, se reporter au chapitre 4.2.2.3 Codage de voix et 4.2.2.5 Convergence des messageries
Page 54/119
3.1.5. Formats de squence vido

MPEG-2 est la norme de seconde gnration issue des travaux du Moving Picture Experts Group qui fait suite MPEG-1. La norme MPEG-2 (ISO 13818) dfinit les aspects compression de l'image et du son et le transport travers des rseaux pour la tlvision numrique. Cette norme de compression pour les images animes fonctionne sur toutes les plates-formes. La norme ISO/IEC 13818-1 dfinit les aspects synchronisation, transport et stockage et les normes ISO/IEC 13818-2 et 3 dfinissent les aspects compression du signal.
Syntaxique
Recommand
MPEG-2
ISO
Il est RECOMMAND d'utiliser la norme MPEG-2 pour l'change, la prsentation et la conservation de squences vido en basse dfinition.
La norme MPEG-4 (ISO 14496) est une norme de compression pour les images animes, dfinie par le Moving Picture Expert Group de l'ISO. Elle a t publie en 1998. MPEG-4 permet de grer des flux pour l'accs travers le rseau Internet. Elle permet aussi de grer la vidoconfrence. Le dernier niveau de la norme MPEG-4 est aussi nomm H.264 par l'UIT-T.
Recommand
MPEG-4
ISO
Il est RECOMMAND d'utiliser la norme MPEG-4 pour l'change, la prsentation et la conservation de squences vido en haute dfinition.
Recommand
MPEG-4 services audiovisuels
ISO
Il est RECOMMAND d'utiliser la norme MPEG-4 pour la mise en uvre de services audiovisuels (vidoconfrence, visiophonie, etc.).
Concernant les protocoles de diffusion vido, se reporter au thme 4.4.2.9 Diffusion vido en mode continu
Page 55/119
3.1.6. Formats dobjet graphique en 2D

Les objets graphiques deux dimensions sont des donnes administratives, sectorielles ou globales ncessitant lutilisation de logiciels graphiques ddis. Les formats de graphiques vectoriels ne dcrivent pas quelles proportions de couleurs possdent un pixel de l'image, mais ils dcrivent des objets. Cette forme de graphique est idale pour le web : les donnes de description d'objets graphiques vectoriels tant en gnral plus lgres que les graphiques orients pixels. Ces formats sont appropris au dessin industriel, aux illustrations et toutes sortes de techniques graphiques. Deux standards normaliss sont conseills : Le format CGM (Computer Graphic Metafile) est une norme pour lchange et la conservation de donnes graphiques deux dimensions ; CGM (ISO 8632) est le format adopt dans de nombreux secteurs industriels comme par exemple l'industrie aronautique (ATA, AECMA), le secteur automobile (J2008), la dfense (CALS), les tlcommunications et la ptrochimie ; La format WebCGM est un profil spcifique dvelopp pour les applications web, il a t normalis par lOASIS et le W3C. Le format SVG (Scalable Vector Graphic) est une recommandation du consortium W3C. Il est bas sur le langage XML et permet la description d'objets graphiques vectoriels en deux dimensions. Il permet l'interactivit et l'excution de scripts et d'animations. Il est indpendant de la plate-forme, document, ouvert et peut tre utilis librement. Il est prfr CGM pour les donnes graphiques de haute qualit et la cration artistique.
Syntaxique
Le format SVG se distingue par les proprits particulires suivantes : il est bas sur le langage XML, il soutient le schma Xlink, il a la possibilit d'tre agrandi ou bascul, il interface le langage SMIL. Les versions les plus rcentes des logiciels de graphiques vectoriels connus soutiennent le format SVG. Les principaux navigateurs peuvent afficher des graphiques SVG. Il existe des programmes d'affichage SVG tlchargeables librement, certains pouvant tre installs comme module dextension au navigateur. Recommand SVG/CGM W3C/ISO
Il est RECOMMAND d'utiliser le format SVG 1.1 pour la description d'objets graphiques vectoriels en deux dimensions. Dans le cadre dapplications industrielles, dans les secteurs de la dfense, laronautique, lautomobile ou lnergie, il est possible dutiliser le format CGM.
Page 56/119
3.1.7. Formats dobjet et dunivers 3D

Afin de proposer des objets et des univers en 3D, les autorits administratives ont leur disposition de multiples applications de modlisation. Un effort doit tre entrepris pour normaliser le format de ces objets. X3D (Extensible 3D) est un format de fichier graphique et multimdia orient 3D. Il a t cr par le consortium Web3D dans le but de succder VRML 2.0. Ce format a t normalis par l'ISO. Le format X3D s'appuie sur une structuration de type graphe de scne et peut tre exprim l'aide de trois syntaxes diffrentes, savoir la syntaxe VRML classique, une syntaxe base sur le langage XML et une version binaire. Il existe ce jour deux API pour les langages ECMAScript (norme ISO 19777 partie 1) et Java (norme ISO 19777 partie 2).
Syntaxique
Recommand
X3D
ISO
Il est RECOMMAND d'utiliser le format X3D pour la description d'objets et d'univers virtuels en 3 dimensions.
Page 57/119
3.1.8. Formats de dessin technique

DWG est le format de fichiers du logiciel AutoCAD de la socit Autodesk, produit incontournable dans le monde du dessin technique. Un consortium but non lucratif, l'ODA (Open Design Alliance) a t cr afin de favoriser la standardisation des dessins techniques. Le but tait d'assurer la prennit du format DWG dans l'avenir, travers le format DWGdirect, mais galement du format DGN travers DGNdirect. Quasiment tous les concurrents de la socit Autodesk ont adhr cette initiative. Recommand DWGdirect ODA
Syntaxique
Il est RECOMMAND d'utiliser le format DWGdirect, ou dfaut le format DWG, pour les changes de dessins techniques en mode rvisable (par exemple des plans devant tre exploits, voire modifis).
Il faut galement noter lexistence du format DWF (Design Web Format), de la socit Autodesk, ddi la publication et au partage de dessins, de plans et de modles sur le Web. Il permet de visualiser et d'imprimer des croquis et des plans issus de l'environnement Autocad (donc au format DWG) mais sans possder lapplication de conception dorigine. Pour ouvrir ces fichiers, il est ncessaire d'installer pralablement un outil de visualisation tlchargeable librement. Le format DWF est plus compact que le format DWG, qualit indispensable pour un partage sur le Web. Echange de dessins techniques en mode non rvisable Le format PDF 1.7, normalis par lISO en juillet 2008 (ISO 32000-1) est une alternative au format DWF, pour l'change de fichiers de dessins techniques en mode non rvisable. Il s'agit de dessins qui n'ont pas vocation tre modifis par celui qui les reoit. Dans le cadre de la dmatrialisation des appels d'offres, les formats PDF et DWF sont trs utiliss pour la diffusion des plans. En effet, les plans inclus dans un dossier d'appel d'offres sont rendus publics, d'o un risque les publier sous un format modifiable. Dans le mme esprit, le format PDF permet d'apporter un premier niveau de protection en limitant la copie illicite ou le plagia de plans ou de parties de plans. Recommand PDF ISO
Il est RECOMMAND d'utiliser le format PDF 1.7, ou dfaut le format DWF, pour les changes de dessins techniques (par exemple des plans) en mode non rvisable.
Pour plus dinformation sur PDF, se reporter aux chapitres 3.2.2 Echange de documents bureautiques non rvisables, 3.2.3 Archivage de documents bureautiques non rvisables statiques, 3.2.4 Conservation des documents bureautiques dynamiques, 3.2.5 Echange de donnes numriques dimpression
Page 58/119
3.1.9. Exportation de bases de donnes

Il nexiste pas de standard de format lmentaire permettant dchanger une exportation de base de donnes. Plusieurs formats sont acceptables (XML, CSV), cependant aucun nest autoporteur. Les fichiers produits doivent donc tre accompagns de documents prcisant la structure et le contenu du fichier ainsi que le jeu de caractres utilis.
Recommand
XML / CSV
W3C
Syntaxique
Il est RECOMMAND dutiliser XML ou CSV pour lexportation de tout ou partie dune base de donnes.
Remarque : XML nest pas prconis pour les volumtries importantes.
Pour de plus amples informations sur les changes XML se reporter au chapitre 3.2.6 Echange de documents structurs
Page 59/119
3.2. Formats composites

Prcisions terminologiques lies aux formats composites : Un document non structur est un document ayant une structure libre, par exemple une page Web ; Un document semi-structur est un document ayant une partie structure et une partie dont la structure est libre. De nombreux formats de document, notamment ceux issus des logiciels bureautiques (traitement de texte, tableur, prsentation, etc.), utilisent ce type d'organisation. Les logiciels de dessin technique, de CAO, de production industrielle entrent eux aussi dans cette catgorie ; Un document structur est un document supportant un format dont chaque lment est parfaitement dfini, par exemple une extraction de base de donnes ; Un document rvisable est un document qui peut tre modifi en utilisant des moyens ordinaires lis la manipulation du format support de ce document ; Un document non rvisable est un document qui ne peut pas tre modifi en utilisant des moyens ordinaires lis la manipulation du format support de ce document ; Un document bureautique dynamique est un document non rvisable qui comprend des lments tels que des scripts ou encore de l'audio ou de la vido.
Syntaxique
Page 60/119
3.2.1. Echange de documents bureautiques rvisables

Les documents crs et manipuls par les suites bureautiques sont des documents semistructurs. L'change de documents bureautiques constitue un lment important du dveloppement des changes par voie lectronique. Recommand Langage XML ISO
Pour les changes de documents bureautiques semi-structurs en mode rvisable, il est RECOMMAND dutiliser un format de document bas sur le langage XML et dont les spcifications sont normalises par l'ISO.
Syntaxique
Deux formats bureautiques coexistent aujourdhui sur le segment des documents bureautiques XML normaliss : ODF (Open Document Format) et OXML (Office Open XML). ODF est un format bureautique bas sur le langage XML. La version 1.0 du format de document ouvert a t approuve par lorganisation OASIS en mai 2005, puis par lISO en mai 2006. Le format Office Open XML a t valid comme standard ECMA en dcembre 2006. Depuis, les spcifications du format ont t amendes et sa normalisation par lISO est intervenue en novembre 2008 (ISO 29500). En observation ODF OASIS
Des amliorations de la norme concernant laccessibilit ont t apportes avec la version 1.1, approuve par lOASIS en octobre 2006. La majorit des implmentations du march reprennent cette dernire version. La version ODF 1.2 est en cours dlaboration et devrait tre soumise lapprobation OASIS et ISO en 2009.
En observation
Office Open XML
ISO
Le format Office Open XML est un format bureautique bas sur XML. Il supporte nativement une partie des formats binaires bureautiques existants. Il nexiste pas ce jour dimplmentation de cette norme.
Les autorits administratives et les usagers peuvent choisir parmi plusieurs solutions bureautiques, ce qui rend critique linteroprabilit lors de lchange de documents. Dans lattente dun support complet des deux normes dans les suites les plus utilises, des mthodes de transformation sont disponibles (ex : ODF Converter, Plugin ODF de Sun). Cette fiche est fonde sur les informations disponibles au mois de mai 2009 et sera rvise d'ici la publication officielle du rfrentiel si de nouveaux lments d'apprciation se faisaient jour.
DGME RGI Version 1.0 12-05-2009 Page 61/119
3.2.2. Echange de documents bureautiques non rvisables

La plupart des documents bureautiques changs ont un but informatif et ne sont pas destins tre rviss. Il est rellement bnfique d'changer des documents dans un format ouvert et parfaitement interoprable. Le format PDF 1.7 a t normalis par lISO en juillet 2008 et ses spcifications rendues publiques. Avant cette normalisation, le format PDF tait devenu un standard de fait de par son adoption par la trs grande majorit des utilisateurs. Un des principaux avantages de ce format rside dans le fait que les documents transforms au format PDF sont parfaitement fidles aux documents originaux. Les polices, les images, les objets graphiques et la mise en forme du fichier source sont prservs, quelles que soient l'application et la plate-forme utilises pour crer ces documents. Recommand PDF ISO
Syntaxique
Il est RECOMMAND dutiliser le format PDF 1.7, pour les changes de documents bureautiques en mode non rvisable.
Page 62/119
3.2.3. Archivage de documents bureautiques non rvisables statiques

Le format PDF/A-1 dcrit dans la norme ISO 19005-1, rpond aux problmatiques darchivage long terme. Toutes les informations ncessaires la reprsentation du document sont inclues dans le fichier, telles que les polices de caractres, les images et les informations colorimtriques. Si le PDF 1.7 (plus lger) est adapt aux changes, le PDF/A est, quant lui, utilis dans le cadre de la conservation et de larchivage. Il est important de noter qu'il y a deux variantes de PDF/A-1. La version PDF/A-1a reprsente la forme complte de la norme ISO ;
Syntaxique
La version PDF/A-1b reprsente une forme allge de la norme ISO. Cette version prserve la lisibilit du document et sa bonne prsentation l'affichage et l'impression. PDF/A ISO
Recommand
Il est RECOMMAND dutiliser le format PDF/A, pour larchivage des documents bureautiques statiques non rvisables.
Remarque : dans le cas dchange de documents archivs dans le format PDF/A, il nest pas ncessaire de les convertir au format PDF 1.7 avant change.
Page 63/119
3.2.4. Conservation des documents bureautiques dynamiques

Le format PDF/A-1 est bas sur le format PDF v1.4. Il sagit donc dune version restreinte du format PDF. Les restrictions sont caractrises par : La non inclusion dobjets dynamiques de type audio ou vido, Linterdiction du lancement de code script ou de fichiers excutables, Linterdiction du chiffrement et de la scurit.
Syntaxique
Du fait de la limitation actuelle des fonctionnalits du PDF/A, il est conseill dutiliser le PDF 1.7, qui prend en compte les aspects dynamiques des documents. Cependant, il faut noter que ce format nest pas ddi larchivage, contrairement PDF/A. Recommand PDF 1.7 ISO
Il est RECOMMAND dutiliser le format PDF 1.7 pour la conservation des documents bureautiques dynamiques.
Des volutions de la norme PDF/A sont en cours, ces travaux sont bass sur le format PDF 1.6 et prennent en compte les aspects dynamiques d'un document bureautique.
Page 64/119
3.2.5. Echange de donnes numriques dimpression

Le format PDF/X a t dfini en 1998 par le groupe de travail CGATS (Committee for Graphic Arts Technology Standards), sur l'initiative du DDAP (Digital Distribution of Advertising for Publications) et du NAA (Newspaper Association of America). Ce format de fichier est adapt aux problmatiques dimpression. La spcification propose par le groupe de travail CGATS a t adopte plus tard par l'ISO. Les spcifications de ce format permettent d'assurer l'change de documents PDF de manire fiabilise dans le domaine de la pr-impression. Les fichiers PDF sont vrifis avant leur envoi de faon viter les diffrences d'interprtation des RIP Postscript. La lettre "/X" signifie Blind eXchange (change aveugle). L'objectif de PDF/X est de permettre un "change aveugle" de fichiers PDF dans un flux de production graphique. La norme ISO 15930 se dcline, ce jour, en plusieurs versions : PDF/X-1a (ISO 15930-1) : cette version est base sur la version PDF 1.3. Elle est utilise dans des environnements adapts et prsente la particularit de pouvoir incorporer les images haute rsolution en fichiers attachs. Cette version est utilise pour l'change complet de donnes numriques ; PDF/X-2 (ISO 15930-2) : cette version n'oblige pas l'incorporation des polices et des images haute rsolution. Elle permet donc l'change de documents avec des ressources partielles, car c'est la rception que les ressources ncessaires seront compltes. Elle noblige pas lincorporation des images haute rsolution ni des polices et ne peut donc tre utilise dans un environnement ouvert. Cette version ne peut tre utilise pour une impression professionnelle ; PDF/X-3 (ISO 15930-3 et 15930-6) : cette version est base sur les versions PDF 1.3 et PDF 1.4. Elle autorise les gestions de la couleur plus tendue que le PDF/X-1a. Elle oblige l'encapsulation des polices utilises et n'interdit pas les compressions du document, mais ne ncessite pas de connatre l'environnement dans lequel ont t prpars les fichiers PDF (principe de l'change aveugle). Elle reprsente ce jour le meilleur compromis entre libert de cration, fiabilit et possibilits de corrections ; PDF/X-4 (ISO 15930-7) : cette version concerne l'change complet de donnes d'impression (PDF/X-4) et l'change partiel de donnes d'impression avec une rfrence de profil externe (PDF/X-4p) par utilisation du format PDF 1.6. Elle a t publie en fvrier 2008.
Syntaxique
La version PDF/X-5 est encore en cours d'laboration au sein de l'ISO. Elle repose sur l'utilisation de la version PDF 1.6. Recommand PDF/X ISO
Il est RECOMMAND d'utiliser le format PDF/X pour lchange de donnes numriques d'impression.
Page 65/119
3.2.6. Echange de documents structurs

Un document structur est un document supportant un format dont chaque lment est parfaitement dfini. XML (Extensible Markup Language) est un langage bas sur le langage SGML (ISO 8879). Il a t dfini et promu par le consortium W3C. XML 1.1 a t conu pour assurer une prise en charge plus tendue des caractres Unicode. Le W3C recommande aux processeurs XML de reconnatre les deux versions. Recommand XML W3C
Syntaxique
Il est RECOMMAND d'utiliser le langage XML pour l'envoi de documents structurs.
XML peut galement tre utilis dans le cadre de lexportation de base de donnes. Se reporter au chapitre 3.1.9 Exportation de bases de donnes
Page 66/119
3.2.7. Langage de transformation de donnes structures

Le langage XSLT (eXtensible Stylesheet Language Transformations), spcifi par le W3C, permet de transformer des documents XML en documents XML ou en documents sappuyant sur dautres formats. XSLT est souvent utilis pour transformer le schma de document XML ou pour convertir du XML en HTML ou XHTML. Pour accder aux donnes XML, le dveloppeur dispose dexpressions formalises en langage XPath spcifi galement par le W3C. XPath est un langage de requte qui permet de naviguer travers larborescence dun document XML et de slectionner des nuds spcifiques selon une large varit de critres.
Syntaxique
Recommand
XSLT / XPath
W3C
Il est RECOMMAND d'utiliser les langages XSLT et XPath pour formater et transformer des documents XML.
Page 67/119
3.2.8. Service de compression de fichiers

La compression de donnes est une technique qui permet de rduire l'espace ncessaire la reprsentation d'une certaine quantit d'information. Elle concerne ainsi la transmission des donnes en ligne mais galement leur sauvegarde dans un fichier. Cette fiche traite exclusivement du thme de la compression des fichiers de donnes. Zip est un format cr en 1989 par la socit PKWARE. Sil sagit dun format propritaire, ses spcifications sont publiques depuis sa cration et limplmentation dune grande partie de ses fonctions se fait sous licence ouverte (il utilise en particulier lalgorithme deflate dfinit dans le RFC 1951).
Syntaxique
Zip est le format de compression de fichiers le plus rpandu travers le monde, il est implment dans une multitude doutils et support nativement dans les dernires versions de Windows et Mac OS. Certaines mthodes de compression telles que 7z, Rar ou Rk proposent des taux de compression plus performants mais impliquent linstallation de clients. De plus, le nombre de logiciels de compression proposant leurs implmentations est limit. Recommand Zip PKWARE
Il est RECOMMAND d'utiliser le format Zip pour la compression de fichier dans un but dchange.
Sur cette mme problmatique de compression, voir le chapitre 4.4.2.5 Meilleures pratiques HTTP
Page 68/119
3.2.9. Syndication de contenu

RSS (Really Simple Syndication) dcrit un format de document XML permettant de raliser de lagrgation (de la syndication) de contenu Web. Cest un langage simple de formatage des donnes. Ce format est habituellement utilis pour obtenir les mises jour d'informations dont la nature change frquemment. Pour recevoir ces mises jour, l'utilisateur s'abonne un flux (ou fil) dinformation. RSS peut tre utilis de deux manires : Agrgation au niveau dun portail des contenus provenant de diffrents services, Accs des contenus directement du poste de travail de lusager laide dun lecteur de flux RSS. Le format de syndication ATOM a t cr pour combler certaines lacunes de RSS. Il se distingue notamment sur les lments suivants : Identification du type de flux transport, Alignement avec les formats de date ISO, Gestion du multilinguisme. Ce format est standardis et maintenu par lIETF. Recommand RSS / ATOM RSS Board / IETF
Syntaxique
Il est RECOMMAND dutiliser les formats RSS et/ou ATOM pour raliser de la syndication de contenu Web de type fil dinformation .
Pour une mise en uvre des techniques de syndication de contenu favorisant l'interoprabilit, il est utile de prciser aux navigateurs le type de contenu (ou type MIME Internet Media Type) des fils d'informations envoys. Recommand Type de contenu des fils dinformation
Afin de prciser le type de contenu des fils d'informations envoys aux navigateurs, il est RECOMMAND de positionner le paramtre HTTP Content-Type header aux valeurs text/xml , application/rss+xml ou application/atom+xml .
Page 69/119
4.. IInteroprabiilliit techniique 4 nteroprab t techn que

Le RGI regroupe les normes et standards techniques selon quatre grands domaines : La prsentation La prsentation traite des technologies de navigation et de restitution. Le multimdia Le multimdia traite des technologies de communication entre humains, notamment de la messagerie et de la tlphonie. Les services web Les services web traitent des technologies dchanges entre SI. Linfrastructure Linfrastructure traite des technologies lmentaires ncessaires aux changes, notamment des protocoles rseau.
Technique
Niveau politique Niveau juridique Niveau organisationnel Niveau smantique

Prsentation
Niveau syntaxique Niveau technique
Figure 17 : Le niveau technique
Page 70/119
4.1. Prsentation
4.1.1. Technologies pour construire les IHM
Le langage HTML (Hypertext Markup Language) est un langage cr et utilis pour crire des pages Web. Il est conforme la norme ISO 8879 qui dcrit le langage SGML (Standard Generalized Markup Language). Il permet notamment dinsrer des liens dans du texte, ce qui autorise une navigation de page en page. Depuis 1999 le langage XHTML (Extensible HyperText Markup Language) a succd au langage HTML. Sa principale force rside dans le fait quil dissocie la forme dune page web de son contenu. Le langage XHTML respecte la syntaxe dfinie par le langage XML. Recommand XHTML W3C
Il est RECOMMAND dutiliser le langage XHTML pour construire les interfaces des sites Internet de ladministration.
Technique
Il existe trois types de syntaxe du langage XHTML : XHTML 1.0 Strict : cette grammaire est la plus stricte et interdit lutilisation des attributs dprcis dHTML, XHTML 1.0 Transitionnal : cette grammaire permet lutilisation de certains attributs de prsentation dprcis, XHTML 1.0 Frameset : cette grammaire autorise lutilisation de frames Recommand XHTML strict W3C
Prsentation
Il est RECOMMAND d'utiliser la syntaxe XHTML 1.0 Strict ou XHTML 1.0 Transitionnal pour construire les interfaces des sites Internet de ladministration.
En observation
HTML 5
W3C
Un groupe de travail, soutenu par les principaux diteurs de navigateurs Internet, a t cr par le W3C pour faire nouveau voluer le langage HTML. Les premires versions de travail des spcifications HTML 5 ont t publies.
Page 71/119
4.1.2. Feuilles de styles

Les feuilles de style en cascade CSS (Cascading Style Sheet) permettent de spcifier l'habillage et la mise en page (couleurs, polices, rendu) des documents structures (XHTML, XML, etc.) mais aussi des IHM des applications Web de l'administration lectronique. Le niveau 2 de CSS permet notamment d'adapter la prsentation diffrents modes d'accs de l'utilisateur (navigateurs graphiques, imprimantes, terminaux braille, etc.).
Recommand
CSS 2
W3C
Il est RECOMMAND d'utiliser les feuilles de style CSS niveau 2 pour ajuster la prsentation de documents structurs.
En observation
CSS 3
W3C
Technique
Le W3C travaille actuellement sur la version 3 de CSS, qui spare en modules distincts les diffrentes fonctionnalits des feuilles de styles.
Prsentation
Page 72/119
4.1.3. Utilisation de scripts

En informatique, le langage de script est utilis pour mettre au point rapidement des programmes. Il s'agit en effet d'une suite d'instructions interprtes et excutes dans l'ordre o elles sont crites. Dans le contexte des applications du Web, le script est intgr une page Web et excut par le navigateur. Il permet de raliser des tches simples comme la vrification des donnes entres dans un formulaire, la gestion des menus, etc. Javascript est une implmentation largement usite de la norme ISO ECMAScript. La majorit des navigateurs web du march limplmentent.
La notation JSON permet le traitement des donnes changes directement dans Javascript.
Il faut noter lexistence de frameworks de scripts, qui sont des bibliothques regroupant un certain nombre de fonctions et mthodes Javascript. Ces bibliothques permettent de faciliter le dveloppement et dassurer une portabilit optimale. Lors de lutilisation de scripts, il est important de prvoir un accs dgrad linformation pour les usagers ayant dsactiv les fonctions de scripts. Recommand ECMAScript ISO
Technique Prsentation
Pour lutilisation de scripts, il est RECOMMAND d'utiliser des langages conformes la norme de langage ECMAScript ; dans le cas dutilisation de frameworks, le choix doit se porter sur des frameworks prennes et supports par une communaut importante.
Page 73/119
4.1.4. Navigateurs web

Depuis quelques annes, il y a une diversification des types d'appareils permettant d'accder au Web. Chaque type dappareil possde sa propre IHM (Interface Homme Machine). Cette diversification est principalement due au dveloppement des possibilits de mobilit. Les dveloppeurs auront le souci de rendre les dveloppements logiciels indpendants de leur support matriel et de sassurer de la compatibilit des services en ligne avec les principaux navigateurs du march.
Recommand
Navigateurs
Il est RECOMMAND de sassurer de la compatibilit des services en ligne avec les navigateurs Web suivants : Internet Explorer (version 6 et suprieures), Mozilla Firefox (version 2 et suprieures), Safari (version 3 et suprieures).
Technique
i i
Afin de favoriser laccessibilit, il est conseill de sassurer de la lisibilit des services en ligne dans des navigateurs de type texte comme Lynx. Pour plus dinformation sur laccessibilit, se reporter au RGAA. Lors de la conception / ralisation dun site internet, il est possible de vrifier la syntaxe des documents web, de valider la syntaxe des feuilles de style, dvaluer lergonomie du site au regard de la Charte Ergonomique .
Prsentation
Page 74/119
4.2. Multimdia
4.2.1. Messagerie
4.2.1.1. Protocole de messagerie SMTP (Simple Mail Transfer Protocol) est le protocole utilis pour le transport des messages lectroniques (appels aussi courriers lectroniques ou courriels) sur Internet. Le protocole SMTP permet le transfert du courrier lectronique selon un procd efficace et fiable. Il est bas sur la couche transport TCP et donc conforme au protocole IP. Les principes de base sont rfrencs par les recommandations RFC 2821 pour la spcification de base et RFC 2822 pour le format des messages.
Rgle 01
SMTP
IETF
Technique
Pour lchange de courriels, il est OBLIGATOIRE d'utiliser le protocole SMTP.
Notons aussi que la recommandation RFC 2821 prvoit lutilisation dextensions SMTP (ESMTP) en fournissant une structure pour la prise en charge de fonctionnalits additionnelles. Recommand ESMTP IETF
Il est RECOMMAND d'utiliser lextension ESMTP pour implmenter les fonctionnalits supplmentaires au protocole SMTP.
Multimdia
Page 75/119
4.2.1.2. Reprsentation des messages et des pices jointes Les spcifications de SMTP ne couvrent pas lensemble des formats tels que les images, les fichiers binaires ou les messages imbriqus. De plus, elles ne supportent que les jeux de caractres ASCII. MIME (Multipurpose Internet Mail Extensions) est un format d'change de message utilis pour la reprsentation des messages lectroniques. Il comble les lacunes de SMTP en dfinissant comment coder les textes non ASCII et les pices jointes, de sorte quils puissent tre vhiculs au sein du RFC 2822. Son usage est obligatoire pour l'envoi de courriels aux usagers et aux agents publics. Rgle 02 MIME IETF
Pour la reprsentation des courriels et des pices jointes, il est OBLIGATOIRE d'utiliser le format d'change MIME.
Technique Multimdia
Page 76/119
4.2.1.3. Scurisation de la messagerie S/MIME est une extension de MIME qui permet de scuriser des messages MIME (chiffrement ou signature). Son usage est obligatoire pour l'envoi scuris de courriels aux usagers et aux agents publics. Rgle 03 S/MIME IETF
Pour scuriser les envois de courriels, il est OBLIGATOIRE d'utiliser lextension S/MIME.
STARTTLS est une extension du protocole SMTP permettant de scuriser une transaction en crant un tunnel TLS entre deux serveurs de messagerie. Recommand STARTTLS IETF
Technique
Il est RECOMMAND de proposer l'extension ESMTP STARTTLS sur les serveurs de messagerie, mais sans exiger que les clients l'utilisent (en particulier entre serveurs ou sur Internet).
Multimdia
Page 77/119
4.2.1.4. Accs aux botes aux lettres lectroniques POP3 et IMAP4 sont des protocoles utiliss pour l'accs aux BAL (Botes Aux Lettres lectroniques). IMAP (Interactive Mail Access Protocol) est moins utilis que POP3 mais il offre plus de possibilits. Il gre plusieurs accs simultans, ainsi que plusieurs botes aux lettres sur le serveur. Il permet aussi les recherches de courrier selon des critres. Il est plus riche mais plus complexe mettre en uvre que POP3. IMAP4 devrait progressivement remplacer POP3. Rgle 04 POP3 / IMAP4 IETF
Pour relever les courriels dposs dans une bote aux lettres, il est OBLIGATOIRE de pouvoir mettre en uvre le protocole POP3 ou le protocole IMAP4.
Technique Multimdia
Page 78/119
4.2.1.5.
Les services de messagerie instantane
La messagerie instantane est un service qui permet de communiquer par ordinateur avec un interlocuteur distant connect au mme rseau informatique, notamment Internet. On parle de dialogue en ligne ( chat en anglais). En voluant, la messagerie instantane tend intgrer des fonctionnalits de voix sur IP ainsi que de visioconfrence grce l'adjonction d'une camra et d'un microphone. Elle s'ouvre galement la communication entre processus automatiss et/ou ordinateur et serveurs. Face labsence dinteroprabilit entre les protocoles propritaires existants, l'IETF a propos en 2004 le protocole XMPP pour pouvoir oprer des services de messagerie instantane sur Internet, de manire ouverte et non propritaire. XMPP est l'acronyme de eXtensible Messaging and Presence Protocol que l'on peut traduire en franais par protocole extensible de prsence et de messagerie . Il est bas sur une architecture client/serveur permettant les changes dcentraliss de messages instantans ou non entre les clients. Il est dfini par les RFC 3920 3923.
Technique
Le protocole XMPP ralise ses changes de donnes par transmission de flux XML. Cela lui offre des possibilits d'extension trs importantes et il peut ainsi tre utilis dans des applications et environnements trs divers. XMPP prsente une architecture de type client/serveur (C2S) et serveur serveur (S2S). Les communications se font donc entre les clients et le serveur et entre les serveurs, comme l'e-mail, ceci prs qu'un serveur XMPP est la fois metteur et rcepteur de messages instantans et de prsence. Un environnement XMPP repose sur deux grands groupes de spcifications : Le premier est le socle de base que constituent les RFC de l'IETF consacres au cur du protocole XMPP. Ce socle est obligatoire pour que l'infrastructure fonctionne ; Le second est constitu par les XEP (XMPP Extension Protocol) qui regroupent un ensemble d'extensions pour ajouter de nouvelles fonctionnalits. Ces extensions sont facultatives aussi bien pour les clients que pour les serveurs. Recommand XMPP IETF
Multimdia
Il est RECOMMAND d'utiliser XMPP pour la messagerie instantane.
Concernant la scurisation des communications changes, XMPP utilise le protocole TLS. Ce protocole est dtaill au chapitre 4.4.2.8 Service de scurisation des changes
Page 79/119
4.2.2. Tlphonie
4.2.2.1. Protocoles pour la tlphonie La voix sur rseau IP souvent abrge en VoIP (Voice over IP), est une technique qui permet de transporter des conversations tlphoniques sur tout rseau acceptant le protocole IP. La technique utilise est une encapsulation des donnes dans les paquets IP. Cest une technique trs diffrente de la tlphonie classique qui dpend de centraux tlphoniques (autocommutateurs) et dun cblage ddi. La tlphonie sur rseau IP souvent abrge en ToIP (Telephony over IP), est une technique qui permet de transporter des conversations tlphoniques sur tout rseau acceptant le protocole IP, mais galement de fournir des services comparables ceux dlivrs par un autocommutateur tlphonique classique. Les protocoles RTP et RTCP sont de niveau Transport (modle OSI couche 4) mais sont placs au-dessus du protocole de transport UDP. Le protocole UDP est lger donc rapide et a l'avantage d'tre multi-cast. Le protocole TCP est trop lent pour envisager de faire du temps rel sur IP.
Technique
RTP est spcifi par l'IETF et s'appuie sur un ancien protocole propritaire, RDP. Le protocole RTCP (Real-time Transfert Control Protocol) est un protocole associ RTP. Il est bas sur des transmissions priodiques de paquets de contrle par tous les participants dans la session. Il contrle les flux RTP et permet de vhiculer des informations basiques sur les participants d'une session et sur la qualit de service. Nanmoins si RTCP mesure les performances, il n'offre pas de garantie de service. Recommand RTP / RTCP IETF
Il est RECOMMAND dutiliser le protocole RTP et son protocole de contrle de flux RTCP pour le transport de la voix sur protocole IP.
Multimdia
Scurit des mdias : pour information, la protection des mdias (donnes, vido, voix) est un point sensible des architectures de tlphonie. Le protocole RTP/RTCP permet de grer les flux de donnes au niveau mdia mais ils ne sont pas scuriss. Le protocole SRTP/SRTCP peut permettre de scuriser les flux mdias.
RTP peut galement tre utilis dans le cadre de la 4.4.2.9 Diffusion vido en mode continu
Page 80/119
4.2.2.2. Signalisation et gestion de session 4.2.2.2.1. Le protocole H.323 Le protocole H.323 regroupe un ensemble de protocoles de communication sur le protocole IP. H.323 assure des services pour communications multimdia sur des rseaux en mode paquet n'offrant pas ncessairement une qualit de service garantie. Les entits H.323 peuvent assurer en temps rel des communications audio, vido et de donnes. Seul le mode audio est obligatoire. Le rseau commutation de paquets sur lequel communiquent les entits H.323 peut tre constitu d'une connexion point point, d'un seul segment ou d'un inter-rseau de plusieurs segments aux topologies complexes. C'est un protocole dvelopp par l'UIT-T. Il est driv du protocole H.320 utilis sur les rseaux RNIS. Terminal : un terminal H.323 est une extrmit du rseau assurant en temps rel des communications bidirectionnelles avec un autre terminal, une autre passerelle ou un autre pont de confrence H.323. Ces communications permettent l'change de commandes, d'indications, de signaux audio, d'images animes vido en couleur et/ou de donnes entre les deux terminaux.
Technique
Signalisation : H.323 dcrit l'utilisation de trois types diffrents de messages: H.245, RAS et signalisation d'appel H.225.0. Le module de commande du systme (H.245, H.225.0) assure la signalisation ncessaire au bon fonctionnement du terminal H.323. Il assure la commande d'appel, l'change des capacits, la signalisation des commandes et des indications et il fournit des messages d'ouverture des voies logiques. RTP/RTCP : Dans certains cas, lutilisation du protocole RTP/RTCP est requise par exemple pour les chiffres DTMF (Dual Tone Multi Frequency), les tonalits et les signaux tlphoniques. Chiffrement : Les fonctions d'authentification et de scurit sont facultatives pour les systmes H.323. Si toutefois elles sont fournies, elles doivent l'tre conformment la Rec. UIT-T H.235.0 Applications de passerelle : Il existe de nombreuses applications pour passerelles dcomposes et composites. Les vendeurs et/ou les exploitants peuvent dcider d'utiliser une passerelle composite ou dcompose selon les exigences applicatives. Les passerelles dcomposes sont appeles par la Rec. UIT-T H.248 interfonctionner avec les passerelles composites. Recommand H.323 UIT
Multimdia
Il est RECOMMAND dutiliser le protocole H.323 pour l'tablissement de sessions de communication multimdia lorsque le transport sous-jacent est un rseau en mode paquet.
Page 81/119
4.2.2.2.2. Protocole dinitialisation de session Le protocole dinitialisation de session ou SIP (Session Initiation Protocol) travaille de concert avec des protocoles permettant aux points de terminaison Internet (appels agents utilisateurs) de se dcouvrir lun lautre et de se mettre daccord sur une caractrisation dune session quils aimeraient partager. Pour localiser les participants potentiels une session et pour dautres fonctions, SIP permet la cration dune infrastructure dhtes de rseau (appels serveurs mandataires) auxquels les agents utilisateurs peuvent envoyer leurs enregistrements, invitations aux sessions et autres requtes. SIP est un outil souple et gnral pour crer, modifier et terminer les sessions multimdia. Il travaille indpendamment des protocoles de transport sous jacents et est indpendant du type de session tablie. SIP nest pas un systme de communications intgr verticalement mais un composant qui peut tre utilis avec dautres protocoles de lIETF pour construire une architecture multimdia complte. Ces architectures incluent gnralement des protocoles tels que :
Technique
RTP (Real-Time Transport Protocol ): un protocole pour le transport en temps rel de donnes et la fourniture dinformations en retour sur la qualit de service, RTSP (Real-Time Streaming Protocol) : un protocole de communication permettant de contrler un serveur de mdia distance, MEGACO/H248 (Media Gateway Control Protocol) : un protocole pour contrler des passerelles vers le rseau tlphonique public commut (RTPC), SDP (Session Description Protocol) : un protocole de description de session multimdia.
SIP devrait tre utilis conjointement avec les autres protocoles afin de fournir des services complets aux utilisateurs. Cependant, le fonctionnement de base de SIP ne dpend daucun de ces protocoles. Recommand SIP IETF
Multimdia
Il est RECOMMAND dutiliser SIP, pour tablir, modifier et terminer des sessions multimdia (confrences) telles que des communications tlphoniques par lInternet.
La protection du protocole SIP est un point sensible des architectures de tlphonie. Le protocole TLS peut permettre de scuriser les flux de signalisation. Ce protocole est dtaill au chapitre 4.4.2.8 Service de scurisation des changes
Page 82/119
4.2.2.3. Codage de voix Il existe de nombreuses manires de coder la voix. Les travaux l'UIT-T et de l'ETSI font rfrence en la matire. Pour une transmission de la voix, sans compression, la bande passante est de 64 kbps en utilisant un codage tel que le codec G.711. Le codec G.711 est utilis en tlphonie classique RTC ou RNIS et en VoIP. Il existe dautres spcifications de codage/dcodage (codecs): La famille de codecs G.729 est utilise pour le codage de la parole 8kbits/s pour obtenir une tlphonie de qualit, la visio-confrence et la VoIP ; Le codec G.723.1 est utilis en VoIP et plus particulirement pour les communications multimdias achemines 5,3 kbit/s et 6,3 kbit/s ; Le codec G.726 est utilis en tlphonie satellite et en VoIP, pour la modulation par impulsions et le codage diffrentiel adaptatif (MICDA) 40, 32, 24, 16 kbit/s ; Le codec G.722 est utilis pour le codage audiofrquence 7 kHz un dbit infrieur ou gal 64 kbit/s. Il est important de prciser que le dbit mentionn est relatif la couche applicative. Le dbit rel engendr au niveau IP ou Ethernet est ncessairement plus important du fait de lencapsulation. Recommand Codecs tlphonie ETSI, UIT-T, GSM, 3PPP
Technique
Il est RECOMMAND dutiliser un ou plusieurs codecs parmi ceux spcifis dans les recommandations G.711A, G.722, G723.1, G.729, G.729A, ETSI GSM 06.10, IETF iLBC, Speex, pour le codage de la voix.
Attention : le choix d'un ou plusieurs codecs se fera en fonction des caractristiques du rseau utilis. Dans la pratique, l'ensemble des codecs indiqus ci-dessus nest pas implment dans chaque poste IP. A lheure actuelle, les postes IP supportent G729, G711 et parfois G722. Le support des codecs GSM 06.10, iLBC et Speex est de fait assez rare. Liste des codecs audio du GSM et de lUMTS Les standards du GERAN et de lUTRAN proposent 40 diffrents codecs de voix (3GPP TS 26.103 V8.1.0) : pour le GSM avant la Rel-4 : GERAN sries 06, pour le GSM Rel-4 et suivantes : GERAN sries 46, pour la 3G/GSM (R99 et autres) : GERAN + UTRAN sries 26.
Multimdia
Page 83/119
4.2.2.4. Annulation dcho Que ce soit sur des rseaux analogiques ou sur des rseaux numriques, il est ncessaire de mettre en uvre des dispositifs d'annulation d'cho ou de suppression d'cho. L'UIT en a spcifi plusieurs ; certains sont compatibles entre eux, comme par exemple G.164 et G.165. Lcho a un effet majeur sur la qualit de la voix dans les rseaux de tlcommunication. Les effets indsirables de lcho rsultent des combinaisons de rflexions venant des composants du rseau, combines avec le signal et le dlai de transmission. Lcho peut causer des difficults de parole et dcoute pour lutilisateur de la connexion tlphonique. Il peut aussi perturber les transmissions des donnes de la bande voix, fax et tltexte. Les annulations dchos du rseau numrique sont faites pour liminer lcho pour lutilisateur et pour faciliter les transmissions des donnes de la bande voix et fax. Une bonne pratique consiste utiliser la recommandation G.168 (UIT-T G.168) comme dispositif d'annulation d'cho sur les rseaux numriques. Bien que lannulation dcho ne ncessite pas dinteraction entre les quipements, il est bon de prciser ce point pour garantir linteroprabilit des solutions de tlphonie. Cela permet d'viter des interactions nfastes entre annulations dcho incompatibles. Recommand G.168 UIT-T
Technique
Il est RECOMMAND d'utiliser la recommandation G.168 comme dispositif d'annulation d'cho sur les rseaux numriques.
Multimdia
Page 84/119
4.2.2.5. Convergence des messageries Les utilisateurs sont confronts une multiplication des systmes de messagerie tels que la messagerie de l'ordinateur, la bote vocale du tlphone fixe et celle du tlphone portable, les messageries des ordinateurs de poche et les SMS (Short Message Service) sur tlphone portable. La convergence des messageries devient une ncessit. Un exemple de convergence consiste transformer les messages vocaux en fichiers. Ces fichiers sont transmis sur la messagerie de l'ordinateur comme pice jointe d'un message classique. Dans le cadre d'une messagerie unifie, le format MP3 permet darchiver des messages audio en provenance d'une messagerie vocale. La taille des messages au format MP3 est plus petite que celle des messages utilisant des formats non compresss. Dans le serveur vocal, les messages ncessitent ainsi moins despace de stockage que des messages utilisant des formats non compresss. Recommand MP3 ISO
Technique
Il est RECOMMAND d'utiliser le format MP3 pour enregistrer les messages vocaux mis en pice jointe dans les messageries unifies.
En observation
Vorbis
Xiph
De conception moderne, le codec Vorbis, qui est un format ouvert, offre une meilleure qualit et un meilleur taux de compression que le format MP3. Cependant, malgr une adoption croissante, il est aujourdhui moins implment que le format MP3.
En observation
Speex
Xiph
Multimdia
Speex est codec spcialis dans les applications de VoIP/ToIP de plus en plus utilis. Etant ddi la voix humaine, il propose un excellent taux de compression dans ce domaine, tout en conservant une trs bonne qualit.
Concernant les formats audio, se reporter au chapitre 3.1.4 Formats de squence sonore
Page 85/119
4.3. Services Web

Ce chapitre prsente les normes, standards et meilleures pratiques mettre en uvre afin de garantir l'interoprabilit des Services Web, cest dire permettre une autorit administrative de consommer des services mis disposition par dautres administrations et dexposer ses propres services des clients (administrations, usagers, ). Les Services Web sont des composants informatiques exposant des fonctions sur le rseau (Internet, intranet). Ils doivent supporter des interactions et des changes de donnes normalises dans un environnement distribu, de manire indpendante des technologies dimplmentation utilises. Lacception Services Web englobe les deux technologies suivantes : Les Services Web SOAP (Simple Object Access Protocol), Les Services Web REST (Representational State Transfer).
Technique
Par ailleurs, ladministration a dfini PRESTO, un protocole dchanges de messages informatiques entre applications bas sur les Services Web SOAP. Pour les changes frquents de petites volumtries en mode requte-rponse, les services Web REST et SOAP sont les plus utiliss. Pour les changes ncessitant accus de rception, fiabilit, intgrit et confidentialit, le protocole PRESTO est appropri. Pour les changes de fichiers ne ncessitant ni daccus de rception, ni de mise en place de mcanismes de reprise, il est possible dutiliser S-FTP (voir le chapitre consacr aux Services de transfert de fichiers).
Services
Page 86/119
4.3.1. Protocole dchange des messages de ladministration
Les changes entre les SI des administrations sont de plus en plus nombreux et concernent toutes les autorits administratives (administrations centrales, organismes de protection sociale, collectivits territoriales, etc.). Les solutions permettant ces changes lectroniques sont nombreuses : dveloppement interne, utilisation de progiciels, choix dun tiers de tltransmission, etc. Dans le cadre dune dmarche dinformatisation et durbanisation des changes lectroniques, PRESTO (PRotocole dEchanges STandard Ouvert de lAdministration), un protocole dchange de donnes, a t dvelopp afin de rpondre la majorit des besoins et avec le but de vhiculer les messages informatiques entre les applications des SI des autorits administratives. Ce profil repose sur des spcifications de profils du WS-I (Basic Profile et Security Profile) et sur des spcifications du W3C et de lOASIS.
Technique
Recommand
PRESTO
DGME
Il est RECOMMAND d'utiliser le protocole PRESTO v1.1 pour les changes de messages entre administrations.
Services
Page 87/119
4.3.2. Les Services Web SOAP

4.3.2.1. Protocole de services SOAP (Simple Object Access Protocol) est un protocole qui fait lobjet dune recommandation du W3C. Il permet de dfinir des mcanismes dchanges dinformation structure et a pour objectif dassurer un dialogue entre composants distribus et dcentraliss en utilisant la notation XML. Si le transport des donnes est ralis le plus souvent l'aide du protocole HTTP, SOAP reste indpendant du protocole de transport (ex : SMTP peut tre utilis). SOAP dfinit un format pour lenvoi des messages XML. Les messages SOAP sont structurs en un document XML qui comporte les lments suivants : Une enveloppe obligatoire qui dfinit le contenu du message et contient : o Un en-tte optionnel qui inclut diffrentes informations (autorisations et transactions par exemple), o Un corps contenant les informations sur l'appel et la rponse. Des attachements optionnels. Recommand SOAP W3C
Technique
Il est RECOMMAND dutiliser le protocole SOAP v1.1 ou SOAP v1.2 lors de la conception de Services Web SOAP.
Services
Page 88/119
4.3.2.2. Langage de description de services WSDL (Web Services Description Language) est un langage de description, qui fournit un modle et un format XML pour dcrire le contrat dinterface dun Service Web. Il permet de sparer la description fonctionnelle abstraite dun service, des dtails concrets de son implmentation (tels que comment et o cette fonctionnalit est offerte). Au niveau abstrait, WSDL dcrit un Service Web en fonction des messages quil envoie et reoit ; les messages sont dcrits indpendamment d'un format de transmission particulier en utilisant un systme de typage. Au niveau concret, une liaison (binding) dfinit les dtails des formats de transport et de transmission d'une ou plusieurs interfaces. Une extrmit (port ou endpoint) associe une adresse de rseau une liaison. Enfin, un service regroupe les extrmits qui mettent en uvre une interface commune. Recommand WSDL v1.1 W3C
Il est RECOMMAND dutiliser le langage WSDL v1.1 pour dcrire les contrats dinterface des Services Web SOAP.
Technique Services
Page 89/119
4.3.2.3. Annuaire de services UDDI (Universal Description Discovery and Integration) est une technologie d'annuaire base sur le langage XML. Cest une initiative ouverte de lindustrie, sponsorise par lOASIS, qui permet aux fournisseurs de publier la liste de leurs Services Web. Un annuaire UDDI permet de localiser sur le rseau le Service Web recherch. Il repose sur le protocole de transport SOAP. Recommand UDDI v2 / v3 OASIS
Il est RECOMMAND dutiliser un annuaire UDDI v2 ou v3 pour la publication de Services Web SOAP.
Technique Services
Page 90/119
4.3.2.4. Profils dutilisation Le consortium WS-I (The Web Service Interoperability Organization) produit des recommandations pour les dveloppeurs de Services Web afin de favoriser l'interoprabilit. Le WS-I Basic Profile contient un ensemble de rgles permettant de favoriser linteroprabilit des Services Web SOAP. Le Basic Profile v1.1 couvre les normes et spcifications suivantes : SOAP 1.1, RFC2616: Hypertext Transfer Protocol -- HTTP/1.1, RFC2965: HTTP State Management Mechanism, XML 1.0 (Second Edition), Namespaces in XML 1.0, XML Schema Part 1: Structures, XML Schema Part 2: Datatypes, WSDL 1.1, UDDI Version 2.04 API Specification, Dated 19 July 2002, UDDI Version 2.03 Data Structure Reference, Dated 19 July 2002, UDDI Version 2 XML Schema, RFC2818: HTTP Over TLS, RFC2246: The TLS Protocol Version 1.0, The SSL Protocol Version 3.0, RFC2459: Internet X.509 Public Key Infrastructure Certificate and CRL Profile. Recommand Basic Profile v1.1 WS-I
Technique
Il est RECOMMAND de se conformer au profil dutilisation WS-I Basic Profile v1.1 .
Un fichier WSDL dcrit le contrat dinterface dun Service Web. Il peut tre encod de diffrentes faons : le style peut tre soit RPC soit document, lencodage peut tre soit literal soit encoded. Pour harmoniser les pratiques et garantir linteroprabilit, il est ncessaire de prfrer lencodage literal, conforme au profil WS-I. Rgle 05 Style dchange et encodage WS-I
Services
Pour les Services Web SOAP, il est OBLIGATOIRE dutiliser le style dchange document ou RPC et lencodage literal .
Page 91/119
4.3.2.5. Pices jointes Pour associer un message SOAP un objet binaire sous forme de pice jointe, il est possible de suivre les recommandations du WS-I ou du W3C. Le profil Attachments v1.0 du WS-I est compos d'un ensemble de spcifications ; elles compltent le Basic Profile v1.1 en normalisant le support des pices jointes. Le packaging XOP (XML binary Optimized Packaging) et le mcanisme MTOM (Message Transmission Optimization Mechanism) du W3C apportent une mthode standard pour associer des donnes binaires un document XML au sein dun paquet ; optimisent lencodage et la transmission de messages SOAP.
Recommand
Pices jointes
WS-I / W3C
Pour des Services Web avec pice jointe, il est RECOMMAND de se conformer au profil dutilisation Attachments du WS-I ou aux normes XOP/MTOM du W3C.
Technique Services
Page 92/119
4.3.2.6. Scurisation Le Basic Security Profile v1.0 est une extension du Basic Profile v1.0. Il est donc compatible avec celui-ci en lui ajoutant des spcifications de scurit. Le Basic Security Profile v1.0 est conu pour supporter lajout de fonctionnalits de scurit aux enveloppes et messages SOAP, ainsi quau niveau de la couche de transport des Services Web. Recommand Basic Security Profile v1.0 WS-I
Il est RECOMMAND de se conformer au profil Basic Security Profile v1.0 pour scuriser les services web SOAP.
Le WSS (Web Service Security) est un standard de lOASIS qui ajoute aux spcifications existantes une structure pour incorporer des mcanismes d'authentification, de signature et de chiffrement dans un message SOAP, utilisables lors de limplmentation de Services Web.
Technique
Cette spcification est flexible et conue pour scuriser les Services Web avec une grande varit de modles de scurit, entre autres, lutilisation de SAML, Kerberos et de certificats X.509. Recommand WS-Security v1.1 OASIS
Il est RECOMMAND de se conformer au WS-Security v1.1 pour scuriser les messages SOAP.
Services
Page 93/119
4.3.3. Les Services Web REST

REST (Representational State Transfer) a t dcrit par Roy Thomas Fielding dans sa thse Architectural Styles and the Design of Network-based Software Architectures . Cest un style d'architecture et non un standard, il n'existe donc pas de spcifications de REST. Dans une architecture REST, le composant de base est appel ressource. Toute information qui peut tre nomme est une ressource : un article de journal, une photo, un service ou nimporte quel concept. Une ressource est identifie par un URI (Uniform Resource Identifier) qui permet de la nommer. Pour invoquer des ressources, il faut utiliser les verbes HTTP : GET pour rcuprer le contenu dune ressource (recherche, lecture), POST pour crer une nouvelle ressource (mise jour), PUT pour crer une ressource, DELETE pour supprimer une ressource. Il faut noter que certains navigateurs nimplmentent pas les mthodes PUT et DELETE.
Technique
REST fait usage des standards prouvs de larchitecture du Web : Utilisation du protocole HTTP, fournissant une interface uniforme pour accder toutes les ressources avec une interface gnrique (essentiellement les verbes GET, POST, PUT et DELETE), Utilisation des URI : chaque ressource du systme est reprsente (adressage et nommage) par une URI dont la connaissance doit suffire accder la ressource, Utilisation de divers formats de la reprsentation des ressources : XML, (X)HTML, GIF, JPEG, Microformat, etc. Utilisation des types MIME pour la description de ces reprsentations : text/html, image/gif, image/jpeg, etc. Atom est un format de document bas sur XML conu pour la syndication de contenu priodique, tel que les sites d'actualits. Atom Publishing Protocol est un protocole informatique de cration, modification et destruction de ressources Web. Recommand Atom Publishing Protocol IETF
Il est RECOMMAND dutiliser le protocole Atom Publishing Protocol dans le cadre des Services Web REST.
Services
JSON (JavaScript Object Notation) est un format de donnes textuel, gnrique, driv de la notation des objets du langage ECMAScript. Il permet de reprsenter de l'information structure. Recommand JSON IETF
Il est RECOMMAND dutiliser le format de reprsentation JSON dans le cadre des Services Web REST.
Page 94/119
4.4. Infrastructure
4.4.1. Services dannuaires et fdration didentit
4.4.1.1. Annuaires LDAP La question de linteroprabilit des donnes entre annuaires consomme beaucoup de temps dans la gestion des SI. De nombreux annuaires coexistent au sein des entreprises et des entits administratives, comme lannuaire tlphonique, lannuaire d'intranet, lannuaire de contrleur de domaine rseau, lannuaire dans les SI de gestion, etc. Linteroprabilit des donnes entre ces annuaires est problmatique. Originellement protocole dinterrogation et de modification de service dannuaire, LDAP a volu en tant que norme et dfinit dornavant les fonctionnalits suivantes : un protocole rseau pour accder l'information contenue dans l'annuaire, un modle d'information dfinissant la forme et le type de l'information contenue dans l'annuaire, un espace de nommage dfinissant comment l'information est organise et rfrence, un modle fonctionnel dfinissant la manire daccder et de mettre jour l'information, un modle de distribution permettant de rpartir les donnes ( partir de la version 3), un protocole et un modle de donnes extensibles, des interfaces pour dvelopper des applications clientes.
Technique
Rgle 06
LDAP v3
IETF
Il est OBLIGATOIRE de prvoir un mode d'accs conforme LDAP v3 pour les annuaires interrogeables par plusieurs entits administratives.
Infrastructure
Page 95/119
4.4.1.2. Echanges entre annuaires LDIF (LDAP Data Interchange Format) permet de reprsenter les donnes LDAP sous un format texte harmonis. Il est utilis pour afficher ou modifier les donnes de la base. Il a vocation donner une lisibilit des donnes tout utilisateur. LDIF est galement utilis pour importer ou exporter des bases dinformations entre annuaires LDAP. La majorit des serveurs LDAP supportent ce format ce qui permet une grande interoprabilit entre eux. Recommand LDIF IETF
Il est RECOMMAND dutiliser le format LDIF pour changer tout ou partie dun annuaire de donnes LDAP.
Le langage DSML (Directory Services Markup Language) structure les donnes changes entre annuaires. Ce langage constitue la principale ouverture des annuaires LDAP vers le monde XML. DSML peut tre considr comme l'anctre d'UDDI.
Technique
En observation
DSML
OASIS
Le langage DSML (Directory Services Markup Language) est un langage bas sur XML. Il normalise les changes de donnes entre des annuaires LDAP.
Infrastructure
Page 96/119
4.4.1.3. Scurisation des annuaires LDAP Le protocole LDAP fournit des mcanismes de scurit mis en uvre pour garantir certains services de scurit dfinis par lISO (ISO 7498-2) . Le protocole TLS peut tre utilis avec LDAP afin de garantir lintgrit et la confidentialit des changes dans une communication entre applications LDAP et dauthentifier la connexion un serveur LDAP. Les lments de scurit pouvant tre mis en uvre par LDAPv3 sont les suivants : Lauthentification des entits LDAP (serveurs, clients, donnes), La signature lectronique des oprations effectues sur lannuaire, Le chiffrement de certaines donnes critiques de lannuaire, Les rgles daccs (ACLs) aux donnes, Laudit du journal des oprations. Enfin, LDAPv3 offre la possibilit daccder un ensemble de fonctions de scurit qui doivent tre interoprables. Cest pourquoi un nombre minimum de ces fonctions doit tre commun toute implmentation supportant LDAPv3.
Technique
Recommand
Extensions LDAP
IETF
Pour scuriser les services dun annuaire de donnes LDAP, il est RECOMMAND dutiliser les extensions de scurisation LDAP.
Pour plus de dtails sur TLS, se reporter au chapitre 4.4.2.8 Service de scurisation des changes
Infrastructure
Page 97/119
4.4.1.4. Service de nom de domaine
Le service de nom de domaine DNS (Domain Name System) a pour vocation deffectuer le lien entre une adresse Internet au format alphanumrique et son adresse rseau effective, communment appele adresse IP. Ce service peut tre vu comme une base de donnes distribue dans lInternet. Le format des adresses dfini dans le protocole IPv4 limite lespace dadressage environ 4 milliards dadresses IP. Lespace dadressage sur Internet pourrait tre rapidement satur. La recommandation RFC 3596 prend en compte le besoin daugmenter cette capacit dadressage ; il dfinit des extensions au DNS permettant dintgrer le format et la dynamique de gestion des adresses IPv6. Cette RFC au statut Draft Standard est aujourdhui implmente dans toutes les solutions permettant de mettre en uvre la rsolution de noms. Rgle 07 DNS IETF
Technique
Pour accder au service de rsolution de noms de domaine, il est OBLIGATOIRE d'utiliser le service DNS.
Infrastructure
Page 98/119
4.4.1.5. Scurisation du service de nom de domaine Le DNS est un service de base important permettant laccs au rseau Internet. En effet, une requte vers un serveur fait appel quasi systmatiquement une rsolution DNS, afin de transformer le nom du serveur en adresse IP, qui est la vritable information que comprennent les routeurs IP, afin de router les datagrammes IP entre eux. Or le service DNS est lun des moins scuriss et ses diverses implmentations ont prsent par le pass de nombreuses vulnrabilits. Les service DNS, font galement parfois lobjet de mauvaises installations et deviennent des vecteurs dintrusion des SI. Les attaques du DNS de type dni de service, usurpation ou inondation recenses par le SANS Institute ou les diffrents CERT sont nombreuses. De telles attaques, menes grande chelle ou bien concentres sur les serveurs racines de larchitecture hirarchique du DNS peuvent, en quelques heures, paralyser lutilisation du rseau. Ce nest que trs rcemment (au regard de lapparition du DNS) que des extensions scurit pour le DNS sont apparues. Ceci afin de scuriser les changes entre serveurs DNS, en permettant lauthentification des parties communicantes ainsi que lintgrit des donnes changes, grce lutilisation de la signature numrique.
Technique
Ladoption de DNSsec (DNS security extensions) en tant que recommandation parat aujourdhui invitable, son adoption sur le terrain prendra du temps. En attendant, de nombreux projets ont vu le jour afin dexprimenter, damliorer puis de valider les fonctionnalits de DNSsec et prparer ainsi son futur dploiement grande chelle. En termes dvolution des recommandations, les travaux portent essentiellement sur loptimisation du support de DNSsec, que ce soit au niveau des performances (RFC 3226) ou au niveau de la facilit de mise en uvre. Recommand DNSsec IETF
Il est RECOMMANDE d'utiliser DNSsec pour la scurisation dun service de rsolution de noms de domaine.
Infrastructure
Page 99/119
4.4.1.6. Fdration didentit La fdration didentit permet aux usagers daccder diffrents services en ligne sur la base dune authentification unique. Chaque autorit administrative conserve sa propre gestion de lidentification des usagers. Une fdration didentit repose sur les lments suivants : un fournisseur de services : il offre des services lusager et utilise le fournisseur didentit pour lauthentification ; un fournisseur didentit : il gre les informations relatives lidentification et lauthentification dun usager; le cercle de confiance : ensemble dentits amenes partager de linformation ; il est form dun portail sappuyant sur un ou plusieurs fournisseurs didentit ; une fdration didentit : elle est une relation entre lidentit, le compte gr par le fournisseur didentit et le compte gr par le fournisseur de services ; cest lusager qui la construit en choisissant de fdrer/dfdrer son compte avec les fournisseurs de services ; la relation entre les fournisseurs de services est matrialise par un couple de cls de fdration connu uniquement par le fournisseur didentit ; une cl de fdration : les diffrents fournisseurs de service ne peuvent communiquer directement entre eux propos de lidentit d'un utilisateur ; ils ne peuvent changer des informations le concernant qu'avec le fournisseur d'identit ; afin de garantir l'intgrit et la non-rvocabilit de l'change, un tiers de confiance, le fournisseur didentits, met un jeton de scurit qui identifie la session mais pas l'utilisateur, ceci afin dviter la diffusion de ses donnes personnelles ; un utilisateur : il cre une fdration entre ses diffrents comptes ; il na besoin de sauthentifier quune seule fois pour accder aux diffrents comptes fdrs. Le consortium Liberty Alliance, soutenu par plus de 150 entreprises ou organismes internationaux, a spcifi le systme d'authentification distribu ID-FF (IDentity Federation Framework). ID-FF permet un utilisateur de disposer dun compte diffrent sur plusieurs applications et de crer une fdration entre ces comptes. La spcification ID-FF 1.2 a t intgre dans la recommandation dassertion de scurit SAML 2.0. SAML (Security Assertion Markup Language) est un protocole de dclaration de donnes dauthentification et dautorisation qui permet dchanger des informations de scurit. Recommand SAML v2.0 OASIS - UIT
Technique
Pour fdrer des services sur un cercle de confiance entre les administrations, il est RECOMMAND d'utiliser le modle de fdration support par la recommandation dassertion de scurit SAML 2.0.
En observation
ID-WSF 2.0
Liberty Alliance
Des principes complmentaires ceux spcifis dans SAML 2.0 dcrivent le transport des attributs lis lidentit. Ils sont spcifis dans ID-WSF (Identity Web Service Framework).
Infrastructure
Les spcifications SAML et ID-WSF sont les plus rpandues et les plus matures parmi les spcifications ouvertes sur la fdration didentit. Il existe dautres spcifications traitant de la fdration des identits comme open ID gr par lOpen ID Foundation ou WS-Federation base sur la pile protocolaire WS-*.
Page 100/119
4.4.2. Technologies
4.4.2.1. Protocole rseau Le protocole IPv4 se prsente comme la rfrence des protocoles de niveau rseau pour linterconnexion entre le rseau local Ethernet et les rseaux longue distance. La version 4 du protocole IP est dploye universellement travers le monde. Avec TCP, protocole de transport associ, IPv4 est le protocole de base du rseau Internet. Rgle 08 IPv4 IETF
Pour lensemble des changes au niveau de la couche rseau, il est OBLIGATOIRE dutiliser le protocole IPv4.
Ce protocole prsente toutefois de nombreuses limites notamment : la capacit dadressage, tant la croissance du rseau est importante (lespace dadressage devrait atteindre la saturation de 4 milliards dadresses vers 2010), linsuffisance des mcanismes de configuration dadresse en termes de simplicit et dautomatisation, frein notable aux dveloppements futurs du rseau Internet mobile, linsuffisance des proprits de qualit de service, notamment sur la priorit des flux temps rel, labsence de fonctions intrinsques de scurit, labsence de corrlation gographique dans le format d'adressage. La version 6 du protocole IP apporte de nouvelles fonctionnalits pour rsoudre certaines de ces limites. Il porte notamment la capacit du rseau internet plus de 600 milliards dadresses. Lvolution du march dcidera du moment opportun pour la migration IPv4 vers IPv6 (croissance du rseau, dveloppement du rseau Internet mobile de masse, du multimdia, etc.). Recommand IPv6 IETF
Technique
Sur les quipements de cur de rseau comme les serveurs, routeurs et commutateurs, il est RECOMMAND de mettre en uvre un systme d'exploitation capable de grer le protocole IPv6.
La recommandation RFC 2675 propose la possibilit dmettre des paquets de taille suprieure 65 kilo-octets. Cette limite tait jusqu maintenant tablie par la conception des protocoles TCP/IP. Le dpassement de cette limite permet dmettre de plus gros paquets sur les rseaux de type haut dbit et d'accrotre les performances aux nuds dinterconnexion sur les transferts de donnes volumineux. En effet, IPv6 permettant dintroduire des options de longueur variable au sein de len-tte de ses paquets, la limite des 65 kilo-octets de donnes nest plus infranchissable. La recommandation RFC 2675 dfinit les conditions de mise en uvre dune option de dpassement de taille de paquets, ainsi que les amliorations apporter aux protocoles TCP et UDP pour permettre cette volution.
Infrastructure
Page 101/119
4.4.2.2. Protocoles de transport Les protocoles TCP (Transmission Control Protocol) et UDP (User Datagram Protocol) forment, avec le protocole IP sous-jacent, le socle de base des protocoles de lInternet. De mme que pour IP, ces protocoles nont pas beaucoup volu depuis leurs spcifications initiales. De nombreuses options damlioration ont pourtant t dfinies mais elles ne sont actuellement pas suivies de manire homogne par le march, de sorte que seules les fonctionnalits de base sont vraiment applicables. Une recommandation, de rfrence RFC 1323, est toutefois relativement suivie. Elle propose des extensions damlioration de performance sur rseau haut dbit. Ces extensions sont compatibles avec les applications distantes ne les supportant pas. La recommandation amliore la gestion de la fentre de transmission et la mesure du temps de transit. Le protocole UDP est utilis pour les transmissions de donnes en temps rel (flux multimdia, type Vidoconfrence, Voix sur IP, etc.). En effet, lors dchanges en temps rel, les retransmissions de paquets perdus sont inutiles car les paquets retransmis arrivent trop tard. UDP tant plus simple, il permet donc daller plus vite.
Technique
Le protocole TCP reste le meilleur composant permettant de fiabiliser les flux de type HTTP, SMTP et FTP. Les fonctionnalits de retransmissions de TCP fiabilisent les changes mais rendent ce protocole moins rapide que UDP. Rgle 09 TCP / UDP IETF
Pour transporter les flux de donnes provenant des couches applicatives, il est OBLIGATOIRE dutiliser les protocoles TCP ou UDP.
Issu de travaux raliss les acteurs tlcoms, SCTP (Stream Control Transport Protocol) a pour objectif de rpondre aux limitations de TCP en ajoutant les fonctionnalits suivantes : ordonnancement des paquets non-obligatoires en fonction des besoins, orientation message et non octet, rattachement multiple et amlioration de la scurit. En observation SCTP IETF
Le protocole SCTP est ce jour arriv maturit mais son adoption reste limite. Une priode dobservation est ncessaire.
Infrastructure
Page 102/119
4.4.2.3. Protocole client-serveur Le protocole HTTP (HyperText Transfer Protocol), littralement protocole de transfert hypertexte , est un protocole de communication informatique client-serveur dvelopp pour le World Wide Web. Il est utilis pour transfrer les documents (document HTML, image, feuille de style, etc.) entre le serveur HTTP et le navigateur Web lorsqu'un visiteur consulte un site Web. Rgle 10 HTTP IETF
Pour la prsentation et les changes entre un serveur Web et un navigateur, il est OBLIGATOIRE d'utiliser le protocole HTTP 1.1.
HTTPS est la combinaison du protocole HTTP et du service de scurisation des changes TLS.
Pour plus de dtails sur TLS, se reporter au chapitre 4.4.2.8 Service de scurisation des changes
Technique Infrastructure
Page 103/119
4.4.2.4. Accs aux ressources via HTTP HTTP en version 1.1 dfinit officiellement 47 directives. La directive Allow dfinit les mthodes utilises (GET, PUT, POST, ...) pour accder aux ressources demandes. Avec la mthode GET, le corps de message dune requte http est vide. Lorsque des informations sont envoyes au serveur l'aide de la mthode GET, elles sont encodes la suite de la ressource aprs le symbole ? dans l'URL. La mthode POST est plus discrte. Elle permet d'envoyer des informations au serveur dans le corps du message d'une requte HTTP.
Recommand
HTTP POST
W3C
Lors du passage de paramtres caractre confidentiel ou personnel, il est RECOMMAND d'utiliser la mthode HTTP POST, au lieu de la mthode HTTP GET.
Technique
La mthode GET devant garantir lidempotence (les appels URL ne doivent pas provoquer de changement dtat du systme), il est prfrable dutiliser la mthode POST pour les requtes modifiant ltat du systme, comme par exemple, un changement de mot de passe ou une cration de compte. Recommand HTTP POST W3C
Pour faire une requte provoquant un changement d'tat persistant dans une application Web, il est RECOMMAND d'utiliser la mthode HTTP POST.
Infrastructure
Page 104/119
4.4.2.5. Meilleures pratiques HTTP Encodage de caractres Lors d'une transaction entre un serveur web et un navigateur, le serveur web renseigne lattribut Content-Type . Il prcise ainsi au navigateur le type du fichier envoy, afin que celui-ci affiche le document dans le format attendu. Rgle 11 HTTP Content Type IETF
Il est OBLIGATOIRE de renseigner l'attribut "Content-Type" du protocole http.
Compression La compression HTTP est paramtrable au niveau des serveurs web et permet des gains en bande passante. Recommand HTTP IETF
Technique
Il est RECOMMAND dactiver la compression HTTP au niveau des serveurs web.
Gestion du cache mmoire Il est possible d'imposer aux applications de grer le cache des pages qu'elles diffusent, en utilisant le paramtre Cache-Control du protocole HTTP/1.1 (se reporter la section 13 et 14 de la recommandation RFC 2616) ainsi que le paramtre Last-Modified. Un serveur diffusant des articles de communication prcisera : "Cache-Control: public", "Last-Modified: Dernire date de modification", "Expires: Date de prochaine validation par le cache"(si possible). Un serveur manipulant des donnes caractre personnel et/ou confidentiel prcisera : "Cache-Control: private". Ainsi, un serveur peut diter des pages sensibles mais dont les logos et images ne le sont pas. Ces composants seront mis en cache mmoire, ce qui permettra de raliser une conomie de bande passante. Inversement, un serveur diffusant des images caractre confidentiel les fera prcder de "Cache-Control: private". Les bonnes pratiques consistent donc renseigner len-tte avec : "Cache-Control" du protocole HTTP/1.1 pour les pages dynamiques diffuses par HTTP, "Last-Modified" du protocole HTTP/1.1 pour les pages dynamiques diffuses par HTTP et dont le cache est autoris par l'en-tte "Cache-Control: public", "Expires" du protocole HTTP/1.1 pour les pages dynamiques diffuses par HTTP et dont le cache est autoris par l'en-tte "Cache-Control: public".
Infrastructure
Page 105/119
4.4.2.6. Services de transfert de fichiers Communment, le transfert de fichiers entre deux ordinateurs connects un rseau IP seffectue via le protocole FTP (File Transfer Protocol). Dutilisation simple, ce protocole a prouv son efficacit en matire de transfert de gros volumes de donnes. Ce protocole FTP sest toff grce aux nouvelles extensions : de scurit (RFC 2228 et 2773), dinternationalisation et de prise en compte du codage UTF-8 (RFC 2640). Des extensions FTP sont prvues pour interoprer avec le protocole IPv6. Le protocole SFTP (SSH File Transfer Protocol) est un protocole scuris pour transfrer des fichiers distance de manire scurise.
Recommand
FTP
IETF
Pour transfrer des fichiers, il est RECOMMAND, hors contexte Web, dutiliser le protocole SFTP ou dfaut le protocole FTP.
Technique
En contexte web, HTTP sera prfr FTP pour le transfert de fichiers.
Infrastructure
Page 106/119
4.4.2.7. Scurisation du protocole rseau IPsec (Internet Protocol security) est un protocole qui assure lauthentification, le chiffrement des donnes et lintgrit. Conu lorigine pour IPv6, IPsec a t adapt pour fonctionner avec IPv4. Contrairement TLS qui est spcifi au niveau de la couche prsentation, IPsec est dfinie au niveau IP (couche rseau). Il permet par exemple de raliser des VPN (Virtual Private Network ou rseau priv virtuel). Un rseau priv virtuel construit avec la technologie IPsec consiste tablir deux canaux de communication (des tunnels) entre les machines : un canal d'change de cls, sur une connexion UDP depuis et vers le port 500 : ISAKMP (Internet Security Association and Key Management Protocol), un ou plusieurs canaux de donnes par lesquels le trafic du rseau priv est vhicul selon les deux protocoles possibles suivants : o ESP (Encapsulating Security Payload), qui fournit l'intgrit et la confidentialit, o AH (Authentication Header) qui ne fournit que l'intgrit. La mise en uvre du protocole IPsec se fait gnralement au niveau des routeurs. Ces quipements permettent en effet d'optimiser les paramtres lis la couche rseau. Recommand IPsec IETF
Technique
Il est RECOMMAND dutiliser le protocole IPsec au niveau de la couche rseau, pour chiffrer, authentifier et valider l'intgrit des changes.
Infrastructure
Page 107/119
4.4.2.8. Service de scurisation des changes TLS (Transport Layer Security) est un protocole de scurisation des changes sur Internet. Dvelopp l'origine par la socit Netscape, anciennement nomm SSL (Secure Socket Layer), il a t renomm TLS suite au rachat du brevet par l'IETF en 2001. TLS fonctionne suivant un mode client-serveur. Il rpond aux quatre mesures de scurit suivantes : authentification du serveur, confidentialit des donnes changes (ou session chiffre), intgrit des donnes changes, authentification du client, de manire optionnelle. Dans la pile protocolaire, TLS se situe entre les couches applications (comme HTTP, FTP, SMTP) et la couche transport TCP. Son utilisation la plus commune reste cependant au dessous de HTTP. La couche TLS est implmente par la couche application de la pile, ce qui a deux consquences : pour toute application existante, il peut exister une application utilisant TLS. Par exemple, l'application HTTPS correspond HTTP au dessus de TLS ; une application TLS se voit attribuer un nouveau numro de port par l'IANA (Internet Assigned Numbers Authority). Par exemple HTTPS est associ au port 443.
Technique
Rgle 12
TLS
IETF
Pour scuriser les changes s'appuyant sur des protocoles applicatifs (FTP, HTTP, IMAP, LDAP, POP3, SIP, SMTP, etc.), il est OBLIGATOIRE d'utiliser le protocole TLS ou SSL V3.0.
Infrastructure
Page 108/119
4.4.2.9. Diffusion vido en mode continu La diffusion video en mode continu (Streaming Video) est une technique qui permet de faire circuler sur un rseau protocole IP (un intranet, un extranet ou le rseau Internet), des flux de donnes contenant des squences audio ou vido. Cette technique est diffrente de la diffusion en mode tlchargement, qui ncessite de rcuprer l'ensemble des donnes d'une squence audio ou vido, avant de pouvoir l'exploiter. Les transmissions et la communication entre serveur et client peuvent utiliser les protocoles RTP ou RTSP (protocoles normaliss par l'IETF). Se reporter au chapitre consacr la tlphonie pour obtenir des prcisions sur ces protocoles. Recommand RTP / RTSP IETF
Il est RECOMMANDE d'utiliser RTP ou RTSP pour la diffusion de vido en mode continu.
Technique
Des problmes dinteroprabilit peuvent apparatre selon les codecs vido choisis pour les mdias faisant lobjet de la diffusion en mode continu. Se rfrer aux thmes 3.1.5 Formats de squence vido
Infrastructure
Page 109/119
4.4.2.10. Horodatage et synchronisation 4.4.2.10.1. Synchronisation des horloges Le protocole NTP (Network Time Protocole) permet de synchroniser l'horloge d'un ordinateur avec celle d'un serveur de rfrence. NTP est un protocole bas sur une couche de transport UDP. Le protocole SNTP (Simple Network Time Protocol) est une adaptation simplifi de NTP. Rgle 13 NTP IETF
Pour raliser une synchronisation des horloges des diffrents ordinateurs et quipements rseaux constituant un SI, il est OBLIGATOIRE dutiliser le protocole NTP.
4.4.2.10.2. Horodatage technique TDF (Tl Diffusion de France) et DCF77 sont des systmes de transmission de l'heure lgale par ondes radio, sur une large zone de couverture.
Technique
Recommand
Signaux horaires (France Mtropolitaine)
Il est RECOMMAND dutiliser les signaux horaires TDF (162 kHz) ou DCF77 (77,5 kHz) pour d'obtenir une fonction dhorodatage technique prcise. Pour les zones gographiques situes en Outre-mer (les DOM et les TOM), la mise en uvre de systme utilisant la rception de signaux horaires provenant de satellites GPS, ou des futurs satellites Galilo, est recommande. 4.4.2.10.3. Temps UTC ou TAI Il est intressant de prciser si les serveurs de temps mis disposition doivent transmettre une heure UTC (Temps Universel Coordonn) ou TAI (Temps Atomique International). UTC est une chelle de temps adopte comme base du temps civil international par un grand nombre de pays. C'est un compromis entre le TAI, stable mais dconnect de la rotation de la Terre et le temps universel TU, directement li la rotation de la Terre mais instable. L'utilisation du format de frquence UTC est propose par l'UIT-R (Union Internationale des Tlcommunications- secteur des radio-communications) comme rfrence dans les missions de frquences talon et de signaux horaires. Recommand UTC UIT-R
Il est RECOMMAND que les serveurs de temps mis disposition des SI, transmettent une heure au format UTC.
Infrastructure
Page 110/119
5.. Gllossaiire 5 G ossa re

Des termes en langue anglaise sont parfois maintenus ou mis en complment entre parenthses dans le prsent document. Ceci permet de ne pas introduire de doute ou d'ambigut sur le sens du terme employ. Terme
AFNOR Agent ANSI
Description
Association Franaise de Normalisation Personne physique agissant pour le compte dune autorit administrative. American National Standards Institute Sont considres comme autorits administratives les administrations de lEtat, les collectivits territoriales, les tablissements publics caractre administratif, les organismes grant des rgimes de protection sociale relevant du code de la scurit sociale et du code rural ou mentionns aux articles L.223-16 et L.351-21 du code du travail et les autres organismes chargs de la gestion dun public administratif. Bote Aux Lettres Business Process Management Initiative Business Process Modelling Notation Business Requirements Specification Spcification des exigences mtier Common Assessment Method for Standards and Specifications UN/CEFACT Core Component Library Bibliothque de composants communs du CEFACT/ONU Core Component Technical Specification Spcification technique des composants communs Commission Electrotechnique Internationale Comit Europen de Normalisation CEN/Information Society Standardization System Comit europen de normalisation lectrotechnique Computer Graphics Metafiles Commission Nationale de l'Informatique et des Liberts Chinese National Institution of Standardization Ide, objet conu par lesprit ou acquis par lui et permettant dorganiser les perceptions et les connaissances
Autorit Administrative
BAL BPMI BPMN BRS CAMSS CCL CCTS CEI CEN CEN/ISSS CENELEC CGM CNIL CNIS Concept
Page 111/119
Terme
CSS CSV DGME Domaine dinteroprabilit DNG DNS DNSsec DWG ECMA EDI EIF EPS ESMTP ETSI FTP HL7 HTML HTTP IANA ICANN IDABC IEC CEI IEEE IETF iLBC IMAP INCITS INSEE Interoprabilit Cascading Style Sheet Comma Separated Value
Description
Direction Gnrale de la Modernisation de lEtat (Ministre du Budget) Les niveaux dinteroprabilit du RGI sont subdiviss de domaines. Par exemple, les domaines Multimdia ou Prsentation sont des domaines du niveau technique. Ils peuvent tre diviss en sous-domaines Digital Negative Domain Name System Domain Name System Security Extension DraWinG Ecma International European association for standardizing information and communication systems Electronic Data Interchange European Interoperability Framework European Public Services Extended Simple Mail Transfer Protocol European Telecommunications Standards Institute Institut europen des normes de tlcommunication File Transfer Protocol Health Level 7 HyperText Markup Language HyperText Transfert Protocol Internet Assigned Numbers Authority Internet Corporation for Assigned Names and Numbers Interoperable Delivery of European eGovernment Services to public Administrations, Businesses and Citizens International Electrotechnical Commission Commission Electrotechnique Internationale Institute of Electrical and Electronics Engineers Internet Engineering Task Force Internet Low Bit rate Codec Internet Message Access Protocol InterNational Committee for Information Technology Standards Institut National de la Statistique et des tudes conomiques La capacit dun systme fonctionner avec d'autres systmes
Page 112/119
Terme
IP IPsec ISO JPEG JO JSON JSR 168 LDAP LDIF MDC Mtadonne Mthode MIME Modle MPEG NASA NIFO NIST Niveau dinteroprabilit Nomenclature Internet Protocol Internet Protocol Security
Description
International Organization for Standardization Organisation internationale de normalisation Joint Photographic Experts Group Journal Officiel JavaScript Object Notation Java Specification Requests : Portlet Specification Lightweight Directory Access Protocol LDAP Data Interchange Format Modle de Donnes Communes Donne servant dfinir ou dcrire une autre donne Dmarche organise rationnellement pour aboutir un rsultat Multipurpose Internet Mail Extensions Plan, reprsentation ou description conu pour dcrire un objet, un systme ou dune manire gnrale une vision de la ralit Moving Picture Experts Group National Aeronautics and Space Administration National Interoperability Framework Observatory National Institute of Standards and Technology Les changes entre parties prenantes reposent sur 6 niveaux dinteroprabilit : les niveaux politique, juridique, organisationnel, smantique, syntaxique, technique. Le RGI traite des trois derniers niveaux Catalogue, rpertoire ou liste dtaills dans lesquels sont dfinis et classs des lments ayant trait un sujet donn et auxquels on peut se rfrer Document de rfrence fixant les conditions dans lesquelles une opration est ralise, un objet excut, un produit labor, avec deux caractristiques fondamentales: tre la fois le fruit du consensus de l'ensemble des acteurs et le rsultat du transfert du savoir-faire de ces acteurs, maner des organismes officiels de normalisation. Network Time Protocol Organization for the Advancement of Structured Information Standards Object Constraint Language Open Office Document Object Management Group
Norme
NTP OASIS OCL ODF OMG
Page 113/119
Terme
OXML Partie prenante PCM PDF PNG POP Praxeme PRESTO Processus RDF REST RGAA RGI RGS RPC RSM RSS RTCP RTP RTSP S/MIME SAML SCTP Smantique Service en ligne SFTP SI SIP SMS SMTP Office Open XML
Description
Tout acteur, personne physique ou entit technique, participant un change par voie lectronique Pulse Code Modulation Portable Document Format Portable Network Graphics Post Office Protocol Mthode de modlisation dentreprise et de conception du SI PRotocole dEchanges STandard et Ouvert Ensemble d'activits corrles ou interactives qui transforme des lments d'entre en lments de sortie. Resource Description Framework Representational State Transfer Rfrentiel Gnral d'Accessibilit pour les Administrations Rfrentiel Gnral dInteroprabilit Rfrentiel Gnral de Scurit Remote Procedure Call Requirements Specification Mapping Really Simple Syndication Real-time Transport Control Protocol Real-Time Transport Protocol Real-Time Streaming Protocol Secure / Multipurpose Internet Mail Extensions Security Assertion Markup Language Stream Control Transmission Protocol La smantique recouvre la fois la signification des mots et le rapport entre le sens des mots (homonymie, synonymie, etc.) Tout SI permettant aux usagers de procder par voie lectronique des dmarches ou formalits administratives. Egalement appel tlservice Secure File Transfert Protocol Systme dinformation Session Initiation Protocol Short Message Service Simple Mail Transfer Protocol
Page 114/119
Terme
SOAP SSL Standard SVG Systme dinformation TCP TDF TIFF TLS ToIP UDDI UDP UIT UIT-T UML UMM UN ONU UN/CEFACT Simple Object Access Protocol Secure Sockets Layer
Description
Modle de rfrence adopt par l'usage d'un groupe de personnes Scalable Vector Graphics Tout ensemble de moyens destins laborer, traiter, stocker ou transmettre des informations faisant lobjet dchanges par voie lectronique entre autorits administratives et usagers ainsi quentre autorits administratives Transmission Control Protocol TlDiffusion de France Tagged Image File Format Transport Layer Security Telephony over Internet Protocol Universal Description Discovery and Integration User Datagram Protocol Union Internationale des Tlcommunications Section de lUIT ddie la normalisation Unified Modeling Language - Langage de modlisation unifi UN/CEFACT Modeling Methodology Mthodologie de modlisation du CEFACT-ONU United Nations Organisation des Nations Unies
United Nations Centre for Trade Facilitation and Electronic Business ou

Centre des Nations Unies pour la facilitation du commerce et les transactions lectroniques United Nations / Electronic Data Interchange for Administration Commerce and Transport Personne physique agissant pour son propre compte ou pour le compte dune personne morale et procdant des changes lectroniques avec des autorits administratives Temps Universel Coordonn 8-bit Unicode Transformation Format Voice over Internet Protocol World Wide Web Consortium Web Accessibility Initiative Waveform audio format Web Services Interoperabilty Organisation Web Services Description Language
UN/EDIFACT Usager UTC UTF-8 VoIP W3C WAI WAV WS-I WSDL
Page 115/119
Terme
WSRP WSS X3D XHTML XMI XML XML NDR XMPP XPath XSD XSLT Web Services for Remote Portlets Web Service Security Extensible 3D
Description
Extensible Hypertext Markup Language XML Metadata Interchange eXtensible Markup Language Langage de balise extensible XML Naming and Design Rules Rgles de nommage et de conception XML eXtensible Messaging and Presence Protocol XML Path Language XML Schema Definition Extensible Stylesheet Language Transformation
Page 116/119
6.. Gestiion des versiions 6 Gest on des vers ons
Version
0.99d 1.0
Date
14-04-2009 12-05-2009
Description
Refonte des trois volets organisationnel, smantique et technique en un seul document. Articulation avec les autres rfrentiels. Ajout du cadre dinteroprabilit. Revue sur les rgles existantes. Projet final pour avis
Page 117/119
7.. Sommaiire dtaiillll 7 Somma re dta

ORGANISATION DU DOCUMENT................................................................................................................... 2 AVANT-PROPOS ................................................................................................................................................ 3 LE DEFAUT DINTEROPERABILITE ........................................................................................................................ 3 COMMENT RESOUDRE UN DEFAUT DINTEROPERABILITE ? ............................................................................... 3 UN REFERENTIEL DINTEROPERABILITE POUR LES SYSTEMES DINFORMATION ................................................ 3 LES DIX BENEFICES ATTENDUS DU RGI ............................................................................................................. 4 PRECISIONS IMPORTANTES ................................................................................................................................ 7 PARTIE 1 : CADRE DINTEROPERABILITE ................................................................................................ 8 SOMMAIRE DU CADRE DINTEROPERABILITE......................................................................................... 9 1. CONTEXTE ET ENVIRONNEMENT...................................................................................................... 10 1.1. 1.2. 2. LADMINISTRATION EN LIGNE ............................................................................................................... 10 CADRE LEGISLATIF .............................................................................................................................. 10
DEMARCHE DELABORATION............................................................................................................. 11 2.1. DEMARCHE ET PARTIS PRIS ................................................................................................................. 11 2.2. DEMARCHE DE SELECTION DES NORMES ET STANDARDS .................................................................. 12 2.2.1. Normes et standards ............................................................................................................... 12 2.2.2. Critres dadoption retenus..................................................................................................... 12 2.3. ORGANISMES DE NORMALISATION ...................................................................................................... 14
3.
DOMAINES DINTEROPERABILITE..................................................................................................... 15 3.1. 3.2. PERIMETRE DE LINTEROPERABILITE ................................................................................................... 15 TYPOLOGIE DES ACTEURS CONCERNES ............................................................................................. 16
4.
PRESENTATION DES NIVEAUX DINTEROPERABILITE ............................................................... 17 4.1. LES DIFFERENTS NIVEAUX DINTEROPERABILITE ................................................................................ 17 4.2. LES NIVEAUX DINTEROPERABILITE TRAITES PAR LE RGI................................................................... 18 4.2.1. Les domaines de linteroprabilit smantique ................................................................... 19 4.2.2. Les domaines de linteroprabilit syntaxique ..................................................................... 19 4.2.3. Les domaines de linteroprabilit technique....................................................................... 19
5. 6.
EVOLUTION DU DOCUMENT................................................................................................................ 20 MODALITES DAPPLICATION DU RGI ............................................................................................... 21
PARTIE 2 : GUIDE DINTEROPERABILITE................................................................................................ 22 SOMMAIRE DU GUIDE DINTEROPERABILITE ........................................................................................ 23 1. STRUCTURE DU GUIDE DINTEROPERABILITE ............................................................................. 24 1.1. 1.2. 1.3. 2. GUIDE DINTEROPERABILITE ................................................................................................................ 24 PRESENTATION DES REGLES DINTEROPERABILITE ............................................................................ 25 LISTE DES NORMES ET STANDARDS REFERENCES ............................................................................. 26
INTEROPERABILITE SEMANTIQUE ................................................................................................... 27 2.1. INTRODUCTION .................................................................................................................................... 27 2.2. CONCEPTION DES ECHANGES ............................................................................................................. 29 2.2.1. Les concepts de base lis aux changes............................................................................. 29 2.2.2. Une dmarche gnrique de conception des changes.................................................... 30 2.3. METHODES DE SPECIFICATION ET LANGAGES .................................................................................... 35 2.3.1. Mthodes de spcification ...................................................................................................... 35 2.3.2. Des langages pour dcrire les changes ............................................................................. 37 2.4. REUTILISATION DES RESSOURCES SEMANTIQUES .............................................................................. 41
Page 118/119
2.4.1. 2.4.2. 3.
Ressources communes aux changes................................................................................. 41 Ressources pour larchivage .................................................................................................. 46
INTEROPERABILITE SYNTAXIQUE .................................................................................................... 50 3.1. FORMATS ELEMENTAIRES.................................................................................................................... 51 3.1.1. Codage des caractres ........................................................................................................... 51 3.1.2. Polices d'criture ...................................................................................................................... 52 3.1.3. Formats dimage....................................................................................................................... 53 3.1.4. Formats de squence sonore................................................................................................. 54 3.1.5. Formats de squence vido ................................................................................................... 55 3.1.6. Formats dobjet graphique en 2D .......................................................................................... 56 3.1.7. Formats dobjet et dunivers 3D ............................................................................................. 57 3.1.8. Formats de dessin technique ................................................................................................. 58 3.1.9. Exportation de bases de donnes ......................................................................................... 59 3.2. FORMATS COMPOSITES ....................................................................................................................... 60 3.2.1. Echange de documents bureautiques rvisables ............................................................... 61 3.2.2. Echange de documents bureautiques non rvisables........................................................ 62 3.2.3. Archivage de documents bureautiques non rvisables statiques..................................... 63 3.2.4. Conservation des documents bureautiques dynamiques .................................................. 64 3.2.5. Echange de donnes numriques dimpression ................................................................. 65 3.2.6. Echange de documents structurs ........................................................................................ 66 3.2.7. Langage de transformation de donnes structures .......................................................... 67 3.2.8. Service de compression de fichiers....................................................................................... 68 3.2.9. Syndication de contenu ........................................................................................................... 69
4.
INTEROPERABILITE TECHNIQUE....................................................................................................... 70 4.1. PRESENTATION .................................................................................................................................... 71 4.1.1. Technologies pour construire les IHM .................................................................................. 71 4.1.2. Feuilles de styles...................................................................................................................... 72 4.1.3. Utilisation de scripts................................................................................................................. 73 4.1.4. Navigateurs web....................................................................................................................... 74 4.2. MULTIMEDIA ......................................................................................................................................... 75 4.2.1. Messagerie................................................................................................................................ 75 4.2.2. Tlphonie................................................................................................................................. 80 4.3. SERVICES WEB ................................................................................................................................... 86 4.3.1. Protocole dchange des messages de ladministration .................................................... 87 4.3.2. Les Services Web SOAP ........................................................................................................ 88 4.3.3. Les Services Web REST......................................................................................................... 94 4.4. INFRASTRUCTURE................................................................................................................................ 95 4.4.1. Services dannuaires et fdration didentit ....................................................................... 95 4.4.2. Technologies........................................................................................................................... 101
5. 6. 7.
GLOSSAIRE ............................................................................................................................................ 111 GESTION DES VERSIONS................................................................................................................... 117 SOMMAIRE DETAILLE ......................................................................................................................... 118
Page 119/119

Langue

RGI - Version1 0

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

RGI - Version1 0

Titre original :

Transféré par

Droits d'auteur :

Formats disponibles

Rfrentiel Gnral dInteroprabilit RGI

DGME RGI Version 1.0 12-05-2009

Organiisatiion du document Organ sat on du document

DGME RGI Version 1.0 12-05-2009

Comment rsoudre un dfaut dinteroprabilit ?

Un rfrentiel dinteroprabilit pour les systmes dinformation

DGME RGI Version 1.0 12-05-2009

Les dix bnfices attendus du RGI

DGME RGI Version 1.0 12-05-2009

DGME RGI Version 1.0 12-05-2009

DGME RGI Version 1.0 12-05-2009

DGME RGI Version 1.0 12-05-2009

Partie 1 : Cadre dinteroprabilit

DGME RGI Version 1.0 12-05-2009

Sommaiire du cadre diinteroprabiilliit Somma re du cadre d nteroprab t

1 - CONTEXTE ET ENVIRONNEMENT ......................................................................................................... 10

4 - PRESENTATION DES NIVEAUX DINTEROPERABILITE.................................................................. 17

6 - MODALITES DAPPLICATION DU RGI .................................................................................................. 21

DGME RGI Version 1.0 12-05-2009

1.. Contexte et enviironnement 1 Contexte et env ronnement

1.1. Ladministration en ligne

1.2. Cadre lgislatif

DGME RGI Version 1.0 12-05-2009

2.. Dmarche dllaboratiion 2 Dmarche d aborat on

2.1. Dmarche et partis pris

DGME RGI Version 1.0 12-05-2009

2.2. Dmarche de slection des normes et standards

2.2.2. Critres dadoption retenus

DGME RGI Version 1.0 12-05-2009

DGME RGI Version 1.0 12-05-2009

2.3. Organismes de normalisation

3.. Domaiines diinteroprabiilliit 3 Doma nes d nteroprab t

3.1. Primtre de linteroprabilit

Autorit Autorit administrative administrative 11

Autorit Autorit administrative administrative 22

Citoyen Citoyen europen europen

Autorit Autorit Administrative Administrative 11

Autorit Autorit Administrative Administrative 22

Administration Administration europenne europenne

Figure 2 : Primtre europen

DGME RGI Version 1.0 12-05-2009

3.2. Typologie des acteurs concerns

DGME RGI Version 1.0 12-05-2009

4.. Prsentatiion des niiveaux diinteroprabiilliit 4 Prsentat on des n veaux d nteroprab t

4.1. Les diffrents niveaux dinteroprabilit

Niveau organisationnel Niveau smantique Niveau syntaxique Niveau technique

DGME RGI Version 1.0 12-05-2009

4.2. Les niveaux dinteroprabilit traits par le RGI

Interoprabilit Interoprabilit Smantique Smantique

Figure 4 : Les trois niveaux dinteroprabilit du RGI

DGME RGI Version 1.0 12-05-2009

4.2.1. Les domaines de linteroprabilit smantique

4.2.2. Les domaines de linteroprabilit syntaxique

4.2.3. Les domaines de linteroprabilit technique

DGME RGI Version 1.0 12-05-2009

5.. Evollutiion du document 5 Evo ut on du document

DGME RGI Version 1.0 12-05-2009

6.. Modalliits dapplliicatiion du RGII 6 Moda ts d app cat on du RG

DGME RGI Version 1.0 12-05-2009

Partie 2 : Guide dinteroprabilit

DGME RGI Version 1.0 12-05-2009