| VendrEDI |  |
lettre de Claude Chiaramonti | ||
| sur les
données de l'échange électronique |
||||
| Numéro 97 22 juillet 2005 | ||||
|
XML et Microsoft :
|
eBusiness français
:
|
|
|
Jean Paoli
à l'honneur
|
normaliser ses pratiques
?
|
|
XML est né du travail d’une
poignée d’experts de la communauté SGML, dont
faisait partie Jean Paoli qui a travaillé à l'INRIA
et est maintenant directeur de XML chez
Microsoft. L’association IDEAlliance dont l'objectif est
d'encourager le développement des standards informatiques, a
remis en novembre dernier la
XML Cup 2004 à Jean
Paoli pour sa contribution à la création du
standard XML au W3C. Robin Cover d'Oasis et éditeur de The
Cover Pages, l'a reçu également.
"Nous sommes enchantés que Jean ait
été honoré par la XML Cup " a
déclaré Bill Gates, président de Microsoft et
architecte en chef des logiciels chez Microsoft, "Jean a conduit le
mouvement qui a fait de XML un élément phare de nombreux
produits Microsoft, comme Office et Windows ; il a aussi
établi les fondations de l’intégration entre des
systèmes qui exploitent les Services Web en XML".
Avec Jean Paoli, la co-signature de Microsoft
figure au bas de la plupart des propositions au W3C de standards
accompagnant XML : namespaces, XSL, XSLT,
schémas etc. De même que pour les
stan-dards des Services Web (SW) basés sur XML : SOAP, WSDL,
UDDI et la gamme WS-*.
L'objectif stratégique de
XML étant de lever les barrières à
l'interopérabilité au niveau des données, Microsoft
a aussi été pionnier de l'implémentation de XML au
coeur de ses produits comme .Net.
Office 2003 contient ainsi un jeu de
schémas XML "ouverts" pour ses outils bureautiques de base,
Word, Excel ou InfoPath pour les formulaires. Cette ouverture
étant une garantie d'interopérabilité, bien que
certains voient là une nouvelle manifestation de la
volonté d'hégémonisme de Microsoft.
En tout cas, pour Jean Paoli, français
pionnier de la normalisation, l'interopérabilité des
schémas secto-riels "métiers" passe bien par le respect
du schéma officiel WXS du W3C et par le recours aux SW.
C'est ce qui devrait permettre à XML d'être un outil
de terrain, et en même temps d'offrir un cadre pour les
mappings entre langages concourrant au
même business, garantie contre la
"babélisation". Et la SOA (Services Oriented
Architecture), basée sur des SW utilisés à la
fois en interne et en externe, ne peut que conforter cette
interopérabilité totale voulue par tous, Microsoft en
tête.
|
L'electronic business group (ebg) est
une associa-tion des grandes entreprises françaises, près
d'un millier, qui est soutenue par Microsoft, et s'étend
en Europe. L'ebg vient de tenir son AG, avec ministres et
PDG, au cours de laquelle Patrick Le Lay (TF1) a
été élu Président, François-Henri Pinault,
prési-dent sortant, restant administrateur. L'ebg traite de
tous les aspects de l'e-business avec des
commis-sions B2B très actives comme le montre le site de
la
revue de
l'ebg, Elenbi Stategic Review, en
français et en
anglais. L'ebg traite aussi de dossiers
très généralistes et stratégiques, par
exemple la straté-gie générale des
constructeurs automobiles, sans
que l'e-business y soit forcément
l'aspect dominant.
Mais, bien que l'Afnor soit membre de
l'ebg, il n'y a guère de participation organisée aux
activités normalisatrices, même si la version papier
de la revue de l'ebg comporte un e-Business Standards
Corner. Car le discours selon lequel normes et standards ont
une importance stratégique pour les offreurs et les
utilisateurs de l'e-business n'est plus convaincant : le
retour sur investissement n'y est pas assez évident pour les
entreprises !
Quelques grandes entreprises françaises
comme France Télécom, ou l'INRIA, pilier maintenant
indirect du W3C, continuent à participer à la mise au
point de standards structurants du côté offreurs.
Mais guère de participation de représentants des
utilisateurs à la standardisation du Semantic Web
(Total ?), ou des Services Web, qu'on peut voir comme les
systèmes nerveux à venir, à la fois du B2B et de la
SOA interne. Cela concerne, certes, des outils techniques valables
pour le monde entier ; mais aussi des standards de contenu,
pour les business process ou la sémantique des
langages-métiers qui seront d'autant plus facilement
utilisés que les entreprises y reconnaîtront leurs
pratiques.
Ces standards de contenu, comme les
schémas XML sectoriels, s'élaborent sur le
terrain, dans des groupements d'e-business internationaux.
Mais ne ne faudrait-il pas que ces standards bottom
up plutôt anglo-américains tiennent compte du
contexte réglementaire et culturel commun à
tou
s les membres
de l'ebg ? C'est le rôle de la
normalisation officielle à laquelle l'ebg
intersectorielle pourrait contribuer. |
 |
