Les réseaux sociaux d’entreprise : pourquoi maintenant ?

Malgré plusieurs essais majoritairement décevants ces dernières années, l’introduction des réseaux sociaux dans les grandes entreprises connaît une très forte accélération depuis fin 2010.

Pourquoi maintenant ?

La première cause semble être bien évidemment la force de propagation des services de réseaux sociaux sur le web. C’est certainement une condition nécessaire, mais elle n’est peut être pas suffisante. Deux autres causes peuvent expliquer ce momentum :

• Un début de maturité des offres à destination des entreprises. Cela veut dire qu’un marché se constitue et donc qu’il y a une logique de conquête mise en place par les vendeurs de solutions. On a connu çà à plusieurs reprise dans le marché des services informatiques : il y a un effet marketing indéniable qui conditionne les clients dans les entreprises et pousse à des comportements grégaires et mimétiques. On en vient ainsi à entendre : « l’entreprise qui n’a pas son propre réseau social est has been ».
• Ensuite il y a un risque de fragmentation. On voit bien que chaque éditeur de logiciel, ou fournisseur de services logiciels, commence à proposer un module « social » à son catalogue. Le CRM a son Réseau Social, l’ERP également, les solutions de RH et de Talent Management de même. Il y a donc un risque éminent d’avoir une offre fragmentée des réseaux sociaux dans l’entreprise. Or, quand on sait que l’intérêt d’un réseau social réside premièrement dans l’effet de réseau, il y a une course contre la montre pour essayer d’« imposer » un réseau global avant que les différents départements de l’entreprise n’aient chacun le leur.

Toujours est-il que c’est parti : les projets de mise en oeuvre se multiplient en 2011.

Les réseaux sociaux comme technologies de publication et d’auto-publication

Les logiques de partage et de collaboration sont au coeur des motivations des entreprises qui mettent en place des services de réseaux sociaux d’entreprise. Or, partager signifie avant tout publier des informations (rendre public, même avec certaines restrictions)

Non seulement les services de réseaux sociaux sont des systèmes de publication mais il faut aller encore plus loin en précisant que ce sont des outils d’auto-publication.

Aussi la première question que se pose un utilisateur est immanquablement la suivante : qui peut voir ce que j’écris, ce que je publie ? Où est-ce que çà va tous ces messages ?

Il faut bien comprendre qu’avec plusieurs dizaines de milliers d’utilisateurs potentiels du service de réseau social dans l’entreprise, nombreux sont ceux n’ont jamais eu de blog, ne savent pas ce qu’est un agrégateur de news, et n’utilisent pas de services de réseaux sociaux publics (ce dernier point change rapidement) ; alors forcément, quand on met ces utilisateurs devant un mur de messages qui crépitent comme les dépêches de l’AFP, c’est la paralysie totale assurée et on tombe souvent sur ce constat emprunté à l’art des soufflets : « çà ne prend pas ».

La plupart des raisons qui font que « çà ne prend pas » se ramènent à la confusion qu’il y a à utiliser un système d’auto-publication, qui plus est dans le contexte de l’entreprise.

Destinataires et destinateurs

Puisque les réseaux sociaux sont des outils de publication et d’auto-publication, la première question d’un utilisateur est donc : « qui voit ce que j’écris? ». Cette question sur le (ou les) destinataire(s) met en retour en question le destinateur qui n’est autre que l’utilisateur qui se retrouve dans une position d’auteur, ce qui n’est pas la norme dans les entreprises.

En effet, dans les entreprises, peu de documents ( ne parlons même pas des données) sont pensés et produits comme étant un  travail d’auteur. Il y a certes des auteurs dans les documents bureautiques, mais ce sont le plus souvent ceux qui ont créé ou enregistré les fichiers et, en tout état de cause l’auteur s’efface derrière le processus au sein duquel a lieu la création du document.

La réalité est que les documents et les données appartiennent à des départements, des filiales, voire des applications, mais les auteurs de ces documents et ces données sont à l’arrière scène, ils ne sont jamais vraiment exposés en tant que tels. Quand il s’agit de communication, c’est le chef qui parle et qui communique pour ses équipes. Mais voilà qu’on leur donne un outil de publication pour d’envoyer des messages à tout le monde. C’est alors moins de l’enthousiasme qu’un sentiment de perplexité qui domine (mention spéciale pour le secteur banque et assurance).

La mise en place des réseaux sociaux d’entreprise fait donc sortir de l’anonymat le profil des utilisateurs pour les mettre en position d’auteur. C’était déjà en partie le cas avec les outils 2.0 comme le blog et le wiki, mais on sait que ces usages 2.0 ont un encéphalogramme plutôt plat dans les entreprises. En fait, s’’il y a bien un service qui met depuis longtemps l’utilisateur en positon d’auteur c’est assurément la messagerie électronique.

Messageries électroniques et Messageries Sociales

La messagerie électronique est en effet l’outil de communication où ces questions de destinataires et de destinateurs se sont posées très tôt. Et elles continuent à se poser : apprendre à rédiger des mails, savoir faire des réponses et utiliser les champs de destinataires à bon escient est une exigence de tout les jours, et les bonnes pratiques prônées ici ou là sont encore loin d’être des pratiques répandues.

