1. PRÉSENTATION GÉNÉRALE ET GUIDE D'USAGE.

1.1. Objet du document.

La présente directive définit les règles applicables pour les échanges interapplicatifs du système d\'information du ministère de la défense. Les règles énoncées participent à la maîtrise des échanges interapplicatifs et à la rationalisation des technologies mises en œuvre.
Ce document s\'inscrit dans les missions de la direction générale des systèmes d\'information et de communication (DGSIC), aux termes du décret n° 2006-497 du 2 mai 2006 portant création de la direction générale des systèmes d\'information et de communication et fixant l\'organisation des systèmes d\'information et de communication du ministère de la défense.

1.2. Niveaux de préconisation.

Les règles présentées dans ce document ont différents niveaux de préconisation et sont conformes au référentiel général d\'interopérabilité (RGI) et à la request for comments (RFC) 2119 :

• obligatoire : ce niveau de préconisation signifie que la règle édictée indique une exigence absolue de la directive ;
  
• recommandé : ce niveau de préconisation signifie qu\'il peut exister des raisons valables, dans des circonstances particulières, pour ignorer la règle édictée, mais les conséquences doivent être comprises et pesées soigneusement avant de choisir une voie différente ;
  
• déconseillé : ce niveau de préconisation signifie que la règle édictée indique une prohibition qu\'il est toutefois possible, dans des circonstances particulières, de ne pas suivre, mais les conséquences doivent être comprises et le cas soigneusement pesé ;
  
• interdit : ce niveau de préconisation signifie que la règle édictée indique une prohibition absolue de la directive.

1.3. Gestion du document.

Ce document est maintenu et mis à jour par le sous-comité architecture et services du comité directeur des intranets. Les modifications sont soumises pour approbation au directeur général des systèmes d\'information et de communication.

Le document est disponible sur le site DGSIC.

Par ailleurs, ce document devra faire l\'objet d\'une revue pour une éventuelle mise à jour lors de l\'un des évènements déclencheurs suivants :

• évolution du référentiel général d\'interopérabilité ;
  
• évolution des profils WS-I ;
  
• évolution du protocole PRESTO ;
  
• modification du domaine d\'emploi/périmètre/limites ;
  

• prise en compte des retours d\'expérience.

1.4. Modalités d'application.

Les règles définies dans cette directive s\'appliquent à l\'ensemble des applications mises en œuvre sur les différents intranets du ministère de la défense, quel que soient leur périmètre fonctionnel et leur niveau de classification.

Ces règles définissent la cible et sont applicables à tout nouveau projet ou toute évolution majeure des applications existantes.

Les directions et services transposent les exigences de la présente directive dans les cahiers des charges aussi bien pour des réalisations internes que pour des marchés externalisés.

1.5. Gestion des dérogations pour les projets.

Les dérogations sont présentées par un expert de haut niveau ou un directeur de projet au sous-comité architecture et services (SC2) qui statue sur la demande.

La commission ministérielle technique des systèmes d\'information et de communication (CMTSIC) peut également être saisie en dernier ressort. Ces dérogations font l\'objet d\'une approbation par le directeur général des systèmes d\'information et de communication.

Elles concernent :

• les circonstances et justifications du non respect d\'une règle recommandée ;
  
• les circonstances et justifications du non respect d\'une règle déconseillée ;
  
• les justifications des exceptions à toute règle absolue (obligatoire ou interdit). Dans ce dernier cas, l\'avis de la DGSIC doit être demandé au préalable et joint au dossier.

2. Cadre documentaire.

2.1. Documents applicables.

RGI	:	référentiel général d\'interopérabilité version 1.0 du 12 mai 2009.
PRESTO	:	protocole d\'échanges standard et ouvert version 1.1.
POS	:	plan d\'occupation des sols version 2.0 du ministère de la défense du 25 novembre 2009.

2.2. Normes et standards applicables.

RFC 2119	:	RFC relative aux mots clés pour les niveaux d\'obligation (mars 1997).
Site DGSIC	:	site intranet défense DGSIC (www.dgsic.defense.gouv.fr).

3. Domaine couvert et emploi.

3.1. Cadre général de la démarche.

Ce document fixe l\'architecture technique applicative, les normes et les standards devant être appliqués ou utilisés par les maîtrises d\'ouvrage et maîtrises d\'œuvre des systèmes informatiques pour les échanges interapplicatifs. Il doit être impérativement appliqué lors des différentes phases de conduite des projets ainsi que lors de la rédaction des dossiers des exigences techniques et fonctionnelles (DEFT) ou cahier des clauses techniques particulières (CCTP).

La mise en relation des applications s\'effectue dans le cadre d\'une approche Service Oriented Architecture (SOA). Dans cette approche, les besoins opérationnels sont définis en services et sont satisfaits par des systèmes et des moyens répartis qui s\'exécutent et coopèrent dans un environnement réseau. L\'approche SOA impose une phase préalable d\'analyse indépendante de l\'implémentation, pour faire émerger des besoins opérationnels une liste de services.

L\'évolution vers la SOA concerne la définition de solutions futures et la migration totale ou partielle de solutions existantes.

L\'adaptation de la mise en œuvre de cette directive pour tenir compte de contextes particuliers ou transitoires doit faire systématiquement l\'objet d\'une demande de dérogation argumentée (correspondance officielle) auprès de la DGSIC.

3.2. Contextes d'emplois.

La réponse au besoin d\'échanges interapplicatifs doit tenir compte de la pluralité des applications et de leur contexte d\'utilisation. Cela nécessite de prendre en compte les contraintes liées aux qualités non fonctionnelles des applications et de leurs environnements de fonctionnement, telles que : comportement des applications vis-à-vis du temps (fonctionnement en temps réel, en temps réfléchi, etc.), capacité et qualité de réseau attendu, niveau d\'autonomie nécessaire, besoin en interopérabilité, niveau de ressources nécessaire (processeur, mémoire, espace de stockage).

Une analyse des qualités non fonctionnelles des systèmes existants en tenant compte des évolutions attendues a permis de segmenter les environnements de fonctionnement selon les trois catégories d\'infrastructure suivantes :

• infrastructure fixe ;
  
• infrastructure déployée ;
  
• infrastructure embarquée.

3.2.1. Infrastructure fixe.

Au niveau infrastructure fixe, on dispose de réseaux fiables, avec des débits importants et éventuellement garantis. Les ressources d\'exécution sont importantes. Les applications sont majoritairement du domaine du « temps réfléchi » (sans contraintes de temps réel). Les propriétés non-fonctionnelles recherchées sont celles du domaine « temps réfléchi » et, dans une optique d\'urbanisation et de convergence, celles liées à l\'interopérabilité. Par ailleurs, les moyens humains pour l\'exploitation des systèmes sont disponibles.

Dans le cadre de l\'infrastructure fixe, des sites d\'hébergement sont mis à disposition pour accueillir de manière rationalisée les applications métiers. La disponibilité et la capacité des réseaux permettent de réduire le nombre de sites d\'hébergement. La localisation de l\'implantation physique des applications métiers n\'a pas d\'importance pour l\'usager dans la majorité des cas. Les techniques de virtualisation sont utilisées et les solutions émergentes regroupées derrière le terme « cloud computing » sont des candidates intéressantes. Elles minimisent les coûts d\'exploitation tout en garantissant une haute disponibilité des applications.

3.2.2. Infrastructure déployée.

