Infrastructure IA multi-locataire : guide de conception complet

3

Une infrastructure IA multi-locataire doit remplir cinq fonctions à la fois. Elle doit maintenir séparés les données, les identités et la piste d’audit de chaque locataire. Elle doit empêcher le pic d’entraînement d’un locataire d’affamer le SLA d’inférence d’un autre. Elle doit mesurer la consommation assez finement pour que la facture corresponde au contrat. Elle doit appliquer des frontières de sécurité qui résistent à un audit. Et elle doit faire tout cela sur du matériel physique partagé, car c’est précisément la raison d’être d’une plateforme multi-locataire.

Ce guide s’adresse aux responsables d’infrastructure qui conçoivent cette plateforme — au sein d’une entreprise exploitant l’IA pour plusieurs unités métier, chez un fournisseur de services vendant de l’IA à de nombreux clients, ou chez un opérateur de cloud souverain fournissant une capacité IA réglementée à des locataires du secteur public. Les choix de conception ci-dessous ne sont pas des options. Ils constituent le socle minimal requis pour qu’une offre d’infrastructure IA multi-locataire tienne face aux contrats, aux audits et à la croissance.

Qu’est-ce qu’une infrastructure IA multi-locataire ?

Une infrastructure IA multi-locataire est l’ensemble combiné des contrôles de calcul, de stockage, de réseau, d’identité et d’exploitation qui permet à une plateforme unique de servir de nombreux locataires — unités métier internes ou clients externes — exécutant des charges IA sur des ressources physiques partagées, avec une isolation forte entre locataires et une responsabilité par locataire en matière de consommation, de performance et de posture de sécurité.

Le terme « multi-locataire » implique plus que plusieurs clients sur une même plateforme. La difficulté réside dans le reste : une isolation qui ne cède pas sous la charge, une identité qui ne se brouille pas entre locataires, des quotas qui tiennent lors des pics, des journaux d’audit qui prouvent ce que chaque locataire a fait et uniquement cela, et une couche de facturation capable de se justifier lorsque le client demande comment un chiffre a été calculé. Une plateforme qui fournit du temps de calcul à plusieurs locataires sans pouvoir mesurer leur stockage par bucket et par niveau n’est pas multi-locataire au sens où l’entend un fournisseur de services IA.

L’infrastructure IA multi-locataire se distingue aussi de l’infrastructure IA purement d’entreprise. Une entreprise construit pour un seul locataire : elle-même. Un opérateur multi-locataire construit pour de nombreux locataires à la fois, sans locataire privilégié, sans identité root partagée et sans confiance implicite entre charges de travail. Cette seule contrainte redessine l’architecture.

Les cinq piliers de conception

Pilier	Ce qu’il couvre	Pourquoi c’est important
Isolation des locataires	Frontières de données, d’identité, de performance, de cycle de vie et d’exploitation entre locataires	Empêche les fuites de données, les effets de voisin bruyant et la propagation des incidents d’un locataire à l’autre
Séparation des espaces de noms	Espaces de noms logiques par locataire — buckets, comptes, IAM, journaux d’audit	Donne à chaque locataire une surface d’API propre qui ne peut pas atteindre les données d’un autre
Quotas par locataire	Limites de capacité, de débit, de taux de requêtes et de concurrence appliquées par locataire	Empêche un locataire de consommer les ressources qu’un autre a payées
Facturation et mesure	Mesure par locataire, par niveau et par opération, alignée sur le contrat	Détermine si l’activité multi-locataire est rentable ou non
Frontières de sécurité	Contrôles d’identité, de chiffrement, d’audit, de résidence et d’accès opérationnel par locataire	Détermine si la plateforme résiste à un audit, à l’examen d’un régulateur ou à l’analyse d’une brèche

Chaque pilier renforce le suivant. Une isolation forte avec une mesure faible fait toujours perdre de la marge. Une mesure forte avec des frontières de sécurité faibles fait toujours perdre le client. Les cinq doivent être conçus ensemble, dans la même couche opérationnelle, sans quoi la plateforme finit par les greffer après coup et par être reconstruite dans les deux ans.

Isolation des locataires : la propriété fondatrice

L’isolation des locataires est la propriété qui rend possible l’infrastructure IA multi-locataire. Quatre frontières doivent tenir simultanément.

Isolation des données. Les données de chaque locataire résident dans leur propre espace de noms logique et ne peuvent être adressées, listées ou consultées depuis l’identité d’un autre locataire. Ce n’est pas la même chose que le chiffrement au repos — le chiffrement protège les données d’un disque volé, l’isolation les protège d’un autre locataire sur la même plateforme.

