Défaut: Architecture Intelligence milieu_associé milieu_dissocié REST SOA
by Christian
6 comments
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 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 ».
Au vu de la capture d’écran, il semble qu’un fonction de zoom écran engendre une extrapolation bitmap, sans recours aux fonctions vectorielles du générateur de caractères.
Voir du côté des paramètres d’accessibilité ?
[Reply]
Intéressante approche que je n’avais jamais envisagée sous cet angle, et encore on ne parle ici que de l’architecture d’accès aux données et non des données en elle-même. Point encore plus sensible… les tours d’ivoire ont encore de longs jours devant elles.
Tiens à ce sujet, est-ce que tu vois une différence d’adoption entre la France et ses voisins européens/et d’autres continents ? (je ne sais pas si tu vas jusque là ou si tu as des échos).
ps : Jean-no ne doit pas avoir de polices Lucida, tu devrais en mettre une dernière plus lisible/courante par défaut dans ta css.body.
[Reply]
Je citerais plutôt le « code is law » V2 de Lessig que l’age de l’accès
http://codev2.cc
[Reply]
J’ai commencé l’article en pensant qu’il était question d’architecture bâtie, et à la réflexion, ça doit aussi s’appliquer au sujet. La généralisation de l’open-space fait très Jeremy Bentham, par exemple.
Note : chez moi, tes pages ne s’affichent pas super, je les lis bien dans mon newsreader mais si je vais directement sur le site ça donne ça
[Reply]