Malgré tous les couacs que la messagerie électronique génère tous les jours dans les entreprises, il n’en demeure pas moins que c’est très largement l’outil le plus utilisé. Et comme ce « succès » se paye par un temps passé de plus en plus important à « dépiler sa correspondance électronique », on a de suite pensé aux réseaux sociaux comme un service pouvant remplacer la messagerie électronique.

Sans entrer dans ces logiques d’opposition, il est plus souhaitable d’arriver à proposer une logique de composition entre un service de messagerie électronique et celui d’un réseau social. C’est en tout cas ce qu’on compris certains fournisseurs de services de réseau social d’entreprise en proposant des modules intégrés à Outlook.

Exemple avec le module Outlook de JIVE :

Articulation entre Web 2.0 et Réseaux Sociaux

Il faut à présent faire une précision importante relative à la distinction entre ce que l’on appelle le web 2.0 et la vague actuelle des réseaux sociaux.

Tout d’abord il faut souligner à quel point ces deux mouvements ont lieu sur une même plateforme applicative qui n’est autre que le web et que nous comprenons ici essentiellement comme un système de publication, et donc de partage.

L’architecture du web a fait le succès des démarche de partage et de collaboration parce que, en tant que système publication, chaque document est à la fois identifié et accessible via son URL. Partager, c’est d’abord partager ces identifiants que sont les URLs, quelle que soit la ressource partagée et le type du document (.jpg, .flv, .mov, .doc, .xls, .html, .xml, etc.).

Selon la nature du document, plusieurs services de publication et de partage sont historiquement apparus sur le web :

• partager des CVs (LinkedIn, Viadeo)
• partager des vidéos (Youtube, Dailymotion)
• partager des images et des photos (Picasa, Flickr)
• partager des réflexions, des convictions ou des passions, des articles (blogs)
• partager des interrogations et discussions collectives, Q&A (forum, StackOverflow, Yahoo! Answers, Cora)
• partager des textes et des documents (wikipedia, knowl)
• partager des statuts and des micro-messages (twitter, Identica)
• partager des géolocalisations (foursquare)
• partager des bookmarks / favoris (delicious)
• etc.

Tous ces services de partage sont couplés à des profils d’utilisateurs, et l’on peut remarquer que, sur le web, la collaboration a évolué  : après les solutions de partage dédiées à des types de documents spécifiques on a assisté à des solutions généralistes de partage (les réseaux sociaux) pour n’importe quel type de documents ; les réseaux sociaux se présentant ainsi comme des plate-formes de meta-sharing.

Dès lors que l’on peut partager n’importe quoi (un message, un texte, une photo, une localisation) ne serait-ce que par l’URL, l’architecture du service n’est plus orienté autour du document mais autour du profil. Ainsi, dans le couple document/auteur c’est le document qui était la majeure dans les solutions de partage 2.0, avec les services de réseaux sociaux c’est le profil qui devient la majeure.

Cette inversion de majeure entre document et profil a une conséquence immédiate sur l’architecture technique des solutions : une architecture technique « orientée document » n’aura pas la possibilité qu’a les architectures « orientées profils » d’avoir, sur une même page, un hub d’agrégation des messages. C’est là le signe manifeste qu’on est sur un « vrai » service de réseau social.

La temporalité des réseaux sociaux

Ce changement de majeure, qui passe du document au profil, ne va pas sans influer radicalement sur la temporalité des services et de leurs usages. En effet, selon que le système est structuré autour des documents ou autour des profils, on a deux logiques différentes.

Dans les réseaux sociaux, compris comme des plate-forme de micro-blogging, c’est la logique d’un flux de messages qui prime : l’attention se concentre sur le dernier message, publié en « temps réel », avant qu’il ne soit lui-même détrôné par un nouveau message. C’est la crête des messages, pour ne pas dire le crépitement, qui prime. Les messages de quelques heures n’ont que peu leur place, perdus qu’ils sont dans la longue traîne du flux de publication.

En ce sens, les plate-formes de réseaux sociaux sont des boucheries de texte encore plus affutées dans leur manière de découper que celle des blogs dont elles poursuivent toutefois la logique initiale. Je parle ici de boucherie au sens où la dialectique de Platon est comme un couteau de boucher pour mettre au jour et expliciter l’articulation des parties d’un discours. C’est le même couteau qui participe processus de grammatisation.

Mais revenons à la temporalité des réseaux sociaux : au contraire d’eux , les services de partage orientés-documents sont moins portés sur les activités en temps réel. Ainsi un document peut-être ancien tout en gardant sa pertinence et son importance dans le cadre d’une entreprise. Si la logique des réseaux sociaux est à rapprocher de celle d’un flux, celle de la documentation serait plutôt celle d’un  espace géométrique.

Pour le dire de manière savante, avec les réseaux sociaux nous sommes dans une logique synchronique (dans le même temps, dans un temps partagé jusqu’à la simultanéité) alors qu’avec les logiques documentaires nous sommes dans une logique diachronique (des temps différés avec des sédimentation documentaires). Je n’en dirai pas plus ici car, sur ces questions de synchronie et de diachronie (qui sont convoqués dans les séminaires actuels de Bernard Stiegler) je n’arrive pas à être clair et précis.

