Rapport Baquiast - Propositions sur les apports d'Internet à la modernisation du fonctionnement de l'Etat. Plateforme d'échange aux normes Internet pour commerce électronique par Rémy Marchand

Rémy Marchand Directeur du développement ALMACOM .

Description générique d'un système de téléprocédures aux standards Internet entre une administration et des partenaires entreprises ou collectivités publiques.

Le présent document présente la maquette de ce que pourrait être le cahier des charges d'une architecture de communication aux standards Internet entre un service administratif, dénommé ici ServiceX, et des partenaires extérieurs, entreprises ou établissements publics locaux. Le réseau ainsi décrit pourrait intéresser, par exemple, un service fiscal s'adressant à des entreprises déclarantes. On remarquera la simplicité des échanges proposés, le faible coût et le bref délai des réalisations.

Nous remercions Rémy Marchand, précédemment auteur de deux rapports au Premier ministre sur les téléprocédures, d'avoir bien voulu nous fournir ce document dont il conserve la propriété intellectuelle et la responsabilité. La mise en forme éditoriale  finale du texte a été réalisée par moi. Je me suis efforcé de respecter l'esprit de l'original. Baquiast
15 pages

Introduction

Lors du second semestre de l'année 1997, le ServiceX a jeté les bases d'un nouveau service de téléprocédures à l'usage des entreprises dont il gère les déclarations.

Ce nouveau service s'assigne les objectifs suivants :

- Préserver un haut niveau de performances des applications informatiques du ServiceX,

- Accroître la pertinence, la qualité et la rapidité des actions du personnel du ServiceX, au bénéfice de ce personnel autant qu'à celui des déclarants.

- Doter le ServiceX d'un outil de gestion susceptible d'attirer vers cette institution de nouvelles demandes de services et de gestion detéléprocédures.

- Structurer les échanges d'informations entre le ServiceX et les entreprises, et corrélativement, permettre de développer une politique de labellisation des logiciels utilisés par ces entreprises en vue d'harmoniser les flux d'information émis et reçus par les différents partenaires,

Autoriser une large utilisation des services grâce à une politique de tarification modérée (cf infra), bien qu' assurant la rentabilité à court terme des investissements consentis.

Compte tenu de la disparité des poids économiques des partenaires du ServiceX, de leurs aptitudes très différentes à mettre en œuvre des systèmes de gestion informatisés, de leur capacité contributive proportionnée à leurs budgets, le ServiceX se propose de développer des services comportant plusieurs niveaux d'accès, des plus simples (entreprises déclarantes de 1 à 10 salariés) jusqu'aux plus complets (entreprises de plus de 500 salariés).

La gamme de services proposés doit permettre une large adhésion du plus grand nombre d'entreprises aux nouveaux services, cette adhésion de masse étant garante d'un retour sur investissements rapide. Le point d'équilibre doit être trouvé grâce à une politique de tarification modérée suscitant un ralliement du plus grand nombre d'entreprises à des services conçus pour leur simplifier la vie et les aider dans l'accomplissement de leurs tâches de gestion.

Les technologies employées font largement appel aux outils et solutions de l'INTERNET associées à celles de l'EDI ou de l'EFI (formulaires électroniques utilisant le standard HTML). La combinaison des technologies précitées permettra de passer de l'une à l'autre sans difficultés et sans faire apparaître le moindre défaut de cohérence entre les composants assemblés. En particulier, la sémantique des données sera identique quel que soit le mode de transmission utilisé.

Il est à signaler que le ServiceX offrira un sentier de migration des solutions utilisées jusqu'à présent (TEDECO, Minitel par exemple) vers les nouvelles solutions plus complètes, plus ergonomiques et néanmoins économiques. A court terme, et pendant le temps que prendra la migration vers les solutions de nouvelle génération, les solutions actuelles seront maintenues.

Enfin, le ServiceX considère qu'il est dans ses prérogatives naturelles de proposer à d'autres entreprises ou collectivités une prestation de services généralisés de communications électroniques.

Cette opinion se fonde sur plusieurs considérations :

- Le ServiceX développant pour ses propres besoins un service de téléprocédures avec les entreprises déclarantes a de ce fait la possibilité d'installer des systèmes matériels et logiciels gérant ce service; le seuil de rentabilité du service est atteint par les seules économies de gestion du ServiceX.

- Les solutions mises en œuvre étant fondées sur des normes de systèmes ouverts et utilisant en outre la norme EDIFACT ou les formats standard HTML (plus tard XML), il est possible - pour un coût marginal - de décliner l'offre de service vers de nouveaux axes de communication n'impliquant pas le ServiceX; l'offre ainsi constituée permettra aux collectivités susvisées de généraliser l'usage des télécommunications et des téléprocédures avec la plupart de leurs partenaires,

- Le ServiceX proposera une offre de services globale dans un cadre concurrentiel; elle tiendra compte, et dans une large mesure tirera parti, d'initiatives prises pour déployer des systèmes de communication électroniques à l'usage d'autres collectivités; ces systèmes seront utilisés ou étendus vers les collectivités, l'offre globale de services intervenant comme complément à valeur ajoutée des systèmes existants.

2. Caractéristiques fonctionnelles de l'offre globale de communications électroniques

Schéma des solutions sur lesquelles s'appuyera le service.

Le ServiceX développera un service de communications électroniques tenant compte des spécifications du document Schéma Directeur Interministériel des Téléprocédures et ayant les spécifications fonctionnelles suivantes :

La gestion des communications s'appuyera en priorité sur les protocoles de l'INTERNET, mais les solutions de communication courantes seront également proposées. La base installée en systèmes de communication (PESIT, TEDECO, Xmodem etc..) des partenaires du ServiceX est en effet importante, et, bien que la migration vers les solutions de l'INTERNET doive intervenir le plus rapidement possible, il serait regrettable de s'interdire une montée en charge rapide s'appuyant sur les systèmes installés. En complément des modes de communication de l'INTERNET, les modes de communication suivants seront donc proposés :

