Quand on en vient à l’interaction entre des machines informationnelles, revient toujours et systématiquement la question du “semantic gap”, qui est une façon condensée de dire :

“comment deux machines peuvent-elles se comprendre sans se connaître a priori ?”

http://neiceyford.com/wp-content/uploads/2013/08/iMessage-Icon.jpg

Je précise “sans se connaître a priori” car si un même concepteur doit interfacer deux systèmes, alors le gap sémantique est de facto résolu par le concepteur lui même : maîtrisant les deux machines dialoguantes, il ne fait finalement que se parler à lui-même au travers d’une répartition des tâches qu’il planifie entre deux composants logiciels.


La quasi totalité des Systèmes d’Information (SI) des organisations ne sont pas sensibles au gap sématique parce qu’il s’agit de leur SI, qui est en fait un espace d’écriture, d’échange et de publication privé et non ouvert ou public. Si l’organisation a un problème d’interopérabilité entre ses différents silos applicatifs il ne tient qu’à elle à résoudre ce problème qui est son problème.

La question est tout autre quand on ne parle plus d’un Système d’Information privé mais d’une architecture applicative étendue et publique comme l’est le web. De fait, la question du gap sémantique est très présence dans le web des machines qui souffre en permanence de la comparaison avec le web comme interaction entre les machines et les hommes, ces derniers prenant en charge les questions sémantiques puisque c’est l’utilisateur qui décide de son cheminement dans les ressources. Le gap sémantique est ce qui empêche que les machines puissent elles-mêmes décider de leur cheminement dans les ressources du web..
Les architectures applicatives clients/serveurs offrent des normalisations (protocoles applicatifs) qui assurent une certaine généricité des échanges. Mais ces protocoles ne disent rien de la manière dont les composants peuvent prendre des décisions.

Si je connais exactement l’enchaînement des séquences (des questions-réponses entre le client et le serveur) je peux très bien automatiser cela, car le processus ne nécessite pas de prise de décisions côté client (ses requêtes sont connues d’avances, elles sont pro-grammées).

Mais alors, comment faire pour que le client acquiert une plus grande autonomie dans la manière dont il va faire ses requêtes au serveur ?

Il n’y a qu’une façon réellement sérieuse de pouvoir répondre à cette question et elle consiste tout d’abord à renvoyer dos-à-dos ceux qui parlent du web uniquement à partir de la distinction entre client et serveur. D’ailleurs, dans le métier des Sociétés de Services Informatique on prend bien soin de distinguer ceux qui travaillent “côté serveur” et ceux qui travaillent “côté client”.

Le cliché veut que les premiers sont les vrais ingénieurs, les vrais développeurs, ceux qui sont du côté de la maîtrise à la fois des données mais aussi des processus métiers, là où les seconds sont des charlots parfois un peu trop créatifs qui bidouillent le HTML & CSS et se réunissent une fois l’an à Paris Web pour tergiverser sur l’accessibilité et s’émouvoir qu’une feuille de style puissent avoir un décalage de deux pixels entre le rendu sur Chrome et sur celui de Firefox.

C’est une vision assez réductrice des choses qui pourtant est très opérante sur le marché – aussi bien côté prestataires que commanditaires – et qui reproduit la veille distinction entre “back” et “front”.
Cette distinction perd heureusement de son sens à vitesse grand V  d’une part à mesure que du code s’exécute dans les navigateurs web, côté client donc (merci JavaScript) et d’autre part parce qu’il y a des développement aussi bien côté serveur que côté client comme le voit avec les APIs. En effet, le client ne peut plus se résumer à un terminal de publication ne faisant qu’afficher les réponses aux requêtes décidées par l’utilisateur.

Si l’on refuse cette partition de plus en plus artificielle entre le monde côté serveur et le monde côté client il faut donc acter qu’il y a du code qui s’exécute aussi bien côté client (et pas seulement pour faire de l’affichage)  que côté serveur ; et que donc le seul moyen de traiter la question du gap sémantique est de rester dans l’entre-deux. Et qui y a il dans l’entre deux ? Des messages qui s’échangent.
La seule chose qu’un serveur voit d’un client ce sont les messages de requête qu’il reçoit  de lui ; et la seule chose qu’un client voit d’un serveur ce sont les messages de réponse qu’il reçoit de lui.

La seule façon de progresser dans la résolution du gap sémantique, et de faire que le client puisse prendre quelques décisions avec une certaine autonomie, est de mettre l’emphase sur l’architecture applicative en tant qu’elle est une architecture de messagerie. Le travail de conception est différent quand on part du message lui-même ; de ce message qui assure l’interface entre le client et le serveur.
En matière de conception d’API, le fait de ne pas travailler selon une “architecture orientée message” a une conséquence quasi immédiate et systématique, comme le dit avec humour David Larlet :  l’API n’est alors qu’un autre nom donné à service de conversion de format de donnée.

@ChristianFaure you mean APIs are just another label for converting a flow of data from one format to another? 😉

— David Larlet (@davidbgk) September 30, 2013


Il faudrait effectivement pouvoir concevoir une API web autrement que comme un convertisseur de format. Pour cela il faut commencer par oublier les logiques focalisée client ou serveur, c’est d’abord cela se mettre dans l’état d’esprit d’une architecture orientée message.

Enfin,  en parlant d’Architecture Orienté Message,  je précise qu’ il ne s’agit pas de remettre à la mode les Middleware Orientés Message d’il y a 15 ans, qui existent encore dans les Systèmes d’Information des organisations et qui ont ensuite produit les EAI/SOA/ESB qui ne répondent nullement aux enjeux du gap semantique dans des architectures applicatives distribuées, ouvertes et publiques.

C’est finalement une approche très “philosophical engineering”, comme dirait Tim Berners Lee, que de dire que les termes d’une relation (ici client-serveur) ne préexistent pas à leur relation, mais bien au contraire que c’est la relation elle-même qui produit les termes qu’elle relie ( les clients et les serveurs). C’est une approche qui est presque devenue un lieu commun dans le champ philosophique depuis plusieurs décennies et qui aurait tout intérêt à être prise très au sérieux dans l’ingénierie logicielle.