Multiplicité et conflit des identités

Si, comme je l’évoquais en introduction, tous les services (et notamment plusieurs services de réseau social) dans l’entreprise ont des profils associés à chaque utilisateur, on constate un risque de fractionnement des profils (après les applications en silo, des profils en silo).

Il est évident que dans le monde de l’entreprise, les solutions sont apportées par les logiciels d’Identity Management, dont le but  est précisément d’assurer un méta-profil connecté à l’ensemble des services. Aussi est-il nécessaire d’inclure la logique des méta-profils au coeur même des démarches de réseau social car, de fait,  le réseau social est le service qui met à jour l’activité liée aux profils de l’annuaire d’entreprise.

La question des « cas d’usages » pour un réseau social généraliste dans l’entreprise et le syndrome du « pilote ».

Définir des cas d’usages des réseaux sociaux est un vrai challenge car ce type de solution est très ouvert et l’expérience sur le web montre que les pratiques des utilisateurs déterminent des usages qui, bien souvent, n’ont pas été imaginé dans la conception initiale du réseau social.

C’est bien parce que ces outils proposent un espace de publication vers des destinataires que la nature d’un réseau social pour 100 personnes peut ne plus être la même pour 10 000 personnes. Ici le quantitatif sur-détermine la nature du qualitatif ; a quoi bon, dès lors, faire des « pilotes » puisque leurs conclusions sur un périmètre restreint ne seront pas généralisable ?

De même, la tendance synchronique des réseaux sociaux porte à penser que leur utilisation dans le cadre de situation de crise serait opportune. Or, le principal problème rencontré est que, en situation de crise, les gens ne peuvent pas utiliser un outil s’ils ne sont pas déjà familier avec lui. Pour un utilisateur novice des réseaux sociaux, ne pas savoir à qui on s’adresse et comment fonctionne la publication des messages est une barrière immédiate pour utiliser l’outil, qui plus est en situation de crise.

Il y a donc paradoxe apparent : bien qu’adapté au temps réel, les outils de réseaux sociaux ne fonctionnent dans ces situations que si les utilisateurs pratiquent régulièrement l’utilisation du Réseaux Social avant et hors de situation de crise.  Il faut donc proposer des usages qui s’inscrivent plus dans l’organisation quotidienne du travail, sans chercher à monter des pilotes pour des situations exceptionnelles.

De toute manière, un pilote de réseau social semble manquer systématiquement ses objectifs car le miniature n’est pas un reflet pertinent du réel pour évaluer les apports « sociaux » de ces technologies que nous avons appelé par ailleurs des technologies relationnelles.

Au delà du réseau social généraliste

Je ne saurai dire si les réseaux sociaux généralistes et globaux s’implanteront durablement dans les entreprises. En revanche je ne crois pas me tromper en disant que l’Identity Management et la gestion des méta-profils sera un vrai enjeu qui non seulement est nécessaire aux réseaux sociaux, mais également à ces nouvelles formes de technologies relationnelles que l’on voit apparaître et qui auront peut-être encore plus de succès dans les entreprises.

Je veux ici parler des solutions de Q&A couplées à des logiques d’identité numérique (réputation) dont les exemples sur le web sont Quora ou Stackoverflow. Karl me faisait remarquer que tous ces rewards et ces badges pour gérer collectivement la réputation faisaient un peu « boyscout » ; or le monde de l’entreprise aime parfois beaucoup le boyscoutisme et son côté « employee of the month » (ce qui est toutefois nettement moins le cas en France qu’aux US).

Signaler sur Twitter

Related posts:

1. Livre sur les Réseaux Sociaux Je suis un des auteurs du livre sur les Réseaux...
2. L’implicite et l’explicite dans les réseaux sociaux On peut dégager deux tendances dans la constitution des réseaux...
3. Il y a bien une science des réseaux sociaux Si j’ai parlé d’un nécessaire retour au structuralisme à notre...

Je suis donc intervenu au RIA 2008 d’Adobe en insistant sur trois points, que je crois essentiels, lorsqu’on parle des RIA.

La qualité des données.

Les « Rich Internet Applications » n’ont de sens que dans une architecture orientée ressources, puisque nous sommes dans la quatrième vague d’architecture des systèmes d’information, celle que je nomme DataWare (après les phases de Hardware, Software et Netware). Le découplage entre les données et les interfaces qui les utilisent, implique une attention particulière aux données, à leur qualité ainsi qu’à la manière dont on les expose (notamment avec les logiques d’API).
Ainsi, ce n’est pas tant une architecture de service (une SOA) dont nos systèmes d’information ont besoin, car même ceux qui prônent une architecture de service sont aujourd’hui les premiers à dire que cela n’est possible que s’il y a déjà une architecture des données, une architecture orientée ressource, sous-jacente.

Une qualité des données déplorable dans un système d’information et c’est tout l’édifice qui menace de s’écrouler. La mauvaise qualité des données est le cancer de nos systèmes d’information mais, bien que chacun a intimement conscience qu’il faut faire quelque chose, personne ne sait comment et par quel bout il faut commencer.