Au niveau infrastructure déployée, les réseaux inter-sites sont moins fiables et peuvent subir des pertes de connexion, leurs performances sont variables d\'un site à l\'autre et peuvent dans certains cas être limitées. De même, les ressources d\'exécution peuvent varier de manière importante selon les sites. Certains sites restent cependant proches d\'une infrastructure fixe (bâtiments à la mer de fort tonnage, base aérienne projetée, poste de commandement de grande unité, etc.) tandis que d\'autres disposent de beaucoup moins de ressources et de réseaux inter-sites contraints.

Le déploiement est réellement distribué : plusieurs sites hébergent chacun une partie des ressources d\'exécution et les applicatifs sont répartis/répliqués sur les différents sites. Il existe à la fois des besoins de communication entre applications métiers intra-site, inter-sites, avec la métropole et vers les plates-formes terminales.

Les principales caractéristiques à prendre en compte dans le contexte « infrastructure déployée » sont :

• pouvoir déployer les applications et services métiers sur une architecture physique multi sites ;
  
• pouvoir fonctionner en autonomie dans le cas d\'une rupture de liaison avec les autres sites ou avec l\'infrastructure fixeet être capable de synchroniser automatiquement les données lorsque le réseau est de nouveau disponible ;
  
• pouvoir fonctionner avec des ressources réseaux réduites et des connexions intermittentes.

Contrairement au cas de l\'infrastructure fixe, l\'implantation physique des applications métiers a une grande importance pour certaines d\'entre elles (par exemple pour celles qui participent directement à l\'accomplissement de la mission). Si les techniques de virtualisation continuent à être utilisées de manière aussi poussée que possible, des solutions de type « cloud computing » paraissent plus difficiles à mettre en œuvre.

Les applications restent du domaine « temps réfléchi », même si le tempo de l\'action s\'accélère et l\'objectif « interopérabilité » reste primordial (en particulier dans le cadre d\'actions en coalition). Elles contribuent à la mission des centres de commandement opératif et tactique.

---

3.2.3. Infrastructure embarquée.

Cet environnement correspond à celui des applications métiers devant s\'exécuter sur une plate-forme (de type véhicule terrestre ou aérien). La partie système de mission (pas le système électronique de bord d\'un véhicule par exemple ni le système de combat d\'un bâtiment de marine) est le seul élément pris en compte pour analyser la segmentation des environnements.

Le réseau inter-plates-formes et avec les sites est cette fois fréquemment indisponible et possède des performances souvent limitées. Les échanges peuvent reposer sur des liaisons spécialisées (exemple : liaison de données tactique (LDT), liaison radio, etc.). Une capacité à communiquer « on the move » est souvent recherchée.

Les ressources d\'exécution sont relativement limitées. Les ressources humaines d\'exploitation sont très peu disponibles.

Ce qui distingue cette catégorie des précédentes est avant tout lié au caractère embarqué des applications métier et au caractère prédominant d\'un fonctionnement en autonomie (cette exigence est ici très forte), aux contraintes d\'intégration fortes. Les communications avec d\'autres plates-formes ou d\'autres sites restent un objectif même si elles sont contraintes et non continues.

