Invité comme conférencier à la réunion annuelle des directions informatiques du Ministère de l’Éducation Nationale qui se tenait à Cannes, j’ai pu mesurer – une fois de plus – le fossé qui se creuse entre d’une part la manière dont on parle des systèmes d’information, dont on vend des projets informatiques, et d’autre part la manière dont on réalise les projets informatiques.


Le conférencier externe qui me précédait lors de cet événement venait parler de la SOA (Service Oriented Architecture). Quant à moi, je parlais juste après lui des architectures ROA, de REST et du Cloud Computing. Autant dire que, sur beaucoup de points, nos discours étaient dissonants voire contradictoires pour l’auditoire.
Aussi, la question qui revenait au moment du déjeuner était :

“Mais alors, faut-il faire de la SOA ou pas ?”

Ma conviction est que la seule chose que propose une démarche SOA c’est un dessin, celui des sempiternels blocs qui s’agencent sur un socle EAI ou ESB, avec un moteur de règle magique qui traîne dans un coin. Ce dessin est une sorte de fantasme récurrent depuis plus d’une décennie dans le mode de l’informatique de gestion d’entreprise. L’illusion repose sur ce principe très simple que, pour masquer une complexité, il faut la mettre dans une boîte. Bien sûr, cela ne résout rien, mais cela repose l’œil de voir toutes ces petites cases qui s’agencent à merveille dans le format d’un slide de power point. A un tel point que je ne suis pas loin de penser que la SOA, qui n’est pas une architecture au sens strict, relève plutôt d’une “architecture power point” : comme si le support et le format de communication conditionnait l’avenir d’un système d’information.

Je suis donc de plus en plus convaincu que la SOA est finalement un style d’architecture, pour reprendre l’expression de Fielding, mais dont les contraintes qui s’expriment n’ont rien à voir avec la réalité d’un système d’information mais bien plutôt avec les contraintes du support de présentation qu’est le slide de power point.

Pour éclairer ce point, il faut jeter un regard en arrière sur les schèmes utilisés par les vendeurs de logiciels, et qui sont toujours utilisés, encore aujourd’hui.

Ainsi, lorsqu’il y a plusieurs années, les premiers éditeurs proposant des solutions d’EAI (Entreprise Application Integration) venaient présenter les bénéfices de leur logiciel aux Directions des Systèmes d’information, voici ci-après les schémas qu’ils utilisaient.

Tout d’abord ils présentaient les flux de données que s’échangent les applications entre elles :

Forcément, ce plat de spaghetti est le cauchemar des responsables des systèmes d’information : çà part de tous les côtés et, pour maintenir en état et gérer tous ces échanges, ce n’est pas une sinécure.
Mais tout çà c’était avant ! Avant que les solutions d’EAI (aujourd’hui marketée en ESB : Enterprise Service Bus, dans le cadre des démarches SOA) n’arrivent en vous présentant cette formidable image :

(j’ai pris ces images au hasard, il y en a des milliers similaires sur le Web)

Avec une telle représentation c’est le calme, l’apaisement et la rationnalité qui s’imposent enfin. Le bus d’entreprise (ESB) permet “simplement” de brancher (to plug, comme plug and play) chaque application du système d’information afin qu’elle puisse dialoguer simplement avec le reste du système d’information.

Le couple formé par ces deux images possède un pouvoir de conviction et d’adhésion qui me surprend toujours. Il semble inusable. Il a été décliné initialement avec Tuxedo pour les middleware orientés transactionnel, puis avec MQseries pour les Middleware orientés Message, puis avec les solutions d’EAI, et après par les Solutions de SOA, il est en train d’être repris au niveau des données avec les démarches de Master Data Management, on le retrouve dans l’UIMA de IBM pour le Text Mining et, pour finir, Google vient de nous le resservir avec son API (pas) OPEN Social :

Mais, en vérité, le fondement de l’interopérabilité, dans un système d’information, ce n’est pas tant que les applications ou les services se parlent, c’est que les données soient ouvertes. Si les données n’étaient pas encapsulées dans les applications, l’image magique du Bus et des démarches orientées services perdraient tout leur intérêt.

Le principe de ce schéma est toujours le même : placer à la périphérie les éléments du système d’informations (applications, services, données, réseaux sociaux, etc), puis poser la pièce maîtresse au centre, le rouage ultime, qui va permettre d’articuler tout ce petite monde. En cela le schéma va plonger dans notre subconscient, reproduisant ici le système solaire, ou là le moyeux la roue. Parfois aussi le temple ou la pyramide, quand on fait appel à des modèles non concentriques.

Mais ce que ne dit pas ce schème de représentation, c’est précisément ce qu’il exclut :

  • il ne dit pas que la solution est loin d’être magique : à défaut de “solution” on a plutôt une boîte à outil qui permet de relier les fils entre eux, mais il faut se taper tout le boulot.
  • il ne dit pas qu’il exclut de facto tout ce qui n’est pas relié au bus. En reliant des applications au service, on enferme encore plus ses applications, ce qui rend le système d’information endogène : l’intégration interne se paye par une exclusion de l’entreprise aux données et aux services externes.

