Dans son Post-scriptum sur les sociétés de contrôle (1990), Deleuze commence par rappeler le travail fait par Foucault qui a décrit l’avènement des sociétés de disciplinaires des 18° et 19° siècles, qui atteignent leur apogée au 20° siècle :

Elles [les sociétés disciplinaires] procèdent à l’organisation des grands milieux d’enfermement. L’individu ne cesse de passer d’un milieu clos à un autre, chacun ayant ses lois : d’abord la famille, puis l’école (« tu n’es plus dans ta famille »), puis la caserne (« tu n’es plus à l’école »), puis l’usine, de temps en temps l’hôpital, éventuellement la prison qui est le milieu d’enfermement par excellence.

Cette logique est à présent arrivée à terme et vit une importante période de crise:

Nous sommes dans une crise généralisée de tous les milieux d’enfermement, prison, hôpital, usine, école, famille. La famille est un « intérieur », en crise comme tout autre intérieur, scolaire, professionnel, etc. Les ministres compétents n’ont cessé d’annoncer des réformes supposées nécessaires. Réformer l’école, réformer l’industrie, l’hôpital, l’armée, la prison ; mais chacun sait que ces institutions sont finies, à plus ou moins longue échéance. Il s’agit seulement de gérer leur agonie et d’occuper les gens, jusqu’à l’installation de nouvelles forces qui frappent à la porte.

Ce qui frappe à la porte, c’est l’avènement des sociétés de contrôle :

Ce sont les sociétés de contrôle qui sont en train de remplacer les sociétés disciplinaires. « Contrôle », c’est le nom que Burroughs propose pour désigner le nouveau monstre, et que Foucault reconnaît comme notre proche avenir.

Le contrôle dont parle Deleuze n’est pas tant le fait d’une logique de la « manipulation » que d’une logique de « modulation ». Celle-ci passe par le protocole d’un réseau. Or, sur le réseau, comment se redéfinit la souveraineté ? Si le réseau est l’instrument d’un contrôle, comment s’exerce-t-il et par qui, maintenant que les frontières au sein des institutions des sociétés disciplinaires se délabrent et deviennent poreuses ?

On pourrait ici rappeler le titre du livre de Jeremy Rifkin sur l‘Âge de l’accès, car la souveraineté sur le réseau passe en partie par le contrôle de l’accès aux informations (en l’occurrence numériques). On peut être dans le réseau sans pour autant jouir de toutes les modalités d’accès et de navigation : il faut des passes, des logins et des passwords. Il faut s’identifier et être identifié pour qu’une topologie du réseau s’instancie pour nous, pour qu’une connexion s’établisse et qu’une porte s’ouvre.

Parlant de réseaux, il faut différencier certaines typologies de réseaux, et donc de protocoles. Une des spécificités du protocole web est sa topologie de milieu associé qui fait de lui le réseau sur lequel les logiques dissociées – qui continuent à exercer une forme de souveraineté sur des réseaux de distribution dissociés – sont inopérantes.

Cette longue introduction, et je m’en excuse, n’était là que pour tenter d’expliciter les motivations qui peuvent – inconsciemment ou non – pousser une entreprise à faire certains choix engageant en matière d’architecture de son système d’information. Par exemple en choisissant de faire un projet SOA (Service Oriented Archtitecture) en privilégiant une archtiecture technique s’appuyant sur SOAP et les Web Services plutôt que sur un style d’archtiecture REST.

Bien souvent le choix se portera sur SOAP si l’entreprise veut faire de son projet la (re)conquête d’une souveraineté : mettre au pas une organisation éclatée avec des processus différents, dans différentes branches ou différents pays. L’intérêt de l’architecture SOAP étant qu’elle propose une architecture distribuée tout en maintenant des règles strictes et centralisées d’accès et de diffusion des informations.

Dans le cas de SOAP on utilisera le protocole HTTP uniquement comme protocole de transport, c’est à dire que l’ensemble des méthodes et des informations seront placées dans des enveloppes remises au « facteur HTTP ». On se refuse donc à exploiter HTTP en tant que protocole applicatif (avec son interface uniforme), ce qu’il est pourtant, et qui est précisément ce sur quoi met l’emphase le style REST.

Que SOAP ne marche pas techniquement, qu’il soit une aberration architecturale puisqu’il utilise le protocole HTTP pour distribuer ses objets en traitant une ressource distante sur le réseau comme une ressource locale, bref tout les arguments techniques (et financiers) ne pèseront pas dans la balance. Le style REST ne sera pas retenu car il ouvre la porte à la totalité de la logique du protocole applicatif HTTP, c’est à dire à la logique d’un milieu associé dans lequel la gouvernance induit de penser à nouveau frais la question d’une souveraineté du système d’information. Celle-ci passera nécessairement par une politique basée sur la participation qui, de facto, impose que l’on croit en la possibilité d’une intelligence collective au sein de l’entreprise.

Maîtriser l’accès et la sécurité (en tout cas le croire), forcer des usages et imposer des pratiques sont infine les arguments explicites ou implicites qui persuadent les décideurs, et ce au moins autant que la viabilité technologique et la pertinence des solutions qu’ils doivent implémenter. Le web, peu d’entreprises en veulent vraiment derrière leur firewalls : on veut bien « webiser » des écrans d’applications, utiliser HTTP mais uniquement comme protocole de transport et se donner l’illusion que l’on fait du web parce que l’on a des « Web Services », mais accepter le web, le vrai, cela impliquerait de revoir ses conceptions de la souveraineté ainsi que la force avec laquelle on croit aux mots que l’on prononce lorsque l’on dit que « les salariés sont la première richesse de l’entreprise ».

Related posts:

1. Il faut plus qu’un homme et une femme pour faire un enfant La psychanalyse freudienne porte en elle une certaine vision dans...
2. Réponse à une objection sur « la prolétarisation dans les sociétés informatiques » Didier Girard, sur Application Servers , fait une remarque intéressante...
3. L’implicite et l’explicite dans les réseaux sociaux On peut dégager deux tendances dans la constitution des réseaux...

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.

Related posts:

1. La vérité sur la SOA Roy Fielding, a propos des SOA, des « Service Oriented Architecture »...
2. C’est quel éditeur qui fait çà ? Je croise un consultant qui travaille sur les architectures de...
3. Une certaine conception de la souveraineté s’exprime aussi dans les choix d’architecture Dans son Post-scriptum sur les sociétés de contrôle (1990), Deleuze...

Roy Fielding, a propos des SOA, des « Service Oriented Architecture » sur la liste de discussion REST :

The reasonable conclusion is that SOA is neither an architecture nor a style, but rather a set of goals that can be sold to overmatched CIOs regardless of the corresponding architecture or implementation.

Related posts:

1. Ars Industrialis sur Twitter Vous pouvez à présent suivre l’actualité d’Ars Industrialis sur Twitter....
2. Le profilage collaboratif sur Twitter Les listes de twitter vous renvoient à présent des mots...
3. Le style d’architecture SOA Invité comme conférencier à la réunion annuelle des directions informatiques...