Cloud computing & virtualisation

[Je parle surtout des technologies de VMWare mais cela est généralisable aux autres solutions]

Le Cloud Computing se définit comme une démarche de mise à disposition, via un accès internet, à des ressources de différents niveaux : infrastructure (IaaS), plateforme de développement (PaaS), services applicatifs (SaaS).

Cette logique est publique en ce que les clients de telles offres partagent une infrastructure commune et mutualisée en louant des ressources dont ils ne sont pas propriétaires. Les mécanismes de location sont à la fois “à la demande” et automatisée en self-service, sans nécessité de passer par des intermédiaires commerciaux : une interface d’administration web permet tout à la fois de commander des services, de les configurer, de les gérer et aussi de les arrêter.

La logique de virtualisation des infrastructures est à a base d’une démarche de Cloud Computing, et c’est en ce sens qu’une entreprise qui se lance dans une logique de virtualisation de ses propres infrastructures peut prétendre mettre en place un Cloud Privé ou Interne. Mais cela ne suffit pas pour autant car, si la virtualisation apporte de la souplesse et une meilleure optimisation de l’infrastructure, elle n’offre pas pour autant une approche self-service couplé à une facturation à la demande.

C’est l’enjeu des offres vCloud de VMware d’étendre son offre de services de virtualisation (VSphere) à une logique de self-service basée sur un catalogue avec une logique de re-facturation (entre services internes).

Virtualisation physique et virtualisation Applicative

Si tous les acteurs de Cloud Computing mettent en oeuvre des stratégies de virtualisation des couches physiques (serveurs, CPU, mémoire, etc.) et bases (Système d’exploitation), ils ne vont pas pour autant jusqu’à virtualiser des environnements applicatifs, préférant déployer des architectures applicatives distribuées s’appuyant sur des systèmes de redondance des données entre différents centres de données.

Cette démarche de virtualisation des infrastructures s’est effectuée, comme dans la plupart des DSI en France, sans que cela n’impacte les différentes couches applicatives. Et il n’est pas rare de constater que cette virtualisation des couches bases et matérielles (la couche physique) se soit faite sans même que les responsables applicatifs et les utilisateurs ne s’en soit aperçus.

Or à présent on constate des initiatives de virtualisation non seulement de ces couches basses mais également des couches applicatives.

Les opportunités de la virtualisation applicative

Il faut tout de suite préciser que, même si le marché actuel est dans une phase de croissance dans la mise en oeuvre de virtualisations non plus des infrastructures mais des applications, ce marché n’est pas pour autant mature : la plupart des grandes DSI françaises en sont au stade d’expérimentation et de prototypage de la virtualisation applicative et de sa mise en oeuvre sous forme de “Cloud Interne”.

La virtualisation applicative offre des pistes intéressantes concernant les points suivants :

• réduction des cycles de validation et de mise en production des applications ;
• portabilité des applications historiques (legacy) dans de nouveaux environnements ;
• un meilleur “time-to-market” pour de nouvelles applications ;
• une automatisation des processus existants ;
• une amélioration de la qualité de service et de la continuité de service

Ces opportunités doivent néanmoins être éprouvées sur certains points pour lesquels les retours d’expériences manquent : robustesse, maintenabilité, performance et sécurité. A cela il faut rajouter la partie organisationnelle et fonctionnelle qui bousculent les processus existants des DSI ainsi que les emplois et les compétences qui lui sont associées.

Comment mieux accompagner le cycle de vie des applications ?

C’est autour de la question du cycle de vie des applications et de leur mise en production que les débats autour de la virtualisation et par extension autour du Cloud se pose au sein des DSI des entreprises.

Certains cabinets d’analystes, notamment le Gartner, on fait état de gains potentiels dans l’approvisionnement et dans les délais de mise à disposition dans les stratégie de virtualisation, mais aussi  dans le déploiement. C’est en partie de ce qui motivé les DSI à s’engager dans une démarche de virtualisation de leur portefeuille applicatif.
Aujourd’hui, on constate un cycle de mise en production qui passe successivement par :

• une première installation par la TMA
• plusieurs installation sur la plateforme de pré-production pour la recette, l’homologation, la qualification, ..
• enfin une dernière installation pour la mise en production.

Ces réinstallations successives peuvent prendre plusieurs semaines et les “métiers” ne supportent plus ces longs cycles de validation qui à leurs yeux ne représentent que des contraintes et des coûts qui se justifient de moins en moins.

La logique de réinstallation de type “Wipe & Load”

Avant de développer l’option de la virtualisation et du Cloud (interne ou externe), envisageons une première option, défendue généralement par ceux qui sont en charge des couches mutualisées de infrastructure.

La logique de virtualisation repose sur l’encapsulation de tout un environnement applicatif dans une machine virtuelle (VM). Celle-ci pourrait alors circuler dans différents environnements et sur différentes plateformes (y compris une plateforme externe).

Or cet idéal se heurte à certaines réalités, parmi lesquelles :

• si dans le fichier *.ini de telle application il y a écrit “en dur” qu’il faut telle machine, cela ne passera pas si la VM n’est pas dans l’environnent d’origine
• il restera des traces dans le registre et un peu partout : l’encapsulation a donc de fortes de fortes limites.

Ainsi tout ce qui est écrit en dur : les adresses IP, l’accès au machines, aux bases (Bases de données, Annuaire, etc.) tous cela ne disparaît pas dans les VM et même dans les Vapp (qui ne suppriment pas les les clés dans le registre).

On peut comprendre les réticences de l’opérateur en charge de la plateforme quand quelqu’un veut pousser une VM dans l’environnement dont il a la charge et il ne manque pas de dire : “les mises en production c’est moi qui m’en occupe”.