Isolation des performances. Le pic d’entraînement d’un locataire, l’écriture d’un gros checkpoint ou un afflux de requêtes d’inférence ne doivent pas affamer le débit ou le budget de latence d’un autre locataire. Les quotas, les limites de taux et les contrôles de qualité de service doivent opérer au niveau du stockage et du réseau, et pas seulement au niveau applicatif.

Isolation du cycle de vie et des politiques. Les locataires appliquent des calendriers de rétention, des régimes de conformité et des postures de protection différents. Un locataire peut exiger une rétention de sept ans avec immuabilité object lock pour des données d’entraînement réglementées ; le suivant une rétention de quatre-vingt-dix jours sans immuabilité. Les deux doivent coexister sur la même plateforme physique sans intervention de l’opérateur.

Isolation opérationnelle. La maintenance, le rééquilibrage de capacité et le remplacement de nœuds doivent être des non-événements du point de vue de chaque locataire. Une mise à niveau globale qui interrompt tous les locataires à la fois n’est pas un service managé — c’est une panne planifiée accompagnée d’une liste de locataires.

La référence isolation du stockage multi-locataire détaille la mécanique au niveau du stockage. Pour les charges IA en particulier, le test consiste à vérifier que le même modèle d’isolation tient pour des jeux de données d’entraînement à l’échelle de plusieurs pétaoctets, un cache d’inférence à latence inférieure à la milliseconde et une rétention longue durée sur supports froids — le tout sur la même plateforme. Si la réponse est non, l’opérateur finit par exploiter trois plateformes avec trois modèles de location, et l’économie unitaire en pâtit.

Séparation des espaces de noms et API exposée aux locataires

La séparation des espaces de noms est le mécanisme qui rend l’isolation réellement exploitable par les locataires. L’API objet S3 est devenue le standard de fait pour la frontière d’espace de noms de l’infrastructure IA multi-locataire, et pour de bonnes raisons.

Tous les outils IA des locataires — frameworks d’entraînement, serveurs d’inférence, bases de données vectorielles, pipelines MLOps, intégrations de sauvegarde — parlent déjà S3. L’adopter comme API exposée aux locataires leur évite d’apprendre une interface propriétaire et dispense l’opérateur de maintenir des SDK clients spécifiques. La hiérarchie comptes, buckets et objets se calque proprement sur les frontières multi-locataires : un compte par locataire, des identités IAM délimitées sous chaque compte, des journaux d’audit et des politiques de cycle de vie hérités du compte.

Trois propriétés de l’espace de noms doivent tenir pour les charges IA en particulier.

Nommage et identité délimités par locataire. Les noms de buckets, les utilisateurs IAM, les clés d’accès et les identifiants d’audit appartiennent au compte du locataire et ne peuvent entrer en collision entre locataires. Une collision de noms de buckets entre locataires est un bug de location, pas un problème d’ergonomie.

Politique par espace de noms. La rétention, la réplication, les clés de chiffrement, l’object lock et la journalisation des accès se configurent par espace de noms. L’opérateur n’applique pas une règle globale « tous les buckets reçoivent X » en la présentant comme une politique par locataire.

Énumération auditable. Un locataire peut énumérer tout ce qui se trouve dans son espace de noms et rien de ce qui se trouve en dehors. Cela paraît évident ; c’est pourtant la propriété qui cède la première lorsqu’un opérateur branche un stockage objet partagé en le présentant comme une plateforme « multi-locataire » sans faire le travail nécessaire.

Lorsque la frontière de l’espace de noms est aussi celle de l’API, l’opérateur peut placer quotas, limites de taux et points d’audit sur un unique point de contrôle au lieu de les répartir entre les équipes applicatives.

Quotas, performances et maîtrise des voisins bruyants

Les quotas par locataire sont le moyen par lequel la plateforme transforme une capacité physique partagée en capacité contractuelle par locataire. Sans quotas, chaque SLA de la plateforme devient du « best effort ».

Quatre classes de quotas comptent à l’échelle de l’IA.

Les quotas de capacité plafonnent le stockage qu’un locataire peut consommer à chaque niveau — flash GPU-direct, chaud, tiède, froid. Ils permettent aussi à l’opérateur de prévendre de la capacité en toute confiance : le calcul tient, car la plateforme n’autorisera pas un locataire à dépasser son allocation.

Les quotas de débit plafonnent la bande passante qu’un locataire peut consommer en lecture et en écriture, généralement sous la forme d’un débit soutenu et d’un budget de pic. Pour l’entraînement, c’est le contrôle de qualité de service le plus important, car une fois les GPU saturés, ce ne sont plus eux le goulot d’étranglement — c’est la couche de stockage.