Mon sentiment peut paraître surprenant mais, eu égard à ces schémas de représentations, je pense que le schéma des spaghetti n’est pas une mauvaise chose en soi. Voilà pourquoi :

  • parce qu’on ne voit que les machines et pas les acteurs et les utilisateurs dans ce schéma. Ou sont les utilisateurs ?
  • on cherche à faire parler toutes les applications avec toutes les autres applications, mais pourquoi donc ? C’est comme si l’on s’épuisait à imaginer tout le champ des possibles en s’imposant cette contrainte un peu folle de vouloir tout connecter avec tout.
  • les données échangées ne sont comprises qu’au niveau des serveurs et pas au niveau des clients, la logique des mash-up, qui marche, permet les échanges au niveau des postes clients et pas au niveau des serveurs et des applications elles-mêmes. Les clients légers ou riches des architectures actuelles sont purement absents.

Ce qui se dégage de toute cette histoire c’est que le Business Model du software est très souvent un modèle qui consiste à identifier une douleur dans le Système d’Information  pour proposer une solution logicielle à cette douleur. Le logiciel joue ici son rôle de pharmakon, de médicament. Et son périmètre dans le système d’information est proportionnel à la taille de la tumeur qu’il est sensé traiter. Il est généralement vendu et “marketé” comme une boîte noire avec en entrée les problèmes et en sortie les solutions. Mais entre ? Que se passe-t-il ? Ouvrons le capot et regardons : que voit-on ? Tout d’abord que la source du mal n’a pas été éradiquée, elle est toujours là. On ne soigne que les symptômes du mal, pas le mal lui-même.

A force de reproduire ce schéma depuis des années, les grands systèmes d’information deviennent, bien souvent, proprement monstrueux. Car plus de logiciel demande toujours plus de logiciel : le code appelle le code. Mais qu’est ce qui a accéléré ce mouvement ? Un défaut initial , ou une négligence d’encodage des données manipulées par le code, c’est à dire un défaut d’architecture des données, de la on assiste à une excroissance du code : comme une huître faisant sa perle autour d’une poussière, mais malheureusement la perle en question est ici une tumeur.

Ceux qui prônent les démarches SOA ne sont pas idiots pour autant : ils reconnaissent qu’il n’y a pas vraiment de références significatives sur la mise en oeuvre d’une telle démarche, prennent d’infinies précautions en instant sur le fait qu’une telle démarche prend, à minima, une décennie avant d’aboutir réellement, et admettent que la plupart des projets SOA sont des échecs.

Ce qu’il y a d’intéressant dans leurs discours, c’est qu’ils soutiennent qu’il y a une “SOA de surface”, celle qui consiste à croire qu’un logiciel miracle va orchestrer les services web pour “aligner l’IT sur le métier”, qui est la cause de la plupart des échecs en matière de SOA. Comment donc appréhender une démarche de SOA afin d’éviter cet écueil ?

“Il ne faut pas commencer par les process et les services mais par les données, disent-ils. La SOA est une chaine de valeur qui commence avec la qualité des données, si ce maillon ne donne pas satisfaction il est illusoire qu’une SOA puisse se mettre en place”.

Étonnante rhétorique pour une démarche d’architecture orientée services qui affirme qu’il faut d’abord commencer par une architecture orienté ressources et données pour arriver à sortir quelque chose qui tient la route ! Pourquoi ne pas commencer directement par la ROA (Architecture Orientée Ressource) comme démarche d’architecture dérivée du style d’architecture REST ?

La raison vient de ce que la finalité des démarches SOA se place toujours sous l’injonction “d’aligner l’IT sur le Business”, la SOA est comme prisonnière de ce slogan. Ce qui n’est pas le cas de la ROA dont l’ambition est beaucoup plus pragmatique puisqu’il s’agit simplement d’aligner l’IT sur le Web : ses architectures, ses normes ainsi que ces usages et ses pratiques.

Quand on voit que ce sont essentiellement le secteur des banques et assurances qui s’essaient à ce type de démarche, je suis tenté de penser que la SOA est à l’IT ce que les subprimes ont été à la finance. Et la SOA serait finalement une démarche de titrisation de la piètre qualité des données dans les systèmes d’information pour valoriser des approches abracadabrantesques. Pourquoi vend-on de la SOA finalement, et pourquoi – parfois – çà marche ? Parce que c’est énorme et, comme pour les mensonges, plus c’est énorme et plus çà a de chances de passer.
Cela éclaire également la remarque de Fielding que j’évoquais récemment et que je traduirais volontiers de la manière suivante :

“La conclusion raisonnable de ceci est que la SOA n’est ni style ni une architecture, mais un ensemble d’objectifs qui peuvent être vendus à des DSI dépassés eut égard aux architectures qui seront réellement implémentées.”

In fine, là où je me désolidarise de Fielding c’est que je crois que la SOA est bien un style d’architecture, c’est le style d’architecture documentaire du power point. Certes, cela n’a plus grand chose à voir avec l’informatique, celle qu’on aime, celle qui marche et qui nous donne satisfaction.