L'administration communicante. Rapport sur l'Echange de Données dans l'Administration (EDI) Rémi MARCHAND - Novembre 1996

Fiches techniques

Guides d'Application de messages EDI

La normalisation des messages EDIFACT fait souvent l'objet d'appréciations mitigées dont il est intéressant de comprendre les raisons, d'autant plus qu'elles n'émanent pas nécessairement d'experts ayant un intérêt commercial ou industriel à inciter leurs partenaires à refuser l'utilisation de messages EDIFACT normalisés dans un système de commerce (relations) électroniques.

L'ambition ultime, et parfois émouvante, des développeurs de messages EDIFACT est de concevoir des messages ayant le champ d'application le plus vaste : le monde entier.

Dans un certain nombre de circonstances, ce résultat peut être obtenu. C'est notamment le cas dans les activités de commerce mondial, dont la recherche de simplifications a été à l'origine même des travaux sur la norme mondiale EDIFACT.

Aucune administration douanière d'un quelconque pays n'envisagerait de faire un choix qui ne soit celui d'EDIFACT.

Lorsqu'un message est normalisé au niveau mondial, il reçoit le statut de d'UNSM, acronyme signifiant : United Nations Standard Message c'est à dire Message Normalisé des Nations Unies.

Deux cas de figure peuvent se présenter :

• le message ainsi défini correspond à une activité fortement réglementée au niveau mondial. Dans ce cas, il peut y avoir un accord quasi complet et universel sur la configuration d'un message dans ses moindres détails et pour la codifications de toutes les données élémentaires. Seules quelques modifications - aisées à concevoir - doivent être prises en considération dans chaque pays, comme celles relatives à la représentation des adresses, à la numérotation minéralogique des véhicules, à l'identification des agents économiques.

• le message correspond à une activité qui est exercée dans tous les pays du monde, et dans un grand nombre de secteurs de l'économie; toutefois si un accord peut être trouvé sur une structure ou une configuration de message, les usages concrets d'un tel message devront tenir compte de variations locales, régionales (continentales) ou nationales, ainsi que de variations sectorielles.

C'est dans les activités commerciales qu'il est le plus facile d'illustrer le type de variations qui sont nécessaires dans le deuxième cas.

Prenons l'exemple d'une commande (le message ORDERS).

On dispose d'une norme de message EDIFACT Commande ayant le statut de UNSM.

L'accord qui a pu être obtenu sur ce message l'a été à l'issue d'un long processus qui a permis de confronter les configurations de commandes du plus grand nombre de pays et de secteurs d'activités. Le résultat obtenu à la fin du processus de normalisation s'apparente à un plus petit commun multiple de ce que chaque utilisateur était en droit de trouver dans un tel message pour qu'il satisfasse ses propres besoins, condition sine qua non de son acceptation d'utiliser le message EDIFACT/UNSM.

Les normalisateurs s'accordent assez facilement sur un certain nombre de données devant impérativement figurer dans un message tel qu'une facture. Ces données se voient alors conférer la caractéristique de donnée obligatoire. Les autres données, insérées pour satisfaire des besoins particuliers, ne sont pas obligatoires, au moins pas obligatoires pour tous les utilisateurs.

En définitive, les messages UNSM résultent d'un consensus qui est extrêmement précieux en ce sens qu'il permet de disposer d'un modèle, d'un patron de message, à partir duquel il est possible de définir exactement la réalisation particulière de ce message-type dont on a besoin, en ayant la certitude que le résultat obtenu sera robuste et que rien d'utile n'aura été oublié.

C'est l'action d'adaptation d'un message UNSM à un usage précis pour un système de commerce électronique opérationnel qui conduit à définir un guide d'application de message, notion qu'il est impératif de ne pas confondre avec celle de message, malgré le fait que le guide soit déduit du message.

Aux Etats-Unis, on distingue ainsi un message UNSM (transaction set) et une convention d'application ( "Implementation convention" synonyme de Guide d'application, terme que l'on préférera à celui de guide d'implementation).

Signalons au passage qu'un autre avantage de la normalisation EDIFACT est que les messages ainsi développés peuvent être introduits sous forme de paramètres dans un traducteur ou gestionnaire de transactions qui peut être acheté "sur étagères" auprès d'éditeurs de logiciels. La programmation de tels logiciels est très rapide, et le développement d'interfaces avec les applications qu'un programme de commerce électronique vise à rendre communicantes est grandement facilité par l'existence de modules de génération de "transformées" ou "mappers", qui sont de véritables ateliers de génie logiciel.

C'est au niveau des enveloppes et des premiers éléments de données des messages que la normalisation a permis de passer :

• d'un stade artisanal de la communication électronique, recommencée à partir de presque rien pour chaque projet,
• à un stade industriel, les projets des différents secteurs ayant recours à une configuration type des enveloppes de message identique pour le commerce, le transport la banque, l'assurance, la justice, la santé, utilisable avec des logiciels achetés clés en mains et adaptés aux besoins (et aux budgets) les plus divers : celui d'une PME ou d'une profession libérale aussi bien que celui d'une multinationale.

Mais revenons à la nuance d'importance qui existe entre message et guide d'application et à son illustration dans le cas des messages commerciaux.

La facture UNSM est donc, en quelque sorte, le plus petit commun multiple de toutes les factures de tous les secteurs d'activité du monde entier. En tant que telle, elle a pu recueillir le consensus qui lui a permis d'accéder au stade d'UNSM. Malheureusement cette facture est inutilisable en l'état pour deux raisons :