S’il y a des GPO (pour Group Policy Object dans l’environnement Windows), avec la virtualisation on ne les annule pas, donc on cumule les GPO précédentes ; certes pour l’administrateur du poste de travail tout marchera mais pas pour l’utilisateur lambda. Donc ce qui va marcher avec dans l’environnement de TMA par exemple, où il y a tous les pouvoirs et droits, en marchera plus en production avec les utilisateurs.

Il peut également exister des cas bien pire que le simple constat “çà ne marche pas”. Ainsi la démarche qui consiste à transférer des VMs dans des environnements et des plateformes différentes peut “en apparence” parfaitement marcher. Mais en réalité les accès peuvent être faussés : par exemple une application en VM qui attaque non pas la base de production mais de pré-production. Ce genre de risque n’est pas sérieusement pris en compte dans la démarche qui consiste à “balader des VM dans des environnements différents”.

On perçoit bien que l’enjeu de l’acceptation des technologies de virtualisation passe par la question des adhérences et des adressages. Les technologies de virtualisation ne permettent pas  de gérer automatiquement et efficacement l’ensemble des adhérences d’une application à son environnement (réseau, OS, middleware et applicatif).

Pour autant, si l’on ne passe pas par la virtualisation pour automatiser la gestion du cycle de vie des applications, y a t il une autre solution ?

L’automatisation peut marcher si l’on repart toujours de zéro, il ne faut pas faire circuler les VM avec des historiques qui sont trop lourd et peuvent être des bombes à retardement. Il faut automatiser les logiques d’installation avec la possibilité de pouvoir toujours revenir en arrière si nécessaire.

L’installation automatique n’est pas la même chose que de faire circuler des VM dans des environnements distincts. Il s’agit de se mettre dans une logique de “wipe and load” (on efface et on recharge) : on repart de zéro avec un livrable qui est un exécutable qui s’installe automatiquement et dont on est sûr de la qualité sachant qu’on ne transfère que la configuration de l’application et pas son l’historique. Du coup, d’un point de vue réseau on ne transfère qu’un fichier de quelques kilo-octets de configuration et pas des VM de plusieurs dizaines de Gigas Octets, ce qui soulagne grandement les limitations de bande-passante qu’on les entreprises.

Cette approche a une part évidente de vérité, mais elle se heurte à une dure réalité concernant les applications les plus critiques du portefeuille aplicatif. Certaines applications sont un véritable mille-feuilles de sédimentation technologique avec parfois plusieurs dizaines de niveaux patchs qui obligent à regarder la réalité en face : certaines applications ne sont absolument pas reconstructibles et réinstallable.

L’approche “Wipe & Load” est peut-être la meilleure solution dans un environnement applicatif dont la complexité est maîtrisé, ou pour de nouvelles applications, mais elle n’est plus opérante pour la prise en compte du Legacy Applicatif, notamment pour les progiciel métiers.

La virtualisation poussée en mode Cloud : les opportunités de la technologie vCloud de VMware

Concernant le parc applicatif qui, pour des raisons de sédimentation informationnelle et de complexité des niveaux de patchs ne peut pas être réinstallé, les entreprises se retrouvent dos au mur. Ce qui a été fait, c’est une image de l’application qui la fige et la sauvegarde, mais une telle image ne peut être redémarreée que dans un environnement “à l’identique” : mêmes CPU, mêmes drivers, etc., ce qui est très contraignant et qui confirme la criticité de la situation.

La promesse de vCloud est de porter les logiques de virtualisation à un niveau d’abstraction encore plus poussé que la simple virtualisation applicative. Ainsi la technologie VMware (comme d’autres) est-elle sensée apporter des solutions aux problématiques d’adhérence des applications évoquées précédemment : encapsulée dans une vApp, une application pourrait être déplacée dans n’importe quel autre environnement vCloud.

Tout n’est pas encore figé et les solutions de VMware sont en pleine évolution. Ainsi le déplacement des VMs avec les vApp nécessite encore de changer à la main certains paramètres d’adressage : IP, accès DNS, machines, bases, etc.

Dans l’approche autour de la mise en place de vCLoud au sein d’une entreprise, la méthodologie suivante émerge :

• Constitution d’un catalogue de souches virtualisées des technologies utilisée par l’entreprise ;
• Les développeurs utilisent ces souches qu’elles choisissent dans le catalogue pour construire et faire évoluer les applications ;
• Une procédure de re-construction de l’application en utilisant les éléments du catalogue vCLoud est réalisée (pour les applications critique on fait passer la VM dans les différents environnements sans les re-contruire) ;
• Une application peut ainsi être théoriquement déplacée dans plusieurs vLCoud internes de l’entrerprise mais également dans un vCloud externe ;

On peut considérer métaphoriquement la technologie vCloud comme un “tapis roulant” qui permet de faire naviguer les vApp (les VMs des applications avec leur couche réseau virtualisée) sur différentes plateformes (interne et externes) qui sont certifiées “vCloud”.

Le recours à une offre Cloud IaaS externe sous un nouvel éclairage

Tout d’abord il faut noter que les offres de vCloud Externe sur le territoire français se résument à ce jour à l’opérateur/hébergeur COLT qui est le seul a posséder les accréditations et la certification de VMWare (OVH est en discussion et devrait obtenir la certification).

Ensuite, ces offres externes ne contiennent pas des souches virtualisées de technologies propriétaires (ex : weblogic) et privilégient des technologies Open Source qui ne sont pas communes chez les “grands comptes”.

Enfin, le mode de virtualisation adopté par les entreprises privilégie le maintient des données applicatives dans le périmètre des plateformes qu’elle opère : c’est le cas des bases de données, des logs mais aussi des annuaires. Ce qui implique qu’une vApp placée chez un opérateur externe devra faire des appels et des écritures dans un environnement vCloud de l’entreprise : tout ceci pose de réelles questions de performance.

A ces questions se rajoutent des questions de sécurité et d’ouverture de VPN entre l’entreprise et un partenaire externe. Même si la solution est théoriquement sécurisée (étanchéité logique des réseaux dans l’environnement mutualisé du prestataire externe), cela induit une réelle méfiance de la part de l’opérateur de plateforme qui y voit également une stratégie de contournement de son rôle au sein de l’entreprise(“on me vole mon job en essayant de me court-circuiter”)

