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.