Le projet de ce mémoire est d'essayer de mesurer le pouvoir de marché dans l'industrie du logiciel. Pour cela, il faut identifier et mesurer une ou des caractéristiques structurelles du secteur. Le logiciel étant un bien immatériel, il est naturel de penser que les économies d'échelle sont cette caractéristique recherchée. Mais pour faire une analyse empirique, il faut identifier les frontières du secteur, car les résultats dépendent lourdement du périmètre retenu. C'est pour cela que nous montrons que le logiciel est un secteur distinct du secteur des services informatiques. Cette démonstration demande une méthodologie d'analyse de secteur. Voici la logique de notre démarche. Cette étude comprend donc quatre chapitres. Le premier chapitre explicite la méthodologie d'analyse de secteurs. Cette méthodologie permet d'identifier les phénomènes de convergence et/ou de divergence sectorielle. Elle sera utilisée ici pour identifier le secteur objet de notre investigation, celui des logiciels informatiques. En conséquence, le second chapitre identifie et quantifie la différence entre l'industrie du logiciel et l'industrie des services informatiques. Le troisième chapitre présentera une tentative de mesure des économies d'échelle dans le secteur du logiciel, économies d'échelle qui apparaissent beaucoup moins radicales qu'une approche purement théorique peut induire. Enfin, le dernier chapitre utilisera les résultats empiriques concernant les économies d'échelle dans l'industrie du logiciel pour évaluer sur moyenne-longue période (10 ans) le pouvoir de marché de l'entreprise dominante, Microsoft.

Basés sur les protocoles XML, SOAP et WSDL, les Services Web (SW) sont la technologie de base pour le développement d'Architectures Orientées Services (AOS). Ces architectures permettent de mettre en place des applications faiblement couplées avec un fort degré de configuration dynamique. Elles se basent sur la notion de relation de "services" formalisée par un contrat qui unit le client et le prestataire de services. Ce contrat est le point charnière de ce type d'applications. D'un point de vue purement marketing, les Services Web peuvent être développés pour satisfaire les besoins des clients, être facile à maintenir et aussi fournir un haut niveau de qualité de service. Les prestataires de Services Web doivent s'assurer de la fiabilité et de la disponibilité de leur infrastructure individuelle de Services Web. Cependant, les prestataires ne peuvent pas tenir compte de tous les besoins possibles des clients et des contraintes liées au développement de l'application donnée. Cela signifie que des mécanismes additionnels doivent être développés et ciblés pour un contexte d'utilisation donné. C'est exactement le type de problèmes que j'ai examiné dans mes travaux. Les développeurs d'application regardent les Services Web comme des COTS (Component Off-The Shell) et ignorent donc leurs implémentations et leurs comportements en présence de fautes. De ce point de vue, les clients ont besoin de développer des mécanismes de tolérances aux fautes spécifiques bien adaptés à leurs applications. Dans ce but, mes travaux de thèse m'ont conduit à proposer une plate-forme pour aider les clients à réaliser des connecteurs spécifiques de tolérance aux fautes (SFTC - Specifique Fault Tolerance Connectors) qui implémentent des filtres et autres techniques de détection d'erreurs (c.à.d des assertions exécutables) ainsi que des mécanismes de recouvrement qui sont déclenchés quand les Services Web ne satisfont plus les caractéristiques de sûreté demandées. De plus, le même Services Web peut être employé dans plusieurs applications orientées services avec différentes contraintes et peut donc tirer profit de plusieurs connecteurs (SFTCs). Le problème est similaire à l'utilisation des composants COTS dans les systèmes critiques de sûreté, et des travaux précédents ont déjà prouvé que des mécanismes tels que les wrappers étaient une solution possible. La différence dans le contexte des Architectures Orientées Services est que des wrappers prédéfinis ne peuvent pas être spécifiés pour satisfaire tous les besoins possibles. L'approche doit être plus adaptative pour permettre à des mécanismes de sûreté : 1) d'être définis au cas par cas pour une utilisation donnée du Service Web et 2) d'avoir une forte dynamique afin d'être modifiés selon les besoins. Ainsi, mes travaux de recherches ont permis de fournir aux développeurs d'Architectures Orientées Services: 1) un langage nommé DeWeL pour décrire les caractéristiques de sûreté de fonctionnement du connecteur et 2) l'infrastructure IWSD pour dynamiquement contrôler et exécuter les connecteurs dans des applications critiques. L'objectif final est de fournir aux développeurs d' Architectures Orientées Services une infrastructure et des outils capables de les aider à déployer des applications orientées services tolérants les fautes.