La société Illicom s'en tient à ce qui lui réussit bien depuis 10 ans : les outils d'intégration, tant en interne qu'en externe, c'est à dire  le B2B en EDI ou en Web EDI et l'EAI, Enterprise Application Inte-gration. Sa gamme d'outils  (cf VendrEDI n°65) est bien implantée, et parfois leader, dans de nom-breux secteurs depuis l'industrie, la logistique et la distribution jusqu'à l'hospitalier.

La gamme-phare d'Illicom reste TradeXpress dont les capacités multifonctionnelles et multiprotocoles se déclinent,  par  exemple pour l'intégration dans les hôpitaux des données médicales, logistiques, administratives et financières, ce qui en fait une plate-forme "santé" ouverte et performante. Parmi les derniers clients de TradeXpress, Toyota, la Fnac et France Télécom pour ses services aux PME. Et pour le Web EDI, Web CarXpress d'Illicom vient d'être homologué par Galia pour l'automobile.

Mais il ne faut pas oublier qu'Illicom se développe aussi sur l'intégration interne en installant des plates-formes EAI, par exemple pour la Direction de la Comptabilité publique, des cliniques privées ou des entreprises de la distribution. Et cette compétence d'Illicom sur l'intégration à la fois interne et externe, devrait la conduire aux Services Web qui ont aussi cette double vocation, interne et externe. Quand les utilisateurs le souhaiteront.

Les qualités des SI urbanisés de demain doivent être "l'agilité" et la grande réactivité aux fréquents chan-gements du global business. Les métiers n'ont plus à s'adapter à la technologie mais l'inverse ! Pour cela, le hub and spokes doit faire place à un réseau décentralisé où l'on peut modifier une application sans toucher aux autres. Puisque, autre agilité, les applications doivent s'échanger des données, en interne comme en externe, seules leurs interfaces doivent être touchées pour réduire la charge d'une modification. D'où l'intérêt de la SOA (Services Oriented Architecture), dont les relations entre applications sont des "services" véhiculés par les messages des SW (Services Web). Si le "service" change, seul le message est modifié, ce qui aboutit à un EAI utilisant les SW en forme "d'EDI interne", avant même leur utilisation prévue en B2B.

Cette concentration des modifications sur les inter-faces était déjà permise, en interne, avec CORBA par exemple, et en externe avec l'EDI en Edifact. Mais l'intérêt des SW est d'offrir un seul support pour toute interface, en interne comme en externe, ce qui ne manque pas d'être mis en avant pour les nouveaux venus du B2B. Avec des fonctionnalités qu'Edifact, conçu il y a 20 ans, ne pouvait offrir.

Pour les entreprises déjà "édifiées", la perspective serait d'éviter le mapping spécial pour l'EDI en Edifact, qui est nécessaire, sauf pour les très rares entreprises comme Siemens, passées en Edifact interne. Mais ce côté excentré d'Edifact par rapport au SI interne ne l'empêche pas d'être toujours le format le plus utilisé du B2B, comme Ansi X12 aux USA. Et avant qu'Edifact céde la place pour qu'en externe l'EDI utilise les messages des SW comme la SOA en interne, il faudra sans doute que des conditions favorables soient réunies : par exemple  que les applications ayant un mapping en Edifact en externe soient passées en interne, d'abord à XML, puis aux SW avec la SOA.

Ce passage à la SOA, qui devrait faciliter le recours à un EDI généralisé en SW, est prévu par de nom-breux petits offreurs et la plupart des majors comme Microsoft, Sun, IBM, BEA, webMethods etc. Sans oublier Oracle annoncant qu'il "injecte" la SOA dans ses produits. Par contre, si SAP s'est ouvert aux SW externes, il hésite sur le niveau de raccord de ses ERP à la SOA. En tout cas, sans hésiter, les Communautés EDI auraient intérêt à contribuer à une SOA où le contenu métier de leur Edifact serait repris, et même amélioré, dans les messages des SW. Pour un EDI à la fois interne et externe.