X 400 et X 400/TEDECO (version ATLAS 440 et P7)
OFTP
X/MODEM
KERMIT
PESIT
ETEBAC 3 et 5
FAX en émission

Les modes précités (actuels, futurs INTERNET) comporte(ro)nt les services de sécurité de référence nécessaires au bon fonctionnement du dispositif.

Aucune modification n'interviendra sur les services de sécurité des systèmes de communication actuels. Les services de sécurité de l'INTERNET évolueront selon les recommandations de l'IETF (cf infra). L'implémentation TEDNET est déjà disponible.

Aux différents modes de communication précités, seront associés les dispositifs de contrôle permettant d'effectuer des relances en cas d'avortement de procédure, de déclencher les procédures en fonction de chronologies prédéterminées, de gérer la traçabilité des échanges.

Enfin, l'interopérabilité avec les opérateurs de réseaux et services à valeur ajoutée sera assurée.

Le système support de l'offre ServiceX comportera une gestion des profils des partenaires.

Celle-ci permettra d'identifier divers paramètres relatifs aux services de communication électronique propres à chaque partenaire :

- mode principal de communication utilisé et mode de communication de secours en cas de déficience du précédent,

- formats de transmission des informations communiquées (EDIFACT, HTML/formulaire électronique, autre).

Le système assurera une gestion des messages par type de message. Pour chaque occurrence de message, un processus de qualification sera invoqué se référant au message modèle correspondant. Le résultat des contrôles permettra d'envoyer aux partenaires un message de contrôle, si l'accord d'interchange le prévoit. Ce résultat sera discriminant pour la poursuite du traitement des messages.

Les pistes d'audit des messages et leur traçabilité seront assurées.

L'administration du système permettra d'intervenir sur les messages en vue de leur recyclage éventuel.

En complément des traitements de messages ou de formats normalisés, il sera proposé un service de mise en conformité avec la norme EDIFACT de formats dits "propriétaires".

Enfin, le système proposera une version Formulaires électroniques des échanges avec les partenaires.

Les formulaires électroniques représenteront le mode d'accès économique aux servicesdu ServiceX. Ils seront gérés de la façon suivante :

- Les données saisies et transportées par ces formulaires électroniques auront la même représentation physique et la même définition sémantique que celles transportées par les messages EDIFACT,

- Les formulaires électroniques feront l'objet d'une saisie contrôlée (applets Java); les contrôles effectués seront en tous points identiques à ceux prévus dans les notes syntaxiques des guides d'implémentation des messages EDIFACT

Se substituant aux échanges de données régis par les messages EDIFACT, les formulaires électroniques seront le plus souvent utilisés avec des partenaires ne disposant pas de systèmes d'information interne contenant les informations les concernant. Les formulaires électroniques seront, dans ce cas utilisés pour restituer aux partenaires concernés leurs propres informations, préalablement transmises au ServiceX. Par ce moyen, il sera possible d'envoyer par les réseaux des formulaires électroniques préremplis que les partenaires n'auront plus qu'à compléter des données de mise à jour. Ainsi, pour une déclaration de ..., les données d'identification de l'entreprise et celles identifiant les autres éléments de la déclaration connus par d'autres évènements saisis par le ServiceX, complétées par les dates de ces évènements, seront transmises aux déclarants qui auront la responsabilité de finir de remplir ces déclarations. La mise en application de ces modalités d'échange, déjà opérationnelles avec les anciens services Minitel, supposera que les interfaces adéquates soient développées avec les systèmes informatiques internes du ServiceX ou que ceux-ci soient dupliqués et mis sur le serveur de commerce électronique.

Le ServiceX recevra l'ensemble des informations qu'il traitera sous un format EDIFACT, que le partenaire ait initialement transmis cette information au format EDIFACT ou selon le mode formulaire électronique.

Les transformées de ces messages en vue de les soumettre aux applications seront de la responsabilitédu ServiceX

3. Les contraintes

Cible de l'offre globale

Le système de commerce électronique/EDI-EFI proposé est destiné à être installé chez les partenaires du ServiceX. Effectués pour un échantillon de ces partenaires, ils pourront être déployés vers l'ensemble de la cible. Les développements requis pour les autres partenaires d'une part, pour passer d'une offre de services ciblée sur les échanges réalisés avec le ServiceX à une offre globale (fournisseurs, INSEE, Réseau comptable du Trésor) d'autre part seront une déclinaison des premiers services, grâce à la référence aux normes et standards de systèmes ouverts.

Les dispositifs EDIFACT permettront des échanges de données d'applications à applications sans intervention humaine,

La gestion des formulaires électroniques sera systématiquement développée comme une alternative aux échanges EDI/EDIFACT, comme indiqué précédemment.

L'offre de services de commerce électronique saura gérer les documents multiformats en ayant recours au standard de messagerie SMTP/MIME. Les documents composites seront assemblés à l'origine selon des mécanismes appropriés à l'application et ventilés à la réception vers les différents processus capables de les traiter.

Intégration de fonctionnalités.

Seules deux applications seront rendues capables d'émettre et recevoir des messages électroniques (développement des transformées) dans le cadre du présent projet, mais dans ce cas également, les principes mis en œuvre par les solutions pourront être généralisés. C'est aux utilisateurs qu'il appartiendra de réaliser les intégrations dans les autres cas.

Réutilisabilité - évolutivité :

La solution proposée doit être ouverte: elle s'interface avec divers mécanismes de communication (transport d'informations interne-externe, LAN, WAN, messageries, SMTP-MIME, middleware de communication inter-applications),

Le projet ServiceX a comme hypothèse de départ d'utiliser le réseau Internet et/ou les technologies de communication associées (courrier électronique, SMTP). Les services développés seront maintenus à niveau, sous réserve que le ServiceX base son offre généralisée de services sur le développement et la maintenance des solutions faisant l'objet de la présente proposition.

