L'EDI aux normes Edifact.

Il faut distinguer l'Echange de Données Informatisées (EDI) qui concerne toutes formes de transactions électroniques, et l'EDI aux normes Edifact-ONU, qui découle d'un processus spécifique de normalisation ISO (ISO 7372 et ISO 9735). L'Edifact lui-même a longtemps encore été confronté à la normalisation d'origine américaine ANSI X 12, sans que l'on sache bien aujourd'hui quel processus l'emporte sur l'autre, celui de l'ONU étant officiellement le seul reconnu mondialement.

Or, depuis une dizaine d'années, la dématérialisation des procédures industrielles et administratives est associée, notamment en France, à l'utilisation de messages et données normalisés Edifact.ONU. Ainsi, la circulaire du Premier ministre en date du 16 janvier 1997 a imposé aux administrations d'utiliser les messages Edifact-ONU quand ils existent, ou de migrer vers eux dans le cas contraire. De ce fait, elles ont l'obligation d'accueillir les déclarations Edifact venant des entreprises. Ceci suppose en principe que les administrations participent à l'effort de normalisation des messages administratifs au sein des Edifact Board, via en France l'association Edifrance, où se retrouvent aussi les représentants de l'industrie et des services.

Edifact présente la caractéristique de lier plusieurs éléments différents : la modélisation des processus intéressés par l'échange (business practices), le message en découlant (par exemple une déclaration fiscale) et une syntaxe utilisant une codification elle-même inspirée d'éléments technologiques supposés relativement stables dans le temps et indépendants des offres industrielles. Ainsi, les utilisateurs du message auront-ils la possibilité, partout dans le monde, de connecter n'importe quel ordinateur avec n'importe quel autre, de façon quasi automatique (en principe sans intervention de programmeurs ou d'opérateurs).

La modélisation des processus représente la partie noble, indispensable, de l'effort de normalisation Edifact. La codification, telle du moins qu'elle est conçue par Edifact, est au contraire, par la force des choses, vite obsolète, dans la mesure où les technologies sur lesquelles elles s'appuie évoluent rapidement. Ainsi, dans les champs en texte libre, Edifact impose-t-il encore (sauf erreur ! ! !) de découper les documents alphanumériques en rubriques de 70 caractères, alors que les outils bureautiques modernes permettent de conserver les paragraphes sans les découper.

Un message Edifact recherche l'exhaustivité et l'universalité. Ce qui en fait un instrument lourd, lent à définir et à normaliser, pénible à utiliser, et très vite obsolète au regard des technologies nouvelles. Pour alléger son utilisation, il est possible de n'en retenir que des éléments pertinents (subsets). Pour accélérer le processus de normalisation, l'on peut aussi à la rigueur se satisfaire d'une normalisation régionale (et non mondiale). Le processus reste très exigeant en temps, en spécialistes et en contraintes diverses.

Les pratiques émergentes de standardisation*

(*et non de normalisation, au sens de l'ISO).

Aujourd'hui, la standardisation porte de plus en plus sur des éléments (ou objets) de programmation entre lesquels le programmeur pourra choisir les éléments lui permettant de bâtir un échange interopérable. L'on ne vise plus à l'exhaustivité d'un programme complet, mais au contraire à l'incomplétude d'éléments de programmes assemblés pour des fins spécifiques. C'est ce qui se fait majoritairement aujourd'hui au sens de l'X'Open, où se retrouvent tous les grands industriels et utilisateurs présents sur l'Internet. Ceux-ci, si l'on observe bien leur comportement, ne cherchent pas aujourd'hui à offrir des messages Edifact aux utilisateurs, mais des galaxies de standards eux-mêmes rapidement évolutifs, pour tenir compte de l'évolution soit des technologies, soit des pratiques.

Ceci est bien en phase avec la généralisation de l'Internet. Celui-ci voit fleurir les nouvelles générations de produits et applications, à un rythme infernal pour qui ne sait pas suivre. Il faut bien pourtant le faire. Mais pour le faire, il faut faire appel à de nouveaux profils d'hommes, ces nouvelles générations de programmeurs et d'utilisateurs plus performants, moins dépendants de l'assistance externe, praticiens du do it yourself, habitués à saisir les émergences et à s'adapter en permanence à ces dernières.

Ces hommes existent déjà en France. On les trouvera au sein même des administrations et des PME, mais pas nécessairement dans les grandes structures lourdes, où l'initiative individuelle n'est pas encouragée. Les réinsérer dans des circuits de production de valeur ajoutée, plutôt que leur imposer des tâches d'exécution, représente un enjeu de société important pour un pays comme la France.

Dans ces conditions, sur quoi doit porter l'effort de normalisation de l'administration (disons plutôt de standardisation) ? En priorité sur ce qui demeure indispensable, la partie noble du processus Edifact: la modélisation et si possible la rationalisation des pratiques administratives (business practices) et des procédures ou documents exprimant celles-ci. Une déclaration de TVA correspond à un processus qu'il sera toujours utile de modéliser, rationaliser et si possible standardiser. Ceci peut inclure des listes plus ou moins longues de standards portant sur des éléments d'informations, par exemple l'adresse, l'activité, le produit. Rien n'interdit d'y ajouter des recommandations plus générales : utiliser tel format de traitement de texte plutôt que tel autre, par exemple.

A ces éléments, l'on ajoutera une liste d'Interfaces programmatiques précisant la façon dont (en ce qui concerne l'exemple de la déclaration fiscale) le programmeur du déclarant doit écrire son propre programme (afin que l'ordinateur de l'entreprise produise sa propre déclaration de TVA à partir de ses propres fichiers de gestion, par exemple). Selon l'état de la dématérialisation des procédures de l'entreprise, le nombre des messages EDI qu'elle utilise déjà, les documents attachés seront fournis sous la forme la plus commode pour l'entreprise.

L'administration, pour sa part, renoncera à définir à l'avance des messages Edifact intégrant l'ensemble des phases successives de traitement, immuable dans le temps, indépendant de la technologie utilisée, excluant entièrement l'intervention humaine. Elle ne cherchera surtout pas à les faire normaliser au niveau mondial. Sauf exception, les exigences de communication n'impose pas de tels investissements en temps et en hommes. L'expérience montre qu'il est moins coûteux et plus efficace de faire appel à des hommes compétents pour réaliser les interfaces, que tenter de réaliser des schémas " parfaits ".

On l'a dit, de tels hommes se trouvent aujourd'hui partout, au sein même des administrations, car ce sont eux que forment les écoles de programmation et de gestion. L'on pourra aussi les rencontrer dans les PME/PMI ou dans de petites sociétés de service locales. Ceci d'autant plus, répétons-le, que les nouvelles générations de praticiens de l'Internet ont acquis, ou peuvent acquérir, grâce au réseau et aux informations qu'ils y trouvent, une compétence qui paraissait jadis réservée à de rares spécialistes. Il serait vraiment dommage de ne pas faire appel à ces nouvelles ressources humaines.

Internet et les messages EDIFACT existants.

Faut-il pour autant cesser d'utiliser les messages Edifact existants (ou des subsets de ceux-ci) si l'on fait appel à Internet ? Certainement pas. Internet représente un tapis roulant facile à utiliser, et assurant une large dissémination. Rien n'empêche d'y charger des contenus, fussent-ils d'une conception dépassés, dès lors qu'ils correspondent à des investissements et à des usages méritant d'être amortis. Pour prendre une image, cela consisterait à charger des diligences sur des plates-formes ferroviaires, dans la mesure où l'on dispose encore de diligences, pour s'éviter d'avoir à mettre en place un mode de transport plus intégré. C'est ce que permet l'encapsulation de contenus Edifact sous TCP/IP.

Il faut être attentif aussi au fait que les promoteurs de l'Edifact s'efforcent actuellement de s'adapter au monde Internet. On sait depuis longtemps qu'EDIFACT est perfectible. L'on peut consulter à ce sujet le texte disponible sur le WEB à l'adresse : http://www.geocities.com/WallStreet/Floor/5815. Les auteurs y traitent de la façon d'utiliser le nouvel HTML (XML) comme moyen de faire de l'EDI de façon plus efficace que maintenant. Ce projet est intéressant, car il prend appui sur les acquis d'EDIFACT et propose des améliorations permises par le progrès technique. Il y a continuité, non rupture.

Les défenseurs d'EDIFACT ne rejettent pas l'INTERNET, au contraire. Pour eux, ce qui a entravé le développement de l'EDI, c'est l'absence d'un réseau universel de transport de l'information. TCP-IP, POP 3, IMAP etc...ont sonné le glas des réseaux propriétaires. Le monde EDIFACT ambitionne d'utiliser INTERNET, mais sans abandonner ses acquis, des lots d'information qui permettent à des communautés de dialoguer, ni renoncer à des structures d'emballage harmonisées et intersectorielle des messages, qui s'échangent à l'échelle planétaire.

On observera également qu'en France, le GIE TEDECO, qui offrait jusqu'à présent un protocole de transfert protégé de fichier sur X400, se propose de rendre les mêmes services sur Internet, avec le protocole Ted-Net.

Pour ce qui les concerne, les administrations doivent de toutes façons s'obliger, comme indiqué ci-dessus, à mieux modéliser leurs processus opératoires, et à doter les usagers d'objets incomplets mais très divers et évolutifs représentant des interfaces programmatiques adaptés aux technologies et standards de l'Internet, comme aux nouvelles applications y apparaissant en permanence. Ceci peut se faire au sein des Edifact Boards, s'il en subsiste à terme, mais tout aussi bien dans toutes autres instances de standardisation et de dialogue. La normalisation sur le mode Edifact, dans le monde de l'administration, peut très bien être conduite, selon les besoins, à un échelon sub-national, national ou européen. L'essentiel est de répondre avec un court délai aux exigences de communication.

Notons cependant que de tels travaux, très liés au métier de chaque administration, ne peuvent être réalisés utilement que sous la responsabilité de chacune d'entre elle. Ceci oblige à faire des réserves sur l'intérêt de Commissions interministérielles de normalisation et de simplification, ou même de Serveur commun de formulaires ou formalités. C'est à chaque ministère, sinon à chaque service, qu'il appartiendra de publier sur le Web les documents administratifs correspondants aux procédures sont il a la charge, et tous éléments de programmation permettant de construire de façon standardisée les messages qu'il attend.

Les entreprises correspondant avec les administrations n'en demandent d'ailleurs pas plus . Elles sont obligées de choisir le profit à court terme. Elles sont peu intéressées par l'exhaustivité à long terme. A l'intérieur d'un processus global bien modélisé, elles préféreront sans doute compléter elles-mêmes les interfaces fournis par l'administration, dans les segments où elles voient la possibilité de faire des économies immédiates.

Des éléments communs peuvent être décidés à un niveau interministériel. D'abord l'ensemble des standards Internet devant s'appliquer à tous. Le travail est nécessaire car ces standards se modifient vite, et il faut définir et actualiser un noyau basique permettant de traiter le plus grand nombre des échanges. D'autres standards pourront être fixés. Par exemple les protocoles ou outils de signature électronique. Mais ils doivent être en nombre limités. L'ambition d'harmoniser de tels éléments n'a d'intérêt que si le temps passé pour ce faire est plus court que celui s'écoulant entre telle génération d'outils et d'usages et la génération suivante, soit nous l'avons dit, environ 6 mois à 12 mois aujourd'hui.

http://www.admiroutes.asso.fr/espace/normes/edifact.htm
écrire à la webmestre
droits de diffusion