Objet d'intérêt particulièrement vif dans les entreprises, figurant parmi les sujets de prédilection des analystes ces derniers mois, les Web Services semblent maintenant avoir dépassé le stade de l'effet d'annonce pour se positionner comme notion d'avenir. Pour autant, la perception de celle-ci reste particulièrement floue, et deux questions restent en suspens pour les directions informatiques, au delà des interrogations techniques: d'une part, est-ce bien nécessaire ? d'autre part: est-ce le bon moment ?

Direction générale ou direction informatique ?
Avant d'apporter des éléments de réponse à ces deux questions, il est sans doute nécessaire de distinguer, dans ces fameux Web Services, ce qui est de l'ordre du service et ce qui est de l'ordre de l'applicatif logiciel. Car c'est là que le bât blesse, finalement: il serait une erreur de présenter les Web Services comme des services - c'est à dire, en tant que tels, des éléments de l'offre d'une entreprise dont il n'appartient pas à la direction informatique de décider de les fournir aux clients. Présenter les Web Services comme une méthodologie nouvelle pour délivrer du service est déjà plus proche de la réalité, mais trompeur, car nous parlons ici de service applicatif, donc de logiciel. Jean-Marie Chauvet, dans son livre: "Services Web avec SOAP, WSDL, UDDI, ebXML", insiste sur l'idée de "logiciel considéré comme service"... preuve qu'il s'agit bien d'abord de logiciel, et donc, en dernière analyse, de choix effectués par la direction informatique (dois-je ou non délivrer du service par tel moyen technique, ou par tel autre ?). Ensuite, seulement, viendra l'examen des nouveaux services que le chantier des Web Services offrira l'opportunité de lancer.

Trois chantiers
Déployer un Web Service, c'est rendre accessible, via le réseau Internet, une fonctionnalité (ou éventuellement un groupe de fontionnalités) d'une application quelle qu'elle soit (client-serveur, bâtie avec un serveur d'application…). Pour cela, trois chantiers sont nécessaires:

- le chantier de la "publication", sous un format standardisé (WSDL, soit du XML), des services (fonctionnalités) que peut rendre l'application;
- le chantier de l'accès à distance au service applicatif, effectué dans le cadre des Web Services grâce au protocole SOAP, qui combine XML pour la description des messages entre l'application qui joue le rôle de client (invoquant le service) et l'application qui joue le rôle de serveur (dont une portion du code est exécutée à distance, délivrant le service), et (notamment) le protocole HTTP. Les messages XML sont deux types: un message contenant les paramètres d'invocation du service, un message contenant les données en sortie après exécution à distance du service (soit de la portion de code correspondante - ou procédure). Ce chantier, très concrètement, consiste au développement d'une API (Application Programming Interface) tirant profit de WSDL et de SOAP;
- le chantier, enfin, du référencement des Web services déployés, au sein d'un annuaire comme UDDI par exemple.

Ces trois chantiers correspondent à l'utilisation des Web Services comme vecteur de collaboration inter-entreprise, mais dans la pratique, le deuxième de ces chantiers risque fort de concentrer la majorité des efforts de déploiement autour des Web Services, car il répond, à lui seul, à la problématique la plus demandée (pour l'instant du moins) par les entreprises: l'intégration inter-applicative, dans l'entreprise elle-même (et non avec ses fournisseurs ou partenaires).

Combiner interopérabilité interne et externe
La question qui se pose est donc, dans un premier temps: pourquoi "remplacer" mon modèle "traditionnel" d'intégration à base de composants (ces briques logicielles qui transportent sur les réseaux la logique applicative) par un modèle d'intégration à base de "services". Deux réponses à cela. La première repose sur les atouts technologiques des web services: l'intégration apparaît moins "lourde", non véritablement en termes de développement, mais surtout en terme d'infrastructure (les Web Services utilisent les protocoles internet pour le routage inter-applicatif).
Deuxième réponse: l'intégration basée sur les Web Services à l'avantage d'être complémentaire de l'intégration basée sur un modèle "objet", dans le sens ou la première n'implique pas l'abandon de la seconde.
En conséquence, le problème est ramené à la question de savoir si l'intégration basée sur les Web Services va permettre à l'entreprise d'aller plus loin que l'intégration elle-même. Si la réponse est oui (que l'entreprise ait ou n'ait pas déjà un middleware d'intégration) alors le choix des Web Services est, de notre point de vue, véritablement judicieux.

En effet, outre que les principales briques technologiques des Web Services sont aujourd'hui arrivée à maturité (et notamment SOAP) - et même s'il existe une incertitude quant au modèle de sécurité associé -, ces briques possèdent également l'avantage de constituer des standards ouverts. Cela signifie, pour ne prendre que quelques exemples:

- que l'on peut envisager d'utiliser des logiciels libres pour déployer des Web Services,
- que les Web Services combinent à la fois la variété d'utilisation en interne (par nature, étant un moyen général de décrire une ou des fonctionnalités d'une application, ils ne sont pas limités à telle ou telle catégorie de fonction, mais peuvent répondre à n'importe quel besoin applicatif - Intranet, Extranet, Internet) et la variété d'utilisation sur des projets impliquant des partenaires (les standards ouverts favorisant la diffusion de la technologie).

En d'autres termes, les Web Services offrent une plus grande probablité de passage réussi de l'intégration intra-entreprise d'aujourd'hui à l'intégration inter-entreprise de demain. Quant à savoir si le chantier des Web Services doit être mené à bien dès à présent, malgré l'investissement moyen évalué, selon Benchmark Group à partir de projets actuellement en cours ou déjà menés à terme en France, à environ 100 000 euros, malgré l'adoption moins massive que prévu d'une technologie comme XML, malgré la nécessité, à terme, de modéliser des procédures métier impliquant plusieurs Web Services... on peut avancer que l'alternative technologique la plus souvent citée, en matière spécifiquement d'intégration B2B, apparaît avant tout comme une solution transitionnelle, puisqu'il s'agit... d'ebXML. On en revient toujours au mêmes fondements.