Or je suis intiment convaincu que la qualité des données métiers d’un système d’information est directement corrélée à la qualité des interfaces applicatives. Combien de fois avons nous vu des interfaces insipides et incompréhensibles où les utilisateurs, ne sachant quoi mettre, finissaient pas remplir les champs en mettant « titi », « tata », et « toto ». Seulement voilà, les « titi », « tata » et « toto », on va les retrouver dans les bases de données et dans le reporting. Aussi, le premier levier dans l’amélioration de la qualité des données passe par là où elles rentrent, dans la phase de saisie, c’est à dire via l’IHM. On notera à ce propos le partenariat entre SAP et Adobe qui vise à mettre une couche de RIA en Flex en remplacement des écrans SAP (que personne ne regrettera).

Un projet RIA amène donc nécessairement la question de la qualité des données au coeur des discussions, non seulement pour les données qui seront consultées mais également pour celles qui seront saisies via ces nouvelles interfaces.

L’alignement de l’IT sur le Business.

« Aligner l’IT sur le Business », vous entendez peut-être comme moi depuis maintenant de nombreuses années cette injonction. Or c’est faux. Il s’agit là d’une énormité, d’un leurre, il ne faut en aucune manière aligner l’IT sur le business.
D’abord parce que ce slogan induit une logique d’allégeance d’un département de l’entreprise vis à vis d’un autre, et cela ne mène qu’à des querelles de chapelles et, in fine, à un système féodal avec ces baronnies et ces mécanismes de servitude. En effet, véhiculer une telle approche c’est vouloir faire de la DSI les soutiers de l’organisation et ça, ce n’est pas possible.
Ensuite, parce que l’histoire ancienne et récente nous apprend que ce sont toujours les systèmes techniques qui provoquent des désajustements par rapport aux autres systèmes que sont les systèmes sociaux, juridiques, économiques, etc. Si quelqu’un devait s’aligner, ce serait donc bien plutôt au métier de s’aligner sur les opportunités technologiques offertes par le système technique du web.

Mais les innovations techniques et technologiques doivent être socialisées, tout comme il a fallu socialiser des inventions comme le dentifrice ou le vélo : personne en effet ne voulait se mettre de la pâte de fluor dans la bouche, tout comme personne ne pensait que l’on pouvait tenir en équilibre sur deux roues. C’est d’ailleurs pour cela que le tour de France à été créé : pour démontrer au grand public que l’on pouvait tenir en équilibre sur une bicyclette. Et ce n’est qu’à partir de ce moment que les ventes de vélos ont décollé. Pour filer la métaphore, le web est aujourd’hui un « tour de France pour des DSI » : il montre que oui, c’est possible, on peut faire plus simple, plus efficace et pour moins cher.

Toujours est-il que si les DSI persistent à ne pas voir les innovations du web d’aujourd’hui, les métiers, eux, les voient tous les jours ; et ils n’ont pas une patience infinie. A la DSI de prendre ses responsabilités et « d’innover le métier » en promouvant les opportunités du web.

L’IT ne doit pas s’aligner sur le business, pas plus que le métier ne doit s’aligner sur l’IT. Il ne faut pas opposer l’IT et le Business, les deux doivent composer. Ce n’est pas une question d’alignement mais de réajustement, précisément d’un réajustement suite au désajustement du web.

Or il me semble que c’est tout particulièrement dans un projet RIA que départements métiers et informatique doivent réinventer leur relation. Ce qui m’amène donc à présenter les nouveautés qu’apportent les RIA dans le design et la conception des solutions informatiques.

Un nouveau design

C’est donc dans le contexte que je viens d’évoquer rapidement que les RIA peuvent apporter de la valeur car :

• il y a un découplage entre les données et les services qui permet une évolution maîtrisée et non conflictuelle entre MOE et MOA, entre IT et Business. En effet, la répartition des responsabilités est beaucoup plus aisée dans les architectures orientées ressources car la granularité des données est beaucoup plus fine que ces lourds processus d’entreprises supportés par les progiciels.

• il y a une « expérience utilisateur » qui tend à se rapprocher d’une expérience cinématographique (et ce n’est pas pour rien que derrière, au niveau du code, on parle de programmation évènementielle). Faire d’une application un flux, plutôt qu’une succession d’écrans statiques, cela implique de nouvelles pratiques dans le design et la conception des applications, notamment grâce à un effort de scénarisation.

Cette logique d’application, qui devient un flux continu, se retrouve dans la possibilité de faire des « Undo » plutôt que d’avoir des « Pop-Up de confirmation ». Tout comme un film, on peut en permanence revenir en arrière : faire des avances et des retours rapides dans le traitement d’un processus. Ceux qui utilisent des logiciels comme Photoshop sont déjà habitués à telles pratiques.

On a longtemps comparé les projets informatiques au BTP (maîtrise d’oeuvre, maîtrise d’ouvrage, cahier des charges, etc.). Avec les RIA, il peut-être temps de comparer un projet informatique à un projet cinématographique (producteurs, scénariste, réalisateur, monteur, etc.)