Les quotas de taux de requêtes plafonnent le nombre d’opérations objet par seconde qu’un locataire peut émettre. Pour l’inférence et la génération augmentée par récupération (RAG), le taux de requêtes compte souvent davantage que la bande passante brute.

Les quotas de concurrence plafonnent le nombre de connexions simultanées ou d’opérations en cours qu’un locataire peut maintenir. Ils évitent qu’un épuisement du pool de connexions provoqué par un locataire ne fasse tomber le plan de contrôle pour tous.

Les quotas doivent être appliqués au niveau de la plateforme — couches stockage et réseau — et pas seulement au niveau applicatif. Un quota applicatif est une demande polie. Un quota de plateforme est un contrat.

Facturation, mesure et refacturation interne

C’est sur la facturation que le modèle économique de l’infrastructure IA multi-locataire se gagne ou se perd. La granularité de mesure requise est plus fine que ce que produisent nativement la plupart des stockages objet généralistes.

Les unités facturables qui comptent pour les charges IA multi-locataires :

• La capacité à chaque niveau de stockage — flash GPU-direct, chaud, tiède, froid — mesurée par locataire, par bucket et par fenêtre de temps
• Le débit consommé pendant les entraînements et l’inférence à forte concurrence, souvent mesuré par gigaoctet lu ou par requête objet
• L’état de protection — nombre de copies immuables, de réplicas géographiques, de copies d’archive — car chaque paramètre de protection a un coût marginal que l’opérateur doit récupérer
• Les événements opérationnels — restaurations d’archives, réplications inter-régions, transitions de cycle de vie — qui consomment de l’infrastructure au-delà de la base de fonctionnement courante

Sans mesure par locataire, par niveau et par opération, l’opérateur finit par lisser les coûts entre locataires et soit surfacture les plus efficients, soit subventionne les moins efficients. Dans les deux cas, les renouvellements en souffrent.

La refacturation interne compte aussi. Les entreprises qui exploitent une infrastructure IA multi-locataire pour de nombreuses unités métier doivent réimputer le coût de l’IA à chacune d’elles. Une plateforme qui produit des rapports par espace de noms, par niveau et par état de protection donne à l’équipe plateforme centrale un livrable de refacturation directement exploitable par l’unité métier — ce qui constitue en soi un avantage sur une allocation interne forfaitaire. L’article SLA (accord de niveau de service) explique comment aligner la mesure sur les engagements contractuels.

Les modèles commerciaux fondés sur les résultats — une tarification alignée sur la disponibilité, le débit, la posture de protection et les garanties de service plutôt que sur les caractéristiques matérielles brutes — deviennent la norme pour les offres de services IA. L’opérateur s’engage sur un résultat, la couche de mesure prouve que ce résultat a été livré, et la facture correspond au contrat. Si la couche de mesure ne peut pas apporter cette preuve, le contrat ne peut pas se défendre.

Des frontières de sécurité qui résistent à un audit

Dans une infrastructure IA multi-locataire, les frontières de sécurité couvrent bien plus que le chiffrement et le contrôle d’accès. Cinq sous-frontières doivent être définies par locataire et appliquées au niveau de la plateforme.

Frontière d’identité. Chaque locataire dispose de son propre compte, de son propre domaine IAM et de son propre cycle de vie des identifiants. Il n’existe aucune identité root partagée pouvant être endossée d’un locataire à l’autre. L’accès inter-locataires est impossible par construction, et non par politique.

Frontière cryptographique. Des clés de chiffrement par locataire, avec rotation et révocation sous le contrôle du locataire lorsque le contrat le permet. Une plateforme qui chiffre les données de tous les locataires avec une seule clé n’a pas de frontière cryptographique, seulement une illusion cryptographique.

Frontière d’audit. Des journaux d’audit par locataire, que le locataire peut lire et que l’opérateur ne peut pas modifier discrètement. Les pistes d’audit infalsifiables sont désormais une attente de base pour les charges réglementées, et non une option premium.

Frontière de résidence. Une politique de résidence par locataire — dans quelles régions, quels sites et quelles juridictions les données peuvent résider. La résidence est appliquée au niveau du placement, et pas seulement promise dans le contrat. La référence niveaux de stockage du data center couvre la conception du placement entre niveaux et sites.

Frontière d’accès opérationnel. L’accès du personnel aux données d’un locataire est auditable, restreignable et, si nécessaire, limité à certaines nationalités ou habilitations. Les locataires souverains le demandent explicitement ; les locataires réglementés le demandent implicitement via les cadres de conformité.

