Annoncée en juin 2000, la stratégie .Net de Microsoft a déjà suscité plus de commentaires que de réelles mises en œuvres… Plus de deux ans après son lancement, il est temps de se poser quelques questions essentielles :
Où en est-on et quel est l’accueil des clients aux USA ?
Mais, au-delà de ces questions évidentes, on peut aussi s’interroger plus globalement :
Quel est le véritable objectif de Microsoft avec .Net ?
Pourquoi .Net serait-elle importante au point que Gates répète qu’il parie l’avenir de sa société sur sa réussite ?
Avant de répondre à ces importantes questions, rappelons que .Net est présentée par Microsoft comme une évolution radicale de l’ensemble de son offre. .Net vise à couvrir l’ensemble des besoins applicatifs de ses utilisateurs (Web, client/serveur, back-office …) en s’appuyant sur un framework commun.
Où en est-on ?
Même s’il est évident que la mise en œuvre de tout ce qui a été annoncé en juin 2000 va prendre du temps, il est légitime de mesurer l’ampleur des progrès réalisés en deux ans. Et, une fois de plus, on ne peut que constater que la machine marketing de Microsoft n’a jamais le temps d’attendre que les développeurs concrétisent les promesses. En effet, pour bien marquer la nouvelle direction, certains produits Microsoft ont été un peu vite rebaptisés .Net alors qu’il y avait eu peu de changements en eux… Au début de l’été 2002, même Bill Gates reconnaissait que l’appellation .Net avait été collé un peu abusivement sur la ligne .Net Enterprise Servers…
Cette stratégie reste néanmoins ambitieuse puisque toute la gamme de logiciels serveurs doit passer sur .Net (et sans doute aussi les offres acquises dernièrement comme l’ERP de Navision).
Aujourd’hui, l’attente se focalise autour de la prochaine version de Windows 2000 Server baptisée Windows .Net Server 2003 qui était initialement prévue pour la mi-2002 mais qu’il ne faut pas attendre avant avril 2003. Bref, .Net n’en est encore qu’au début de son déploiement au sein de l’offre de Microsoft, il ne faut pas donc pas trop en attendre…
Quel est l’accueil aux USA ?
Soyons clair, pour le moment .Net n’a pas encore bénéficié d’une adoption massive de la part du marché et, d’une certaine manière, c’est normal ! Le retard à l’allumage s’explique facilement, .Net étant présenté comme la solution Microsoft pour les web services, son accueil est alors lié aux développement effectifs de ces web services… or, pour le moment, ceux-ci marquent le pas. Comment expliquer que les web services tardent à décoller alors que tous les observateurs les présentaient comme « la nouvelle grande affaire ! » ?
Plusieurs raisons objectives permettent d’expliquer pourquoi les web services n’ont pas encore « explosé » comme tout le monde le prédisait :
- Situation économique déprimée et atmosphère pas favorable.
- Concept un peu subtil à saisir et mise en œuvre moins facile qu’espéré.
Le dégonflement de la bulle Internet ne s’est pas contenté d’assécher les crédits des équipes informatiques, il a aussi considérablement réduit l’enthousiasme pour le couple nouvelle technique/nouveaux usages. Non seulement il n’y a plus d’argent à dépenser mais, en plus, le moral ne se prête pas à de « nouvelles grandes conquêtes » vu que les dernières campagnes n’ont pas vraiment donné les résultats escomptés.
Bref, c’est la crise et cette situation ne se résume pas à des coupes dans les budgets et dans les équipes, ce sont aussi les initiatives qui sont rejetées sans être examinées, même si elles pourraient être potentiellement profitables. Dans le contexte actuel, on se contente de « faire du sûr » et cela se résume souvent à économiser là où c’est possible.
De plus, on peut même affirmer qu’une certaine forme de scepticisme (légitime) touche les web services et cela peut se comprendre. Comme d’habitude, l’industrie informatique (Microsoft y compris) n’a pas été avare d’hyperboles pour présenter ce nouveau concept, tellement elle était à la recherche d’un second souffle juste après l’éclatement de la bulle. Le concept n’est pas si évident et il n’a pas été présenté de façon à séduire les entreprises : on a noyé les web services dans une perspective grandiose complètement utopique alors qu’il s’agit simplement de la bonne forme de middleware.
Rappelons qu’un middleware n’est pas une application, c’est seulement le moyen d’intégrer des applications entre elles et donc d’en étendre les possibilités et l’intérêt (le système ainsi constitué vaut plus que la somme des parties…). C’est important, c’est même crucial dans certains cas, mais ce n’est pas très spectaculaire et c’est pour cela que les fournisseurs ont cru devoir rosir le tableau… mauvaise idée !
Du coup, les web services ont été catalogués comme la nouvelle mode des fournisseurs et cette étiquette était purement éliminatoire tellement les utilisateurs ont souffert de ces modes illusoires, y compris et surtout dans un passé récent.
Donc les moyens manquent, la volonté manque et l’industrie informatique a fait ce qu’il fallait pour compliquer encore le tableau… mais il y a plus, les web services ne sont pas si faciles que cela à mettre en œuvre !
Tout d’abord, il s’agit encore en partie d’un « projet en cours » : tous les éléments n’ont pas été disponibles simultanément et la standardisation n’est pas encore complètement achevée.
Les offres des fournisseurs ne se sont complétées que très progressivement car il leur a fallu, à eux aussi, comprendre le concept, faire la part entre le concret et le hype, faire le tri entre les éléments disponibles et markéter le tout. Cela a pris du temps.
Ensuite, il faut avouer que développer une interface de type web services, c’est simple mais quand même pas aussi simple que de faire des pages en HTML… il s’agit de programmation et la programmation ne sera jamais « simple ». Pour développer une interface de type web services, vous n’avez pas besoin d’un développeur top gun, un développeur moyen suffira mais n’imaginez pas que vous aller pouvoir confier cette tâche à un webmaster formé sur le tas qui maîtrise le HTML mais pas plus !
Certes, les web services représentent un grand progrès en terme de facilité de mise en œuvre par rapport au formes précédentes de middleware mais ce n’est pas encore assez pour les mettre au niveau de n’importe quel technicien capable de designer des pages web.
Les web services représentent tout de même un grand enjeu dans l’informatique d’aujourd’hui : permettre enfin l’harmonisation des différents systèmes qui se sont accumulés dans chaque entreprise ces dernières années. En effet, les entreprises sont sur-équipées avec des systèmes et des applications qui sont autant d’îlots de données qu’il est bien difficile d’agréger afin d’avoir une vue globale de la situation à un instant T.
Ce problème n’est pas nouveau mais, de part les échecs répétés en matière de middlewares, la situation n’a fait qu’empirer au point où elle est désormais perçue comme intolérable.
Les web services sont donc surtout utilisés pour des problématiques de type EAI (intégration) et, dans ce contexte, .Net n’est pas très bien placé.
En effet, Microsoft et les outils de Microsoft sont perçus comme peu adapté (à tort ou à raison) au développement ayant pour but d’harmoniser les échanges entre systèmes hétérogènes (donc ayant une part significative de « non-Microsoft »).
Pour certains clients qui ont déjà lourdement investi dans les technologies Microsoft (par exemple ceux qui ont développé leurs sites Internet ou Intranet avec ASP…), .Net peut même apparaître comme une menace aussi bien sur le plan technique (nécessité de migrer ou même de réécrire !) que sur le plan financier (les changements récents de la politique de licences de Microsoft ont provoqué un tollé). Cette incertitude peut en pousser quelques-uns à étudier des solutions alternatives et confiner le gros de la cible dans l’attentisme. D’ailleurs, en la matière, la concurrence vis-à-vis de .Net ne vient pas de J2EE mais plutôt du côté du monde Open Source.
En effet, on commence à voir apparaître des adaptations de tout ou partie de .Net dans des projets open source sérieux comme Mono (voir à http://developer.ximian.com/projects/mono/) ou DotGNU (voir à http://www.fsf.org/projects/dotgnu/). En fait, c’est assez logique : c’est grâce à la communauté open source que SOAP s’est concrétisé et est devenu le succès que l’on sait, il est donc naturel que le mouvement englobe désormais les outils destinés à mettre en œuvre les web services.
Donc, le bilan à mi-parcours (les responsables de Microsoft répètent qu’il faudra encore 2 à 3 ans pour compléter l’offre .Net) n’est pas encore formidable. Pour autant, on aurait tort de croire que .Net n’est qu’un projet comme les autres pour Microsoft.
Le vrai enjeu de .Net ne se limite pas à être un outil de mise en œuvre des Web Services… Gates le dit lui-même « il n’y a pas réellement de différence entre .Net et Windows » (cf. une interview dans InformationWeek du 18 février 2002) et il faut comprendre cette stratégie comme étant une continuation des batailles passées ainsi qu’une projection pour protéger la position dominante de Microsoft, rien de moins !
Oui, .Net est aussi une énième tentative de Microsoft pour s’imposer dans le domaine des serveurs et des middlewares d’entreprise. Cette bataille remonte aux tous premiers affrontements entre COM/DCOM (proposition Microsoft des objets distribués) et Corba (proposition soutenue principalement par Sun) puis autour de Java et des serveurs d’applications et enfin aujourd’hui sur la question des Web Services.
A chaque fois, Microsoft a proposé sa propre version d’un middleware qui permettrait de fonctionner en mode distribué avec ses propres serveurs, toujours en opposition avec les environnements plus hétérogènes venant de la concurrence. C’est toujours là que résidait le principal atout des offres réseaux badgées Microsoft (une intégration étroite avec les versions successives de Windows) mais c’est aussi à ce niveau qu’on pouvait y voir sa principale lacune (en dehors de l’univers MS, point de salut…). Même si le succès n’a pas été au rendez-vous, Microsoft a poursuivi sans dévier de sa trajectoire car, et c’est là une constante de cette société, Microsoft ne renonce jamais !
Le véritable objectif de .Net est donc bien de préparer la plate-forme qui va permettre de « relayer » Windows tout comme Windows, au temps de sa mise au point laborieuse, était destiné à « relayer » MS-Dos (ce qu’il fit avec succès). C’est pour cela que l’enveloppe de .Net est si vaste et si diversifiée : des Web Services à la gestion des droits numériques (DRM). Le but est de diffuser (via Windows XP qui est le premier vecteur silencieux de la prolifération nécessaire de .Net) des services réseaux qui soit attractifs et qui assurent le caractère indispensable de Microsoft dans le futur.
Avec .Net, le but de Microsoft est de passer, progressivement, de la vente de logiciels à la fourniture de services réseaux payés par abonnement. Mais le rôle de .Net ne s’arrête pas à la concrétisation de la notion de services rendus par le réseau et vendus par abonnement. Le plan d’ensemble imaginé par Microsoft est encore plus vaste et ambitieux, il s’agit ni plus ni moins d’être en mesure de piloter les machines des utilisateurs partout et tout le temps !
A travers la notion de services réseaux omniprésents, il s’agit aussi de faire passer le PC du stade de machine cliente au niveau de nœud du réseau capable d’envoyer mais aussi de recevoir des requêtes de tout type…
Il y a vingt ans, la machine de l’utilisateur était un terminal passif incapable d’afficher autre chose qu’une image de ce que le mainframe avait calculé pour lui. Le PC et le modèle client-serveur a fait évoluer la situation et un dialogue s’est instauré : le PC est capable d’envoyer des requêtes que le serveur traite en ne faisant plus qu’une partie du travail. Ceci dit, l’inverse n’est pas vrai : encore aujourd’hui, il est difficile de considérer que le PC est un nœud du réseau à part entière, il est confiné à son rôle de client. Or, « l’informatique en réseau » qui est en train de se mettre en place exige bien plus !
Ne serait-ce que pour des raisons d’auto-administration, chaque machine branchée sur le réseau devra être en mesure de répondre à des requêtes de service et c’est bien pour cela que Microsoft associe aussi étroitement Windows et .Net.
Pour en revenir à l’évocation du terminal, à l’époque, la direction informatique avait les moyens de contrôler complètement l’usage de ces systèmes et de ces applications. Le PC et le modèle client-serveur a fait voler en éclat cette capacité et bien des directions ne s’en sont jamais consolées. Microsoft va jouer sur ce regret quand il s’agira de lancer Palladium, un projet futur qui est complémentaire de .Net.
Palladium est un logiciel que Microsoft déclare vouloir incorporer dans les futures versions de Windows (première version vers 2005). Palladium va redéfinir la façon dont vos PC vont non seulement fonctionner mais également se comporter vis-à-vis des applications installées sur votre machine et sur les contenus présents sur votre disque dur… le tout sous le prétexte de restaurer « la sécurité et la confiance dans le monde PC ».
Il sera beaucoup plus difficile avec Palladium d’utiliser des logiciels sans licence. Les logiciels piratés pourront être détectés et même effacés à distance (grâce à des services .Net !). À côté de la vente, la location des logiciels sera facilitée ; et en cas de cessation du paiement du loyer, non seulement le logiciel ne fonctionnera plus mais peut-être aussi les fichiers qu’il a créés. Le but ultime sera bien d’avoir un contrôle actif sur sa base installée et pas seulement par le poids du monopole, bien vu !
Avec une finalité pareille, Microsoft peut se permettre de prendre son temps, .Net représente son « assurance santé » pour les vingt prochaines années si, toutefois, le marché se laisse faire…