Related posts:

1. Adobe RIA 2008 A l’invitation d’Adobe, Je ferai l’allocution d’ouverture de l’évènement annuel...
2. Vers les « Semantic RIA » La question d’une interface graphique (IHM) pour la navigation et...
3. Sens et enjeux des modèles de stockage et d’accès aux données C’est typiquement le genre d’article qui nécessite des corrections, des...

A l’invitation d’Adobe, Je ferai l’allocution d’ouverture de l’évènement annuel RIA 2008 qui aura lieu le 16 Décembre à partir de 10 heures à Coeur Défense.

Il y aura des gens intéressants comme Vivek Badrinath, le directeur technique d’Orange / France Telecom, Michael Chaïze d’Adobe (que j’apprécie particulièrement) ainsi que des témoignages d’entreprises : ETAM, M6, Geodis, SNCF, MAAF Assurances, etc.

C’est gratuit mais il faut s’inscrire au préalable sur le site.

Related posts:

1. La représentation graphique de l’information Maintenant que la quantité d’information, particulièrement sur le web, a...
2. Cloud Computing 2008 J’organise, avec Didier Girard et le Benchmark Group l’évenement Cloud...
3. La chaîne du livre en France Pour le profane que je suis et qui entend souvent...

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...

Google vient de rajouter la video dans son Offre Google Apps. Chaque entreprise ayant Google Apps bénéficie de ce « YouTube pour l’entreprise » avec 3 Gigas par utilisateur.

La video de présentation :

De quoi faire revivre certains intranets un peu moribons et faire de la communication et du partage avec plus d’efficacité ?

C’est de plus en plus difficile de justifier un non-choix de Google Apps pour une organisation. D’ailleurs, nous en parlerons avec Google ce Mardi 9 Septembre, si çà vous intéresse.

Related posts:

1. Google Apps Engine C’est mon collègue, l’excellent Franck Emsallem, qui m’apprend à l’instant...
2. Les « apps stores » débarquent dans les entreprises C’est apparu récemment avec Google Apps qui donnait accès au...
3. Stage Google Apps Engine [Message à caractère professionnel] Pour faire suite à l’annonce de...

Le blog sur le thème de l’Entreprise 2.0, fait par les acteurs d’Atos Origin France travaillant sur ce sujet est certainement une bonne source d’information à rajouter dans vos agrégateurs et bookmarks si le sujet vous intéresse.

C’est Bruno Paul qui vient de l’inaugurer, et il me lance des fleurs : on ne pouvait pas rêver meilleur départ !

Nos principales motivations sont :

• de ne pas faire de la langue de bois
• de communiquer notre passion et nos convictions
• de valoriser nos compétences aussi bien à l’intérieur qu’à l’extérieur de l’entreprise
• d’attirer des talents dans nos équipes
• d’instaurer un lieu d’échange et de discussion

Si j’en juge par l’image du header, ce sera un lieu cooool

Related posts:

1. Que peut-il faire pour vous ? Assurément il peut faire beaucoup pour vous si vous avez...
2. Par ailleurs, les technologies de l’information deviennent une industrie de masse C’est une danse parfois douloureuse à laquelle le trio Entreprise/Editeur/Conseil...
3. Je ne suis pas un expert IBM Software et les organisateurs du salon ICC’2007 m’ont gentiment...

L’entreprise 2.0 est constitutive de deux tendances majeures :

• La première tendance est celle du web 2.0 où il s’agit, comme on s’en doute, de mettre du web 2.0 dans le système d’information de l’entreprise.
  
• La deuxième tendance est celle du « Software as a Service« , voire du « quelque chose as a Service » (XaaS), qui constitue une nouvelle façon de consommer les technologies de l’information, avec de nouvelles offres portées par de nouveaux acteurs dans le périmètre de l’entreprise.

Les deux tendances sont très intimement liées en ce sens que les solutions web 2.0 que le grand public connaît sont toutes, originairement, en mode Software as a Servce (SaaS). C’est à dire qu’aucune installation sur l’ordinateur individuel n’est requise : on accède directement à l’interface d’une application SaaS en utilisant un navigateur web, ce qui implique, comme on le verra, que les donnés soient stockées ailleurs que sur l’ordinateur, où dans le système d’information de l’entreprise. Elles sont souvent hébergées et gérées par l’acteur SaaS lui-même.

Commençons par le Web 2.0.

Premier constat, dès que l’on évoque le web 2.0 dans des réunions d’entreprise, les discussions partent dans tous les sens. C’est un sujet qui souvent passionne et où chacun a sa propre compréhension, mais cet enthousiasme et cette profusion fait souvent peur aux décideurs en entreprise. Ils n’y voient que confusion et manque de maturité.
D’où la nécessité de donner une vision structurante du Web 2.0 pour mettre l’entreprise dans de meilleures prédispositions aux opportunités offertes.

Je distingue trois composantes, que je nomme souvent « l’ADN du Web 2.0″, et qui sont : la participation, la simplicité, et enfin l’ouverture des données. Voyons ce qu’elles signifient.

1. La participation :
C’est l’axe business et organisationnel du Web 2.0.

