Dans une base de données répartie, la réplication de données peut servir à augmenter la fiabilité et la disponibilité de données ainsi que les performances d'accès. En général, l'unité de réplication (copie ou replique) est un table relationnelle (ou un fragment), un document ou un fichier. La réplication consiste alors en placer plusieurs copies sur différents noeuds distincts. Cela fournit une grande disponibilité de données. Si un noeud devient non opérationnel à la suite d'une panne par exemple, une autre copie est toujours accessible sur un autre noeud. La réplication permet aussi aussi de améliorer les performances d'accès en augmentant la localité des références. Lorsque le coût de communication est un facteur dominant, le placement d'une copie sur le noeud où il est le plus souvent accédé favorise les accès locaux et évite l'accès au réseau. Les avantages apportés par la réplication sont à comparer avec la complexité et les coûts supplémentaires de maintenance des copies qui doivent, en théorie rester identiques à tout moment. La mise à jour d'une copie doit être répercutée automatiquement sur toutes ses repliques. Le problème est compliqué par la présence de pannes de noeud ou réseau. Le compromis recherché entre performance d'accès en consultation et en mise à jour des données rend difficile le choix du niveau de réplication. Celui-ci est très dépendant de la charge de travail demandée par les applications. Face à ces défis dans mes travaux de recherche nous avons focalisé sur la gestion de la cohérence pour réplication asynchrone pour plusieurs contextes : entrepôts de données, grappes et applications collaboratives et en pair à pair (P2P). 1. Entrepôts de Données Dans les architectures proposes pour la gestion de entrepôts de données les configurations mono- maître sont souvent utilisés. Dans la réplication mono-maître, plusieurs types configurations acycliques dirigés sont possibles: diffusion, mono-consolidation multi-consolidation, triangulaire. La gestion de la cohérence se pose surtout pour certaines configurations comme dans la multi-consolidation et triangulaire et ses généralisations en combinant les configurations de base. 2. Grappes Les applications dans lesquelles sont utilisées les grappes sont typiquement des applications de lectures intensives, ce qui rend plus facile l'exploitation du parallélisme. Cependant, les grappes peuvent également être utilisées dans un nouveau modèle économique, les Fournisseurs de Services d'Applicatons ASP - Application Service Providers. Dans un contexte ASP, les applications et les bases de données des clients sont stockées chez le fournisseur et sont disponibles, typiquement depuis Internet, aussi efficacement que si elles étaient locales pour les clients. Pour améliorer les performances, les applications et les données peuvent être répliquées sur plusieurs noeuds. Ainsi, les clients peuvent être servis par n'importe quel noeud en fonction de la charge. Cet arrangement fournit également une haute disponibilité: dans le cas de la panne d'un noeud, d'autres noeuds peuvent effectuer le même travail. Le défie est de gérer la réplication multimaître totale et partiel en assurant la cohérence forte et toute en passant à l'échelle. 3 Applications Collaboratives en P2P Les systèmes P2P adoptent une approche complètement décentralisée au partage des ressources. En distribuant données et traitements sur tous les pairs du réseau, ils peuvent passer à très grande échelle sans recourir à des serveurs très puissants. La réplication de données dans les systèmes P2P devient un enjeu majeur pour les applications collaboratives, comme les forums de discussion, les calendriers partagés, ou les catalogues e-commerce, etc. En effet, les données partagées doivent pouvoir être mises à jour en parallèle par différents pairs. Les premiers systèmes P2P existants supposent que les données sont statiques et n'intègrent aucun mécanisme de gestion des mises à jour et de réplication. Une mise à jour d'une donnée par le pair qui la possède implique une nouvelle version non propagée à ceux répliquant cette donnée. Cela résulte en diverses versions sous le même identifiant et l'utilisateur accède à celle stockée par le pair qu'il contacte. Aucune forme de cohérence entre les répliques n'est alors garantie. Le défi est gérer la cohérence éventuelle face au dynamisme des pairs tout en passant à l'échelle.