Internet et commande publique
2 pages	Jean-Paul Baquiast jp.baquiast@chello.fr	maj le 12-2-99

En 1999, tout programme général de dématérialisation de la commande publique (avant et après conclusion du marché ou de la commande) suppose de s’appuyer systématiquement sur Internet, tout en réutilisant les travaux réalisés à ce jour dans le domaine de l’Edi. 

Internet permet en effet, mieux que l’Edi, de mettre en relation de façon économique et simple l’ensemble des partenaires, quelle que soit leur taille, par exemple un économat d’hôpital ou un secrétaire général de petite mairie, d’un côté, une entreprise artisanale vendant des plats cuisinés ou des meubles, d’autre part. Il suffit que l’un et l’autre soit équipés d’un micro-ordinateur connecté à Internet (rappelons que l’offre commerciale propose aujourd’hui l’ensemble micro + abonnement de 5 ans à 2.000 F environ à l’achat, avec forfait mensuel de 300 F environ).

Dotés de cet équipement minimum, les deux partenaires peuvent accomplir les diverses formalités s’imposant à eux, plus ou moins complexes selon l’importance de la somme à dépenser : consulter un catalogue, lancer un appel d’offres, passer une commande, recevoir une facture, la certifier et la payer, etc.

Ils peuvent le faire selon des méthodes plus ou moins standardisées : soit par de simples messages (e.mail) informels qui seront l’équivalent du fax sur Internet, soit en entrant dans des processus pré-étudiés pour automatiser et rationaliser au maximum la procédure. Dans cette perspective, ils ont tout intérêt à réutiliser les importants investissements faits par les communautés professionnelles dans le domaine de l’Edi, tout en conservant la souplesse du web. Ceci peut se faire par l’intermédiaire de ce que l’on appelle de plus en plus le web-edi.

Une session On Line du 11 février 1999, organisée par Edifrance (www.edifrance.org/), sur le thème " Edi et Internet, l’avenir des échanges électroniques professionnels ? " a fait le point sur les techniques et les acteurs à ce jour. Deux éléments nouveaux ont été mis en évidence :

XML/Edi 