Cet axe est très souvent mal compris ; aucune des entreprises avec lesquelles j’ai discuté ne le comprenait proprement. Souvent, on confond « participation » avec « volontariat » ou encore avec « personnalisation », voire même avec des démarches de management des connaissances classiques.

Or, les mécanismes participatifs qui sont à l’oeuvre dans l’économie du Web 2.0 sont d’une puissance énorme : actuellement ils font, et défont, des empires. Toute entreprise qui est en contact direct avec le marché des consumers, du grand public, peut dévisser si un de ses concurrents, voire un nouvel acteur, met au point des mécanismes participatifs dans son coeur de métier.
Pour comprendre les enjeux de l’axe participatif du Web 2.0 il faut utiliser le concept de milieu associé que l’on emprunte à Gilbert Simondon.

La quasi totalité des entreprises travaillent en mode dissocié, c’est à dire que leur état d’esprit est le suivant :

Il y a une dissociation entre le producteur et le consommateur, contrairement à ce que l’on constate sur le Web 2.0 où les producteurs peuvent être, en même temps, des consommateurs.
Accepter de mettre de la participation dans une entreprise c’est donc accepter de basculer dans un milieu associé, c’est à dire accepter que ses clients prennent part, en amont, au design et à la conception des services ou des produits de l’entreprise. C’est aussi accepter, en interne, de repenser les logiques d’organisation du travail afin de s’émanciper des pures logiques hiérarchique et administratives.
Autant dire que toutes les organisations n’ont pas le même degré de maturité face à cette bascule en mode participatif.

2. La simplicité :
C’est le volet design du Web 2.0.

Il s’agit de la simplicité des interfaces applicatives, qui relèvent bien souvent du cauchemar dès qu’on franchit les pares-feux des entreprises. Cela s’explique car les utilisateurs des applications sont rarement ceux qui décident ; dans le meilleur des cas on les consulte pour les fonctionnalités attendues, mais les interfaces de travail sont bien souvent la cinquième roue du carrosse.
Simplicité des interfaces renvoie donc à la convivialité des interfaces utilisateurs ainsi qu’à la réflexion autour du poste de travail en entreprise. Derrière cet aspect on retrouve également toutes les logiques de Rich Internet Application (RIA) ou Rich Desktop Application (RDA) dont Google, Microsoft et Adobe sont les principaux acteurs.
Mais l’axe simplicité du Web 2.0 renvoie aussi à la simplicité des services. Si les site web 2.0 qui ont du succès c’est toujours parce qu’ils proposent un service très simple, pas besoin d’une formation ou d’un mode d’emploi. Les solutions web 2.0 ne font qu’une chose et en général elle le font bien : Flickr pour partager des images, Youtube pour partager des video, Del.ico.us pour partager des bookmarks, etc. On est à l’opposé de la logique du « tout intégré » que portent généralement les systèmes d’informations des entreprises, induisant des lourdeurs dans la gestion et l’évolution de celui-ci. Par provocation on pourrait dire que la logique du web 2.0 c’est une logique du tout désintégré.

3. L’ouverture des données :
C’est le volet technique du Web 2.0.

Pour que les données et les services puissent collaborer et constituer un écosystème il faut que l’accès aux données soit non seulement possible mais aussi favorisé. Pour cela, l’ensemble des logiciels doivent proposer des APIs (Application Programming Interface). Ces APIs décrivent comment accéder aux données et aux services de l’application, c’est grâce à elles que les programmeurs peuvent créer de nouveaux services très simplement à partir d’autres services et réutiliser des données existantes.

C’est cette possibilité qui permet de faire des Mashups, c’est à dire des mélanges de données provenant de différents services applicatifs (ce que fit Google en proposant des APIs pour Google Maps permettant d’exposer des données pour géolocaliser un lieu sur une carte).

Dans le périmètre de l’entreprise, les applications doivent proposer des APIs pour pouvoir exposer des données qui seront utilisées ailleurs, et pourquoi pas à l’extérieur de l’entreprise. Pour une banque de détail par exemple, il s’agira d’exposer les données financières des clients pour leur permettre de consulter leur état de compte dans un portail personnalisé grand public comme Netvibes ou iGoogle. C’est à dire que les données de l’entreprise peuvent être consultées indépendamment de l’interface que propose la banque sur son propre site web.

Bien sûr, les application natives du web 2.0 (Blogs, wiki) ont cet  « ADN du Web 2.0″, et donc cette ouverture des données en standard en proposant des APIs et en générant des flux Atom/RSS.

Voyons à présent les logiques industrielles et économiques dernières le web 2.0.
Le Web 2.0 a changé la figure du web en ce sens que le web a commencé à devenir non plus un web de pages mais un web de données.

Dans le web de pages, les informations sont stockées puis projetées sur la toile, c’est un procédé essentiellement cinématographique qui est à l’oeuvre, avec le public des internautes qui regarde et consulte les pages sur la toile.

