| VendrEDI |  |
lettre de Claude Chiaramonti | ||
| sur les
données de l'échange électronique |
||||
| Numéro 86 19 novembre 2004 | ||||
|
Reliable
Messaging
|
Téléprocédures
:
|
|
|
en Services Web comme en EDI
|
EDI+EFI et
Edifact+XML
|
|
Les messages EDI bénéficient
d'une garantie de bon acheminement assurée par le
RVA par lequel ils transitent. Les messages des Services Web (SW),
comme ceux de l'EDI en AS1-AS2, passant simplement par Internet ne
bénéficient donc pas a priori de cette garantie :
d'où l'importance, pour la confiance dans les SW, puisqu'il
n'y a rien de prévu, ni dans HTTP, ni dans SOAP,
qui l'assure, d'un standard supplémentaire (du type WS-*)
assurant que le messaging sera bien
reliable.
En effet, les messages d'un SW complexe,
allant au-delà d'une simple demande de cours de Bourse,
doivent être échangés dans un ordre spécifique
scrupuleusement respecté, chacun de ces messages ayant une
répercussion sur les suivants : demande de prix, offre de
prix, commande, acceptation de commande par exemple. Et en
l'absence de contrôle humain, des SW automatisés
supposent qu'un mécanisme saura bien assurer ce bon ordre, et
que les applications émettrices et réceptrices de ces
messages seront bien informées, et en phase, à leur
sujet. Cela suppose, en conséquence que les outils
utilisés des deux côtés aient bien recours
au même standard pour ainsi pouvoir mettre
automatiquement en oeuvre des services à distance !
Et, comme souvent dans les WS-*, il y a deux
propositions de protocoles standards concurrents :
-
WS-Reliable
Messaging, proposition de BEA, IBM, Microsoft
et Tibco ;
-
WS-Reliability de Sun,
Sonic, Fujitsu, Hitachi, NEC et autres, proposition se
référant à ebXML, et depuis ce mois standard
Oasis.
Les deux ne garantissent pas le bon acheminement des messages,
mais simplement que l'information sur cet acheminement sera
identique des deux côtés, par exemple qu'un message n'a
bien été envoyé et reçu qu'une seule fois.
Malgré cette convergence, ces deux propositions de
standards ne sont pas interopérables ! Si cette
concurrence n'est pas une mauvaise chose au départ, il
faudrait que le marché tranche, et qu'une seule de ces
proposi-tions, ou une combinaison des deux, finisse par
s'imposer ! Pour faciliter les SW. Et
il est dommage que
"l'amitié" de Microsoft et Sun en matière de standards
WS-* ne leur ait pas permis de se "relier" à ce sujet ! |
Les téléprocédures fiscales,
sur la TVA et l'impôt sur les sociétés
représentent déjà plus de la moitié des
encaissements du Minefi. Non seulement des grandes entreprises et
des PME, mais même des TPE, au besoin par
l'intermédiaire de leur cabinet d'expert-comptable. La
télédéclaration peut être soit
automatique en EDI (machine to machine de
l'entreprise à la DGI), ou semi-automatique (human to
machine) avec ressaisie de ses données par l'entreprise
sur un formulaire EFI. Si l'entreprise est
déjà "édifiée", cette ressaisie des
données en EFI est, bien sûr peu astucieuse. Mais, à
l'inverse, passer à l'EDI pour économiser la ressaisie de
quelques données, c'est recourir à un marteau pour
écraser une mouche ! Par contre, en EFI, il faut autant
de certificats électroniques de confiance (30 à 100
euros chacun pour deux ans) que de personnes pouvant intervenir
(congés etc.) alors qu'en EDI c'est l'application seule qui
est certifiée.
In fine, EDI et EFI sont donc
complémentaires et n'ont pas à être
opposés. Parmi les portails de déclaration, si Net-entreprises.fr s'est spécialisé
dans le social en EFI, d'autres, comme le
portail jedeclare.com (experts-comptables, SSII
et banques) reçoit social ou fiscal, aussi
bien des entreprises que des cabinets d'experts-comptables
qui déclarent pour le compte de centaines d'entre-prises,
et donc ne peuvent le faire qu'en EDI auto-matisé. Ce qui
simplifie d'ailleurs le mandatement des cabinets par les
entreprises quant aux certificats de confiance intuitu
personnae exigés par la DGI !
Le portail jedeclare.com respecte le cahier
des charges de l'association Edificas qui a mis au point les
messages Edifact de télédéclaration comme leurs
équivalents XML. Selon son fondateur, Michel Lesourd, d'autres
téléprocédures fiscales que la TVA ou l'impôt
sur les sociétés devraient d'ailleurs être mises en
oeuvre par les experts-comptables :
- communication aux banques des
comptes annuels des entreprises (les greffes les attendent
également)
- déclaration des revenus IRPP des
artisans à partir des données comptables. Ces
téléprocédures à venir étant faites
suivant le format Edifact ou selon son équivalent XML,
suivant ce que souhaitera la DGI.
Donc EDI ou EFI, Edifact ou XML, la technique
peut s'adapter aux besoins !
|
 |