• elle est trop complexe, comportant des informations utiles aux uns mais pas aux autres et réciproquement,
• elle est trop floue, les informations étant définies sur une base consensuelle. Par exemple, dans une adresse on trouvera un code postal, mais le message UNSM ne peut bien entendu que constater les innombrables variations nationales de la représentation d'un code postal et ce qui figure dans les messages à ce sujet est bien imprécis.

Au contraire, un guide d'application peut être et même doit être extrêmement précis.

Le passage d'un message UNSM à un guide d'application s'opère par un double mouvement :

• simplification du message UNSM, dont on élague tout ce qui n'est pas nécessaire de mentionner pour les factures utilisées dans un contexte particulier,
• introduction de définitions très précises de chaque donnée, et notamment pour chaque donnée des valeurs qu'elle est susceptible de prendre par rapport à un code.

Le passage d'un message UNSM à un guide d'application peut s'opérer en deux temps. C'est ce qui s'est produit dans le cas de l'organisation européenne EAN, qui gère le système de codes à barres du même nom.

Partant des messages commerciaux UNSM (commande, facture, avis d'expédition, information sur un partenaire, rapport de ventes etc..), EAN en a produit une version simplifiée et adaptée au secteurs de la distribution. Le jeu de messages ainsi produits est connu sous le nom de messages EANCOM. Il a été traduit dans toutes les langues européennes, et notamment en français avec le concours de l'organisation correspondante de GENCOD en France.

Toutefois, les messages EANCOM, dans leur version française restent insuffisamment précis pour constituer des guides d'application au sens où nous l'entendons.

En effet, si l'on examine l'adresse postale, on trouvera :

l'absence de distinction d'un champ numéro de rue séparé, et

la donnée 3229 identification de la division territoriale : Comté

la donnée 3251 Code postal : donnée alpha numérique au plus égale à 9 caractères.

N'importe quelle informaticien ayant défini des structures de fichiers échangés avec des partenaires, et au sein de celles-ci des adresses, a eu le souci de mieux définir ses données, pour mieux les créer, les contrôler, bref pour assurer la qualité de l'information sans laquelle l'informatique perd une partie de sa rigueur.

Des mécomptes importants ont résulté de guides d'application mal faits; la norme EDIFACT a été, pour ce motif, l'objet de critiques injustifiées.

On ne saurait trop recommander la rigueur dans la définition des guides d'application.

Ceux-ci ne doivent pas seulement comporter des données définies avec précision.

Ils doivent aussi donner toutes les précisions nécessaires aux développeurs d'applications communicantes.

Quelles indications autres que la plus grande précision pour chaque donnée doit-on trouver ?

Brièvement, on recommande :

• des notes explicatives, recommandant - lorsque des choix alternatifs sont possibles dans l'organisation propre à un partenaire - des usages qui se sont avérés efficaces,
• des notes syntaxiques , qui donnent des indications sur la cohérence interne d'occurrences singulières de messages.
• des notes sémantiques, qui précisent le sens d'une définition de donnée dans différentes situations,
• des commentaires ou conseils.

Hélas, il n'a pas été possible, en France de convenir d'un formalisme unique pour décrire les guides d'application de messages. C'est regrettable. On recommandera qu'au moins tous les guides d'application de messages utilisés par les administrations françaises et leurs partenaires soient alignés sur un formalisme strictement unique, ce qui favorisera une compréhension mutuelle. Tous les guides d'application - publics et privés, sectoriels ou intersectoriels - sont identiques aux Etats-Unis, et les utilisateurs s'en réjouissent d'autant plus que cela permet de générer ces guides à l'aide d'automates logiciels de documentation et de présentation qui simplifient considérablement la tâche des concepteurs en amont, celle des informaticiens programment les applications en aval.

Une dernière remarque reste à faire.

La forme des guides d'application de messages qui vient d'être décrite, pour être rigoureuse, n'en reste pas moins littéraire.

Des travaux ont été entrepris pour définir une notation formelle des contraintes décrites dans les guides d'application de messages.

Certes, il ne s'agit encore que de voies de recherche. Mais elles sont suffisamment explorées pour démontrer qu'il est possible de développer un langage formel d'écriture des contraintes de complétude et de cohérence interne des messages.

Comprenant :

des opérateurs de comparaison : =, non =, <, >, > ou =, etc ..

des opérateurs arithmétiques : +, -, *, /,

des opérateurs logiques : & (et), (ou),

des opérateurs conditionnels :

des références de dates

des opérateurs d'itération

des appels de fonctions,

une telle notation formelle présenterait l'avantage considérable :

• de permettre vérifier la qualité intrinsèque de chaque messages émis ou reçus,
• et de programmer automatiquement les gestionnaires de messages EDI capables d'interpréter cette notation.

Il serait bien étonnant que le marché n'offre pas assez rapidement de telles fonctionnalités, qui rendraient les logiciels EDIFACT encore plus attractifs qu'ils ne le sont déjà.

Il serait par ailleurs souhaitable que des laboratoires informatiques portent un intérêt aux travaux de recherche en génie logiciel appliqué aux systèmes de commerce électronique. EDIFRANCE pourrait prendre des initiatives en ce domaine.

Pour plus de détails, on se référera aux travaux du NIST, US Department of Commerce, en n'oubliant pas que des ingénieurs européens ont pris une part significative dans les travaux ci-dessus.

1. A formalized notation for EDI constraints Alex TH. de Jong

2. A standard language for implementation convention, Thèse de A de Jong, sous la conduite de Dr Jean-Philippe Favreau, Chef de programme au NIST.

3. IMPDEF, Implementation definition, message pour véhiculer un guide d'application de message.

Résumé de la fiche :

• Un message UNSM est un message type, un patron, un gabarit de message

• Dans les projets, on n'utilise pas les messages sous leur forme normalisée, qui est trop générique et floue car résultant d'un consensus mondial.

• Les projets utilisent des guides d'application de messages, dont toutes les données doivent être définies avec une extrême précision.

Les guides d'application sont déduits des messages normalisés, mais ils sont plus simples et plus précis.

Des notes syntaxiques et sémantiques doivent déterminer les conditions de complétude et de cohérence interne de chaque occurrence (réalisation concrète) de message.

• Des projets EDI ont été compromis car les guides sur lesquels ils s'appuyaient étaient mal rédigés.

• Une notation formelle des guides d'application de messages EDIFACT est envisageable.

• La normalisation des enveloppes de messages est identique pour tous les messages EDIFACT. Combinée avec la syntaxe EDIFACT, cela a rendu possible le développement de solutions performantes, variées, peu coûteuses.

• EDIFACT permet de réaliser des systèmes de commerce électronique de façon industrielle et non plus artisanale.

Fiches techniques

Procédures de certification

des opérateurs de réseaux ou de services à valeur ajoutée EDI

Préambule

Le développement des téléprocédures entre les citoyens et les entreprises d'une part, les administrations d'autre part, peut tirer parti de l'existence de systèmes de commerce électronique (RSVA) auxquels des entreprises de toutes tailles sont actuellement reliées.

Le fait d'utiliser ces systèmes existants comporte de nombreux avantages :

• des entreprises les utilisent couramment pour leurs usages quotidiens; elles ont acquis des savoir-faire, une culture de la communication électronique, réalisé des investissements en logiciels, matériels, abonnements à des réseaux de télécommunication; bref les téléprocédures pourront se développer avec ces entreprises pour un coût marginal, presque négligeable,
• les administrations pourront, en peu de temps, trouver un grand nombre de partenaires disposés à pratiquer les télédéclarations, ce qui leur permettra de réaliser des retours sur investissements rapides,
• le soutien des programmes de développement des téléprocédures pourra tirer parti des programmes de commerce électronique courants; les entreprises y trouveront une possibilité de simplifier leurs relations avec les administrations; les opérateurs des services proposeront une prestation supplémentaire; les éditeurs de logiciels seront incités à développer des modules de télédéclarations.

Cependant, les opérateurs de RSVA restent en France majoritairement sectoriels, et leurs offres de services ne sont pas toujours caractérisées par leur ouverture. Au contraire, plusieurs d'entre eux cherchent à préserver des clientèles captives par des artifices ou en ne mettant pas dans le domaine public les spécifications de leurs produits afin de conserver le monopole d'une offre.

Cette situation comporte d'ailleurs des inconvénients majeurs pour des utilisateurs se trouvant aux franges de plusieurs secteurs d'activité, qui doivent, parfois se doter de plusieurs stations de télécommerce alors qu'une seule pourrait suffir si l'interopérabilité des RSVA était garantie.

Dans ces conditions, les administrations ne peuvent envisager de tirer parti des bases installées d'entreprises communicantes que sous les conditions suivantes :

• ne conférer de monopole de trafic de téléprocédures à aucun opérateur,
• définir des spécifications de service universelles, devant être satisfaites par tous les opérateurs et vérifiées par un laboratoire d'essais,
• proposer des voies alternatives à celles des RSVA, afin que les entreprises voulant se rallier aux procédures de télédéclarations ne soient pas contraintes de le faire par l'intermédiaire de leur opérateur sectoriel, même si elles sont obligées d'utiliser celui-ci pour d'autres liaisons commerciales électroniques, imposées celles-ci,
• développer des spécifications des passerelles des différentes administrations qui garantissent que les solutions pratiquées avec une administration seront utilisables pour toute administration, à l'exception de ce que chaque administration pourra justifier de spécifique (messages déclaratifs essentiellement, les services de sécurité étant définis par un profil particulier parmi un jeu de services génériques).

Bien qu'il ne soit pas dans le rôle de l'administration de susciter l'émergence d'un opérateur privé de télédéclarations administratives, et encore moins de créer - sous quelque forme que ce soit - une nouvelle administration à laquelle serait sous-traitée la gestion des procédures de télédéclarations, chacune d'entre elles ayant un intérêt évident à installer ses propres passerelles de communication administratives, il pourrait néanmoins être envisagé, afin de préserver la plus grande liberté de choix des entreprises, de créer un point d'entrée indépendant de tout opérateur, auquel pourraient se connecter les entreprises ne trouvant pas d'autre moyen d'accéder aux plates-formes des administrations.

Outre les avantages précités, un processus de certification des opérateurs de RSVA, les rendant aptes à drainer les télédéclarations vers les administrations, aurait l'avantage d'introduire une plus grande interopérabilité entre les différents opérateurs, une plus grande concurrence dans l'offre de services, bref un meilleur service aux entreprises et aux administrations.

Le programme de certification d'un RSVA pourrait reposer sur les principes suivants :

1. Visite des sites

Revue des listes de spécifications et autres données nécessaires pour établir les connexions expérimentales. Vérification de l'état de préparation des équipes chargées des tests.

2. Tests de connectivité

Un site type de l'administration sera mis en relation avec le(s) site(s) du postulant. Il servira à vérifier la capacité à télécommuniquer et à mesurer les performances.

2.1. Tests de connexion simple

2.2. Tests dynamiques en mode émulation comportant une vérification des fonctionnalités obligatoires et de la batterie de celles qui sont proposées en option.

2.3. tests en mode réel, pour vérifier que le postulant ne perturbe pas le fonctionnement des sites de l'administration et l'infrastructure globale.

3. Tests d'aptitude à la traduction

Ces tests n'ont lieu d'être exécutés que si le postulant propose des services de traduction. Dans ce cas, les tests d'aptitude à émettre et recevoir des messages conformes aux guides d'application officiels seront passés.

4. Tests en conditions de production

Tests de capacité à émettre, router, stocker les fichiers reçus de l'administration, à faire rapport des incidents en temps voulu, à détecter les pertes de messages, à relancer les opérations, à stocker les informations pendant le temps requis pour assurer un fonctionnement continu et fiable.

5. Mise à niveau des services de l'administration pour que la mise en opérations devienne effective.

Services EDI exigés des RSVA postulant à la certification

• Fournir à l'administration une boite à lettres, les logiciels et les moyens de communication nécessaires pour superviser les tests, (hors matériels)
• Prévoir un stockage des données destinées à l'administration pour une durée de 5 jours ouvrés,
• Log et mot de passe,
• Fournir à l'administration une boite à lettre de type partenaire, afin qu'elle puisse simuler le rôle d'un partenaire privé du RSVA; fourniture de la documentation technique livrée couramment aux clients du RSVA,
• Etre capable de supporter les guides d'application de messages officiels; des tests seront passés pour chacun d'eux.
• Supporter les protocoles suivants : FTP sur TCP/IP; SMTP INTERNET RFC 822 chaque message EDI étant dans une enveloppe distincte, Protocole TEDECO X 400 et X 435 en fonction des souhaits de l'administration,
• Accusés de réception par le VAN, de remise (ouverture) au destinataire, excepté pour les messages à distribution universelle ou collective (un message n destinataires),
• Connexions de l'administration aux frais du RSVA,
• Charges liées à l'établissement et à l'entretien des connexions à la charge du RSVA,
• Accès permanent de l'administration aux locaux du RSVA à des fins d'inspection,
• Doubles connexions pour garantir un fonctionnement permanent,
• Sites de récupération (back up),
• Spécification des vitesses de transmission circuits dédiés V35, 56 000 bauds,
• Spécifications INTERNET DOD,

Concernant les clients des RSVA

• les informer de la politique de l'administration, vérifier qu'ils interprètent convenablement les informations et contrats,
• les enregistrer selon les méthodes prévues, notifier électroniquement l'existence d'un nouveau partenaire( message PARTIN), notifier au partenaire l'acceptation de l'administration,

Concernant le RSVA lui même

• responsabilité sur les données, ne pas envoyer un message reçu erroné, altéré durant la transmission,
• heures d'ouverture 7 jours sur 7, 22 h / jour (2 heures pour la maintenance,
• conditions de sauvegarde et restauration assurant une reprise sans pertes de données,
• rapports de tous incidents sous une heure après la détection, incluant les données permettant de diagnostiquer l'incident,
• contrôle de qualité,
• protection des données administrative, technique et physique,
• niveaux de sécurité requis pour les accès au système, aux bases de données, aux Boites à lettres,
• prévention des pertes, des altérations d'information, de la divulgation de données.
• procédures de relance du système en cas de sinistre majeur sur un site alternatif

Opérations EDI

• à définir dans chaque cas particulier,
• messages, accusés de réception, etc..

Fiches techniques

Proposition de création d'un site de certification de partenaire EDI

Qu'il s'agisse de qualifier un fournisseur de l'administration pour l'inclure dans un système de commerce électronique, un organisme d'assurance pour traiter électroniquement des échanges de messages de facturation hospitalière ou des demandes de prise en charge, une entreprise pour qu'elle effectue des télédéclarations sociales ou fiscales, ou enfin un éditeur de logiciel incorporant un module de télédéclaration dans les applications de gestion de la paye ou de la facturation, dans tous les cas, il est préférable de vérifier avant toute chose que le candidat partenaire satisfait toutes les exigences qui permettent de l'admettre dans le système sans risques qu'il ne le perturbe.

Chaque procédure de qualification sera faite en regard d'un ou de plusieurs guides d'application de message au sens où on l'entend dans la fiche traitant de ce sujet.. Chaque partenaire qualifié pour un échange particulier sera autorisé à pratiquer couramment cet échange et sera dûment enregistré comme tel. Une base de données d'enregistrement des partenaires sera maintenue; elle sera alimentée par un message d'enregistrement - le message PARTIN c.à.d. information sur un partenaire - envoyé à la base. Cette dernière sera consultée par une administration avant qu'elle n'accepte que la mise en opérations d'un échange électronique pour un message et un partenaire ne soit effective. Le centre de certification alimentera cet enregistrement des mentions attestant de la bonne fin des tests de qualification.

Un partenaire enregistré pour un guide d'application déterminé sera autorisé à échanger électroniquement avec toute administration susceptible de recevoir le message correspondant.

Un partenaire désirant échanger un nouveau message devra accomplir de nouveau la procédure de qualification pour ce message.

Dans le cas où un partenaire utilise un logiciel acheté à une société de services ayant elle même fait subir à ce logiciel la procédure de test, la procédure de qualification sera simplifiée : le partenaire n'aura qu'à déclarer quel logiciel qualifié il utilise et pour quel message.

Dans le cas où un partenaire utilise un logiciel fourni par l'administration, il n'y a lieu qu'à procéder à une simple notification, l'administration étant censée avoir qualifié son logiciel avant de le mettre dans le domaine public.

Lors d'une procédure de qualification, tous les éléments d'information susceptibles d'être trouvés dans un message donné seront objet de test, qu'ils soient obligatoires ou optionnels. Il est en effet important d'une part que l'administration s'assure de la capacité de ses partenaires qui auront peut être à lui envoyer une certaine information, non prévue au départ, mais dont l'envoi est autorisé et d'autre part que les tests de qualification puissent être uniques et non à la mesure de chaque partenaire.

Mettre en place un site de certification est indispensable dès lors que le nombre de partenaire peut être important. En vertu du caractère générique de la norme EDIFACT, un site de test est capable de réaliser des tests pour tout guide d'application de message EDIFACT, pourvu que le modèle de ce guide ait été préalablement fourni au site de test.

Méthodologie du plan de tests

Note : Un postulant doit être connecté à un RSVA agréé ou être lui même agréé comme ayant satisfait les mêmes tests qu'un RSVA si le postulant veut établir des connexions directes avec l'administration. (voir la fiche technique sur ce sujet).

Le site de certification enverra à chaque postulant des messages sous la forme de fichiers afin que ledit postulant puisse effectuer ses tests d'aptitude.

Une copie des messages de tests sera disponible soit sur la passerelle de l'administration, soit sur le serveur du RSVA, soit sur un noeud d'accès au réseau de l'administration.

Au cas où une cause externe perturberait le déroulement d'un test, celui-ci serait repris ultérieurement ou recommencé selon la nature de la perturbation.

Evaluation

Un postulant sera certifié lorsqu'il aura été capable d'envoyer :

• trois jeux de messages 100 % conformes consécutivement,
• au cours de sept transmissions au maximum.

Si l'une des deux conditions n'est pas satisfaite, le test sera considéré comme défectueux.

Les motifs d'échec seront notifiés, afin que le postulant puisse effectuer les corrections qui s'imposent. Une nouvelle session de test sera proposée au postulant.

Si une procédure de tests est conclue de façon satisfaisante, le postulant sera notifié comme ayant satisfait aux tests auprès de la base de donnée des partenaires certifiés.

Note : Etant donné que les systèmes de commerce électronique, et dans le cas de déclarations administratives, les systèmes de télédéclarations supposent que non seulement les partenaires de l'administration lui envoient des messages mais aussi que l'administration envoie des messages en réponse à ceux qu'elle a reçus, les procédures de certification s'appliqueront à l'administration ouvrant un service de commerce électronique ou de télédéclaration.

Le site de certification sera doté des logiciels lui permettant d'accomplir les tests énumérés ci-dessus. Ces logiciels seront soit développés par l'administration, un par sous-traitant qu'elle aura qualifié par voie d'appel à propositions à partir d'un cahier des charges, soit achetés clés en mains. Le site de certification sera commun à l'ensemble des administrations.

Fiches techniques

Fonctionnalités d'une plate-forme EDI

Capacités élémentaires

• Support des normes et de leurs versions
• Support des guides d'application
• Type de système d'exploitation dans l'environnement duquel le produit est disponible

Contrôles d'accès

• Procédure de log
• Accessibilité sélective : profil d'utilisateur
• Activités de contrôles simultannées

Communications ( ou interfaces avec des dispositifs de)

• Transferts de fichiers, FTQ
• Messageries (SMTP, X400, X435)
• Connexions à des RSVA
• Connexions directes à des partenaires (dont veille d'appels, modems ..)
• Outils d'écriture de scripts
• Transmissions programmées, automatiques
• Transmissions manuelles
• Audit des communications
• Visualisation des tâches exécutées et de leur résultat, administration des communications

Installation et maintenance

Routines d'installation automatiques

Mise à jour des normes et de leurs versions

Traces (des messages et de leur traitement par les applications, interface données messages/données applications)

Logs

Archivages (ou logs de long terme)

Purges automatiques

Restauration des données et relance du système EDI

Interfaces avec les applications

Interfaces par fichiers intermédiaires

Interface avec des SGBD

Impression de messages

Traitement des formulaires

Retournement de document électronique (production d'un message à partir d'un réarrangement de données d'un autre message)

Formulaires électroniques (génération de )

Expansion de données (invocation à partir d'un code de la donnée en clair)

Transformées (voir rubrique spéciale)

Personnalisation

• Personnalisation par l'utilisateur ( moyens de)
• Référencement des normes
• Profils de partenaires
• Normes et guides d'application
• Identification des messages avec ce partenaire
• Variantes syntaxiques
• Sens des échanges
• RSVA
• Type de communication (protocoles, heures ..)
• Insertion automatique d'un partenaire (à partir du message PARTIN)
• Gestion des références d'interchange, de messages par partenaire (séquences)
• Génération des messages CONTROL après qualification des messages
• Personnalisation des menus
• Gestion des langues (français, autres ..)
• Gestion des erreurs (à examiner attentivement)
• Génération de guides d'application
• Gestion de la sécurité (à détailler en fonction des besoins, intégrité, non répudiation etc..)

Conversion de données et corrections

Conversions de caractères 'ASCII, EBCDIC..)

Conversion de codes

Corrections automatiques de messages erronés ( à manipuler avec précautions)

Corrections manuelles, afin de recycler des messages dont les erreurs sont évidentes et sans conséquences

Suivi des séquences de messages

Rapports de contrôle et d'audit

Rapports d'erreurs

Rapprochement des messages de CONTROL et du message auquel ils correspondent

Rapports sur les messages émis, reçus, par critères

Analyses de trafics (volumes, fréquences ..)

Personnalisation des rapports (suivi fin d'un nouveau partenaire)

Niveaux de rapports (synthèse, détails ..)

Support

Aides en ligne (écrans)

Documentation utilisateur

Documentation technique

Tutoriels en ligne

Services du vendeur (formations)

Support aux utilisateurs

Formations

Divers

Prix (achat, matériel, logiciel, maintenance redevance annuelle, nouvelles versions, nouvelles normes )

Code source déposé

Performances

Applications livrées avec le produit

Applications interfacées avec le produit

Transformées ("mapping")

• Description de guides d'application
• Description des formats applicatifs internes
• Définition de règles
  • Assigner
  • opérateurs arithmétiques (+,-,*,/)
  • Entrée/sortie séquentielle
  • Entrée sortie sur une clé
  • Effacer un enregistrement
  • Exécuter une règle (ou plusieurs successivement)
  • Conversions de codes
  • Si ..alors..ou..
  • Echappement utilisateur (vers un programme ad hoc)
  • Traitement de chaînes de caractères (troncatures à droite, à gauche, concaténation)
• Prises en compte de variables système (date, heure, compteur )

Un logiciel doit impérativement être doté de moyens efficaces pour permettre de développer rapidement les transformations de structures applicatives existantes en messages EDIFACT et vice versa.

Fiches techniques

Les segments d'en tête de la norme EDIFACT

ou

pourquoi EDIFACT est LA norme de référence

C'est grâce à l'existence d'une syntaxe unique, et à son utilisation par un grand nombre de secteurs d'activités, que les systèmes de commerce électronique peuvent devenir de réels systèmes ouverts, installés en utilisant des logiciels, des plates-formes de communications nombreux, de fonctionnalités variées.

Le développement de messages est une affaire qui peut être confiée à des utilisateurs qui savent définir leurs lots d'information à échanger, décrire chaque donnée minutieusement, assembler le tout conformément aux règles de l'art EDIFACT.

Il ne reste plus alors qu'à paramètrer les solutions et à développer les interfaces applicatifs, avec de véritables ateliers de génie logiciel, ceux que dont la norme EDIFACT a suscité, par son existence même, le développement.

Voici ce que contiennent les segments d'en tête des messages EDIFACT

Un interchange contient un ou plusieurs messages.

UNB Interchange : en-tête de l'interchange (informations contenues)

• N° de la version de la syntaxe (changement peu fréquent)
• Emetteur de l'interchange
  • identifiant de l'émetteur
  • nature (qualifiant) de cet identifiant
  • Adresse d'acheminement en retour (si elle n'est pas déterminée à l'avance)
• Récepteur de l'interchange
  • identifiant de l'émetteur
  • nature (qualifiant) de cet identifiant
  • Adresse d'acheminement en retour (si elle n'est pas déterminée à l'avance)
• Date/Heure de préparation
• Référence unique attribuée par l'émetteur
• Référence du destinataire/Mot de passe
• Référence de l'application (permet de router les messages vers une destination prédéterminée
• Code de priorité (permet de lisser les pointes de trafic)
• Demande d'accusé de réception
• Identification de l'accord d'interchange
• Indicateur d'essai (permet de différencier un usage effectif d'un test)

Un interchange contient un ou plusieurs messages.

Chaque message est précédé d'un segment d'en tête UNH

UNH Message : informations contenues dans l'en tête de message

• Numéro de référence du message (référence unique attribuée par l'émetteur)
• Identifiant du message (type de message)
  • type de message
  • Numéro de la version (quand le message a connu plusieurs versions successives)
  • Numéro de la révision (quand une version a été révisée)
  • Agence de contrôle (responsable de la définition du message)
• Référence commune d'accès (pour mettre en rapport des messages liés à une même affaire)
• Statut de transfert (lorsqu'une série de transferts est prévue)

Enfin, un message possède un segment BGM, Begin Message (Commencement du message), qui permet de distinguer des variantes d'utilisation d'un même message, et sa fonction :

On trouve, par exemple, dans le segment BGM de la facture EANCOM, faite à partir de l'UNSM EDIFACT INVOIC :

BGM

Nom du document : (il s'agit au principal d'une facture que "nom du document" précise)

Choix entre :

• Facture proforma
• Facture commerciale
• Note de crédit (avoir)
• Note de débit
• Facture consolidée
• Facture de services mesurés
• Note de crédit (ajustements financiers)
• Note de débit (ajustements financiers
• Facture d'acompte
• Facture affacturée

Fonction du message :

Choix entre

• Annulation
• Remplacement
• Duplicata
• Original
• Copie

C'est à partir de cette normalisation, qui s'applique à tous les messages EDIFACT sans exception, qu'il a été possible de développer des systèmes de commerce électronique de façon industrielle.

Il va de soi qu'il existe une liberté d'organisation des en têtes d'interchange et de messages.

Cette liberté peut comporter des inconvénients, notamment si les mêmes rubriques sont employées différemment d'un message à l'autre pour un même partenaire.

Il est donc hautement recommandable que l'administration décide d'usages communs des segments dits de service des messages EDIFACT afin de simplifier la tâche de ses partenaires.

L'identification universelle de ces partenaires est le sujet le plus important.

De même l'identification des administrations doit être conçue de façon que le développement des télédéclarations, et plus généralement du commerce électronique avec l'administration, soit aussi simple que possible.

Enfin, au coeur des messages, un certain nombre de segments devront être utilisés sous des formes uniques quelque soit l'administration et le message, ce principe pouvant souffrir des exceptions justifiées.

Un segment tels que l'adresse est candidat à une normalisation universelle sur le territoire national, à partir de la norme postale.

Cette fiche technique explique pourquoi une norme EDIFACT(avec sa syntaxe) s'est imposée.

Il est très clair que la norme EDIFACT pourrait reposer sur une syntaxe plus "scientifique" (cela comporterait des inconvénients, notamment pour les non informaticiens qui jouent un rôle prépondérant dans le développement des messages).

Cependant, c'est telle qu'elle est qu'elle s'est imposée, qu'elle a conduit à des développements de solutions :

• nombreuses,
• adaptées à des organisations de toutes tailles,
• plus ou moins riches de fonctionnalités,
• à la portée des budgets les plus modestes
• aussi bien qu'aux usages complexes de multinationales.

C'est ainsi qu'EDIFACT est devenue, comme on dit, incontournable.

Liste des documents réunis ou utilisés pour l'étude

Etats-Unis

• Guidelines for the evaluation of Electronic Data Interchange products, NIST, Computer systems technology (signalé)
• EDI compliance test facility, Document à l'usage des candidats-partenaires au programme Electronic Commerce (signalé)
• "Enabling privacy, commerce, security and public safety in the Global Information Infrastructure", Draft paper,Bruce W. McConnel and Edward J. Apple Co-Chairs, Interagency Working group on cryptography policy; 20 mai 1996,
• "The impact of electronic information" (on US government), Bruce McConnel, "users fee for government information may not exceed the cost of dissemination".Journal of Government information.
• Good security practices for electronic commerce, including electronic data interchange, Roy Saltman Editor, NIST (signalé)
• Information Technology Management reform, instructions aux directeurs des administrations et agences fédérales, 20 pages, dont une section sur le programme Electronic Commerce. (signalé)
• US Department of the Treasury, Electronic commerce clearing house, Draft project plan , consistent with the Presidential memorandum "Streamlining procurement through Electronic Commerce", février 1996
• Federal information processing standards (FIPS), Category index; liste des 125 normes ou guides applicables au traitement de l'information, que doivent respecter les acheteurs publics. On retiendra parmi ces normes le FIPS 161-2 concernant l'EDI et le FIPS 192, Federal Information Locator Service, qui permet de localiser une série de serveurs décentralisés contenant des informations accessibles au public soit directement, soit par un intermédiaire. (signalé)
• A standard language for implementation conventions, Alex Theo de Jong, Université de Twente, Pays-Bas
• Electronic Data Interchange Transaction set development, NIST, janvier 1995
• Guides d'application de messages (Implemantation conventions), exemples : Procurement notices et Request for quotations
• Federal documents : (signalés)
  1. VAN License Agreement,
  2. Electronic Data Interchange, Value Added Network Certification Process,
  3. Electronic Data Interchange, Operations

• Comptroller General of the United States, Decision, (signalé) Digest : "Contracts formed using EDI technologies may constitute valid obligations of the government for purposes of 31 Uniform SC §1501, so long as the technology used provides the same degree of assurance and certainty as traditional "paper and ink" methods of contract formation. Note : les normes édictées par le NIST (cf ci-dessus) sont la référence qui fait autorité.
• Executive Office of the President, Office of Management and Budget, "National Information Infrastructure Security issues : The Federal role".
• Federal Reserve Boosts E-Cash viability, Washington Tech, 25/05/96
• Tech Report : A look at Technology in Government, Doing business on the Internet : article décrivant l'orientation vers Internet du programme Electronic Commerce et les mesures prises à cette fin en matière de sécurité.
• Your Introduction to Electronic Commerce, a Handbook for Business, document à usage de promotion du programme Electronic Commerce.
• US Department of Justice : "Admissibility of Electronically filed Federal records as evidence (Octobre 1991).
• NIST Technical Report : Federal EDI Standards Management Coordinating Committee, Juin 1996
• EDI : Federal Programs and policies : un résumé des références concernant la sécurité et le droit de l'EDI (dématérialisation généralisée sous conditions de sécurité). Peter N. Weiss, OMB (signalé)
• Contractor registration : procédure pour enregistrer electroniquement un nouveau partenaire, Electronic Commerce Acquisition Project Management Office
• Liste des 112 Plates-formes de Commerce Electroniques opérationnelles dans 30 administrations différentes (State Department, Department of Justice, Department of Health, Department of the Treasury, Social Security administration, Department of Labor etc... (signalé)
• The Electronic Reporting Streamlining Act of 1996, Testimony of Environmental Defense Fund before the US House of Representatives 22 Mai 1996 : Ce document comporte des développements intéressants sur les conditions propices au développement des téléprocédures, qui a connu un vigoureux développement en Californie, dont l'administration fédérale tire exemple. (signalé)
• The Electronic Reporting Streamlining Act of 1996, Testimony of Environment and safety data exchange before the US House of Representatives : 22 Mai 1996 : idem supra.
• The Electronic Reporting Streamlining Act of 1996, Testimony of Sally Katzen Office of Management and Budget before the US House of Representatives : une déposition qui propose un certain nombre d'amendements en vue de donner sa pleine efficacité à la loi en encourageant une réingénierie préalable des procédures et en définissant des priorités destinées à concentrer les efforts sur l'essentiel au lieu de disperser les énergies.
• Local Governments turn to electronic commerce : technology lowers costs and increases competition, in Washington Tech 28/09/1995
• International Association of Industrial Accident Boards & Commissions (US, Canada et quelques autres pays ) : Un Programma comparable à TESS en Europe
• Case Study Electronic Commerce/EDI, DISA 19 Mars 1996 : Série de 22 Transparents présentant le programme fédéral (signalé)
• Information technology Management Reform Act of 1995 : Texte de la loi lui même. (signalé)
• National Defense authorization act for fiscal year 1996, un document montrant comment chaque département ministériel incorpore dans ses propres budgets et projets :
  1. "the Federal Acquisition Reform Act " et
  2. " The information technology management reform".
• Federal EDI implementation Registry mail server : texte expliquant comment le registre électronic des messages EDI du gouvernement est organisé et accessible; les messages sont soutirés électroniquement et gratuitement.
• Electronic Reporting and Streamlining Act of 1996 : Projet de loi sur les Télédéclarations aux administrations fédérales. Ce projet a été bien reçu dans son principe, mais subira des modifications importantes avant d'être adopté. Il donne une possibilité d'initiative aux citoyen et aux entreprises.
• Electronic Cash, tokens and pPayements in the National Information Infrastructure : Cross industry working team, septembre 1994,
• Secure electronic transactions (SET) on the Internet, cahier des charges du consortium VISA-MASTERCARD : bonne description des mécanismes de sécurité disponibles.
• Electronic Commerce and the NII (National Information Infrastructure) : Source Information infrastructure technology and applications task group, National coordination office for high performance computing and communications
• State Department - Office of the Legal Advisor - : "Negociability through EDI of rights in tangible goods".
• Liste des logiciels gratuits mis à la disposition des PME par la Small Business Administration (signalé)

Etat de Singapour

• Singapore Tradenet : Manuel d'utilisation du service créé à l'usage des exportateurs de Singapour, document transmis par les services commerciaux de l'Ambassade de France à Singapour. (signalé)

Royaume-Uni

• CCTA : Government Services : How to publish information
• CCTA : Government Services : How to access information
• Superhighways for Education : The way forward : Department for Education and Employement
• The Government Centre for Information Systems - CCTA - : Report on Information Superhighways (signalé)
• The Government Centre for Information Systems - CCTA - : Information Superhighways : an update on opportunities for public sector applications in the UK
• The Government Centre for Information Systems - CCTA - :Making the best use of the Internet in administrations and ministries(signalé)
• The Government Centre for Information Systems - CCTA - : Internet acces via the Government telecommunications network
• http://www.open.gov.UK est un serveur WEB régulièrement actualisé des projets du Gouvernement liés au développement de la Société de l'Information. (signalé)
• G7 : Improving access to Government services
• National Inventory Project : Status of Information Society Development in the UK: Stuart Carruthers & Simon Smith for CCTA Juillet 1995 (signalé)
• Current Status of EDI in UK administrations : Etudes de cas : National Health Service, Ministry of Defence, Criminal Courts of Justice, INCA - Information Net and Card for the adapted management of the European Road Traffic - Etudes sélectionnées pour leur caractère exemplaire. Utilisation d'EDIFACT dans tous les cas. (signalé)
• An Information and Management Technology Strategy for the NHS in England, NHS Executive (signalé)
• Les Autoroutes de l'Information au Royaume-Uni : Une étude du service science et technologie de l'Ambassade de France, réalisée avec l'appui de l'INRIA

Suède

• L'EDI dans l'administration suédoise : Note de synthèse des Services Commerciaux de l'Ambassade de France : intégralement reprise dans le rapport (signalé)
• EDI entre pharmacies, médecins, cliniques et hôpitaux. Utilisation de la norme EDIFACT

Documents remis par les administrations rencontrées

• ACOFA : Etudes de deux projets EDI/EDIFACT
• ACOSS : 4 èmes rencontres nationales des URSSAF dont une table sur la simplification administrative
• Assistance Publique Hôpitaux de Paris : Dossier de synthèse sur la politique EDI
• AFNOR : Rapport d'étape sur l'EDI Ouvert
• AFNOR : Groupe de travail sur les annuaires électroniques
• AFNOR : Groupe de Travail NF EDI
• AFPA : Dossier de synthèse : Projets et réalisations nationales, expériences d'intérêt local
• Assemblée Permanente des Chambres de Métiers Etude sur les échanges de données informatisés dans l'artisanat
• Association pour la Promotion de la Simplification - APSA - La Déclaration Sociale Unique : Une expérience de télédéclarations
• Commission Centrale des Marchés
  • Rapport sur le Système d'information marchés publics (SIMAP)
  • Comptes rendus des activités des groupes de travail sur l'EDI
• CNAF : Dossier de synthèse : Synoptique des échanges - Analyse des flux
• CNAM-TS
  • Cible fonctionnelle SESAM VITALE
  • Télétransmission des feuilles de soins électroniques entre professionnels de santé et organismes d'assurance maladie : Cahier des Charges
• CNASEA : Rapport annuel 1996
• CNAV :
  • Analyse des Communications EDI externes : Rapport de synthèse établi pour le Schéma Directeur 2000
  • Cahier des Charges pour les serveurs EDI/EDIFACT du CIN et des CRAM
• Conseil de l'Informatique Hospitalière et de santé : rapport d'activité et journées d'études
• Direction des Hôpitaux (voir Ministère de la Santé
• Douanes (voir Ministère de l'Economie et des Finances).
• Interministériel : Groupe de travail sur les normes dans le domaine des technologies de l'information : Contributions
• Ministère de l'Agriculture : Schéma directeur des systèmes d'information : Rapport de synthèse
• Ministère de la Défense : Extraits du Programme Rafale; Dossier de synthèse
• Ministère de l'Economie et des Finances - Direction Générale des Douanes - Dossier sur la transmission électronique de la Déclaration d'Echanges de Biens
• Ministères chargés de l'Equipement, du transport, du tourisme et du logement

Conseil Général des Ponts et Chaussées : Rapport concernant les EDI de Monsieur Pierre Chemillier

• Ministère des Entreprises et du Développement Economique, chargé des Petites et Moyennes Entreprises et du Commerce et de l'Artisanat : Rapport sur l'état d'application de la loi n° 94-126 du 11 février 1994 relative à l'initiative et à l'entreprise individuelle
• Ministère de la Santé - Direction des Hôpitaux : Rapport de Mr Chatelain sur les EDI
• Organisations Patronales : CNPF, CGPME, UPA : Statuts de l'Association EDISOCIAL, Charte EDISOCIAL
• Poste (La) : Service d'échanges dématérialisés EDIFACT
• UNEDIC : Dossier de synthèse sur la politique de communication externe de l'UNEDIC et des ASSEDIC avec leurs partenaires; éléments de stratégie.