Dissensus et Consensus au sein des Entreprises

On constate vite que les responsables des couches applicatives, proches des préoccupations des métiers, se sentent freinés dans leur appétence à virtualiser non plus la couche infrastructure mais celle des applications.

En dessous de la ligne applicative, responsables de la sécurité, responsable des plateformes et responsables infrastructure & réseaux freinent des quatre fers. On peut imaginer que la solution ne sera pas “tout virtualisé” car chaque application va avoir une trajectoire de virtualisation qui sera différente des autres, mais il me semble inévitable de virtualiser notamment les grosses applications métiers que plus personne ne saurait redémarrer en cas d’incident majeur. C’est donc sous la contrainte de leur patrimoine applicatif que les entreprises avancent et tentent d’instruire des arbitrages de virtualisation.

Related posts:

1. A propos de la virtualisation de Windows Nasstar (il faut aller voir leur site avec la video...
2. SUN bascule la totalité de son informatique « on the cloud » Avec plus de 30 000 employés, on ne peut pas...
3. L’Un et le Multiple comme défi technologique du Cloud Computing Construire un data center est tout ce qu’il y a...

Les intégrateurs, à la différence des autres SSII, se définissent par leur capacité à prendre en charge de très gros dossiers informatiques que l’on appelle tout simplement des « Big Deals ». Toute l’attention des intégrateurs est donc focalisée sur le gain de ces affaires qui ont été historiquement le moteur de leur développement et de leur croissance.

Or — bel exemple pharmacologique —  ce qui a fait la croissance des intégrateurs est, je crois, en train de devenir un vrai poison.

La première raison est que le nombre de ces big deals a nettement diminué sur le marché ses dernières années, et cela pour diverses raisons :

• d’abord parce que les entreprises ont atteint un taux d’équipement dans leur informatique professionnelle qui est celui de la maturité, donc moins de nouveaux grands chantiers ;
• ensuite parce que les entreprises ont eu une mauvaise expérience, à la fois financière et qualitative, de précédents grands projets. On préfère désormais avancer à petit pas et sur des périmètres budgétaires plus étroits : appelons çà une meilleure gestion des risques des projets informatiques ;
• enfin, mais je ne vais pas y revenir ici, le modèle du « Coud Computing » change les modes d’acquisition et d’usage du software et court-circuite le marché d’installation et de paramétrage de progiciel.

Mais même moins nombreux, il en reste encore. La rareté fait que leur importance croît ; louper un gros dossier chez un client et ce sont les objectif de plusieurs années de chiffre d’affaire qui peuvent en subir les conséquences.

Tout est donc fait pour gagner les quelques big deals qui apparaissent encore. Ce qui veut dire que les processus commerciaux et administratifs, les modes de prises de décisions, l’organisation des phases d’avant-vente, la gestion des compétences, etc., tous cela est ré-ajusté pour mieux attendre l’objectif n°1 : les big deals.

Le big deal a ses intérêts : il donne une visibilité financière à long terme, il permet plus de souplesse pour l’affectation des ressources. Pour l’intégrateur, c’est comme une île au milieu de l’océan, un refuge providentiel pour enfin se reposer, se réapprovisionner, faire le point et pouvoir préparer le prochain départ vers une autre hypothétique île, que l’on espère toujours plus grande. C’est également la promesse de faire plusieurs autres petits projets, en s’en servant de locomotive. Mais permettez-moi de douter car à chaque fois que l’on m’a dit que vendre un gros projet en ferait gagner d’autres plus petits dans son sillage, jamais je n’ai vu cela se produire. Ces modèles d’affaires et les modes de raisonnement managériaux qui les véhiculent sont complètement erronés.

Mais comme il n’y a pas que les grosses affaires dans la vie, l’ensemble des autres dossiers, de plus petits montants mais qui tendent à devenir majoritaires en chiffre d’affaire cumulé, pâtissent de la lourdeur et du manque de réactivité de l’organisation qui a fait des big deals sa priorité en parlant, à l’impératif, de « must win ».

Mais dans cette tendance à la rareté, le big deal devient vraiment toxique. De part l’impératif de gain, les efforts en avant vente deviennent considérables et je crois que l’on pense tous à certains projets dont le coût de l’avant vente s’est avéré pratiquement aussi élevé que le budget du projet. Du côté de la rentabilité de ces projets, la tendance est nettement à la rentabilité nulle quand ce n’est pas parfois des pertes notables sur projet.

Ce big deal, pour lequel toute l’organisation de l’intégrateur s’est mise au diapason, nous coûte au final très cher. Les externalités négatives qu’il produit (pertes financières, ressources accaparées, démoralisation des troupes et démissions, insatisfaction du client,…) sont par contre bien réparties sur l’ensemble des autres projets qui doivent porter un fardeau dont ils se passeraient bien volontiers, notamment quand il s’agit de développer de nouvelles offres.

Le big deal, cela devient notre boulet ; tous ceux qui travaillent sérieusement n’en veulent pas, n’en veulent plus, et ce au moment même où les directions générales des intégrateurs continuent à scander, de manière irresponsable, qu’il faut mettre encore plus le « paquet ».

Il faut dire également qu’un intégrateur peut difficilement ne pas répondre à la sollicitation d’un « grand compte » qui sort son grand projet pour avoir la sensation d’exister ; une fin de non-recevoir, un NoGo côté intégrateur, et c’est prendre le risque d’offenser le client (ne pas répondre à un appel d’offre c’est, d’une certaine manière, décrédibiliser le projet et sa faisabilité) et de perdre tous les autres projets qu’il soumettra au marché. Il s’agit donc de rappeler que le problème des big deals reste un problème partagé entre intégrateurs et leurs clients. On ne peut jeter la pierre aux intégrateurs tant que le comportement des clients ne change pas : or il change puisque le nombre de big deals est en baisse. La balle est donc dans le camp des intégrateurs pour qu’il ne sombrent pas dans une sur-enchère qui vire à la spéculation sur ces affaires.

Related posts:

1. Je pressens un grand vide dans la force Bon d’accord, Google va peut-être racheter Youtube, tout le monde...
2. Prêts pour la nouvelle réorganisation ? Cette fois c’est la bonne. La nouvelle réorganisation va changer...
3. Le silence des organisations Dans une étude récente, intitulée « Silence Fails », on apprend que...

C’est apparu récemment avec Google Apps qui donnait accès au Google Apps MarketPlace, et puis je constate que la plupart des solutions SaaS / Cloud commencent à proposer un « Apps Store » qui donne accès à des solutions développées par des tiers. Jive (solution de Social Software) Yammer le fait déjà, box.net va s’y frotter, sans compter Salesforce, etc.

Bien sûr, dans un contexte d’entreprise, ces « apps stores » sont immédiatement désactivées. Il n’empêche que se dessine une tendance où le salarié va être considéré comme un consommateur dans le cadre de son travail : ce n’est plus une décision qui s’imposera identiquement à tous puisqu’une marge de manœuvre pour des « exceptions » locales, voire individuelles, vient de s’ouvrir. Cela prendra le temps qu’il faut, mais on va vers des situations où le salarié pourra faire son « pick and choose » pour faire son « My SI »

Les DSI, bon gré mal gré, sont de plus en plus sensibles à la qualité perçue par les utilisateurs. Or celle-ci est généralement très mauvaise, pour ne pas dire catastrophique dans certains cas, aussi je vois mal le marché des « apps stores » ne pas se développer à courte échéance.

Je sais que certaines entreprises commencent à ré-évaluer leur position initiale à l’égard des « apps store » ; la situation est à suivre de près dans les prochains mois.

Related posts:

1. Stage Google Apps Engine [Message à caractère professionnel] Pour faire suite à l’annonce de...
2. Quelques ressources sur Google Apps Si vous avez à travailler autour des Google Apps, dans...
3. Google Video for Business Google vient de rajouter la video dans son Offre Google...

Il y a une tendance très nette des vendeurs de solutions en SaaS ou Cloud Computing, ayant des offres pour les grandes entreprises, de baser leur approche commerciale sur le fait que leur solution est déjà utilisée par les employés.

Yammer ou Box.net le font par exemple.

Leur solution gratuite étant déjà utilisée par les employés dans le cadre de leur activité professionnelle, ces vendeurs peuvent ainsi non seulement présenter leurs services mais également donner des comptes rendus analytiques détaillés de l’usage de leurs services part les employés du prospect.

En somme, cela prouve que la solution a déjà été appropriée par les utilisateurs ; c’est un sérieux argument dans la prise de décision côté client.

Google pouvait également prétendre que ses services étaient déjà largement utilisés par les internautes, mais la société ne pouvait pas pour autant présenter des rapports d’utilisation et d’adoption par les salariés de ces services car les identifiants mail étaient différents ( gmail et mail d’entreprise ; google ne sait pas (ou ne doit pas savoir) combien d’employés d’une société ont gmail )

Avec cette « analytics based selling », l’acte de vente devient, du point de vue du client, moins un investissement qui peut comporter des risques que  la contractualisation d’une solution qui est déjà utilisée.

L’acte de vente est alors présenté comme la régulation d’une situation où les utilisateurs étaient en dehors du périmètre de l’entreprise, et donc du SI, tout en ayant des relations et des activités de travail.

Tout le monde est content, les brebis rentrent dans le périmètre contractuel de l’entreprise avec un outil qu’elles ont adopté collectivement. Le décideur lui, n’a pas eu à prendre une décision critique (car généralement ces solutions s’adressent à potentiellement tous les employés),  donc il se sent soulagé d’une prise de responsabilité.

Related posts:

1. Search Based Applications C’est une tendance forte dans le marché des moteurs de...
2. WebMethods s’offre Cerebra L’editeur américain WebMethods, offrant des solutions EAI (Enterprise Application Integration)...
3. Irresponsabilité et violation Quand on voit comment les partis politiques appréhendent les potentialités...

Après l’informatique embarquée et l’informatique de gestion, tend à s’en rajouter une troisième informatique qui est l’informatique relationnelle. Celle-ci ne repose plus sur des technologies de gestion mais sur des technologies relationnelles.

Pour expliciter ce qui se passe, il faut d’abord dire que ces deux informatiques, de gestion et relationnelle, malgré les différences que je vais souligner, ne s’opposent pas systématiquement. Ainsi, une application peut relever à la fois d’une informatique de gestion et d’une informatique relationnelle.

*

Dans les entreprises, les DSI sont organisées pour gérer une informatique de gestion : on met en place une application de gestion, on la valide, puis elle passe en TMA (Tierce Maintenance Applicative). Quand pointent les technologies relationnelles, le réflexe des DSI est de les traiter comme des technologies de gestion, ce qui explique les difficultés systématiques pour que ces technologies relationnelles pénètrent les Firewalls des Systèmes d’Information (SI).

La chose n’est pas nouvelle, elle ne date pas de 2005 et du Web 2.0, c’est le cas depuis internet, à commencer par le email. Mais c’est surtout avec le web qu’une réaction en chaîne (une réaction de type transductive) s’est enclenchée. Disons donc que cela a commencé dans les années 90 pour plupart des grandes entreprises, et cela perdure encore.

Le web, qui est le lieu de convergence des technologies relationnelles, n’a ainsi pas vraiment pénétré dans les SI. Car ce que les DSI faisaient – et ce que les éditeurs proposaient – c’était des applications non pas « web » mais « webisées« , çà ressemble à du web mais quand on soulève le capot on voit que c’est juste l’utilisation d’un navigateur web (en général IE6). Même les services web n’avaient pas la même tête dans le SI que sur le web, ce qui a produit le monstre du tunnelling Http et des normes WS-*, et tout cela a culminé avec le matraquage marketing autour de la SOA.

La raison en est que, à chaque fois, les DSI appréhendaient les technologies relationnelles comme des technologies de gestion. Le web en entreprise a toujours été « dénaturé » et pris à rebrousse poil, tant au niveau des standards et des protocoles que des pratiques et des usages. Encore aujourd’hui, il y a des personnes dans les DSI qui croient qu’il faut un bon gros serveur d’application pour avoir des applications et des services web, de la même manière qu’il y a en a qui demandent encore des portails web sur des serveurs d’applications dit « d’infrastructure ».

La situation est devenue cocasse quand les DSI ont commencé à intégrer des solutions « Web 2.0″ parce qu’elles apparaissent dans la roadmap et dans le catalogue de leur éditeur attitré : les blogs et les réseaux sociaux pensés par IBM ou SAP, çà faisait quand même froid dans le dos tellement il était évident que les gars qui étaient derrière çà ne comprenaient pas « le truc ». Le « truc » en question était que ces solutions reposaient majoritairement sur des technologies relationnelles plutôt que sur des technologies de gestion. Et, il y a à peine quelques années, je pense n’avoir pas été le seul à penser :

« s’ils passent avec çà et l’imposent sur le marché, je démissionne pour aller élever des chèvres dans le Larzac ».

Les professionnels de l’informatique de gestion, SSII/Integrateurs, Éditeurs et DSI, n’ont toujours pas digéré le web.

A une échelle bien plus large, aux niveaux économiques, sociétaux et politiques, le web est également un emmerdement maximal pour ceux qui voient leur modus vivendi , quand ce n’est pas leur rente de situation, se déséquilibrer. Mais restons-en ici au niveau des Systèmes d’Information des entreprises.

Entre la tentation de se croire plus gros que le web au point d’arriver à le marginaliser et celle de l’intégrer à sa sauce gestionnaire, tous ces faits, qui constituent un marché professionnel, disaient le contraire de la tendance que, pourtant, ils manifestaient. Cette tendance est précisément l’avènement des technologies relationnelles qui prennent ici le visage du web.

Aujourd’hui, je milite beaucoup auprès des DSI pour qu’elles mettent en place une Direction des Technologies Relationnelles (DTR) en parallèle de la traditionnelle Direction des Systèmes d’Information (DSI). Ceux qui suivent un peu ce que j’écris sur ce site peuvent certainement entrevoir les caractéristiques de ces Technologies Relationnelles, mais j’aurai certainement l’occasion de les développer plus en détails. En revanche, je veux dès à présent souligner une distinction essentielle entre l’informatique de gestion et l’informatique relationnelle qui repose sur la notion de métastablité.

On se souvient de nos cours de mécanique et de physique en classe de seconde où l’on a appris qu’il y avait des équilibres stables et des équilibres instables. Un équilibre était instable si une force, en s’exerçant sur lui, le faisait quitter son point d’équilibre sans qu’il n’y revienne naturellement. Le rocher en haut de la colline est dans un équilibre instable car si on le pousse il va dévaller, ce qui n’est pas le cas du rocher dans une cuvette qui, lui, est dans un équilibre stable (il y a bien sûr beaucoup à dire sur la métastabilité en reprenant les travaux de Gilbert Simondon, mais je ne garde ici que l’explication la plus simple et la plus courante).

Les technologies relationnelles reposent sur un milieu métastable, un équilibre instable, alors que les technologies de gestion reposent sur un milieu stable.

On ne peut pas reprocher à une entreprise de mettre en place des systèmes de gestion qui, en tant que reposant sur des technologies de gestion, sont censés assurer un maximum de stabilité : gestion de la paye ou gestion de la production tolèrent mal un contexte métastable. Seulement voilà, quand on a l’esprit formaté par les technologies de gestion, on finit par croire que seul un équilibre stable est possible en matière d’informatique. L’idée même d’un système informatique métastable n’est pas acceptable et est immédiatement balayé d’un revers de main.

La web est le lieu contemporain par excellence d’un milieu technologique métastable : il contient des potentialités qui peuvent advenir selon les forces qui s’exercent sur lui. Le visage du web ne cesse de changer, or ce simple fait est une preuve d’inachèvement et d’échec pour celui qui le regarde avec le filtre des technologies de gestion. Pour celui-là, « le cahier des charges n’a pas été respecté » et ne parlons même pas des version d’application en mode Beta et autres méthode de travail en mode agile (parce que les méthodes agiles sont des méthodes de travail dans des contextes métastables).

Il y a encore beaucoup, beaucoup de travail à faire, et pas seulement dans les DSI, pour que le brouillard se dissipe et que les enjeux des technologies relationnelles puissent être saisies par les entreprises.

*

Je terminerai par une devinette à l’attention de ceux qui connaissent le web sémantique : le web de donnée, celui qui est produit par les normes du web sémantique, est-il une technologie stable ou métastable ? Relève-t-il plutôt des technologies relationnelles ou des technologies de gestion ?

Related posts:

1. De la mécroissance à l’économie de la contribution en passant par les technologies relationnelles L’ARCEP (Autorité de régulation des communications et des postes) édite...
2. Des techniques relationnelles aux technologies relationnelles L’évolution du web et le succès des réseaux sociaux ont...
3. MeetUp Semantic Web : « comment réconcilier le SI legacy et le Web par le Web sémantique ? » Voici l’enregistrement vidéo du MeetUp Semantic Web de décembre 2010...

Didier Girard, sur Application Servers , fait une remarque intéressante à propos de ma note sur la prolétarisation dans les société informatiques :

Dans certaines branches, l’opensource est un des vecteurs de la prolétarisation, je pense en particulier au monde java. Il y a quelques années lorsque nous devions développer une application java nous devions tout faire : coder un struts, coder un spring, coder un hibernate, coder un maven… Ce n’était pas très productif pour nos clients mais par contre c’était très formateur pour nous, ingénieurs.
Maintenant ce n’est plus le cas, les projets démarrent, les « architectes » assemblent deux ou trois frameworks et le tour est joué. La conséquence est moins réjouissante, ces « architectes » ne sont plus capables de coder un framework, tout juste sont-ils capables d’en comprendre le fonctionnement. Encore quelques années et je vais m’ennuyer ferme lorsque je recevrai un candidat pour un entretien d’embauche…

J’ai côtoyé des ingénieurs dans la plupart des industries : chimie (SNPE, Isochem, Saint Gobain), mécanique et électronique (Renault, PSA, EADS). Ainsi, les plus anciens se plaignent toujours que l’évolution des techniques fait « perdre de vue » le fonctionnement général de l’objet technique. Dans l’automobile, par exemple, certains des ingénieurs qui travaillaient sur plan n’ont pas pu se faire au travail assisté par ordinateur en CAO, ils ne « voyait plus » la voiture. Le constat est souvent le même, et on pourrait le résumer avec la remarque que nous faisait un des mes professeurs de mathématique :

Avec ces calculettes vous ne savez plus calculer.  De mon temps, il faillait faire un effort pour compter. Aujourd’hui vous rentrez une fonction et çà vous fait toute l’étude, çà vous dessine même la courbe. Ces machines vous rendent idiots !

La perte de connaissances et de savoir faire est donc une composante intrinsèque de l’évolution des techniques et des technologies, y compris dans les technologies open source de l’informatique. C’était déjà perçu par Platon qui pointait du doigt les techniques d’écriture qui externalisaient la mémoire (Stiegler souligne à ce propos que le premier discours sur le prolétariat remonte à Platon).

Cela dit, et pour revenir sur le terrain de l’informatique, je pense qu’il faut appréhender tout ça à partir du modèle en couche. Ainsi, le jeune ingénieur travaille généralement au niveau d’une couche qui correspond à l’état de sédimentation et de maturité de la technologie sur laquelle il travaille. Dans l’exemple de Didier Girard, le développeur ne va pas faire de l’assembleur, pas plus qu’il ne va re-développer un framework ; il va partir de la couche la plus haute qui masque la complexité des couches inférieures. Et c’est une chose heureuse car il faudrait 10 ans à un ingénieur pour arriver au niveau d’un Didier en Java !

Mais l’ingénieur qui utilise un framework, sans être lui-même capable d’en développer un, n’est pas pour autant prolétarisé, car il doit développer de nouvelles compétences er de nouveaux savoir-faire sur des couches supérieures. Est prolétarisé celui qui n’a pas su trouver sa place dans l’évolution des techniques. Je peux donc dire qu’entre le jeune ingénieur et Didier, c’est bien Didier qui est le plus menacé par le risque de prolétarisation, d’ailleurs il le pressent lui-même en écrivant :

« encore quelques années et je vais m’ennuyer ferme… ».

je dis que Didier est le plus menacé de prolétarisation car, contrairement au jeune ingénieur, il a quelque chose à perdre – un savoir et des connaissances – en ce sens qu’il risque de ne plus pouvoir les exercer.

Si je reviens maintenant au modèle en couche, on ne peut donc pas connaître sur le bout des doigts tous les protocoles de chaque couche, mais on doit à minima connaître les interfaces en tant que lieu d’échange entre chaque couche, car c’est à partir de là que la possibilité d’un regard critique s’exerce.

Cela dit, je crois qu’aujourd’hui le débat en matière de prolétarisation (perte de connaissance et de savoir faire qui permet de s’individuer, de se réaliser) n’est plus au niveau du débat logiciel propriétaire versus logiciel libre. Il se cristallise sutout autour des données. L’enjeu est moins l’open source que l’open data, pour aller dans le sens du commentaire de David Larlet sur la même note qui parle de  » Sociétés de Service en Données Libres ».

Ce débat se jouera bien sûr autour des plate-formes web, du software as a Service et du Cloud Computing.

Related posts:

1. La prolétarisation dans les sociétés informatiques Par prolétarisation, j’entends le processus qui conduit à la perte...
2. Prolétarisation dans la généalogie des SSII Le processus de prolétarisation qu’il m’arrive d’évoquer dans certaines réunions...
3. Chat sur le Cloud Computing Vous pouvez vous inscrire pour participer au chat organisé par...

Par prolétarisation, j’entends le processus qui conduit à la perte de connaissance critique et de savoir-faire. Bernard Stiegler a clairement expliqué ce processus en rappelant qu’un prolétaire n’était pas nécessairement un pauvre (Alan Greenspan est un prolétaire qui a été le patron de la réserve fédérale américaine pendant vingt ans). Prolétarisation ne veut pas dire la même chose que paupérisation, même si l’un entraîne souvent l’autre.

Au début de la phase d’industrialisation, le prolétaire est celui qui a vu son savoir-faire passer dans la machine. En conséquence de quoi on ne l’a plus payé pour son savoir faire mais pour sa simple force de travail qui ne le distinguait dès lors plus d’un autre travailleur, et donc pouvait être mis en concurrence permanente.

C’est quelque chose que l’on peut constater : dans tout marché, dans la mesure où il s’industrialise, il y a une prolétarisation non seulement des utilisateurs et des consommateurs mais également de ceux qui font partie de la chaîne de conception et d’ingénierie. Aujourd’hui un garagiste ne répare plus les voitures : il branche une machine à diagnostic et vous indique le module à changer si son appareillage ne peut faire la réparation en réinitialisant le module incriminé.

Le marché de l’informatique et des technologies de l’information (Editeurs, DSI, SSII, Intégrateurs) n’échappe pas à cette tendance. ll est étonnant de voir que les ingénieurs qui ont participé à la conception des machines, puis des ordinateurs et enfin des logiciels sont eux aussi dans une phase active de prolétarisation. Ils participent à la mise en place d’un système technique qui prolétarise les utilisateurs de ces dispositifs, avant de les prolétariser eux mêmes en retour.

Confronté à la baisse tendancielle du taux de profit, une entreprise du secteur de l’informatique est condamné à étendre son marché : soit en augmentant le nombre de clients, soit en vendant plus (ou plus cher) chez chaque client.

C’est dans ce contexte que le marketing intervient pour optimiser le positionnement de l’entreprise sur un marché concurrentiel. Et, comme tout marché, le marché de l’informatique est façonné par le marketing. Façonné à un point où l’organisation et les départements des SSII et des intégrateurs est calqué sur le découpage des parts de marché des grands acteurs du logiciel : il y a le département Oracle, SAP, Microsoft, IBM et parfois, au fond du couloir à gauche, une plus petite équipe Open Source.

Si l’on considère le marché de l’informatique de gestion – et notamment celui des grandes entreprises – la prolétarisation est arrivé à un paroxysme. Signe de cette tendance, une spécialisation accrue des compétences qui est due à la complexification des systèmes d’une part, et au morcellement des applications déclinées par chaque vendeur de logiciel d’autre part (le spécialiste Weblogic ne sera pas à l’aise sur Websphere et inversement, pareil pour les bases de données, les EAI, etc.).

Pour chaque typologie de logiciel, la société de services informatique va devoir choisir les éditeurs avec lesquels elle souhaite travailler, car on ne peut maintenir des compétences sur tous les produits.

Situation à laquelle il faut rajouter la multiplicité des langages, où l’on voit chaque développeur plus ou moins limité par le spectre des solutions qui entrent dans le périmètre du langage qu’il maîtrise.

Ce qui se perd – dans le contexte que je viens de survoler rapidement – c’est le savoir-faire et la connaissance critique. Et cela est d’autant plus vrai du point de vue de l’architecte qui doit penser l’articulation entre des composants du système d’information.

Or ne peut pas être architecte (que ce soit de l’architecture réseau, applicative ou même de l’architecture des données) en étant incapable de porter un regard critique. Cela passe nécessairement par la capacité à discuter et à émettre des avis critiques, ce que ne sont pas capables de faire les experts techniques maîtrisant les solution d’un seul éditeur de logiciel.

je suis particulièrement sensible à cette situation car, n’étant pas un « informaticien expert », je me nourris de l’expérience des autres, des discussions et des échanges que je peux avoir avec les meilleurs d’entre eux (laurent, gautier, aurélien, bruno, yves-marie, etc.). Je suis comme le canari dans une mine de charbon qui prévient le manque d’oxygène : si je n’ai pas de répondant, c’est qu’il y a un affaissement de la capacité critique autour de moi.

La situation serait devenue pourtant bien pire si le web n’était pas là. Car les discussions et les échanges sont décuplées par le réseau qui est un espace participatif car chacun peut prendre la parole.
Mais il y a encore des informaticiens qui n’utilisent pas le web. Chose surprenante car les discussions techniques sur l’informatique sont très présentes sur le web. Je dis « n’utilisent pas le web » en ce sens que si un problème technique est posé, ils restent prisonniers de leur propre expérience, éventuellement de quelques collègues, mais n’ont pas le réflexe de mener des recherches approfondies et une réelle investigation sur le web (j’en avais fait l’exercice à propos des URIs déréférençables ).

Cela n’étonnera personne si j’affirme que c’est dans le domaine du logiciel libre qu’il y a le plus d’échanges et de discussions, c’est aussi là que les regards critiques s’exercent le plus car le mouvement repose sur une économie de la contribution dans laquelle chacun progresse parce que la communauté progresse. C’est également là que les standards sont les plus implémentés et les plus éprouvés.

Les informaticiens qui participent – ou on été élevé – à l’open source, sont toujours les meilleurs, même lorsqu’il s’agit d’aller mettre leur nez dans des solutions propriétaires : précisément parce qu’ils exercent un regard critique qui leur donne une hauteur que ne peut que difficilement développer quelqu’un qui reste dans les limites d’une solution propriétaire (quand ça va mal sur un projet SAP il n’est pas rare qu’un architecte « open source » arrive en renfort). « Meilleur » ne veut pas ici nécessairement dire  « techniquement plus compétent », cela veut aussi dire plus autonome, plus entreprenant, plus curieux. Bref, plus passionné.

Le mouvement Open Source est un véritable antidote à la prolétarisation de l’informatique. Mais cela ne doit pas être pour autant compris comme étant une invitation a imposer de l’Open Source partout, car le remède administré à trop forte dose deviendrait vite un poison.

Quoi qu’il en soit, « l’ingénieur open source » fait peur au marché et au management des grandes SSII : précisément parce qu’il a un savoir-savoir faire qui peut tout remettre en cause, notamment des choix commerciaux ou une stratégie marketing. C’est un peu celui qui n’est pas facilement « manageable » parce qu’il est singulier. Et si beaucoup de profils « professionnels » de l’informatique se ressemblent, c’est parce que ce sont des « ressources » interchangeables et prolétarisées, qui n’ont pas la singularité des ingénieurs open source.

Or manager et tirer tout le profit de ces passionnés qui participent au développement du métier est un enjeu majeur pour toutes les SSII, qu’elles n’exploitent que très mal. Il est toujours plus facile d’avoir une stratégie d’allégeance inconditionnelle aux pressions du marketing des éditeurs de logiciels que de développer sa propre vision en faisant confiance à ceux qui sont encore capables de porter un regard critique sur les technologies.

C’est parce que l’intelligence technique – qui au sens strict du terme s’appelle le génie – est sacrifiée à une vision exclusivement mercantile et court-termiste du métier que l’on se retrouve avec une population d’informaticiens prolétarisés.

Il y a un manque chronique d’architectes ou de développeurs de talent dans les grandes SSII, non pas qu’ils n’existent pas, mais ils sont trop peu nombreux en proportion de la masse salariale. je repense à Yves Marie Pondaven qui me parlait de Jean Paul Figer , figure emblématique de Capgemini, qui peut arriver sur un grand projet de plusieurs millions d’euros à la dérive et dire en substance :

« je vous refais tout pour deux fois moins cher et deux fois plus vite, mais on fera comme je dirai ».

Combien sont capable de dire çà à des grands clients ? Combien d’entre-nous sont capables de dire à un client :

« la solution que vous demandez et la façon dont vous voulez qu’elle soit réalisée relève d’une profonde erreur d’appréciation »

Mais, si c’est si dur à dire à un client, c’est parce que la prolétarisation des informaticiens touche aussi celle des entreprises clientes qui sont devenues des consommatrices de solutions packagées par le marketing des éditeurs.  Les départements informatiques, dans leur grande majorité, ont perdu tout sens critique depuis que leur culture technique repose dans le meilleur des cas sur la lecture hebdomadaire de 01 Informatique ses dix dernières années.

Aussi quand vous êtes en face du client qui vous dit, fier de lui et avec l’oeil qui pétille « Je veux de la SOA avec un bon gros serveur d’application qui crache du SOAP avec un ESB et du MDM », que faut-il faire ? On se dit que c’est trop tard, et trop risqué de revenir en arrière ou d’émettre des doutes, et on lui dit « mais bien sûr, je vois que vous êtes un connaisseur, on va vous faire un beau projet « state of the art » … sachant que l’on va droit dans le « state of the art failure ».

Related posts:

1. Réponse à une objection sur « la prolétarisation dans les sociétés informatiques » Didier Girard, sur Application Servers , fait une remarque intéressante...
2. Prolétarisation dans la généalogie des SSII Le processus de prolétarisation qu’il m’arrive d’évoquer dans certaines réunions...
3. Prolétarisation paysanne et terracide Dominique Guillet, fondateur de Kokopelli, association qui produit et distribue...

Dans tout projet d’intégration d’entreprise visant à agréger des services provenant de différents silos applicatifs, le serveur d’application centralisé semble être une évidence, et l’on parle alors de Portail d’Entreprise.

On écoutera patiemment les arguments des éditeurs de telles solutions ainsi que ceux des DSI qui vantent les qualités du portail d’entreprise comme point d’entrée centralisé (maîtrisé, personnalisable, sécurisé, etc.) pour l’ensemble d’un porte-feuille applicatif.

Allons donc !

• Un point d’accès centralisé ? Pas besoin, j’ai des bookmarks dans n’importe quel navigateur qui me permettent d’accéder aux applications (web ou « webisées ») avec lesquelles je travaille.
• Plusieurs écrans d’application en même temps ? A quoi bon puisque de toute manière je peux ouvrir une nouvelle fenêtre de navigateur ou un nouvel onglet pour avoir plusieurs interfaces d’applications.
• Un seul point d’authentification ? Un Active Directory ou n’importe quel LDAP fait cela tout aussi bien.
• Le portail offre des vues personnalisées ? Mais qui se sert de çà et qui en a besoin ?
• Une intégration applicative de haut niveau dans une seule page ? Mais qui *travaille* dans un portail ! Une simple page web personnalisée avec des widgets me donnera un bon petit tableau de bord personnalisé pour gérer mon activité, avant de basculer sur de pleines pages si nécessaire.

Un grand portail d’infrastructure d’entreprise n’a aujourd’hui plus aucun intérêt (s’il en a jamais eu) si les services applicatifs qu’il centralise sont des services web  : la mise en place de flux RSS et ATOM, plus quelques widgets ont beaucoup plus de valeur que ces projets de centralisation de l’accès à l’information et aux applications.

Ici avec le portail, mais comme avec l’ensemble des démarches d’intégration (SOA, MDM, ESB), il faut se poser la question : mais pourquoi vouloir tout centraliser ? Dans les démarches d’architecture des SI en entreprise, trop souvent le choix de centraliser l’architecture est un axiome, donc un a priori, rarement la conséquence d’un choix raisonné, d’une conception.

Je comprend que les grand éditeurs poussent l’idée de centralisation car plus le Système d’information devient centralisé, plus le pactole à ramasser est important (« bingo ! Untel a pris mon ESB, tout son SI repose sur mon produit »). Mais pour les DSI, et derrière eux les utilisateurs du SI, cela n’a aucun sens.

Related posts:

1. APIE : Agence Pour l’Incurie de l’État Créée en 2007, juste après la publication du rapport « Lévy-Jouyet »(PDF)...

Dans le cadre d’une demi-journée consacrée à Google et au Cloud Computing, les étudiants de l’EFREI avaient invité Didier Girard et ses équipes de  SFEIR pour parler de GWT et d’Android, ainsi que moi-même pour parler du Cloud Computing.

La vidéo de mon intervention :

Cliquez pour télécharger/regarder

Les autres videos sur Talus’ LaBlog.

Related posts:

1. Chat sur le Cloud Computing Vous pouvez vous inscrire pour participer au chat organisé par...
2. Cumulus de billets sur le Cloud Deux bons billets d’Aurélien Pelletier et Bruno Paul sur le...
3. Le cloud computing et l’internet des objets Voici la vidéo de mon intervention lors des « Entretiens du...

Sur le blog d’Atos Origin je reviens sur les enjeux d’une politique de gestion des données.

A quand des architectes de l’information et des données ?

Related posts:

1. Table ronde sur le futur des applications Web La table ronde sur le futur des applications Web, qui...
2. Ars Industrialis sur Twitter Vous pouvez à présent suivre l’actualité d’Ars Industrialis sur Twitter....
3. C’est clair, non ? Le site twitteradar vous tient informé de l’actualité du service...