Pour que "le message passe" il faut être d'accord
sur le sens des données Petit
Glossaire du B2Bfr
|
|
Global ET local
:
|
|
Sémantique XML :
|
|
pour vendre à
tous dans Babel
|
|
noyau ebXML CCTS + chair RDF
|
|
Si les plus unilatéralistes de nos
amis américains se préoccupent de connaître la
diversité des cultures mondiales, c'est d'abord pour mieux
assurer la vente de leurs produits en les adaptant aux "goûts"
de leurs acheteurs étrangers. En effet, les ventes des
majors US sont désormais localisées en majorité
hors des USA et leurs produits s'y vendront d'autant mieux qu'ils
ne heurteront pas les usages. C'est vrai pour MacDo, mais aussi
pour Microsoft, par exemple, qui accompagne .Net d'un
système de glo-balisation
avec
RegionInfo,
CultureInfo etc.
C'est pour cela que la localisation,
d'origine et à usage US, est ainsi
octroyée top down aux indigènes
locaux. Edifact, au contraire avait réglé le
problème du locale en bottom up : les
données transmises sont codées (sauf noms et adresses),
et c'est à chaque destinataire de se confectionner un
affichage "localisé" en clair dans sa langue à partir du
répertoire officiel, bien sûr, en anglais.
Le recours à des données
localisées est propre à chaque type de produit, du
hamburger aux notices d'utilisation des logiciels et à
l'habillage des jeux vidéo. Cela commence néanmoins
par les données universelles, valables pour tous les
produits : langue, devise, unité de
mesure, taxes et autres réglemen-tations. Certes, il
y a les normes ISO en la matière. Mais elles peuvent être
complétées et précisées, par exemple par la
proposition de Phillips à l'IETF concernant la
norme identifiant les langues.
A noter que si la localisation (ou
localization aux USA) va bien au-delà de la
simple traduction, il faut d'abord rendre hommage au standard
Unicode qui permet d'utiliser toutes les langues et alphabets
connus, latins ou non, avec accents ou non.
Pour la localisation des standards
XML, le groupe de XML.org Focus Area
on Localisation avec un centre de
recherche irlandais et un projet européen, passent en revue
l'existant pour son adaptation "culturelle", et d'abord
pour la traduction en utilisant
XLIFF (XML Localisation Interchange File
Format) d'Oasis comme format intermédiaire (cf un
Livre Blanc). A citer aussi le
projet CDLR lancé par IBM, Sun, Linux et
OpenOffice.
Un
article d'IBM explique la mise en oeuvre de XLIFF en
liaison avec d'autres formats d'aide à la traduction comme
TMX ou
TBX de Lisa (Locali-zation Industry Standards
Association), dont le Forum du mois dernier,
au Dysneyland de Marne la Vallée, a réaffirmé
l'enjeu économique et social du multilinguisme et de la
"localisation". Pas seulement pour les majors US, mais aussi
pour les sites Web ou les notices des entreprises
francophones.
|
La liberté de création de langages
métiers avec le métalangage XML sera d'autant plus
efficace si elle peut s'appuyer sur l'existant : inutile de
réinventer la définition de la roue si on peut la trouver
formulée dans un directory accessible ! Mais ce
n'est pas si simple : on peut, en effet, constater qu'il
y a bien toujours la partie sémantique du
directory TDID d'Edifact, mais sa suite attendue, les
Core Components ebXML du Cefact-Onu, n'est pas
complétée. Et c'est le chaînon manquant qui
con-tinue de faire bien défaut à ceux qui
définissent un vocabulaire XML vertical, comme le fait
remarquer
Nicolas Maurin d'Arcelor. Seule la
spécification technique
ebCCTS a été
adoptée comme telle par l'ISO
TC154 ; le groupe d'Oasis UBL,Universal Business
Language, s'y réfère déjà dans ses
Naming and Design Rules, adoptées ce
mois par des contributeurs très anglo-américains, à
la notable exception de Fabrice Desré de France
Télécom. Et UBL fournit bien un directory
de définitions qui a été validé comme standard par Oasis sans
attendre le Cefact. Bien qu'ayant été adopté par le
Danemark (VendrEDI n°73), ce standard ne
comprend pas toutes les définitions de la supply
chain : il y manque des définitions, ne
serait-ce que pour les appels d'offres électroniques
européens.
Mais un directory, même
incomplet, présente quand même l'intérêt de
fournir le noyau, le core, sur les
informations universelles, adresses, identifiants etc.
qui ne sont pas à réinventer. Du type des
définitions que la Dublin Core
Metadata Initiative (DCMI)
propose pour le core des documents
de l'édition etc.
Mais la DCMI utilise RDF, ce qui
permet à tous d'enrichir librement le core en
tant que de besoin. La sémantique des Services Web, elle aussi
peut utiliser RDF avec OWL-S (VendrEDI n°83) et peut donc
s'étendre par adjonctions successives de
défi-nitions reliées au core par
RDF. D'ailleurs Oasis, parallèlement à ses groupes
ebXML/UBL, poursuit aussi un projet
XDI (VendrEDI n°73) pour localiser et partager
toutes les données du Web exprimées en RDF, comme
prévu par le Semantic
Web du W3C.
Il devrait en être de même pour
ebXML pour qu'il ne reproduise pas le splendide isolement d'Edifact
! Il ne suffit pas de "faire son marché" parmi les
"articles" Core Components isolés dans leur
rayon : la sémantique XML bénéficie avec RDF et les
namespaces de la possibilité de relier les "notices
explicatives" de tous les articles ! Chacun pe
ut ainsi agréger au noyau
des Core Components la chair des données
spécifiques à son langage métier,
explicitées avec RDF. |
|
Ce numéro 86 de VendrEDI a
été adressé à
1355 abonnés Pour
écrire
|
| Tous les numéros de VendrEDI peuvent être téléchargés à http://www.actimum.com/acvendredi.htm |