Le modèle de cyber-résilience CORE5 — immuabilité, durabilité par erasure coding, protection des métadonnées, réplication multisite et cycle de vie piloté par des politiques — est ce qui transforme chacune de ces frontières d’option de configuration en propriété de la plateforme. Pour les opérateurs multi-locataires, c’est cette distinction que les équipes d’audit examinent en premier.

Pourquoi tout cela mène à une infrastructure de données autonome

Chacun des piliers ci-dessus — isolation, séparation des espaces de noms, quotas, facturation, frontières de sécurité — révèle la même lacune architecturale. Le stockage traditionnel a été conçu pour un locataire par plateforme, un niveau par charge de travail et un cycle de renouvellement par architecture. Les charges IA multi-locataires brisent ces trois hypothèses à la fois.

Une plateforme IA multi-locataire a besoin d’une infrastructure qui supporte des exigences de charge variées — entraînement, inférence, récupération, archivage — sans obliger l’opérateur à exploiter des systèmes distincts pour chacune. Elle a besoin d’opérations pilotées par des politiques pour que l’équipe d’exploitation croisse moins vite que le nombre de locataires. Elle a besoin d’une cyber-résilience intégrée à l’architecture plutôt qu’ajoutée via un produit de sauvegarde. Elle doit pouvoir inspecter, prouver et rendre compte de son propre état par locataire, tant pour les SLA que pour les audits. Et elle doit offrir tout cela sur une plateforme que l’opérateur peut faire croître sur un niveau sans revoir la tarification de tous les autres.

C’est cette lacune que Scality ADI (Autonomous Data Infrastructure) a été conçue pour combler.

Comment Scality ADI s’applique à l’infrastructure IA multi-locataire

Scality ADI est une infrastructure de données pour l’IA d’entreprise, la cyber-résilience et le contrôle souverain, qui aligne de manière autonome et durable les bons supports de stockage, de l’échelle multi-pétaoctet à l’exaoctet. Pour les opérateurs d’une plateforme d’infrastructure IA multi-locataire, quatre propriétés comptent le plus.

S3 multi-locataire à grande échelle. Scality ADI expose un stockage objet compatible S3 comme API pour les locataires, avec des espaces de noms isolés, un IAM par locataire, des quotas, des frontières d’audit et des politiques de cycle de vie. Les locataires disposent de l’API que leurs outils comprennent déjà ; l’opérateur dispose d’un point de contrôle unique au niveau de la plateforme pour appliquer l’isolation, mesurer la consommation et produire des preuves d’audit.

Conception sur quatre niveaux de température sous un même modèle opérationnel. La flash GPU-direct avec S3 over RDMA, le stockage chaud en QLC et NL-SSD, le tiède sur HDD et le froid sur bande et archivage adjacent au cloud relèvent tous du même modèle opérationnel. L’opérateur peut proposer un stockage IA hiérarchisé à ses locataires — capacité GPU-direct premium pour l’entraînement, chaud pour le cache d’inférence, tiède pour les embeddings, froid pour la rétention — sans exploiter quatre systèmes distincts en coulisses. La référence stockage hiérarchisé pour l’IA (en anglais) présente ce modèle de conception.

Opérations autonomes avec exécution encadrée par des politiques. Des agents Guardian remontent analyses et recommandations dans le cadre des politiques définies par l’opérateur : extension de capacité, réparation, rééquilibrage, transitions de niveau, validation des mises à niveau. L’équipe d’exploitation décide de ce sur quoi agir, ou autorise des outils IA approuvés à agir dans le cadre des politiques via MCP (Model Context Protocol). Les effectifs n’ont pas à croître linéairement avec le nombre de locataires — c’est cette propriété qui détermine si l’économie multi-locataire fonctionne à cinquante comme à cinq cents locataires.

Cyber-résilience CORE5 dès la conception. Immuabilité, durabilité par erasure coding, protection des métadonnées, réplication multisite et cycle de vie piloté par des politiques sont des propriétés de la plateforme et non des fonctionnalités que l’opérateur doit assembler. Pour chaque locataire, l’opérateur peut présenter la posture de durabilité, l’état d’immuabilité et la capacité de reprise comme des preuves d’audit — et non comme des arguments marketing.