Avec le web 2.0, les sites web proposent de stocker les données des internautes (le fameux User Generated Content), le sites web deviennent dès lors de moins en moins des vitrines de documents commerciaux mais de véritables applications qui se nourrissent du contenu envoyé par les utilisateurs.
Avec les données des utilisateurs (documents, photos, video, audio) sur le web, on peut dire que le Web devient la plate forme de données pour le grand public. Mais cela va beaucoup plus loin car le web devient également la plate-forme de toute l’industrie des technologies de l’information.

Le SaaS est totalement intégré dans l’environnement du web, dans son architecture et dans le respect des standards. En conséquence on accède aux services en mode SaaS par HTTP et via une URL, et bien sûr on offre toutes les APIs qui vont bien. 

Économies d’échelle et outil de production :

Un acteur SaaS est de facto dans une logique industrielle d’économie d’échelle. Il doit bénéficier d’infrastructures importantes pour la production de ses services, soit les siennes s’il veut être un acteur de rang 1, soit celles d’un partenaire (par exemple Amazon) s’il est un acteur de rang 2. 

Sans installation :

Aucune installation dans le système d’information et aucun accès à l’environnement desktop sur le poste de travail n’est nécessaire. Tout passe par le navigateur. 

Multi-tenants :

Une seule instance du logiciel pour x clients. Ce qui signifie que l’environnement de production est mutualisé et virtualisé. Aucun hébergement dédié pour un client n’est possible. Et ce, contrairement aux solutions ASP qui disposent d’un environnement dédié pour chaque client et qui donc ne peuvent bénéficier des vertus de la mutualisation (nouveaux clients = nouvelles bases de données). 

Web Analytics :

Une solution SaaS n’est viable que si elle dispose de puissants outils d’analyse et de reporting pour détecter les tendances d’utilisation et de comportement des clients. Grâce à çà, les évolutions seront plus en phase avec les pratiques des utilisateurs. Le vrai métier d’un acteur SaaS c’est de “tâter le pouls” de ses utilisateurs en quasi temps réel. 

Agilité :

On voit bien que les acteurs proposant des solutions en mode SaaS viennent soit du marché grand public, soit du marché des PME. Or, les technologies de l’information restent une industrie et à ce titre sont soumise à certaines logiques industrielles dont l’une des toutes premières est la nécessité de faire des économies d’échelle pour abaisser les coûts.

Oeuvrant sur le marché grand public, les acteurs SaaS ont de facto conçu des solutions utilisées par des millions d’utilisateurs, constituant ainsi une des condition de base pour faire des économies d’échelles, à savoir un marché de masse.

La conséquence de cette mutation industrielle est que le système d’information d’une entreprise va être de plus en plus déporté de ses locaux vers les plates-formes web en mode SaaS (voir le parallèle fait par Nicholas Carr dans son dernière livre « The big Switch », même si le livre est très médiocre). Autre conséquence bien sûr : les données ne vont plus être dans le giron technologique de l’entreprise.Les données du système d’information de l’entreprise vont être réparties sur ce que l’on commence à appeler des super-plateformes :

 

Attention, tout n’est pas magique, il y a des points de vigilance que chaque entreprise doit évaluer.

La qualité réseau : dans l’optique d’une bascule de plusieurs milliers d’utilisateurs vers des solutions en mode SaaS il vaut mieux muscler la qualité réseau de la connexion internet (qui est généralement médiocre dans les entreprises). La bonne nouvelle est que le coût de la bande passante internet est moins chère que celui des réseaux internes (LAN ou WAN), mais il faudra quand même revoir la politique réseau de l’entreprise.

La Road Map (modifications et ajout de nouvelles fonctionnalités) d’une solution SaaS est quelque chose que l’entreprise ne va plus maîtriser. On le voit au quotidien avec les modification que fait Google sur Google Doc : un coup l’interface change, de nouvelles fonctions sont ajoutées, et tout cela bien sûr sans demander l’avis des clients ou des utilisateurs. Il faudra notamment mettre en place un support/help desk musclé car le moindre changement et c’est des milliers d’appels assurés (je ne trouve plus le bouton « Enregistrer »!)

La confidentialité des données est bien sûr un sujet de discussion majeur. Mais il est en grande partie psychologique de mon point de vue.

Autre point à aborder avant de passer au SaaS : le Off Line. Que vont faire tous vos employés s’ils ne se sont plus connectés ? Il faudra identifier les situations de mobilité et d’absence de connexion afin de mesurer objectivement l’impact que peut avoir le mode déconnecté sur certaines populations. Jetez également un oeil aux modes déconnectés qui existent (en natif chez Microsoft pour cause de client lourd, intégré ou à venir chez Salesforce et Google).

Le statut juridique des acteurs en mode SaaS reste encore flou : souvent ils ont le statut de « fournisseurs de contenu », étrange quand on sait que c’est vous qui fournissez vos données! Sachez également que la législation Américaine et Européenne n’est pas la même. Il existe des solutions sectorielles en mode SaaS incompatibles avec la législation européenne qui interdit à certaines entreprises de déléguer la gestion et le stockage des données à des tiers.

Bien sûr il faudra évaluer les modalités de sortie de la solution SaaS, ce n’est pas après une migration massive des données qu’il faudra réaliser qu’il n’y a rien de prévu pour automatiser l’export des données (on parle de Rollback).