Pour que "le message passe" il faut être d'accord
sur le sens des données Petit
Glossaire du B2Bfr
|
|
SOA pour les PME
|
|
DGI hors-normes ?
|
|
Un SI de services pour le
métier
|
|
pourtant la norme simplifie !
|
|
La SOA (Services Oriented
Architecture) est-elle réservée aux grandes
entreprises qui tiennent à combler sans "coder" les
fossés séparant les diffé-rentes applications de
leur SI foisonnant ? Les PME doivent-elles se contenter d'un ERP
(progiciel de gestion intégrée) conçu pour articuler
de manière rigide les quelques fonctionnalités de leur
gestion ?
Les PME sont concentrées sur leur coeur
de métier et n'ont pas l'intention d'essuyer les plâtres
avec des technologies de pointe. Ce n'est donc pas parmi les PME
que la SOA, l'ESB (Enterprise Service Bus) et ses Services
Web (SW) seront implantés en priorité ! Et
pourtant ces outils sont particulièrement bien
adaptés aux PME. D'abord la SOA est une approche pragmatique
qui part de l'existant du SI : les applications existantes
n'ont qu'à comporter des endpoints, points
d'entrée des messages provenant ou destinés aux autres
applications. C'est le début du loose coupling,
la relation lâche qu'offrait déjà CORBA
par exemple, pour relier les applica-tions qui doivent
échanger des données : les modifs d'une application ne se
répercutant pas sur les autres mais seulement sur les
messages. Et pour tester le concept, on peut démarrer avec des
messages REST basiques (cf. VendrEDI n°89) avant de passer
à l'ESB, SOAP-WSDL et les SW proprement dits. L'objectif,
souplesse, réactivité aux changements du
business ne pouvant que répondre aux besoins des PME
comme des très grandes entreprises internationales.
Mais même en démarrant prudemment,
une aide extérieure est le plus souvent nécessaire à
la PME : c'est ce qu'IBM, par exemple, essaye d'organiser avec
son récent PartnerWorld Industry
Networks
visant à faire relayer par le plus
possible de SSII proches des PME ses
produits et services SOA. En
choisissant le périmètre de départ le plus
appro-prié, la PME peut ainsi être aidée par
une SSII pour se rapprocher progressivement d'une architecture plus
souple et réactive envers les métiers de l'entre-prise.
Naturellement, ce qui reste à la charge des PME c'est la
réflexion sur son métier pour identifier les "services"
qui devront être mutualisés entre les applications,
éventuellement remodelées autour de ces services. Sans
vouloir trop rêver, l'idéal serait la
formalisation de la sémantique métier de la PME
qui permette de coder ensuite des outils de management du SI, par
exemple avec un registre des services et des processus SW. En tout
cas, pour adapter la SOA aux PME avec l'approche d'IBM : voir grand
et réaliser petit à petit !
|
La DGI avait été en pointe dans
l'application de la circulaire Juppé de 1997 demandant aux
adminis-trations d'appliquer la norme Edifact dans le B2A. A
l'inverse, aujourd'hui, pour le contrôle fiscal, la DGI se
refuse à accepter des messages Edifact ou XML, et même
les jeux de caractères normalisés !
Dans le cas de formulaires informatisés
(EFI), cela peut obliger les PME à ressaisir manuellement
les données déjà informatisées de leurs
déclarations, TVA ou autres, dans le format exigé par la
DGI. Et dans le cas d'une copie de fichiers des grandes
entreprises ou des cabinets d'experts-comptables, le Livre des
Procédures Fiscales prévoit des modalités
d'échange basiques, peu coûteuses, et le plus possible
indépendantes des environnements des entreprises, alors que
les grandes entreprises pratiquent, en majorité, Edifact et/ou
XML pour leurs échanges B2B. Revenir à du basique pour le
B2A est donc très coûteux justement ! En fait, la
véritable raison de ce souci du "basique" est de prendre en
compte les limites des outils utilisés par la DGI qui, eux,
sont restés basiques et ne suivent pas l'évolution
technologique des entreprises.
Pour les jeux de caractères, la DGI, ne
demandant que des déclarations en français, pas en
cyrillique, ignore les nouvelles normes, permettant de
repré-senter toutes les langues européennes ! Certes,
mais l'UTF-8, issu d'ISO 10646, recommandé par l'IETF
pour les protocoles d'Internet, est le codage de base de XML et
devient donc le jeu de caractères le plus courant dans
les entreprises. Là aussi, transcoder serait une charge
inutile et coûteuse. Par exemple, pour la DGI, le signe
d'une somme en est le 1er caractère à gauche, alors qu'en
XML il est séparé de la somme. Les caractères
accentués sont bien pris en en compte en XML, pas en
ASCII etc.
Pourtant, le respect de la norme est l'un des pre-miers moyens de simplifier les transferts informa-tisés de données entre les administrations et les entreprises, ce qui reste une priorité de l'action gouvernementale. Et sous-tend l'action de l'ADAE (cf. VendrEDI n°94) et de ses recommandations aux administrations qui portent notamment sur le recours à XML. Pour la DGI, au contraire, si les normes et standards utilisés par les entreprises ne sont pas directement exploitables par ses logiciels, c'est aux entreprises de se conformer à ses outils "propriétaires" ! Pourtant, la loi Mad elin dit
que l'Administration ne doit pas reporter sur les
entreprises le coût de sa propre complexité ou de
son incapacité à faire ! |
| Ce numéro 97 de VendrEDI a été adressé à 2037 abonnés Pour écrire |
| Tous les numéros de VendrEDI peuvent être téléchargés à http://www.actimum.com/acvendredi.htm |