Scality ADI est livrée sous forme de logiciel open-code, disponible en appliance logicielle ou en modèle de service managé. Pour un opérateur multi-locataire, cela signifie que la plateforme peut être déployée dans ses propres installations, commercialisée sous sa propre marque et inspectée à la fois par l’opérateur et ses locataires lorsque les exigences de résidence ou d’audit l’imposent. Scality offre aux entreprises et aux organisations souveraines un moyen d’atteindre des performances à l’échelle de l’IA sans renoncer au contrôle, à la résilience ni à la discipline économique à long terme — et c’est cette même propriété qui permet à un opérateur multi-locataire d’intégrer ces résultats dans une offre commerciale défendable.

La conception MultiScale — capacité, débit et opérations évoluant indépendamment — est la propriété qui permet à l’économie unitaire multi-locataire de tenir sur tout un horizon de renouvellement. Un opérateur qui accueille un locataire développant des modèles de fondation peut étendre le niveau GPU-direct sans revoir la tarification de l’archive froide. Un opérateur de cloud souverain qui élargit sa base de locataires peut ajouter de la capacité sur un niveau tout en maintenant stable son empreinte opérationnelle.

Découvrez comment Scality ADI soutient l’infrastructure IA multi-locataire à grande échelle

Questions fréquentes

Qu’est-ce qu’une infrastructure IA multi-locataire ?

Une infrastructure IA multi-locataire est l’ensemble combiné des contrôles de calcul, de stockage, de réseau, d’identité et d’exploitation qui permet à une plateforme unique de servir de nombreux locataires exécutant des charges IA — entraînement, fine-tuning, inférence, récupération et rétention — sur des ressources physiques partagées, avec une isolation forte entre locataires et une responsabilité par locataire en matière de consommation, de performance et de posture de sécurité. Le socle minimal couvre l’isolation des locataires, la séparation des espaces de noms, les quotas par locataire, la facturation et la mesure, ainsi que les frontières de sécurité.

En quoi l’infrastructure IA multi-locataire diffère-t-elle de l’infrastructure IA mono-locataire ?

Une plateforme IA mono-locataire est construite pour un seul client : l’entreprise qui l’exploite. Une plateforme multi-locataire est construite pour de nombreux locataires sur une infrastructure partagée et doit les isoler en matière de données, de performances, de cycle de vie, d’exploitation, d’identité, de chiffrement, d’audit et de résidence. Les opérateurs multi-locataires ont aussi besoin d’une mesure par locataire pour la facturation, de rapports SLA par locataire et de frontières de sécurité par locataire — autant d’éléments qu’une plateforme mono-locataire n’a généralement pas à produire.

Qu’exige concrètement l’isolation des locataires ?

L’isolation des locataires exige quatre frontières qui tiennent simultanément : l’isolation des données, pour qu’un locataire ne puisse atteindre l’espace de noms d’un autre ; l’isolation des performances, pour que le pic d’un locataire n’affame pas le SLA d’un autre ; l’isolation du cycle de vie et des politiques, pour que les locataires puissent appliquer des régimes de rétention et de protection différents sur la même plateforme ; et l’isolation opérationnelle, pour que les opérations de maintenance soient des non-événements du point de vue de chaque locataire. Chaque frontière doit être appliquée au niveau de la plateforme plutôt qu’au niveau applicatif.

Comment les quotas sont-ils appliqués dans une infrastructure IA multi-locataire ?

Les quotas par locataire doivent être appliqués au niveau du stockage et du réseau, et pas seulement au niveau applicatif. Les quatre classes de quotas qui comptent pour les charges IA sont la capacité à chaque niveau (GPU-direct, chaud, tiède, froid), le débit (débit soutenu plus budget de pic), le taux de requêtes (opérations par seconde) et la concurrence (opérations simultanées en cours). Un quota applicatif est une demande polie ; un quota de plateforme est un contrat.

De quelles frontières de sécurité une plateforme IA multi-locataire a-t-elle besoin ?

Cinq frontières doivent tenir par locataire : une frontière d’identité, sans identité root partagée entre locataires ; une frontière cryptographique, avec des clés par locataire ; une frontière d’audit, avec des journaux infalsifiables par locataire ; une frontière de résidence, appliquée au niveau du placement ; et une frontière d’accès opérationnel, avec un accès du personnel auditable et restreignable. Chaque frontière doit être une propriété de la plateforme plutôt qu’une option de configuration que l’opérateur doit assembler.

Pour aller plus loin

• Isolation du stockage multi-locataire
• SLA : accord de niveau de service
• Niveaux de stockage du data center
• Stockage hiérarchisé pour l’IA : performances évolutives et maîtrise des coûts (en anglais)
• Stockage cloud souverain
• Souveraineté des données dans le cloud
• Solution de cyber-résilience CORE5 (en anglais)
• Pipelines de données IA : architecture, étapes et bonnes pratiques