Référence : Claude Chiaramonti. Rôle d’Edifrance dans la réconciliation de l’Edifact-Onu et de l’XML/Edi. (http://www.admiroutres.asso.fr/action/theme/internet/chiaxml.htm)

 La dématérialisation des opérations relatives à la commande publique étudiées jusqu'à ce jour en France portait sur des marchés entre grands acheteurs (par exemple la Délégation générale à l’Armement) et grands vendeurs. L’utilisation de l’Edi, préalablement défini par les uns et les autres, soit dans l’Edifact international, soit au sein d’Edifrance, soit en leur sein propre, dans la perspective notamment de favoriser le concurrent engeenering (CALS), allait de soi. Mais cela ne touche qu’une infime partie des relations entre acheteurs publics et fournisseurs, dans les trois fonctions publiques. De plus les procédures relatives à la normalisation Edifact sont jugées de plus en plus lourdes et peu évolutives. Leur emploi demandent des préalables eux-mêmes trop astreignants pour des échanges occasionnels, même lorsqu’il s’agit d’Edi allégé ou Edi-lite où l’entreprise s’adresse à un serveur pour obtenir la conversion de son message en Edi.

Depuis est apparu le langage XML bien adapté à l’Internet, et à la nécessité de faire dialoguer ensemble, de façon normalisée, le plus grand nombre possibles d’utilisateurs (100% des acheteurs et vendeurs en matière d’achat public). XML est un dérivé allégé de SGML, mais enrichi par rapport à HTML, qui permet de définir, entre partenaires à l’échange (ici l’acte d’achat) des objets et contenus communs d’objets échangés, manipulables à la fois comme des éléments de bases de données (par exemple un catalogue) et comme des informations faisant l’objet d’un message E.mail (par exemple une commande : livrez-moi tel produit de votre catalogue).

 Les grands fournisseurs de logiciels offrent désormais des ensembles de formats de messages, les DTD (Document Type Definition) directement utilisables par les échangistes, sans accords préalables entre eux. Rien n’empêchera, par exemple, un économat de collège achetant de l’outillage d’utiliser le contenu d’un tel DTD, s’il en trouve un qui lui convienne. L’équipementier choisi comprendra et traitera la commande sans avoir précédemment négocié avec la commune un accord détaillé d’interchange.

 Pour éviter néanmoins la babélisation, et surtout la prise en mains de leurs métiers par les éditeurs de logiciels, ou grands industriels internationaux, les communautés commerciales françaises (par exemple les industries de l’habillement, les libraires, l’outillage, etc) pourraient participer au développement de XML/Edi en récupérant le contenu du dictionnaire de normes Edi, le TDID, afin d’en faire des DTD, par ailleurs formulés en français, ce qui s’imposera dans le cas de l’achat public en France, si l’on ne veut pas exclure les PME qui ne sont pas toutes anglophones. Le même sort serait fait aux Tags des données. Ce travail pourrait être entrepris au sein d’Edifrance.

 Par ailleurs, au sein de l’ISO, il serait intéressant de faire gérer, par l’intermédiaire d’Edifrance, un Basic Semantics Register, le plus possible, là encore en français et autres langues européennes, qui rassemblerait les contenus normalisés utilisés par les partenaires à l’échange.

 En fait les communautés françaises de l’Edi ne mettront sans doute pas dans un tel objectif, pourtant souhaitable, toute l’énergie nécessaire. Le cadre fédérateur d’Edifrance n’est pas à abandonner pour autant. Les Pouvoirs Publics peuvent très bien prendre l’initiative de demander à Edifrance (puis aux groupements de professionnels qui la composent) de répertorier les normes et standards Edi et Edi-lite existants , ainsi que les groupes capables , en dialogue avec les représentants de telle ou telle catégorie d’administration ou d’acte d’achat, de compléter cet existant par des DTD et BSR XML, eux-mêmes constamment mis à jour. Chacune des administrations concernées devrait évidemment, dans cette perspective, participer au travail, en précisant les contenus dont elle a besoin, pour l’accomplissement de ses missions d’achat. Vraisemblablement, d’ailleurs, l’ensemble des nomenclatures serait concerné.

Pour encadrer ce programme, il faudrait constituer (ou reconstituer) au sein d’Edifrance un groupe Achat public rassemblant les représentants des principaux intérêts en présence.

2. Les services d’intermédiation à valeur ajoutée.

 Si l’on veut généraliser rapidement, au bénéfice de 100% des entités concernées, la dématérialisation par Internet des opérations et procédures intéressant le commande publique, il est indispensable de faire appel à des intermédiaires du secteur commercial offrant la fonction web-Edi. De nombreuses entreprises à valeur ajoutée, ainsi que des groupements professionnels pour leurs adhérents, offrent dorénavant ce service sur le marché français. D’autres organismes offrent des conseils, gratuits ou payants.

 Entreprises et administrations doivent être laissées libres de faire appel à ces offres ou non (Nous avons vu qu’avec XML, elles peuvent en principe s’en passer, mais cela suppose cependant un certain savoir-faire). Par ailleurs, le marché doit rester très ouvert, afin d’éviter toute dépendance à l’égard de fournisseurs cherchant à se donner des monopoles dans ce domaine très lié aux grands enjeux du commerce électronique. Les services à valeur ajoutée offerts doivent par ailleurs offrir toute la gamme de ce que peuvent attendre les partenaires à l’échange, y compris, initialement, convertir des messages fax en Edi ou XML/Edi.

 Pour faciliter la connaissance des offres, et accélérer la dématérialisation des échanges, au bénéfice de la communauté globale des acheteurs-vendeurs opérant sur le marché français, le groupe Achat public précité, crée au sein d’Edifrance, pourrait mettre en place un site web portail d’information, ou les différents offreurs de services d’intermédiation présenteraient leurs offres, sous leur responsabilité. Un format de présentation-type minima pourrait cependant être exigé, ainsi qu’une rubrique FAQ et forum.

http://www.admiroutes.asso.fr/espace/achatpub/intercom.htm