La solution développée sera la pleine propriété du ServiceX. Les programmes source lui seront remis.

La solution sera capable d'évoluer en termes de capacité à absorber des trafics croissants.

Performance :

La solution proposée doit garantir la performance et la fiabilité du service : elle garantira un trafic en nombre de messages, temps de réponses, nombre de partenaires, taille des messages, etc. Elle doit également absorber des dysfonctionnements externes au niveau des systèmes de télécommunications comme au niveau des messages/lots d'information.

Facilité :

Une attention toute particulière sera portée sur la facilité de mise en oeuvre des solutions en particulier pour les aspects liés à leur exploitation (traçabilité, accès aux services d'administration, ...).

Fiabilité - Administration - Sécurité :

Les solutions proposées intègreront des modalités d'administration et de supervision des différents services (traçabilité en particulier),

Des dispositifs de tolérance aux pannes pourront être prévus, les conditions du secours/restauration des solutions EDI/EFI seront définies,

La sécurité des communications sera assurée, au niveau des différentes couches du modèle ISO. Des dispositifs de gestion de relances en cas d'indisponibilité des systèmes vers lesquels les émissions sont faites seront prévus et des fonctionnement en mode dégradé pourront être utilisés en cas de défaillance durable des systèmes avec lesquels les tentatives de communications auront échoué..

Stabilité - Maintenabilité :

La solution sera basée sur des normes et standards du domaine public: les communications reposent sur les standards Internet (SMTP, SMIME, HTTP),

Les normes EDIFACT sont un élément fondamental du service,

Les formats HTML sont une alternative à la norme EDIFACT et ces formats véhiculent les mêmes données que les messages EDIFACT qui leur correspondent,

Les solutions sont maintenues en parallèle par le couple EDIFACT/HTML

Les solutions composant le service évolueront au gré des normes EDIFACT, d'une part en ce qui concerne la configuration des messages, d'autre part en ce qui concerne les versions futures de la norme EDIFACT , en particulier celles qui font l'objet de travaux XML/EDI

(cf http//:www.geocities.com/WallStreet/Floor/5815)

Portabilité :

Les solutions EDI/EFI composant le service seront portables sur les plate-formes UNIX (POSIX),

Les solutions EDI clients opéreront dans les environnements DOS, Windows et UNIX

Les solutions EFI ne nécessiteront pas d'autre logiciel que les navigateurs INTERNET (NETSCAPE/MICROSOFT).

Interfaces utilisateurs :

L'interface utilisateur sera de préférence de type X-Windows-Motif (Unix) et de type Windows sur le poste client.

En résumé, les moyens matériels et logiciels mis en oeuvre possédent les caractéristiques suivantes :

- interfaces ergonomiques et conviviales pour faciliter l'exploitation,

- architectures respectant les normes et standards du marché,

- évolutivité et modularité permettant de suivre les évolutions du système d'information sans remise en cause des choix et des investissements initiaux

- respect des orientations générales qui s'imposent aux partenaires du fait de leur relation avec le secteur public (cf Schéma Directeur des Téléprocédures).

Les avantages des solutions proposées sont les suivants :

- Un traitement complet des messages EDIFACT, GENCOD, INOVERT et capacité à gérer des formats propriétaires,

- Une utilisation des protocoles Internet standards : SMTP, FTP, HTTP, SSL et SMIME,

- La portabilité immédiate en environnements Unix, Windows 3.51 et Windows NT 4.0,

- L'utilisation des certificats, cryptage par SSL, signatures digitales, etc...

- L'administration est complètement développée en langage Java et accessible par les navigateurs,

- La gestion de la traçabilité des messages et des pistes d'audit, la restauration des messages.

4. Ancrage des solutions proposées sur les travaux de l'INTERNET

L'EDI sur Internet a très vite été considéré comme une moyen efficace de développer le commerce électronique.

INTERNET apporte trois compléments de premier plan qui donnent une nouvelle vigueur au développement de l'EDI :

- une solution globale (mondiale) pour le transport économique des informations,

- les compléments nécessaires à l'EDI pour gérer l'ensemble des relations électroniques entre partenaires et non seulement les échanges de données structurées entre applications,

- une voie d'entrée économique et n'exigeant pas d'application pour les partenaires modestes (PC connecté et Navigateur), ce qui permet aux partenaires importants de généraliser les échanges électroniques avec la plupart de leurs partenaires et non seulement avec les plus importants d'entre eux.

Le projet asseoit en conséquence son offre de solutions sur les spécifications développées par l'IETF(Internet Engineering Task Force).

Pour traiter des questions relatives à la sécurité des systèmes de commerce électronique, l'IETF a formé un groupe de travail, l'EDIINT (Electronic Data Interchange-Internet Integration). Ce groupe de travail a défini les spécifications nécessaires pour la sécurisation et l'interopérabilité des services EDI.

Le groupe a écrit un rapport " MIME-based Secure EDI " qui spécifie les standards Internet nécessaires pour assurer des échanges de documents EDI en utilisant MIME et la cryptographie par clé publique. Les solutions proposées s'appuient sur les standards spécifiés dans ce rapport.

Pour garantir l'intéropérabilité des solutions EDI sécurisées basées sur MIME, l'IETF a formé l'Interoperability Test Team. Les solutions proposées seront garanties conformes aux standards d'EDI sur Internet.

5. Description des solutions sur lesquelles s'appuiera le service

Les solutions développées et livrées : comprendront :
Des navigateurs, NETSCAPE ou INTERNET EXPLORER au choix,
Un serveur de messagerie,
Un générateur de rapports,
Oracle 7 Workgroup Server Release 7.3.2.2,
Un gestionnaire de transformatages gérant les transformées
    De format propriétaire vers EDIFACT,
    De format EDIFACT vers un format propriétaire
    D'un format propriétaire vers un autre format propriétaire
Un gestionnaire spécialisé dans la transformation HTML/EDIFACT et inversement.

Pour les solutions EDI clients deux possibilités sont offertes:

- Une solution minimale pour les partenaires qui évoluent dans des environnements MS-DOS seul - Client mail standard - Ces partenaires n'ont accès qu'à un sous-ensemble des fonctionnalités du serveur (par exemple ils ne pourront pas utiliser des certificats).

- Pour les environnements Windows 3.11, Windows 95, Windows NT, UNIX, OS/APPLE la solution client sera basée sur un navigateur standard dont la version sera adaptée aux performances des ordinateurs. Dans les cas où les solutions feront l'usage de certificats, celles-ci exigeront les versions les plus récentes des navigateurs ( Netscape Communicator ou Internet Explorer 4 de Microsoft par exemple ).

Pour garantir une sécurité de haut niveau et la plus grande facilité d'utilisation par les utilisateurs des services déployés, le(s) navigateur(s) seront paramétrés avant d'être livrés afin d'accepter les certificats du serveur. Les navigateurs seront livrés en version française.

L'interface utilisateur sera développée en Java et accessible par navigateur.

La solution EDI client sera développée en HTML. Une aide en ligne, spécifique pour la CDC-BCR, sera développée. L'aide en ligne sera également en HTML.

Pour ce qui est de l'interface utilisateur finale, une solution spécifique en français sera développée

L'ensemble des composants intégrés dans la solution constituera une solution autonome et complète. Aucun dispositif tiers ne sera nécessaire à son bon fonctionnement, exception faite des licenses Oracle 7 Workgroups Server (Release 7.3.2.2).

En standard le service s'appuie sur les protocoles de communication et de messagerie suivants :
Simple Mail Transfer Protocol (SMTP), protocole de messagerie de l'INTERNET
MIME et S/MIME (MIME sécurisé), protocole de messagerie de l'INTERNET multicorps,
File Transfer Protocol (FTP), protocole de transfert de fichiers de l'INTERNET,
Hyper-Text Transfer Protocol (HTTP) et Hyper-Text Transfer Protocol Secure (HTTPS), protocoles associés aux formats HTML
Interface avec les réseaux à valeur ajoutée EDI courants (ATLAS 400, ALLEGRO, d'ARVA, GE etc (d'autres sont en cours de développement),
TCP/IP protocol couches basses de l'INTERNET et ses API.

Au terme d'un an, le service supportera l'administration de réseau SNA et les protocoles synchrones 3780.

L'interface avec les environnements BULL non UNIX et AS400 ne sera pas incluse en natif.

L'interface de communication sera prise en compte par le module Gestion des Communications Handler. L'API de ce module sera publiée.

Cette dernière permettra donc le développement et l'intégration dans le système des différentes interfaces à mettre en oeuvre dans le cadre de ce projet (X400 en particulier).

La solution complète nécessitera 256 Megabits de mémoire RAM.

Le service proposera une fonctionnalité de formulaire électronique (EFI). Le système permet de présenter un formulaire HTML à l'utilisateur permettant d'envoyer un message/fichier ayant le même contenu sémantique qu'un message EDIFACT, et assorti des mêmes contrôles. C'est l'émetteur de ces formulaires/messages qui fera la saisie des informations, les contrôles lui étant envoyés par le réseau.

En complément d'applications de type WEB/EFI, il sera proposé des applications simples fonctionnant en mode déconnecté.

La génération de formulaires HTML à partir d'un message EDI sera également intégrée et autorisera les scénarios suivants :

Les données applicatives sont présentées au serveur,

Les données sont transformées dans un format qui peut être traité par un programme CGI,

Quand le partenaire se connecte au serveur Web, le programme CGI "montre" les données au partenaire sous l'aspect d'un formulaire HTML,

Le statut des données dans la base du serveur est mis à jour.

Pour traiter les messages entrants le service utilisera un module Gestionnaire de Services . Le gestionnaire de services contrôle pour chaque unité de travail quels processus (ou services) doivent être exécutés. Ce contrôle est basé sur des Listes de Services qui seront aussi détaillées que nécessaire en fonction du nombre de types de partenaires et du nombre de types de document.

Etape 1. Chaque message obtient d'abord un Identifiant de traçe. Ceci permet d'identifier et de suivre un interchange EDI pendant les différents processus de traitement. Le message est gardé avec son Identifiant dans la base Oracle.

Etape 2. Le système authentifie le message en utilisant les informations relatives à :
-l'émetteur,
-le récepteur,
-le type de document.

Etape 3. Le système valide qu'il existe une relation EDI entre l'émetteur et le récepteur. Dans l'affirmative, l'interchange est transmis au Gestionnaire de Services.

Etape 4. Le Gestionnaire sélectionne une Liste de Services prédéfinie pour l'interchange et exécute séquentiellement chaque service dans cette liste.

Par exemple, pour des déclarations de ...., le service gestionnaire de ServiceX pourra définir une liste de services contenant quatre services :

Vérification de la structure du message, en regard du modèle qu'elle est censée appliquer; production de l'information de diagnostic du message (CONTRL); avortement en cas de structure invalide ou poursuite du processus

Traduction,

Génération d'un accusé de réception fonctionnel,

Communication par FTP (ou tout autre moyen à la discrétion du ServiceX) afin d'envoyer les données - convenablement présentées - à une application de traitement des cotisations.

La traduction au sens du système se réfère à une conception étendue de ce terme et non à une simple trans-formation de nature exclusivement syntaxique. Elle comportera donc en fait des services complets permettant de suivre la progression des messages, de bout en bout, jusqu'à leur prise en compte par les applications, sans oublier l'information en retour vers les émetteurs de messages.

Certains services seront proposés systématiquement, notamment pour garantir la bonne suite des opérations de bout en bout. Ce sera, en particulier le cas des services générant la notification des messages (voir à ce sujet les développements relatifs à la sécurité) qui assure au récepteur qu'un message a été reçu et les acquittements.

L'administrateur pourra également créer des services personnalisés: par exemple un service de décompression, un service de groupement de messages en fichiers, un traitement de fichiers avant de les transmettre aux applications finales, etc.

Le messages sortants sont simplement produits, puis émis, en recourant aux services des dispositifs de communication électronique auxquels on se référera.

Le Gestionnaire de Services supervisera chaque processus pour s'assurer qu'il est bien exécuté. Si un processus n'est pas exécuté correctement, le Gestionnaire prendra à sa charge plusieurs relances. Après plusieurs tentatives infructrueuses, le Gestionnaire enverra un message (alerte) au module d'administration.

Le service de Gestion de Documents contiendra :
- La sauvegarde des documents ou messages,
- Le traçage d'activités, avec l'aide du support de la base de données relationnelle Oracle 7.

Quand un message sera authentifié, le système lui assignera un Identifiant de traçage. Ceci permettra d'identifier et de suivre un interchange EDI pendant les différents processus de son traitement.

L'interchange sera gardé avec son Identifiant dans la base Oracle. Ceci garantira une prise en charge complète entre la réception du message et la remise de l'interchange à une application.

Le système gérera le cycle de vie complet d'un message.

Un module de Sauvegarde de documents/messages permettra à une application de faire prendre en charge la sauvegarde de ses données.

Chaque entité gestionnaire sera en mesure de suivre tous les processus la concernant, notamment les réconciliations (appariement message émis/message CONTRL correspondant), les générations de notifications_ et les accusés de réception.

En matière de gestion des documents/messages, les critères de recherche pourront être très détaillés.

Par exemple, les utilisateurs pourront chercher des accusés de réception, des erreurs de transformation combinés avec des critères de dates, de partenaire.

Certaines catégories d'information seront dans la base ORACLE, telles que :
- Les informations système configurant les processus,
- Les informations sur les utilisateurs du système et sur leurs droits pour contrôler l'accès,
- La définition des partenaires,
- Les statuts des messages et des événements.

Les messages ne seront pas stockés dans la base. Ils seront écrits dans certains répertoires (UNIX).

Le traducteur (au sens strict) inscrit dans le système est un outil de transformation de données, capable de répondre à presque tous les besoins de transformation.

L'outil sait traiter les messages EDIFACT, GENCOD, INOVERT et les autres standards publics. Il est également possible de transformer vers des formes qui peuvent être traitées par des applications (tables SQL, fichiers COBOLS, tableurs, etc.).

Des programmes de transformées (dits mapping) peuvent être pré-chargés en mémoire pour améliorer la performance. Ils peuvent également être exécutés en plusieurs processus.

Le système disposera d'un Programmateur de tâches qui offrira une alternative à l'envoi de données immédiat et permettra de lisser les trafics, donc autorisera à puissance de traitement identique un écoulement de trafic plus important.

Par exemple, un utilisateur (ou une application) voulant accéder à sa boîte de courrier chaque heure pour envoyer et recevoir des messages pourra le faire. En ce qui concerne les messages non urgents, ils pourront être traités en procédure différée. Au contraire, les messages urgents pourront être traités en priorité. Le programmateur pourra également être utilisé pour des tâches de maintenance comme l'archivage, les purges.

L'accès au programmateur sera assuré depuis le module d'administration du système.

On notera que les systèmes clients, installés sur leurs sites, auront les mêmes capacités de programmation des émissions-réceptions.

Avec le système, chaque utilisateur du ServiceX et chaque partenaire sera un membre d'une communauté de commerce électronique.

Des Types de membres détermineront les privilèges de chaque utilisateur, qui appartiendra à l'un des types prédéterminés.

L'administrateur système aura accès à tous les composants du système.

En revanche, un membre de base ne peut accéder qu'à des informations qui le concernent. De même, un membre de base ne peut pas créer de nouveaux membres, de relations entre partenaires, de certificats ou de services.

L'administrateur assignera à chaque membre un Identifiant unique, un mot de passe et un Type de membre.

Chaque membre peut être défini comme émetteur et/ou récepteur dans une relation EDI.

Le système utilisera les technologies de sécurité suivantes :
- X.509 v3 (certificats),
- intéropérabilité avec EDIINT (cf ci-dessus INTERNET IETF),
- S/MIME pour le cryptage et l'authentification (en France - pour l'instant - SMIME S/MIME est autorisé pour signer les messages électroniques mais ne l'est pas pour crypter; les décrets libérant ce dernier usage permettront d'étendre l'emploi de S/MIME),
- La mise à disposition/notification pour les reçus signés,
-Secure Socket Layer pour la communication entre le navigateur et le serveur (en France 40 bits autorisés pour l'instant),
-Nom d'utilisateur et mot de passe pour accéder au système d'administration.

La suite de ce chapitre présente et décrit les technologies mises en oeuvre dans le cadre de la sécurisation.

Sur Internet, l'information transite généralement par plusieurs ordinateurs. D'un point de vue technique, il est réalisable d'intercepter une communication, voire même de substituer un message à un autre. Des fonctions visant à sécuriser les communications ont pour cette raison été adjointes aux technologies standards de l'Internet. Les caractéristiques d'une communication sécurisée sont :

L'authentification,

La confidentialité,

L'intégrité.

L'authentification garantit que la personne ou le site contacté est bien celui ou celle auquel on croît avoir affaire.

La confidentialité de la transmission interdit à une tierce personne de comprendre l'information transmise.

La vérification de l'intégrité de l'information permet de détecter les tentatives d'altération d'une communication par une tierce partie.

La mise en place d'une communication sécurisée utilise le cryptage des messages. Le cryptage est le processus par lequel un message est transformé dans un format incompréhensible. Le décryptage est le processus permettant de restaurer un message crypté sous sa forme compréhensible.

Cryptographie

La sécurité sur Internet fait appel à deux technologies de cryptage connues sous les noms de cryptage symétrique et de cryptage par clé publique.

Cryptage symétrique

Le cryptage symétrique est utilisé depuis longtemps, le code César pouvant être assimilé à ce système. Dans cette méthode, on utilise une chaîne de caractères de longueur fixe (40 bits pour RC4, 56 bits pour DES, etc.) qui va être appliquée à chaque message en clair suivant une fonction mathématique plus ou moins complexe. Le résultat est un message crypté qui pourra être décrypté en appliquant la fonction mathématique inverse avec la même clef. Cette méthode de cryptage a prouvé son efficacité en termes de rapidité et de résistance à la crypto-analyse. Toutefois, elle présente un problème majeur dans le contexte de l'Internet. L'émetteur et le destinataire doivent chacun posséder la clef, ce qui sous-entend que celle-ci a été transmise à un moment donné. Si elle a été transmise en clair, elle peut avoir été interceptée par une tierce partie ce qui remet complètement en cause la sécurité de la communication.

Cryptage par clef publique

La solution au problème du transport de la clef a été donnée par le cryptage par clef publique.

Dans ce système, le cryptage/décryptage est fait par deux clefs : la clef privée et la clef publique. Un message crypté par l'une de ces deux clefs ne peut être décrypté que par l'autre clef. Chaque individu possède une clef publique et une clef privée :

la clef publique est mise à disposition de toute personne voulant crypter un message à destination d'un individu,

la clef privée n'est accessible que par l'individu et réside physiquement sur une machine donnée. Elle est utilisée notamment pour décrypter les messages qui ont été cryptés par la clef publique.

RSA est l'algorithme le plus couramment utilisé dans le cryptage par clef publique.

Confidentialité d'une communication

La confidentialité d'une communication sera établie de la façon suivante :

A veut établir une communication sécurisée avec B,

B envoie sa clef publique à A,

A génère une clef symétrique,

A crypte la clef symétrique générée avec la clef publique de B et envoie le tout à B,

B décrypte le message et obtient la clef symétrique.

En suivant ces étapes, il a été possible de transmettre une clef symétrique de A vers B sans qu'elle puisse être décodée par une tierce personne.

En théorie, il serait possible de gérer la confidentialité d'une communication sur Internet uniquement avec la technologie Clef publique. En pratique le cryptage par clef publique est beaucoup moins efficace que le cryptage symétrique  et il est donc plus réaliste de combiner les deux technologies.

Authentification

Le cryptage par clef publique permet également de traiter le problème de l'authentification. Supposons que A veuille prouver son identité. Il lui suffit de crypter un message avec sa clef privée. Lorsque B décrypte le message, il retrouve le message en clair. Un message généré par toute autre personne que A n'aurait pas été décryptable par la clef publique de A.

En réalité cette méthode d'authentification, connue sous le nom de signature, prouve seulement que l'émetteur possède la clef privée qui correspond à la clef publique que B utilise. Il ne prouve pas que l'émetteur est vraiment A. Un imposteur C pourrait très bien prétendre être A et communiquer avec B en utilisant son propre jeu de clef publique/privée.

Certificats

Il faut donc un moyen de lier la clef publique d'un individu à son identité. Les certificats répondent à ce problème. Un certificat est un document électronique infalsifiable et lisible par tous où figure entre autres, le nom de l'individu ou de l'organisation, et sa clef publique. Le certificat a été généré par une autorité de certification (CA) par la procédure suivante :

l'utilisateur ou le serveur souhaitant obtenir un certificat génère un couple clef publique/clef privée sur son poste local,

il transmet sa clef publique et son identité à l'autorité de certification ainsi que d'autres caractéristiques,

l'autorité de certification valide l'information, i.e. elle doit vérifier que la personne est vraiment qui elle prétend être,

l'autorité de certification transmet le certificat à l'individu.

Deux types de certificats sont utilisés par les applications Internet :

les certificats clients sont délivrés aux utilisateurs et garantissent leur identité,

les certificats serveurs certifient l'identité et la clef publique d'un serveur.

Pour établir une communication sécurisée entre un client A et un serveur B il est obligatoire d'avoir généré un jeu de clef public/privée sur le serveur et d'avoir demandé un certificat. En revanche il n'est pas indispensable d'avoir généré un couple clef publique/clef privée sur le poste client.

Le certificat client permet d'authentifier un utilisateur d'une manière plus puissante qu'un simple mot de passe.

En envoyant son certificat signé (par sa clef privée), l'utilisateur prouve son identité.

Intégrité

L'authentification de l'émetteur et l'intégrité d'un message seront vérifiées par la technique de signature digitale :

L'émetteur appliquera à son message une fonction de hash pour générer un message condensé (128 bits avec MD5, 160 bits avec SHA),

L'émetteur cryptera le message condensé avec sa clef privée,

L'émetteur enverra le message et le condensé crypté au destinataire,

Le destinataire décryptera le message condensé,

Le destinataire appliquera la même fonction de hash au message et compare le résultat au message condensé,

Si le résultat est identique, le destinataire saura que le message a bien été envoyé par l'émetteur présumé et que le message n'a pas été altéré durant la transmission.

Les techniques de cryptographie décrites ci-dessus constituent une panoplie de fonctions qui seront utilisées dans les différentes implémentations de la sécurité sur Internet. Il est important de comprendre qu'il n'existe pas une implémentation universelle de la communication sécurisée. Par exemple, SSL et SET (secure electronic transactions - système de paiement électronique spécifié conjointement par VISA et MASTERCARD) sont deux protocoles permettant de sécuriser les communications, chacun utilisant à sa manière tout ou partie des techniques décrites.

Les solutions proposées utiliseront deux services Internet fondamentaux  qui sont le WEB et la messagerie, tous deux sécurisés.

Le protocole SSL

SSL est un protocole de bas niveau agissant au dessus de la couche TCP/IP et offrant un ensemble de primitives permettant d'établir des communications sécurisées. SSL est le fondement des protocoles sécurisés HTTPS, NNTPS et LDAPS.

SSL génère un surcoût d'environ 15% par rapport à une communication non sécurisée.

Sécurisation du Web

HTTPS est la version sécurisée de HTTP, largement adoptée par la communauté Internet. HTTPS est fondé sur le protocole SSL (Secure Socket Layers actuellement en version 3.0).

HTTPS répond au problème de la sécurisation d'un site Web. La mise en place d'un site Web sécurisé au protocole HTTPS nécessite :

Coté serveur

Installation d'un serveur Web supportant SSL,

l'obtention d'un certificat.

Côté client

un navigateur supportant SSL.

Ayant satisfait ces prérequis, il devient possible à tout navigateur supportant SSL de se connecter au site mis en place. Typiquement, l'établissement d'une session sécurisée comprendra les étapes suivantes :

Le navigateur contacte le serveur,

Le serveur renvoie son certificat signé,

L'utilisateur vérifie la validité du certificat. Il compare notamment le nom du serveur indiqué dans le certificat avec le nom du serveur auquel il essaie d'accéder,

L'utilisateur génère une clef symétrique qui sera utilisée dans la suite des échanges.

Dans ce processus, seul le serveur est authentifié, ceci garantissant au client qu'il dialogue avec le bon serveur.

Le système développé s'appuiera sur les mécanismes décrits ci-dessus et permettra également d'utiliser des certificats clients. Cette configuration spécifique du serveur forcera tout utilisateur se connectant au serveur à présenter un certificat, où figurera la clef publique de l'utilisateur et son identité. Ayant récupéré l'identité de l'utilisateur, le serveur en déduira, dans sa base de données locale, les droits d'accès qui lui sont associés. Il est à noter que l'utilisation de certificats clients réduira considérablement le nombre de saisie de mots de passe pour les utilisateurs, ceux-ci n'ayant plus qu'à s'authentifier une fois sur leur poste pour l'accès aux services de l'Intranet. On notera toutefois que les login d'accès aux applications restent aussi possibles.

L'utilisation des certificats clients est particulièrement bien adaptée à un Extranet avec des utilisateurs sédentaires.

Actuellement, l'obtention de certificats nécessite de s'adresser à une autorité de certification tierce telle que Verisign. Ce système est bien adapté aux certificats serveurs mais pose des problèmes pour la délivrance de certificats clients.

Le système développé permettra à la CDC de délivrer ses propres certificats tant clients que serveurs. Ce produit permettra donc de générer des certificats clients portant l'estampille de la CDC.

Comme l'interface d'administration du système sera basée sur un applet Java, SSL pourra être utilisé pour sécuriser le lien HTTP entre le client administration et le serveur. Pour garantir un accès contrôlé le système demandera un login ID et un mot de passe pour accéder au système.

S/MIME

RSA's spécification de S/MIME est devenu le standard pour crypter et signer (de façon numérique) les messages sur Internet. Le système supportera S/MIME conformément aux recommandations de l'IETF EDI work group, EDIINT.

Actuellement en France, S/MIME n'est pas autorisé pour crypter des messages. Il est autorisé par contre pour signer ses messages. Si le cryptage des messages est nécessaire une dérogation devra être demandée auprès du SCSSI, à moins que les décisions prochaines ne le rendent superflu.

Notification et mise à disposition des messages

EDIINT à également défini comment utiliser un nouveau standard IETF, les Message Disposition Notification (MDN), pour retourner des reçus signés. Les MDN permettent aux partenaires EDI d'avoir des échanges qui ne peuvent pas être répudiés.

Tous les processus du système seront multiprocessus et pourront être distribués sur plusieurs plates-formes.

La solution pourra être déployée sur plusieurs environnements, station de travail NT, sachant que le développement ici prévu sera effectué sur une plate-forme UNIX, multiprocesseur.

En résumé, les atouts majeurs de cette solution sont :
- Une solution ouverte qui privilégie les services Internet/Intranet,
- Une solution complètement intégrée sur le même matériel,
- Une solution évolutive (services WEB publics, commerce électronique, pleinement conforme aux orientations que le gouvernement préconise pour les collectivités locales et hospitalières...),
- Une solution fondée sur des normes ou standards disponibles dans le domaine public (CORBA, JAVA, ACTIVE X, DCOM...),
- Une solution intégrée et structurante permettant la mise en place d'une Base extensible (ressources et/ou services)

6. Les modalités de réalisation

Le présent projet vise à jeter les bases d'un système de commerce électronique à l'usage desentreprises et des administrations.

Mettant en œuvre la gestion électronique de procédures relatives à la déclaration de.... provenant des entités mentionnées ci-dessus, le système et les services qu'il permettra d'assurer reposeront sur l'usage de moyens de traitements informatiques et de télécommunications susceptibles d'être fonctionnellement étendus.

L'extension des fonctionnalités du système en vue de proposer à ses utilisateurs une prestation de service de commerce électronique généralisée pourra se faire en déclinant les axes de communication suivant la cartographie des flux émis et reçus par les différentes catégories d'utilisateurs. Cette extension aura pour effet d'accroître le nombre de partenaires impliqués. Elle aura également pour conséquence la nécessité de bâtir des passerelles avec des systèmes de commerce électronique existants.

L'ensemble des moyens à mettre en place et des étapes de réalisation sont listés ci-dessous.

Gestion du projet (Programmation des tâches, affectation des moyens, suivi de la progression des développements)

Gestion du processus de concertation avec les futurs utilisateurs,

Gestion des relations avec des tiers partenaires, notamment avec les éditeurs de logiciels fournissant les PME/PMI

Résolution des difficultés rencontrées,

Suivi de la qualité

Etude de l'environnement, des flux gérés, de la base installée, inscription dans le cadre du nouveau système, chemin de migration,

Détermination définitive des développements constituant le cœur du bouquet de services, afin que le système puisse ensuite décliner ses axes de communication complémentaires,

Programmation des tâches en vue de constituer le noyau du système

Spécifications du système

Installation des matériels (serveur de commerce électronique)

Intégration des composants logiciels du système

Développements complémentaires, personnalisation des logiciels, paramétrages,

Développement des interfaces avec les applications du ServiceX

Spécification des services de télécommunication, qualification des offreurs de services,

Définition des modalités de qualification du système

Qualification du système

Plan de déploiement

Plan de communication (marketing)

Mise en place d'un dispositif de qualification des éditeurs de logiciels

Mise en place d'un dispositif de formation des utilisateurs

Plan d'assurance de la qualité

Architecture du système

Spécifications définitives du système et des services qu'il assurera

Supports graphiques de présentation de l'offre

Dossiers de tests

Solutions "clientes" et documentations de celles-ci (API, Cahiers des charges pour les éditeurs de logiciels)

Formations

Assistance aux utilisateurs (garanties de disponibilité)

Maintenance du système

Le processus de développement mettra en œuvre une démarche de perfectionnement actif, les réalisations initiales ayant pour objet de qualifier les étapes du développement des différentes composantes de l'offre globale de service.

Les remises initiales reposeront sur des spécifications stabilisées. L'efficacité de la démarche sera ainsi vérifiée, non seulement d'un point de vue technique mais aussi en relation avec les utilisateurs, dont on vérifiera qu'ils accueillent favorablement l'offre de services (facilité de mise en œuvre, coût des services).

Il sera accordé une attention équivalente à la qualification des réalisations initiales au niveau du serveur et au niveau des solutions clientes, celles qui seront installées sur les systèmes des utilisateurs finals des services.

Une fois qualifiée la démarche initiale, et vérifiés les résultats qu'elle produit, étant donné le caractère industriel des développements, il sera alors possible de gérer un processus de développement parallèle des services envisagés.

Au terme des développements faisant l'objet de la présente proposition, il sera avéré :

Que le système satisfait les exigences essentielles de ses différents utilisateurs,

Que les solutions intégrées ont les performances requises, tant du point de vue du confort d'utilisation que du point de vue du rapport coût/efficacité du système et des services qu'il propose,

Que les processus d'intégration des données échangées avec les systèmes de traitement de l'information propres à chaque utilisateur peuvent se développer sans difficultés majeures, en dépit du caractère unique de chaque intégration.

Les phases du développement:

Constitution du noyau de l' offre de service: Etape 1. Spécification détaillée et définition des éléments constituants du noyau

Définition du noyau de l'offre de services

Identification des partenaires initiaux (panel)

Définition des moyens matériels et logiciels devant être intégrés

Architecture réseau, exigences attendues des fournisseurs de solutions de télécommunications

Définition des guides d'implémentation des messages

Planification des tâches

Dossier des spécifications définitives

Plan de développement Etape 2 : Procédure de tests

Cahier des charges des tests

Paramétrage des outils de tests (serveur et clients

Mise en place d'une procédure de qualification des éditeurs de logiciels à l'aide des outils précédents_Dossier de qualification

Outils d'autotests (préqualification) livrés aux éditeurs de logiciels

Etape 3 : Intégration du système (des services) avec les systèmes existants (utilisateurs, réseaux, applicationsdu ServiceX

Installation des différents éléments de l'offre de services (matériels, logiciels, réseaux)

Paramétrages, développements complémentaires

Scénarios de qualification. Choix des moyens matériels et logiciels.

Etape 4 : Qualification du système et des services

Tests de qualification

Bilan: Bilans des tests de qualification

Labellisation des logiciels

Etape 5 : Plan de déploiement des services

Axes de développement proposés

Evaluation de la charge en vue de généraliser l'offre

Proposition d'un plan de déploiement

Rapport final et plan de déploiement

7. Environnement logistique

La plate-forme matérielle nécessaire (UNIX) en vue de mener à bien les travaux faisant l'objet de la proposition est fournie. Les systèmes intégrés sur cette plate-forme seront portables dans d'autres environnements UNIX ou NT. Les performances de la plate-forme seront suffisantes pour créer le noyau de l'offre de services. Elles ne permettront pas d'effectuer le déploiement de l'offre. Toutefois, le déploiement de l'offre ne dépendra que d'une augmentation des performances des métériels et des moyens de communication et n'affectera pas le comportement des logiciels.

Les outils de tests seront fournis aux éditeurs de logiciels. Les outils de tests seront différents selon qu'il s'agira de tester les applications internes du ServiceX, le serveur, les solutions clientes. Seuls les outils de tests du serveur font l'objet de la présente proposition. Les outils de tests à mettre à disposition des éditeurs de logiciels feront l'objet de devis, sachant que le coût que devront supporter les éditeurs sera modéré (de l'ordre de quelques milliers de francs).

Les outils de tests se borneront à vérifier que les logiciels sont capables d'émettre et recevoir des messages normalisés. En aucune façon ils ne contribueront à qualifier l'ergonomie et les performances des logiciels qualifiés du seul point de vue de leur aptitude à s'interfacer avec l'offre de services du ServiceX

8. Estimation des charges

10. Proposition financière et conditions associées

Le montant des prestations est de 600 000 F.H.T.  (ce montant n'a qu'un intérêt indicatif, faute de produire ici les quantifications du projet)

Le ServiceX aura la pleine propriété des logiciels développés.Il aura donc la faculté de récupérer l'ensemble des développements effectués. Le ServiceX fera son affaire de l'acquisition d'une plate-forme en cas de reprise des développements effectués. Il en ira de même en ce qui concerne les composants logiciels intégrés.

Le noyau du bouquet de services devra être réalisé avant la fin de l'année 1998, pourvu que le contrat soit accepté avant le fin du mois de février 1998. En cas d'acceptation postérieure, le délai de réalisation sera repoussé du nombre de mois séparant la fin du mois de février de la date de signature du contrat.


retour au sommaire du rapport