Multitenant
Cet article ne cite pas suffisamment ses sources ().
Si vous disposez d'ouvrages ou d'articles de référence ou si vous connaissez des sites web de qualité traitant du thème abordé ici, merci de compléter l'article en donnant les références utiles à sa vérifiabilité et en les liant à la section « Notes et références ».
En pratique : Quelles sources sont attendues ? Comment ajouter mes sources ?
En informatique, multitenant[1], ou multi-entité, désigne un principe d'architecture logicielle permettant à un logiciel de servir plusieurs organisations clientes[réf. nécessaire] (tenant en anglais, ou locataire en français) à partir d'une seule installation. Elle s'oppose à une architecture multi-instance où chaque organisation cliente a sa propre instance d'installation logicielle (et/ou matérielle)[2]. Avec une architecture multi-tenant, un logiciel est conçu pour partitionner virtuellement ses données et sa configuration, et chaque organisation cliente travaille avec une instance virtuelle adaptée à ses besoins.
Avantages
[modifier | modifier le code]Une architecture multitenant permet de mutualiser les ressources et les coûts nécessaires à l’exécution de l'application. En ce sens, cette architecture peut être vue comme une alternative à la virtualisation. L’agrégation de données et la fouille de données sont facilitées car une seule base de données stocke toutes les données[3]. Le processus de livraison est simplifié car il n'y a qu'une instance à mettre à jour.
Inconvénients
[modifier | modifier le code]Le développement d'une application multi-tenant est plus difficile car il y a plus de possibilités de configuration et la gestion des données est complexifiée[2]. La sécurité des données est essentielle afin qu'un utilisateur d'une entité ne puisse pas accéder aux données d'une autre entité. Afin d'y parvenir, le chargement des données doit se limiter à n'inclure que les données de l’entité courante, sauf à de rares exceptions telles que le traitement par lots. Le processus de livraison est plus risqué car si l'application contient un bug, il y aura un impact sur toutes les entités. De plus il peut devenir difficile de trouver des fenêtres pour la mise à jour de l'application lorsqu'une application multi-tenant est utilisée sur plusieurs fuseaux horaires. Enfin, les mécanismes de sauvegarde, et encore plus de restauration, posent aussi de vrais problèmes. En effet, alors que la sauvegarde peut s'effectuer à chaud, sur l'ensemble des données (toutes entités confondues), il est beaucoup plus difficile de réaliser une restauration des données d'une seule entité.
Notes et références
[modifier | modifier le code]- Guillaume Plouin, « Retour d’expérience d’architecture multi-tenant », sur Blog plouin.fr, (consulté le )
- « Architecture multi-tenant, une fausse bonne idée ? – Fier de coder », sur www.fierdecoder.fr (consulté le )
- « Plate-Forme Multi-Tenant : La Clé du Succès à la Demande - salesforce.com France », sur www.salesforce.com (consulté le )
