Partenariats, codéveloppements... Microsoft investit aujourd'hui lourdement pour convaincre les éditeurs d'adapter leur offre à .Net. Si la plupart d'entre eux disposent déjà d'une solution pour s'interfacer avec .Net ­ services web notamment ­, les véritables connecteurs natifs et redéveloppements des noyaux de logiciels ne se concrétiseront réellement qu'à partir du second semestre de 2004. « Nous avons un peu négligé les éditeurs, reconnaît Alain Le Hegarat, responsable marketing de la division .Net de Microsoft France. Nous rattrapons cette erreur depuis neuf mois avec la création d'un groupe spécifique chez Microsoft France, dédié uniquement à l'accompagnement commercial et technique des éditeurs désireux d'adapter leur offre à .Net. »

Erreur qui n'explique qu'en partie l'attentisme des éditeurs, la plupart d'entre eux ayant préféré attendre la maturité de .Net. « La seule chose dont on soit certain, c'est que l'on ne peut pas ignorer .Net, explique Laurent Carrière, directeur avant-vente Emea de Siebel. Microsoft est souvent arrivé après les autres sur le marché, et il a toujours su s'imposer ! » Comme le souligne Claude Verdier, directeur technique de FDV Concept, éditeur d'une solution de GRC, « .Net permet de réconcilier Windows et le web. Le client web est limité en fonctions ; il ne correspond pas à tous les besoins de nos clients. Avec .Net, il est possible de générer une interface riche de type Windows et/ou une interface web à partir d'un seul développement ».

En outre, en période de récession des investissements informatiques, la nouvelle plate-forme de Microsoft dispose d'un dernier atout : le coût global d'une solution. Avec .Net pour socle d'exécution, les éditeurs peuvent, en effet, attaquer le marché des PME et des projets départementaux avec des solutions dont le prix n'est pas majoré par des briques techniques (serveur d'applications J2EE) et du matériel plus onéreux que les serveurs Intel utilisés par Microsoft. Un argument qui n'a pas échappé à certains éditeurs comme Geac, dont le PGI, initialement conçu en Cobol pour AS/400, vient d'être redéveloppé en C#. « Nous avons envisagé l'option J2EE et... déchanté, explique Sylvain Pineau, responsable de l'offre produits de Geac. Pour répondre à la demande de nos clients qui voulaient du client léger sur le poste de travail, nous avons considéré la possibilité de profiter de l'arrivée de Websphere sur l'AS/400. Mais, après étude, nous avons réalisé à quel point l'investissement global que requérait la mise en place de notre PGI était exorbitant, compte tenu du coût du matériel, de Websphere, des différentes extensions et autres outils d'exécution. Avec .Net, nous n'imposons pas un socle d'exécution hors de prix, étant entendu qu'il est intégré à Windows présent dans la plupart des entreprises. »

L'engouement pour .Net ne remet toutefois pas en cause les stratégies J2EE des éditeurs. SAP, par exemple, qui a remplacé son serveur d'applications propriétaire par un autre compatible J2EE, n'envisage pas de revenir sur ce choix. Ce qui ne l'empêche pas de s'impliquer fortement dans .Net. « SAP continuera de fonctionner sur J2EE, car c'est la seule plate-forme qui nous garantisse la portabilité, et donc la présence sur différents systèmes d'exploitation, explique Jean-Michel Franco, directeur marketing France de SAP. Mais certains composants fonctionneront nativement dans .Net. Aujourd'hui, la moitié de nos installations en entreprise fonctionnent sur Windows, et le marché se développe surtout du côté des PME, où Microsoft est également très présent. Nous pouvions difficilement faire autrement qu'adapter au maximum notre offre à .Net. »