Dernier point, il ne faudrait pas passer d’une logique de silos applicatifs dans le système d’information tant décriée, à une logique de silos sur le Web. Les solutions SaaS choisies devront être interopérables avec d’autres offres SaaS et bien évidemment continuer à être articulées avec les application patrimoniales (Legacy qui restent dans le systèmes d’information. La richesse des APIs sera ici déterminante.

Nous voilà arrivés au terme de cette introduction à l’Entreprise 2.0 avec, pour terminer, un petit schéma qui résume la définition suivante :

Une entreprise 2.0 est une entreprise qui est soumise à un double mouvement de balancier : d’un côté elle met du Web 2.0 dans son système d’information, et de l’autre elle commence à basculer une partie de son portefeuille applicatif en mode SaaS.

Related posts:

1. Le périmètre trouble du Search en terrain SaaS La promesse d’une solution de Search fédérée permettant de lancer...
2. Il n’y a pas que le SaaS dans la vie Il y a aussi Saas, petit village suisse : Image...
3. Adobe Photoshop en SaaS Conformément à sa stratégie SaaS, Adobe a mis en ligne...

J’aurai le plaisir d’animer la table ronde qui aura lieu lors du lancement officiel de la dernière mouture d’eXoPlatform le 18 Avril prochain.
Une table ronde avec du beau monde puisque seront présents :

• Mozilla Europe, Tristan Nitot (Founder and Chairman)
• Microsoft, Christophe Lauer (Web Platform Evangelist at Microsoft France)
• Sun Microsystems, Eric Mahe (New Technologies Manager)
• Google, Dave Armstrong (Product Marketing Manager)
• eXo Platform, Benjamin Mestrallet, Founder
• Adobe, Michaël Chaize

La thématique sera : « Quel avenir pour les applications Web ? »

Related posts:

1. Table ronde sur le futur des applications Web La table ronde sur le futur des applications Web, qui...
2. SUN bascule la totalité de son informatique « on the cloud » Avec plus de 30 000 employés, on ne peut pas...
3. Ironie du sort Le « slogan » de Microsoft pour décliner sa mutation vers le...

C’est quand on est au pied du mur, dans une impasse, que l’on est bien souvent prêt à écouter des conseils qu’on n’aurait pas entendu dans d’autres circonstances. C’est dans ces moments que l’on est prêt à reconsidérer ses positions et où l’on accepte de prendre des chemins que l’on jugeait inopportuns quelques temps auparavant.

Un projet s’enfonce et s’enlise ? Et si l’on vous dit à ce moment là que l’on peut le réaliser deux fois plus vite et pour deux fois moins cher, forcément on est tout ouïe. Et vous n’allez pas objecter que c’est du REST, du web 2.0 ou quoi que ce soit d’autre, c’est devenu le dernier de vos soucis pourvu que vous puissiez sortir par le haut de cette impasse.
Méthodes Agiles, architectures REST, projets Web 2.0, solutions SaaS, rien de mieux pour concrétiser ces démarches que d’avoir une entreprise qui a pris un bon mur de face (ou de dos car ne le voyant pas venir) pour entrevoir les choses différemment.

Je ne cherche plus à convaincre une entreprise que son système d’information devient endémique – comme dirait Nicolas Hulot – et donc qu’il faut adopter le web au travers de ses normes, de ses architectures, de ses pratiques et de ses usages.
Il suffit juste d’attendre l’impact avec le mur pour que la raison et le bon sens reprennent leur droits, comme par enchantement.

Je me demande parfois si les démarches d’Entreprise 2.0 ne sont pas un remède, et si je ne devrais pas plutôt ouvrir une pharmacie 2.0.
Que dis-je, Hôpital 2.0 serait bien mieux approprié, tant les maux dont souffrent les systèmes d’informations sont vastes et profonds.

Related posts:

1. Manifestations contre le Contrat Première Embauche La question est : est-ce que les jeunes des émeutes...
2. You ? Vous êtes convaincu que le web est la plateforme ?...

Avec plus de 30 000 employés, on ne peut pas dire que Sun soit vraiment une PME. C’est une compagnie avec une couverture mondiale qui vient d’annoncer qu’elle arrêtait de patrimonialiser son système d’information.

En clair, l’objectif affirmé est ne plus avoir d’infrastructure dédiée à leur système d’information d’ici 2015 : 0 centres de données.

Plus de système d’information « on premises », dans les locaux de Sun.

Un exemple particulièrement rapide dans la mise en oeuvre de l’exode des données que j’avais évoqué.

Virtualisation, cloud-computing et SaaS sont bien sûr les leviers de ce changement dont les motivations sont la réduction des coûts IT, la souplesse de gestion, et l’alignement sur les besoins métiers (on évoque même les mashups).

A combien d’annonces de ce genre va-t-on assister en 2008 ?

Related posts:

1. Table ronde sur le futur des applications Web La table ronde sur le futur des applications Web, qui...
2. Prolétarisation informatique Il faut commencer par rappeler ce qu’est un prolétaire. Pour...
3. eXo Enterprise WebOS J’aurai le plaisir d’animer la table ronde qui aura lieu...