Les applications sont cette fois-ci du domaine du « proche temps-réel » et doivent parfois dialoguer avec les systèmes temps réel de la plate-forme (a minima pour de la remontée d\'informations). Elles contribuent à l\'exécution de la partie tactique de la mission et se rapprochent du combat.

Dans certains cas, la communication ne se fait pas directement avec la plate-forme mais par l\'intermédiaire d\'un système déployé sur un site. Dans ce cas la problématique se rapproche également du cas infrastructure déployée.

3.3. Périmètre technique.

Le périmètre de ce document couvre l\'ensemble des technologies qui participent aux échanges interapplicatifs internes au ministère incluant les systèmes d\'information, d\'administration et de gestion (SIAG), systèmes d\'information opérationnels et de communication (SIOC) et les systèmes d\'information scientifiques et techniques (SIST). Pour les échanges interministériels, il est impératif de se reporter au RGI.

Cette directive s\'applique aux catégories d\'infrastructures fixes et déployées.

4. Architecture orientée services.

4.1. Qu'est-ce que la Service Oriented Architecture ?

La SOA est un modèle d\'architecture qui vise à optimiser les points suivants :

• réutilisation des fonctionnalités existantes, accessibles sous forme de services qui sont mis à disposition par un certain nombre d\'applications sur le réseau ;
  
• adéquation entre l\'informatique et les règles « métiers » ;
  
• interopérabilité native dans un environnement technique hétérogène ;
  
• unicité de l\'information en évitant ainsi les recopies de données asynchrones ;
  
• couplage lâche entre la conception et l\'implémentation du service.

De manière plus large, l\'architecture SOA offre les moyens de mettre en phase rapidement et régulièrement le système informatique et l\'ensemble des règles métiers utilisées, au rythme des évolutions imposées par les travaux d\'urbanisation du système d\'information (changements techniques et fonctionnels).

4.1.1. Qu'est-ce qu'un service ?

Un service est définit comme un travail unitaire permettant à un fournisseur de fournir un résultat utile à un consommateur. Le résultat utile peut être une information servant à produire la réponse d\'une interface homme machine (source nato architecture framework).

Chaque traitement de ce service est conceptualisé sous le terme d\'opération. Un service est un regroupement d\'opérations qui s\'effectuent dans un contexte homogène.

Chacune de ces opérations nécessite une série distincte d\'informations, afin que le traitement sous-jacent puisse être effectué. Ces informations peuvent être issues de plusieurs sources.

Généralement, ces informations sont une composition de :

• paramètres fournis par le consommateur du service, sous forme de message ;
  
• informations extraites de sources de données (base de données, annuaire, etc.) ;
  
• informations acquises auprès de sous-services dont la granularité est moindre (composition de services).

Une fois le traitement exécuté par une application « serveur », cette dernière restitue une réponse sous forme de message à l\'application « cliente » qui l\'a invoqué. En architecture SOA, on peut aussi trouver le terme de « fournisseur de services » et « consommateur de services ».

 

 

Un service appartient exclusivement à l\'une des deux catégories suivantes :

• les services métiers (exemple : initier une demande de transport, affecter une salle de cours, etc.) ;
  
• les services techniques (exemple : authentifier un utilisateur, envoyer un email, etc.).

La réalisation et l\'exécution de ces services, qui sont généralement accessibles sous forme de services web, sont cadrées par des descriptions web services description language (WSDL) faisant référence elles-mêmes à des schémas extensible markup language (XML). Les descriptions WSDL sont répertoriées et catégorisées dans un annuaire de services.

Seules la disponibilité et la généricité des services permettront de mettre en œuvre avec succès une architecture SOA.

4.1.2. Les services web.

La convention de notation suivante est utilisée dans le présent document pour désigner les services web :

• service web : désigne indistinctement un service web representational state transfer (REST) ou un service web simple object access protocol (SOAP) ;
  
• Web Service : service web simple object access protocol (SOAP) défini par un standard Web Service (WS-*) des organismes world wide web (W3C), organization for the advancement of structured information standards (OASIS).

4.1.2.1. Définition.

Le service web est un programme informatique permettant la communication et l\'échange de données entre applications et systèmes hétérogènes dans des environnements distribués (internet ou intranet).

4.1.2.2. Présentation.

Deux méthodes se distinguent :

• les services web REST ;
  
• les services web SOAP.

Les services web SOAP (Web Services WS-*) contiennent des messages XML qui sont encapsulés dans une enveloppe SOAP. Le fichier de description WSDL (web service description language) accompagne généralement le service web et lui permet d\'être indépendant de la plate-forme d\'exécution.

Les services web SOAP sont mis en œuvre dans le cadre d\'échanges entre applications métiers.

Les services web de type REST sont basés sur l\'architecture du web et ses standards de base : HTTP et URI. Ils exposent entièrement les fonctionnalités d\'un système d\'information comme un ensemble de ressources identifiables et accessibles par la syntaxe et la sémantique du protocole HTTP (get, put, post et delete).

Les services web REST sont mis en œuvre dans le cadre d\'échanges entre un client riche et son serveur.

Les avantages de la mise en œuvre de services web sont :

• leur utilisation par une large communauté, dont les éditeurs et les prestataires de services ;
  
• l\'interopérabilité qui évite le développement de convertisseurs ;
  
• la disponibilité d\'outils dédiés (package services web) ;
  
• l\'accès multi plates-formes, y compris les systèmes propriétaires (exemple : PGI), et les vieux systèmes (exemple : mainframe).

Les inconvénients sont :

• les compétences techniques à acquérir ;
  
• les surcharges réseaux.

4.1.2.3. Profils d'interopérabilité.

Les services web constituent, à l\'heure actuelle, un socle technique indispensable pour l\'interopérabilité des systèmes d\'information. Les standards de Web services ne sont pas tous compatibles et/ou interopérables. La création de profils (exemple : les Basics Profiles) par le consortium ws-i.org, permet de définir des sous-ensembles cohérents de Web services avec leurs contraintes d\'utilisation afin de garantir l\'interopérabilité des plates-formes respectant les spécifications d\'un profil donné.

La figure suivante illustre l\'articulation des principaux profils définis par le consortium WS-I.

 

 

 

Articulation des profils du WS-I (source : http://blog.xebia.fr).

4.2. Le bus d'échange.

Dans l\'approche SOA, le bus d\'échange permet de relier le fournisseur et le consommateur d\'un service. Il permet de fournir une solution de communication entre des applications et services métiers qui peuvent utiliser des protocoles et des technologies d\'implémentation différents.

 

La communication entre services peut être mise en œuvre selon trois niveaux de complexité.

---

 

4.2.1. Niveau 1.

Le premier niveau, minimaliste, est réalisé par une architecture de simple invocation de service telle que représentée sur le schéma ci-dessous.

4.2.2. Niveau 2.

Le niveau 2 est atteint lorsqu\'en plus de l\'invocation de services, il est possible de publier et de rechercher dans un annuaire des informations sur les services (APIs et modèles de données) et leurs instances (protocole d\'invocation, localisation sur le réseau, etc.). Ce niveau est présenté sur la figure ci-dessous. 

4.2.3. Niveau 3.

Le niveau 3, le plus riche, permet le couplage lâche à travers la mise en œuvre du pattern « médiateur de services » présenté sur la figure ci-dessous.

Remarque : le pointillé de la flèche (2) indique que cette flèche est facultative : dans la plupart des cas, le médiateur interroge lui-même l\'annuaire de services.

Dans ce modèle, les systèmes n\'interagissent pas directement entre eux mais par l\'intermédiaire d\'un médiateur. Ce médiateur est l\'acteur unique chargé de « réconcilier » les différences entre les interfaces des différents systèmes en termes d\'Application Programming Interface (API), de modèles de données métier (le format et non la sémantique) et de protocoles d\'échange. Pour implémenter ce pattern de médiateur, les différents vendeurs de solutions logicielles proposent des produits appelés Enterprise Service Bus ou « ESB ».

Ce niveau isole dans les mécanismes de réconciliation du médiateur la complexité de la mise en relation des applications mais ne réduit pas la complexité intrinsèque des échanges ou des réconciliations.

4.3. Référentiel et annuaires des services.

4.3.1. Principes.

Dans l\'approche SOA, les services sont identifiés dans une phase préalable d\'analyse indépendante de l\'implémentation. La description et l\'utilisation de ces services sont réalisées à travers une fonction d\'annuaire. Dépendant de la granularité des services ainsi que de leur contexte d\'utilisation, les différentes vues illustrées dans la figure suivante peuvent être envisagées pour la description et le fonctionnement des services.

 

Une organisation est indispensable pour mettre en œuvre le référentiel global des services tel que décrit ci-dessous.

Il est nécessaire de mettre en place une capitalisation et une gestion en configuration des services métiers.

4.3.2. Référentiel global des services.

Le référentiel global des services contient la définition de tous les services issus de l\'ensemble des besoins opérationnels. Il est utilisé en phase de conception et constitue une base d\'information unique et commune pour l\'ensemble des services.

4.3.3. Annuaire des services.

La combinaison des éléments « annuaire public » et « base de registre » offre la fonctionnalité d\'annuaire des services telle que mise en œuvre dans une architecture SOA. L\'annuaire public constitue une vue utilisateur des services disponibles (analogie avec la notion de page jaune/page blanche d\'un annuaire). La base de registre interne à l\'ESB est une vue technique des services disponibles.

L\'annuaire des services permet la découverte, la localisation et la description des services intégrés à la solution d\'hébergement. Cet élément correspond au bloc fonctionnel « annuaire des applications » du plan d\'occupation des sols (POS) du ministère de la défense).

L\'annuaire permet au consommateur de découvrir le bon service, d\'en bénéficier ceci de façon transparente. Ce mécanisme, illustré dans le schéma ci-après, est souvent décrit par « publish, find, bind ».     

 

     

L\'annuaire des services est un élément d\'infrastructure qui permet de conserver et exposer la description des services et leur mode d\'accès (contrats de services, protocole d\'accès, localisation des instances, etc.). Ces descriptions sont normalisées et référencent des interfaces et protocoles permettant d\'utiliser le service exposé (par exemple au format WSDL).

L\'annuaire de services contient les services qui sont implémentés et qui peuvent être déployés.

L\'annuaire des services doit être différencié de la notion de référentiel de services élaborée dans le cadre d\'une démarche d\'urbanisation du SI. Ce référentiel de services représente l\'ensemble des fonctionnalités offertes par le système sous forme d\'un catalogue des services permettant d\'élaborer une stratégie d\'intégration des processus métiers de l\'entreprise.

L\'annuaire des services est utilisé à l\'exécution (« runtime »).

L\'annuaire de services est constitué à partir du référentiel des services.

---

4.4. Orchestration de services.

Les processus métiers sont composés à partir de services de haut niveau, de grosse granularité, qui s\'enchaînent ou collaborent suivant une logique métier. Ces services de haut niveau sont eux-mêmes modélisés à partir d\'autres services de plus petit grain qui s\'enchaînent ou collaborent également suivant une logique soit métier soit technique.

Ces mécanismes de regroupements coordonnés de services, appelés compositions de services, se déclinent suivant deux modes : l\'orchestration de services et la chorégraphie de services.

L\'orchestration suppose l\'existence d\'un chef d\'orchestre mettant en œuvre un processus exécutable, et la chorégraphie implique une collaboration pair-à-pair basée sur une description des interactions entre ces pairs. La spécification WS-BPEL (web services business process execution language) s\'impose comme standard de langage d\'orchestration des Web Services. Aucun standard n\'émerge pour la chorégraphie de services.

L\'orchestration de services est généralement réalisée à travers l\'utilisation d\'un moteur de business process management (BPM) permettant de modéliser les processus et de paramétrer leur exécution automatique. Cette fonctionnalité n\'est pas fournie par le bus d\'échange lui-même, mais elle est complémentaire de ce dernier pour la mise en œuvre de l\'infrastructure SOA. L\'interfaçage de l\'outil d\'orchestration de services avec le bus d\'échange permet de le déployer comme un client de ce bus, et de l\'utiliser pour invoquer les services intervenant dans un processus métier selon le schéma classique d\'un consommateur [qui peut être une application interactive, un service, un moteur business process management (BPM)] accédant à un service à travers le bus d\'échange comme représenté sur la figure suivante.   

4.5. Contrat d'échange.

Une solution d\'échanges interapplicatifs réalisée dans le cadre d\'une architecture SOA nécessite de mettre en œuvre des contrats d\'échange qui établissent la description technique des modalités d\'invocation des services ainsi que les niveaux de services attendus par les parties prenantes d\'un échange service level agreement (SLA).

On peut distinguer deux aspects du contrat d\'échange qui sont illustrés dans la figure suivante dans le cadre des services web :

Le contrat de service technique décrit les interfaces et les modalités d\'utilisation des services. Dans le cadre des services web, ce contrat de service technique peut être défini par des descriptions WSDL, XML-Schema, WS-Policy.

Le contrat de niveau de service (SLA) définit les engagements vis-à-vis du service, notamment en terme de niveau de service rendu, garanties apportées, tarification éventuelle du service (« billing »). Des indicateurs ⁽¹⁾ ou métriques peuvent être utilisés pour préciser le niveau de cet engagement (exemple : pourcentage de disponibilité, temps d\'inactivité, fiabilité du résultat, temps moyen d\'exécution, temps de réponse garanti, nombre maximum d\'appel de services pour une période de temps donnée, etc.).

Remarque : le terme « technique » dans « contrat de service technique » est utilisé pour souligner le fait que les descriptions du service fournies sont compréhensibles par un programme informatique. Les SLA peuvent également contenir des descriptions techniques automatisables.

5. Les règles.

5.1. Architecture.

La mise en œuvre de nouveaux systèmes d\'information et de communication s\'effectue dans le cadre d\'une approche SOA qui impose une phase préalable d\'analyse indépendante de l\'implémentation, pour faire émerger des besoins opérationnels une liste de services : le référentiel des services du système d\'information des armées (SIA) contient la définition de tous les services issus de l\'ensemble des besoins opérationnels du SIA.

La mise en œuvre de SOA ne doit pas se faire sans la prise en compte de l\'existant. Elle doit intégrer de nouveaux éléments matériels et logiciels mais aussi des systèmes existants éventuellement adaptés.

• RT01 : il est obligatoire que les nouvelles applications s\'inscrivent dans une démarche SOA dont les principes fondamentaux sont :
  
•  couplage lâche entre la consommation et la fourniture du service ;
  
•  définition de services avec une granularité adéquate, permettant d\'optimiser la réutilisation de ces services et la capacité de les composer afin d\'obtenir d\'autres services de plus grosse granularité ;
  
•  mise en œuvre de modes d\'interaction événementiels et asynchrones ;
  
•  tenir compte dès la phase de conception d\'une application de la réutilisation des services définis par d\'autres applications.

• RT02 : il est recommandé d\'inscrire les applications existantes dans une démarche SOA lors d\'évolutions majeures (fonctionnelles et/ou techniques) ;
  
• RT03 : il est obligatoire que la conception de nouvelles applications ainsi que les évolutions majeures des applications existantes s\'appuie sur les services existants par l\'usage des protocoles standards et normalisés (approche modèle en couches) ;
  
• RT04 : il est interdit de développer et d\'utiliser des API propriétaires pour les échanges interapplicatifs.

5.2. Formats d'échanges.

5.2.1. Documents structurés.

• RT05 : il est recommandé d\'utiliser le langage XML pour les échanges de données (fichier et base de données) ;
  
• RT06 : il est recommandé de mettre en œuvre XML 1.0 comme langage de document structuré.

Les défauts de la première spécification XML (XML 1.0) a amené le W3C à proposer une nouvelle spécification XML (XML 1.1) plus complète.

Néanmoins, ces deux versions n\'étant toujours pas compatibles, seule la version XML 1.0 qui est la plus répandue est préconisée.

La version XML 1.1 sera préférée à la version 1.0 dans certains cas d\'usage comme la mise en œuvre du protocole PRESTO.

• RT07 : il est recommandé de mettre en œuvre XML 1.1 lorsque la version XML 1.0 ne suffit pas comme langage de document structuré.

Le contenu d\'un document XML doit être décrit à l\'aide d\'un schéma XML (voir format de description d\'un document XML).

• RT09 : il est obligatoire de contractualiser tout flux XML par un schéma XML.

5.2.2. Format de description d'un document XML.

• RT10 : il est obligatoire d\'utiliser XML-SCHEMA 1.0 pour décrire le contenu et la structure d\'un document XML. La sémantique des informations échangées doit être définie en s\'appuyant sur l\'urbanisation et l\'administration des données.

5.2.3. Codage des caractères.

Le format UTF-8 fait partie intégrante de la norme UNICODE et il est à ce titre, largement supporté par les différents outils de traitement de caractères.

• RT11 : il est recommandé d\'utiliser le format UTF-8 pour l\'encodage des caractères ;
  
• RT12 : il est recommandé d\'utiliser le format UTF-16 pour l\'encodage des caractères dans les langues le nécessitant.

5.3. Services web.

Lorsqu\'un service métier est partagé entre plusieurs applications métier, il est  nécessaire de le concevoir sous forme de service web.

• RT13 : il est obligatoire d\'utiliser les services Web pour les échanges interapplicatifs métiers ;
  
• RT14 : il est recommandé que les services web utilisés pour les échanges interapplicatifs respectent les standards WS*, définis par les organismes W3C et OASIS.

5.3.1. Services web Simple Object Access Protocol.

5.3.1.1. Profil d'utilisation Basic Profile 1.1.

• RT15 : il est recommandé de se conformer au profil d\'utilisation « WS-I Basic Profile v1.1 ».

Défini par le consortium WS-I, le Basic Profile version 1.1 ⁽²⁾ est composé des standards suivants :

• Simple Object Access Protocol (SOAP) 1.1 ;
  
• RFC2616 : Hypertext Transfer Protocol -- HTTP/1.1 ; 
  
• RFC2965 : HTTP State Management Mechanism ;
  
• Extensible Markup Language (XML) 1.0 (Second Edition) ; 
  
• Namespaces in XML 1.0 ; 
  
• XML Schema Part 1 : Structures ;
  
• XML Schema Part 2 : Datatypes ;
  
• Web Services Description Language (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 ; 
  
• RT16 : pour les nouvelles applications, il est obligatoire que la fonctionnalité d\'échange entre applications permette l\'utilisation de services web SOAP ;
  
RT17 : pour les applications anciennes, il est recommandé que la fonctionnalité d\'échange entre applications permette l\'utilisation de services web SOAP.

5.3.1.2. Invocation de services.

• RT18 : il est recommandé d\'utiliser le protocole SOAP v1.1 lors de la conception de services web SOAP ;
  
• RT19 : il est recommandé d\'utiliser le protocole SOAP v1.2 lors de la mise en œuvre de PRESTO 1.1.

5.3.1.3. Description des services.

• RT20 : il est obligatoire d\'utiliser le langage WSDL v1.1 pour décrire les interfaces des services web SOAP.

5.3.1.4. Protocole d'échange de messages.

Le Protocole d\'échange standard et ouvert (PRESTO) pose les bases d\'un protocole d\'échange de messages informatiques entre les applications des différentes administrations.

PRESTO repose sur des standards ouverts et reconnus, afin de garantir :

• une normalisation des échanges ;
  
• une interopérabilité des systèmes ;
  
• une pérennité et une évolutivité des implémentations.

Sa spécification est pilotée par la direction générale de la modernisation de l\'État (DGME) et sa mise en œuvre est réservée aux échanges applicatifs interministériels.

• RT21 : il est recommandé que la fonctionnalité d\'échange entre applications dans le cadre de l\'administration électronique respecte la spécification PRESTO v1.1.

PRESTO v1.1 repose sur les profils d\'utilisation Basic Profile 1.1 et Basic Security Profile 1.0. Néanmoins, afin de répondre aux besoins des échanges applicatifs interministériels, PRESTO déroge aux standards contenus dans les profils d\'utilisation.

En effet, PRESTO est composé des standards suivants :

• XML 1.1 ;
  
• SOAP 1.2 ;
  
• WSDL 1.1 ;
  
• WS-Addressing 1.0 ;
  
• XOP/MTOM 1.0 ;
  
• WS-RM 1.1 ;
  
• WS-Security 1.1.

5.3.1.5. Style d'échange et encodage.

• RT22 : pour la réalisation des services web SOAP métiers, il est obligatoire d\'utiliser le style d\'échange « document » et l\'encodage « literal » wrapped ;
  
• RT23 : il est recommandé d\'utiliser WS-Addressing 1.0 pour l\'adressage des services web ;
  
• RT24 : il est recommandé d\'utiliser WS Reliable-Messaging 1.1 pour la fiabilité des échanges.

  ---

5.3.1.6. Pièces jointes.

• RT25 : il est recommandé de se conformer au profil d\'utilisation « attachments » du WS-I ou aux normes XOP 1.0/MTOM 1.0 du W3C pour gérer les pièces jointes des services web.

5.3.1.7. Sécurisation.

Défini par le consortium WS-I, le basic security profile 1.0 est composé des standards suivants :

• RFC 2818 : HTTP over TLS ; 
  
• RFC 2246 : The TLS Protocol Version 1.0 ; 
  
• The SSL Protocol Version 3.0 ; 
  
• Web Services Security : SOAP Message Security 1.0 (WS-Security 2004), OASIS Standard 200401, March 2004 ; 
  
• Web Services Security : SOAP Message Security 1.0 (WS-Security 2004), Errata 1.0 Committee Draft 200512, December 2005 ; 
  
• Basic Profile Version 1.0 (BP1.0) ; 
  
• Basic Profile Version 1.0 Errata ; 
  
• Basic Profile Version 1.1 (BP1.1) ; 
  
• Simple SOAP Binding Profile Version 1.0 (SSBP1.0) ; 
  
• XML-Signature Syntax and Processing ;
  
• XML Encryption Syntax and Processing ;
  
• Web Services Security : UsernameToken Profile 1.0, OASIS Standard 200401, March 2004 ; 
  
• Web Services Security : UsernameToken Profile 1.0, Errata 1.0 Committee Draft 200401, September 2004 ;
  
• Web Services Security : X.509 Certificate Token Profile, OASIS Standard 200401, March 2004 ;
  
• Web Services Security : X.509 Token Profile 1.0, Errata 1.0 Committee Draft 200512, December 2005 ; 
  
• RFC2459 : Internet X.509 Public Key Infrastructure Certificate and CRL Profile ; 
  
• Information technology « Open Systems Interconnection » The Directory : Public-key and attribute certificate frameworks Technical Corrigendum 1 ; 
  
• Web Services Security : Rights Expression Language (REL) Token Profile 1.0, OASIS Standard: 19 December 2004 ; 
  
• Web Services Security : Kerberos Token Profile 1.1, OASIS Standard Specification, 1 February 2006 ; 
  
• Web Services Security : SAML Token Profile 1.0, OASIS Standard, 01 Dec. 2004 ;
  
• Attachments Profile Version 1.0 (AP1.0) ; 
  
• Web Services Security : SOAP Messages with Attachments (SwA) Profile 1.1, OASIS Standard, 1 February 2006 ;
 
• RT26 : il est recommandé de se conformer au profil « Basic Security Profile v1.0 » pour sécuriser les services web SOAP.

Pour le besoin de confidentialité :

• RT27 : il est obligatoire d\'utiliser la spécification XML Encryption pour chiffrer des documents XML.

Pour le besoin d\'authentification et d\'intégrité :

• RT28 : il est obligatoire d\'utiliser la spécification XML Signature pour signer tout ou partie d\'un document XML.

Pour le besoin de sécurisation des messages SOAP :

• RT29 : il est recommandé de se conformer au WS-Security v1.1 pour sécuriser les messages SOAP.

5.3.2. Les Services web REST.

• RT30 : Il est recommandé d\'utiliser REST dans le cadre d\'interactions entre un client léger ou riche et un serveur et/ou dans le cadre d\'accès de type Create, Read, Update, Delete (CRUD) à une base de données.

Remarque : cette recommandation qui dépasse le cadre de cette directive permet d\'orienter l\'usage de REST. Pour être applicable, cette directive doit rester pragmatique et compte-tenu de certains contextes particuliers, elle ne saurait déconseiller l\'utilisation de REST. Ainsi, l\'utilisation de REST est caractérisée par le niveau de préconisation immédiatement supérieur : recommandé.

Cependant, dans une perspective d\'homogénéisation, l\'utilisation des services web SOAP est à privilégier systématiquement au détriment des services web REST.

5.4. Messages asynchrones.

Les applications peuvent communiquer entre-elles à l\'aide de files de messages asynchrones. Cette technique d\'échange permet à l\'expéditeur et au destinataire de traiter les messages de manière déconnectée.

• RT31 : il est obligatoire que la fonctionnalité d\'échanges interapplicatifs permette le transport de messages asynchrones ;
  
• RT32 : pour les développements en java, il est recommandé d\'utiliser Java Messaging Service (JMS) pour le transport des messages avec traitement asynchrone.

5.5. Infrastructure.

5.5.1. Enterprise Service Bus.

La fonctionnalité d\'échanges interapplicatifs est implémentée par un Enterprise Service Bus qui équipe les infrastructures fixes.

• RT33 : il est recommandé d\'utiliser un ESB pour les échanges interapplicatifs.

Il se peut que la solution retenue pour les infrastructures fixes ne réponde pas aux besoins des infrastructures déployées à cause des contraintes réseaux. Dans ce cadre, une solution d\'échange adaptée doit être mise en œuvre.

• RT34 : dans le cadre d\'une infrastructure déployée, il est recommandé de mettre en œuvre une solution d\'échanges adaptée aux réseaux contraints :
  
• débit limité ;
  
• coupure inopinée ;

• RT35 : il est obligatoire que les échanges interapplicatifs s\'appuient sur les services support d\'infrastructure suivants fournis par l\'intranet MINDEF : annuaire d\'entreprise, authentification forte (SSO global), service de nommage de référence (DNS), service horaire de référence (NTP) et qui seront référencés dans l\'annuaire de service du ministère ;
  
• RT36 : il est obligatoire que la solution d\'échanges interapplicatifs permette la mise en œuvre de contrat d\'échange avec les applications fonctionnant sur cette solution ;
  
• RT37 : il est recommandé que la solution d\'échanges interapplicatifs fournisse des informations contribuant à la vérification de la satisfaction du contrat d\'échange ;
  
• RT38 : il est recommandé d\'utiliser le modèle de contrat d\'échange joint en annexe ;
  
• RT39 : il est obligatoire que la solution d\'échanges interapplicatifs journalise les événements en vue de garantir l\'imputabilité des actions ;
  
• RT40 : Il est obligatoire que la solution d\'échanges interapplicatifs supporte les langages XSLT 2.0 pour formater et transformer des documents XML ;
  
• RT41 : il est recommandé que la solution d\'échanges interapplicatifs supporte XQUERY 1.0 ;
  
• RT42 : il est obligatoire que la solution d\'échanges interapplicatifs permette d\'exporter les journaux vers le service de journalisation de l\'intranet.

5.5.2. Annuaire de services.

• RT43 : il est obligatoire de fournir une fonctionnalité d\'annuaire de services pour le référencement et le fonctionnement des services mis en œuvre pour les échanges interapplicatifs ;
  
• RT44 : il est obligatoire de fournir une fonctionnalité de référencement des services (référentiel) ;
  
• RT45 : il est recommandé d\'utiliser un annuaire de services Universal Description Discovery and Integration (UDDI) v3 pour le référencement des services web SOAP dans le cadre de la synchronisation des annuaires de services ;
  
• RT46 : il est obligatoire que l\'annuaire de services utilisé par l\'ESB lors de l\'exécution (base de registre) soit constitué à partir d\'une référence unique qui est le référentiel des services.

Afin de faciliter la traçabilité des services avec les blocs fonctionnels du POS.

• RT47 : il est recommandé que l\'annuaire des services permette d\'exposer les services selon une taxonomie définie en coordination avec les responsables des zones fonctionnelles du POS du ministère de la défense ;
  
• RT48 : il est obligatoire de contrôler l\'accès en écriture à l\'annuaire des services ;
  
• RT49 : il est recommandé de contrôler l\'accès en lecture à l\'annuaire des services, pour permettre la gestion du droit d\'en connaître si nécessaire.

5.6. Sécurité.

Il est important qu\'un consommateur s\'identifie avant d\'invoquer un service. Cette action permet de filtrer les accès à un service, mais permet également d\'élaborer des statistiques d\'accès aux services.

• RT50 : il est recommandé que les mécanismes d\'échanges interapplicatifs permettent de véhiculer les informations d\'identité du système émetteur ;
  
• RT51 : il est obligatoire de sécuriser les échanges s\'appuyant sur des protocoles applicatifs (FTP, http, IMAP, LDAP, POP3, SIP, SMTP, etc.). Pour sécuriser ces échanges, il est obligatoire d\'utiliser le protocole TLS ou SSL v3.0 ;
  
• RT52 : il est recommandé d\'utiliser les standards Security Assertion Markup Langage (SAML) 2.0 pour l\'échange d\'informations liées à la sécurité ;
  
• RT53 : il est recommandé que les services et applications métiers hébergées soient intégrés à la solution de SSO global mise à disposition par l\'intranet Ministère de la défense (MINDEF) ;
  
• RT54 : il est recommandé d\'utiliser des certificats issus de l\'infrastructure de gestion de clé pour assurer l\'authentification.

5.7. Règles métiers.

• RT55 : il est interdit de rendre l\'Enterprise Service Bus (ESB) dépendant de règles métiers ;
  
• RT56 : il est obligatoire que les règles métiers soient implémentées dans un moteur de règles indépendant de l\'ESB.

Afin de permettre l\'exécution automatique des règles métiers, le moteur de règles doit pouvoir fonctionner comme un fournisseur de services disponible à travers la solution d\'échanges interapplicatifs.

• RT57 : il est obligatoire que le moteur de règles implémentant les règles métiers s\'interface avec l\'ESB afin de permettre l\'accès aux services disponibles.

5.8. Transfert de fichiers.

• RT58 : en contexte web et sur des volumes faibles (inférieurs ou égal à 10 Mo), il est recommandé d\'utiliser http plutôt que File Transfer Protocol (FTP) pour le transfert de fichiers ;
  
• RT59 : hors contexte web, pour transférer des fichiers, il est recommandé d\'utiliser le protocole FTPs (TLS/SSL v3.0) ;

En contexte web, HTTP sera préféré à FTP pour le transfert de fichiers.

• RT60 : il est recommandé d\'utiliser le protocole PeSIT pour l\'échange de fichiers afin de sécuriser et durcir le protocole.

  ---

6. AUTRES MODALITÉS D'ÉCHANGES INTERAPPLICATIFS.

6.1. Échange de données au moyen d'un extract, transform and loading.

Un outil d\'Extract, Transform and Loading (ETL) permet l\'extraction, la transformation et le chargement des données depuis des sources et des cibles diverses [bases de données, fichiers, progiciels de gestion intégrés (PGI), etc.]. Les principaux domaines d\'emploi sont l\'alimentation ou l\'échange entre systèmes opérationnels, et l\'extraction des données de systèmes opérationnels à l\'usage des systèmes dédiés au décisionnel.

Il s\'agit essentiellement de traitements différés (batch) qui mettent en œuvre des volumétries de données importantes.

• RT61 : il est recommandé d\'utiliser un ETL pour les échanges de base de données à base de données ;
  
• RT62 : il est recommandé d\'utiliser le mécanisme de réplication disponible sous réserve de disposer du même moteur, que les schémas soient identiques et que le BD soient colocalisées d\'un point de vue logique [même Local Area Network (LAN) ou à distance avec Virtual Private Network (VPN)].

7. Glossaire.

TERME.	DÉFINITION.
API.	Application Programming Interface. Interface de programmation d\'application. Ensemble de classes participant à la mise en œuvre d\'un ensemble cohérent de fonctionnalités techniques.
BPEL.	Business Process Execution Language. Langage d\'exécution de processus métier. Le BPEL est une initiative de la BPMI (Business Process Management Initiative, un consortium d\'entreprises) dont le but est de proposer une représentation XML des activités liées à l\'exécution d\'un processus. Là où la notation BPMN s\'attache à décrire statiquement les processus, le langage BPEL décrit la dynamique d\'ensemble.
BPM.	Business Process Management. Gestion des processus métiers. Le BPM est une approche consistant à modéliser informatiquement les processus métiers de l\'entreprise ainsi que leurs interactions, aussi bien dans leur aspect applicatif qu\'humain, afin d\'être en mesure de les optimiser et, dans la mesure du possible, de les automatiser au maximum à l\'aide d\'applications métier. La standardisation du BPM (par exemple en vue de la réutilisabilité) a lieu à différents niveaux : - au niveau de la modélisation des processus à l\'aide de la notation BPMN ; - au niveau de l\'exécution des processus, à l\'aide de la notation BPEL.
BPMN.	Business Process Modelling Notation. Notation pour la modélisation des processus métier. Le BPMN est une initiative de la BPMI (business process management initiative, un consortium d\'entreprises) visant à définir une notation graphique commune permettant de modéliser les processus métier. La notation BPMN permet notamment de découpler l\'information métier de l\'information technique (éléments techniques du système d\'information) afin de maximiser sa portabilité d\'une entreprise à une autre. BPMN peut être vu comme une notation UML appliquée à la gestion des processus métier.
CCTP.	Cahier des clauses techniques particulières.
Cloud Computing.	Mode de traitement des données d\'un client, dont l\'exploitation s\'effectue par l\'internet, sous la forme de services fournis par un prestataire. Note : l\'informatique en nuage est une forme particulière de gérance de l\'informatique, dans laquelle l\'emplacement et le fonctionnement du nuage ne sont pas portés à la connaissance des clients. (JO du 6 juin 2010).
Consommateur.	Au sein d\'une architecture SOA, ce terme désigne l\'application cliente à l\'attention de laquelle est offert un service par une application fournisseuse.
CMTSIC.	Commission ministérielle technique des systèmes d\'information et de communication.
CPSIAT.	Centre de pilotage des systèmes d\'information de l\'armée de terre. Le CPSIAT a pour mission de piloter la réalisation des projets du domaine de l\'informatique du SIAT afin de garantir à l\'armée de Terre la maîtrise de son système d\'information.
CRL.	Certificate Revocation List. Liste de révocation de certificats.
DEFT.	Dossier des exigences fonctionnelles et techniques.
DGME.	Direction générale de la modernisation de l\'État.
DGSIC.	Direction générale des systèmes d\'information et de communication du ministère de la défense.
DNS.	Domain Name System. Système de noms de domaine. Le DNS est un service de nommage hiérarchique de toute ressource connectée sur le réseau (internet ou intranet), permettant d\'établir une correspondance entre une adresse IP et un nom de domaine et inversement.
ESB.	Enterprise Service Bus. Bus de services d\'entreprise. Elément de l\'infrastructure informatique (souvent logiciel) interagissant, telle une couche de médiation, entre les applications qui invoquent des traitements ou s\'échangent des informations. Les ESB communiquent principalement au moyen des services web et du protocole SOAP, mais ils sont capables de s\'interfacer avec des applications particulières au moyen de connecteurs. Les ESB permettent ainsi un découplage entre les applications, ce qui permet de prendre en compte des changements technico-fonctionnels sur l\'une des applications sans impacts sur les autres.
ETL.	Extract, Transform and Loading. Extraction, transformation et chargement. Outil permettant d\'extraire les informations d\'une base de données, de les modifier et d\'alimenter une autre base de données. L\'ETL est également utilisé pour les migrations de données entre systèmes opérants, les opérations de reprise de données existantes et les projets de consolidation de référentiels métiers.
Évolution majeure.	Sont considérées comme des évolutions majeures : - un ajout significatif de fonctionnalités ; - une refonte technologique ou une évolution significative d\'architecture ; - un changement de la confidentialité, intégrité, disponibilité des données ou des fonctions du SI ; - l\'ajout, la modification ou la suppression de fonctions ou d\'équipements de sécurité ; - une modification à la baisse de l\'agrément ou de la qualification d\'un équipement de sécurité ; - la modification de la stratégie d\'homologation ; - une évolution des interconnexions ou une extension à des utilisateurs hors ministère. Source : Instruction N° 2005/DEF/DGSIC du 22 juillet 2010.
Fournisseur.	Au sein d\'une architecture SOA, ce terme désigne l\'application productrice qui offre un service à l\'attention d\'une application consommatrice.
FTP.	File Transfer Protocol. Protocole de transfert de fichier. FTP est un protocole dédié à l\'échange de fichiers sur un réseau TCP/IP.
HTML.	Hypertext Markup Language. Langage de description des pages web composé d\'une suite de signe ASCII, dans laquelle sont inclues les commandes spéciales fondées sur un système de balises concernant le formatage des pages, la police de caractères et les multimédia.
IETF.	Internet Engineering Task Force. Afin de résoudre les problèmes techniques liés au protocole IP ou afin de le faire évoluer, cet organisme prépare et élabore les nouveaux standards et normes appelés RFC.
IMAP.	Internet Message Protocol. Protocole de messagerie axé sur la gestion des réceptions.
IP.	Internet Protocol. Protocole internet. L\'un des protocoles utilisés sur l\'internet qui définit, notamment, le format des adresses des machines à employer sur le réseau. La version actuelle de ce protocole est IPv4, décrit dans la RFC, mais le passage à IPv6 (RFC) est à l\'étude ce qui permettra notamment de multiplier par plusieurs milliards le nombre d\'adresses disponibles.
JMS.	Java Messaging Service. Librairie d\'échange de messages entre « clients » soit en mode « point à point », en mode « file d\'attente » ou en mode « publish/subscribe » (abonnements).
LDAP.	Lightweight Directory Access Protocol. Protocole d\'accès aux annuaires informatisés (norme X500) comprenant, entre autres, le protocole réseau, le modèle des informations, l\'espace de nommage et des API pour développer des applications clientes.
MTOM.	Message Transmission Optimization Mechanism. Mécanisme d\'optimisation de message. MTOM utilise les fonctionnalités de XOP pour encoder les messages SOAP. La sérialisation des messages SOAP est optimisée, ce qui accélère les temps de traitement et de transmission.
NTP.	Network Time Protocol. Protocole d\'heure réseau. NTP est un protocole qui permet de synchroniser, via un réseau informatique, l\'horloge locale d\'ordinateurs sur une référence d\'heure.
OASIS.	Organization for the Advancement of Structured Information Standards. Organisation pour la promotion des standards d\'information structure. OASIS, créé en 1993 et comptant 3500 membres répartis dans 600 organisations au sein de 100 pays, est un consortium mondial qui travaille pour la normalisation et la standardisation de formats de fichiers ouverts fondés notamment sur XML.
OGC.	Open Geospatial Consortium. L\'OGC est un consortium international pour développer et promouvoir des standards ouverts, les spécifications OpenGIS®, afin de garantir l\'interopérabilité des contenus, des services et des échanges dans les domaines de l\'information géographique et de la géomatique (ensemble des outils et méthodes permettant de représenter, d\'analyser et d\'intégrer des données géographiques).
PGI.	Progiciel de gestion intégré.
ERP.	Enterprise Resource Planning. Désigne l\'ensemble des logiciels intégrant les principales fonctions nécessaires à la gestion des flux et des procédures de l\'entreprise (comptabilité et finances, logistique, paie et ressources humaines, etc.).
POP3.	Post Office Protocol version 3. Protocole de bureau de poste version 3. Protocole s\'appuyant sur TCP/IP permettant de récupérer du courrier électronique sur un serveur à partir d\'un client, voire des commandes de base du protocole.
POS.	Plan d\'occupation des sols. Le plan d\'occupation des sols, ou POS, de la démarche d\'urbanisation est un cadre de représentation synthétique et structuré de la vision fonctionnelle et applicative du système d\'information.
PRESTO.	Protocole d\'échanges standard et ouvert. PRESTO a pour objectif de définir une couche générique d\'échange de messages pour les échanges de l\'administration électronique. PRESTO a été conçu en tenant compte des contraintes et exigences collectées par la DGME. La spécification PRESTO est la spécification d\'un profil Web Service.
PeSIT.	Protocole d\'échanges pour un système interbancaire de télécompensation. Ce protocole issu de la profession bancaire est largement utilisé dans d\'autres contextes pour échanger des fichiers de façon sécurisée et compressée notamment dans le cas de volumes importants.
REST.	Representational State Transfer. REST n\'est ni un protocole ni un format, mais un style d\'architecture qui est le style architectural du Web. Il est de plus en plus utilisé pour la réalisation d\'architectures orientées services utilisant des services web destinés à la communication entre machines. REST se pose en alternative au style architectural RPC et à la plupart des cas d\'utilisation de SOAP.
RGI.	Référentiel général d\'interopérabilité.
SAML.	Security Assertion Markup Language. Spécifications XML favorisant l\'interopérabilité entre différentes solutions de gestion des droits utilisateurs et ce, afin de faciliter la mise en œuvre de systèmes SSO.
Service.	Un service est défini comme un travail unitaire permettant à un fournisseur de fournir un résultat utile à un consommateur. Le résultat utile peut être une information servant à produire la réponse d\'une interface homme machine (Source Nato Architecture Framework).
SIA.	Système d\'information des armées.
SIAG.	Système d\'information d\'administration et de gestion.
SIOC.	Système d\'information opérationnel et de commandement.
SIST.	Système d\'information scientifique et technique.
SIP.	Session initiation protocol. SIP est un protocole standard ouvert de gestion de session souvent utilisé dans les télécommunications multimédia (son, image, etc.). SIP est un protocole normalisé et standardisé par l\'IETF.
SMTP.	Simple Mail Transfer Protocol. Protocole de transfert de courrier. Utilisé pour transférer les courriels vers une boite de messagerie.
SLA.	Service Level Agreement. Accord de niveau de service. Partie d\'un contrat de service traitant d\'un niveau de service exigé (par exemple : temps de réponses, nombres d\'appels, coûts, temps d\'indisponibilité maximum).
SOA.	Service Oriented Architecture. Architecture orientée services. Modèle d\'interaction applicative mettant en œuvre  des connexions entre divers composants logiciels. Un service désigne une action exécutée par un composant « fournisseur » à l\'attention d\'un composant « consommateur », fondé éventuellement sur un autre système.
SOAP.	Simple Object Access Protocol. Protocole d\'accès aux objets. Protocole orienté objet bâti sur XML permettant de formaliser les échanges de services web.
SSL.	Secure Sockets Layer. Ancien nom du protocole TLS destiné à sécuriser les échanges sur internet (brevet déposé par Netscape).
SSO.	Single Sign on. Système d\'authentification unique qui permet à l\'utilisateur de ne fournir ses éléments d\'identification (compte et mot de passe) qu\'une seule fois, quel que soit le nombre des applications auxquelles il a accès.
SwA.	SOAP message with attachments.
TCP.	Transmission Control Protocol. Protocole de la couche transport orienté connexion qui assure une transmission fiable en duplex des données. TCP fait partie de la pile de protocoles TCP/IP.
TLS.	Transport Layer Security. Nouveau nom du protocole SSL, ce protocole est destiné à sécuriser les échanges sur Internet et est particulièrement performant lors de l\'emploi de clés symétriques.
UDDI.	Universal Description Discovery and Integration. UDDI est un standard d\'annuaire fondé sur XML mis en œuvre afin de référencer des services web SOAP.
UNICODE.	Norme informatique visant à donner à tout caractère de tout système d\'écriture un nom et un identifiant numérique, de façon unifiée.
URI.	Uniform Resource Identifier. Un URI est une courte chaîne de caractères identifiant une ressource (par exemple une ressource Web) sur un réseau, et dont la syntaxe respecte une norme d\'Internet mise en place pour le World Wide Web (voir RFC 3986). Par exemple urn:ietf:rfc:2396 est un URI identifiant le RFC 2396. Les URI sont la technologie de base du World Wide Web car tous les hyperliens du Web sont exprimés sous forme d\'URI.
UTF.	Unicode Transformation Format. Format de codage pour les caractères au standard Unicode, caractérisé par des formes liées au nombre de bits utilisés.
W3C.	World Wide Web. Consortium fondé en 1994 pour promouvoir la compatibilité des technologies du web (HTML, XML, SOAP, etc.) au moyen de recommandations (pas de normes).
WS-Addressing.	Web Services Addressing. Standard du W3C du 9 mai 2006, couvrant le besoin de routage de données XML, au niveau des entêtes du message SOAP.
WS-BPEL.	Web Services Business Process Execution Language. Standard de l\'OASIS de spécification de langage d\'exécution de processus métier.
WS-Policy.	Web Services Policy. Standard du W3C permettant aux services web d\'utiliser XML pour exprimer les règles de conception et d\'utilisation (par exemple sur la sécurité, la qualité de services ...).
WS-Reliable-Messaging (WS-RM).	Web Services Reliable Messaging. Standard de l\'OASIS du 14 juin 2007 (v1.1) et du 2 février 2009 (v1.2), couvrant le besoin d\'assurance de délivrance de message SOAP.
WS-Security.	Web Services Security. WS-Security est une spécification d\'élément de sécurité en matière de services web.
WS-I.	Web Services Interoperability Organization. Consortium industriel constitué pour la promotion de l\'interopérabilité entre plates-formes par la rédaction des spécifications des Services Web WS-*. Cette organisation a été créée au début des années 2000 par des industriels de l\'informatique comme IBM, Microsoft, BEA Systems, SAP, Oracle, Fujitsu, Hewlett-Packard ou Intel. Leurs travaux sont par ailleurs complétés par la rédaction de profils d\'utilisations des Services Web WS-* et d\'exemples applicatifs pour favoriser une meilleure implémentation des spécifications.
WSDL.	Web Services Description Language. Langage de description de services web Spécification qui permet de décrire les interfaces d\'accès public aux services web.
XML.	Extensible Markup Language. Méta-langage, standardisé par le W3C, permettant de décrire et de structurer des données de manière hiérarchisée au moyen de balises.
XML-Encryption.	Standard du W3C du 10 décembre 2002, couvrant le besoin de chiffrement d\'arbres et de sous-arbres XML.
XML-Signature.	Signature XML. Recommandation du W3C permettant de signer tout ou partie d\'un document XML. Elle assure l\'authentification et l\'intégrité des données.
XML-Schéma.	XML schéma. XML Schéma est un langage de description de format, il permet de décrire et de structurer le contenu des documents XML. Connu aussi sous le nom XSD, XML Schema participe à la validation d\'un document XML. Les schémas (XSD) sont standardisés sous forme de recommandation du W3C. XML Schéma est un langage de description de format, il permet de décrire et de structurer le contenu des documents XML. Connu aussi sous le nom XSD, XML Schéma participe à la validation d\'un document XML. Les schémas (XSD) sont standardisés sous forme de recommandation du W3C.
XOP.	XML Binary Optimized Packaging. Standard du W3C définissant un mode de transmission de données XML de manière optimisée au moyen de XML Infoset et de représentations binaires.
XPath.	XML Path Language. Syntaxe (non XML) de désignation de portions de flux XML adoptée comme langage d\'interrogation et de positionnement au sein d\'un flux XML.
XQuery.	Langage de requêtage adapté aux structures XML, dont la logique se rapproche du langage SQL. XQuery constitue une alternative à l\'usage de XSLT et réciproquement, en fonction des besoins techniques.
XSD.	XML schéma définition. Fichier de description de structures XML (cf. définition de XML SCHEMA).
XSLT.	Extensible Stylesheet Language Transformations. Langage de transformation de flux XML fondé sur des règles appliquées au cours du parcours de ce flux.

---