3 La plupart des entreprises ne construisent pas une infrastructure d’IA sur site pour faire passer un message. Elles le font parce que leur corpus d’entraînement est trop sensible pour être envoyé chez un hébergeur étranger, parce que l’egress d’un seul cycle de réentraînement coûte plus cher qu’une année de capacité en propre, ou parce que le régulateur exige que le plan de données soit exploité sous une seule juridiction. La question n’est plus de savoir s’il faut garder les charges de travail d’IA en interne, mais comment concevoir les couches de stockage, de réseau et d’exploitation pour qu’un programme d’IA de plusieurs pétaoctets fonctionne au rythme des GPU sans compromettre la résidence, la restauration ni la maîtrise des coûts. Ce guide s’adresse aux responsables d’infrastructure, aux responsables de l’infrastructure d’IA et aux architectes stockage qui conçoivent ou étendent un programme d’IA sur site. Il présente les couches dont une conception opérationnelle a besoin, les avantages qui font passer la dépense du statut d’option à celui d’évidence, et les contraintes qui déterminent où se situe la frontière entre le sur-site et le reste. Qu’est-ce qu’une infrastructure d’IA sur site ? Une infrastructure d’IA sur site est l’ensemble des couches de calcul, de stockage, de réseau, d’identité et d’exploitation qui font fonctionner le cycle de vie de l’IA — ingestion, préparation, entraînement, affinage, inférence, récupération, checkpoints et conservation à long terme — dans des installations exploitées par l’entreprise. Sa propriété déterminante est que le placement, l’accès, la conservation et l’inspection des données réglementées sont appliqués par une infrastructure que l’entreprise contrôle, et non par un contrat avec un fournisseur de cloud public. Cette catégorie est plus étroite que l’« IA privée » — qui peut inclure des variantes en cloud souverain ou isolées (air gap) — mais plus large qu’un simple cluster GPU. Une conception d’IA sur site opérationnelle doit prendre en charge l’ensemble du cycle de vie, et pas seulement l’entraînement phare. Trois propriétés distinguent une véritable conception d’une ferme GPU renommée : L’éventail des charges de travail. Elle doit servir, depuis une même couche opérationnelle, l’entraînement GPU-direct, l’inférence à forte concurrence, les pipelines RAG et d’embeddings, les checkpoints de modèles et des décennies de conservation. Le contrôle au niveau du plan de données. La résidence, l’accès lié à l’identité, l’isolation multi-locataire et l’immuabilité sont des propriétés de la plateforme de stockage, et non des affirmations dans des présentations de politique. Une évolutivité indépendante. Le calcul et le stockage doivent évoluer chacun à leur rythme. Les charges de travail d’IA croissent dans les deux dimensions, rarement à la même vitesse. Si l’une de ces propriétés manque, la conception se heurtera à un mur dès que le mix de charges de travail changera — ce qui arrive toujours. Les couches de conception Une conception d’IA sur site opérationnelle comporte cinq couches. Elles ne sont pas indépendantes — chacune contraint celles qui se trouvent au-dessus et en dessous — mais il est plus simple de les examiner séparément. 1. La couche de calcul La couche de calcul est l’enveloppe GPU et CPU. Pour l’entraînement, il s’agit d’un cluster GPU dense — accélérateurs de classe H ou B interconnectés par une infrastructure réseau à haut débit. Pour l’inférence, il s’agit d’un mélange de nœuds GPU et CPU dimensionnés pour la concurrence et la latence plutôt que pour le débit de pointe. Cette séparation compte, car l’entraînement et l’inférence partagent rarement le même profil matériel, et vouloir les regrouper sur un même cluster gaspille de la capacité des deux côtés. La couche de calcul définit aussi l’enveloppe énergétique. Les nœuds d’entraînement modernes consomment tellement d’énergie que la planification des installations — baies, refroidissement, capacité des PDU — fait partie de la conception dès la première esquisse, et non d’une note de bas de page à la fin. 2. La couche de stockage La couche de stockage est celle où se concentre l’essentiel des difficultés opérationnelles. Les charges de travail d’IA n’ont pas un schéma d’accès unique. L’entraînement lit de gros objets de manière séquentielle à un débit extrême. L’inférence lit de petits objets de manière aléatoire avec une forte concurrence. Les embeddings, la récupération et le cache KV se comportent encore différemment. Les checkpoints écrivent par rafales. La conservation à long terme reste froide pendant des années. Une conception de stockage opérationnelle utilise des supports hiérarchisés sous un modèle opérationnel unique : La flash GPU-direct pour les jeux de données d’entraînement actifs, les checkpoints de modèles pendant une exécution et le cache KV d’inférence. Une latence inférieure à la milliseconde à grande échelle. La capacité chaude (QLC, NL-SSD) pour les jeux de données de travail, les journaux d’inférence récents et les index d’embeddings — un débit élevé, pour un coût par téraoctet inférieur à celui de la flash haut de gamme. La capacité tiède (NL-HDD, HDD) pour le data lake au sens large, les corpus d’entraînement historiques et la conservation récente. L’archivage froid (bande, archivage proche du cloud) pour la conservation réglementaire, les modèles retirés et les copies de reprise après sinistre. Le principe de conception est que les quatre niveaux se trouvent sous un seul espace de noms et un seul moteur de politiques. Sinon, l’équipe finit par exploiter quatre systèmes de stockage et par écrire des scripts de migration entre eux — exactement la charge opérationnelle que la plateforme est censée supprimer. 3. La couche réseau Dans une conception d’IA sur site, la couche réseau comprend deux réseaux, et non un seul. L’infrastructure est-ouest — généralement InfiniBand ou Ethernet haut débit — transporte le trafic GPU à GPU et GPU vers stockage à la bande passante qu’exige l’entraînement moderne. Le réseau nord-sud gère l’ingestion, la réplication vers les sites de conservation, le trafic d’identité et la télémétrie opérationnelle. Les regrouper sur une seule infrastructure économise du câblage et fait perdre du débit. Pour les charges de travail GPU-direct, c’est le chemin entre le stockage et le GPU qui constitue la contrainte. S3 sur RDMA, GPUDirect Storage et d’autres chemins sans copie existent pour retirer le passage par le CPU et la DRAM de l’hôte du chemin des données. Consultez GPU Direct Storage pour la manière dont cette couche est généralement construite. 4. La couche d’identité, d’accès et d’audit Dans les environnements réglementés, les charges de travail d’IA exigent un accès lié à l’identité au niveau du plan de données : chaque lecture, chaque écriture et chaque événement du cycle de vie doivent être liés à une identité authentifiée et consignés dans une chaîne d’audit infalsifiable. C’est là qu’apparaît la différence entre un cluster sur site générique et une conception de niveau réglementaire. La chaîne d’audit doit résister aux contraintes opérationnelles — entraînements qui saturent l’infrastructure réseau, pics d’inférence qui décuplent la concurrence, réplication multisite qui rattrape son retard après un incident réseau. Des lacunes d’audit sous charge font échouer les revues d’accréditation. 5. La couche opérationnelle La couche opérationnelle est celle que l’équipe utilise réellement au quotidien : provisionnement, supervision, gestion du cycle de vie, planification de capacité, autoréparation, mises à niveau, extensions. L’objectif de conception est que l’équipe qui exploite l’environnement n’augmente pas proportionnellement à l’empreinte. Cela exige une automatisation pilotée par des politiques, des analyses tenant compte des charges de travail et un environnement d’exécution qui gère les cycles de renouvellement sans remplacement complet perturbateur. Les principaux avantages L’argumentaire économique et opérationnel en faveur du maintien des charges de travail d’IA en interne repose sur quatre avantages. Chacun est suffisamment concret pour être modélisé — ce qui les distingue du discours générique selon lequel « le cloud coûte cher ». Souveraineté et contrôle démontrable La souveraineté est l’avantage qui rend l’exploitation en interne incontournable pour une liste croissante de charges de travail. Lorsque le jeu de données est classifié, réglementé ou soumis à des règles contractuelles de résidence, la seule façon de prouver le contrôle est d’exploiter le plan de données à l’intérieur des frontières juridiques et opérationnelles de l’entreprise. Les garanties de résidence du cloud public ne résistent pas au test des injonctions de divulgation pour les organisations soumises à des régimes extraterritoriaux. L’avantage ne se limite pas au fait que « les données restent dans le pays ». Il tient à ce que le placement, l’accès, la conservation et l’inspection sont appliqués par du code plutôt qu’affirmés dans des contrats. Consultez la souveraineté des données dans le cloud et le stockage cloud souverain pour une vision juridique et architecturale plus approfondie. Des coûts prévisibles à grande échelle et dans la durée La tarification horaire du cloud public est attractive pour des expérimentations courtes, mais ne tient pas pour des charges de travail d’IA durables. Trois postes de coûts se cumulent : le stockage haut de gamme, l’egress et les engagements sur instances réservées, qui paraissent moins chers que l’usage à la demande mais verrouillent une capacité que la charge de travail n’utilisera pas forcément. Dès que les données d’entraînement actives dépassent deux à trois pétaoctets — ou que la charge de travail fonctionne assez en continu pour que la capacité réservée l’emporte sur la tarification horaire — l’économie unitaire s’inverse. La réflexion sur la stratégie de rapatriement depuis le cloud détaille ce point de bascule. Une infrastructure en propre remplace un modèle de coûts variables par un plan d’investissement prévisible. L’avantage n’est pas toujours un coût total inférieur dès la première année. C’est une courbe de coûts qui ne s’infléchit pas dans le mauvais sens à mesure que le programme se développe. L’avantage de la gravité des données À l’échelle du pétaoctet, les données ne se déplacent pas facilement. Si le corpus d’entraînement se trouve déjà dans l’entreprise — télémétrie des systèmes industriels, données de sinistres, archives d’imagerie, historique transactionnel —, le déploiement d’IA le plus rentable s’exécute là où se trouvent les données, et non là où il est le plus facile de louer des GPU. Envoyer en continu des jeux de données de plusieurs pétaoctets vers un cloud public et les rapatrier est la conception qui transforme un programme d’IA sain en facture d’egress récurrente. L’article sur le problème de la gravité des données en détaille la dynamique. L’avantage est positionnel. Placer le calcul à côté des données que le programme produit déjà élimine une catégorie de coûts et une catégorie de risques qu’aucune architecture cloud ne peut totalement neutraliser. Un contrôle opérationnel sans dépendance au fournisseur Le quatrième avantage est plus difficile à modéliser, mais il se manifeste chaque fois que le programme doit évoluer. Une plateforme fondée sur des standards ouverts — stockage objet compatible S3, matériel de calcul ouvert, protocoles d’identité standard — permet à l’entreprise de renouveler son matériel, de changer d’outils d’exploitation et d’adopter de nouvelles générations d’accélérateurs sans refondre la couche de données. Les services d’IA du cloud public lient le plan de données aux API, aux formats et aux conditions contractuelles d’un fournisseur. Les coûts de changement augmentent avec chaque téraoctet de données d’entraînement accumulé. L’avantage, c’est la liberté de mouvement tout au long d’un cycle matériel qui s’annonce long et rapide. Les contraintes qui façonnent la conception Cinq contraintes déterminent à quoi ressemble concrètement la conception. Le mix de charges de travail. Un programme composé à 90 % d’entraînement et à 10 % d’inférence ne se conçoit pas comme un programme composé à 30 % d’entraînement, 50 % d’inférence et 20 % de RAG. La répartition des niveaux de stockage et l’infrastructure réseau suivent la forme des charges de travail. La résidence des données. L’endroit où les données doivent légalement résider, les personnes qui peuvent y accéder et la juridiction dont les lois s’appliquent sont des données d’entrée de premier plan pour la conception. Les entreprises présentes dans plusieurs régions exploitent souvent un déploiement multisite avec une autonomie régionale sous une vue opérationnelle unifiée. L’enveloppe énergétique. La densité des GPU modernes est un problème de conception des installations avant d’être un problème d’achat. La puissance totale, la capacité de refroidissement et la disposition des PDU déterminent la capacité d’accélération que l’on peut déployer dans une salle donnée. Le réalisme des cycles de renouvellement. Les générations de GPU se renouvellent tous les 12 à 24 mois. Les générations de stockage évoluent plus lentement. La conception doit permettre à l’équipe de renouveler le calcul sans renouveler le stockage, et inversement. Les architectures désagrégées — voir le stockage objet distribué — sont la manière habituelle d’y parvenir. Les effectifs d’exploitation. La plupart des entreprises qui construisent ce type de plateforme ne peuvent pas augmenter leurs effectifs proportionnellement à l’empreinte. L’automatisation, le cycle de vie piloté par des politiques et un environnement d’exécution qui fournit des analyses opérationnelles plutôt que de la télémétrie brute font la différence entre une équipe qui suit la croissance et une équipe qui se noie. Pourquoi cela mène à une infrastructure de données autonome Un déploiement d’IA sur site sollicite chaque couche au rythme des machines, dans des conditions de charge qui évoluent sans prévenir. Trois propriétés doivent être réunies simultanément : Des performances à grande échelle — assez rapides pour ne pas brider les GPU pendant l’entraînement et l’inférence à forte concurrence, avec chaque objet placé sur le support adapté à son schéma d’accès. Un contrôle au niveau du plan de données — placement, accès, conservation et périmètres des opérateurs appliqués par la plateforme, et non affirmés dans une procédure. Une économie opérationnelle — l’équipe qui exploite la plateforme n’augmente pas proportionnellement au nombre de pétaoctets ou à la variété des charges de travail. Les architectures de stockage traditionnelles gèrent une ou deux de ces propriétés et cèdent sur la troisième. Une infrastructure de données plus autonome — dans laquelle la couche de stockage applique le placement, fournit des analyses opérationnelles dans le cadre des politiques et aligne le bon support sur chaque charge de travail sans intervention manuelle — est ce qui rend les trois réalisables ensemble. Scality ADI (Autonomous Data Infrastructure) repose sur ce principe, avec le contrôle souverain comme pilier central pour les charges de travail d’IA sur site. Comment s’applique Scality ADI 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 plusieurs pétaoctets à l’échelle de l’exaoctet. La plateforme se déploie sur site, dans une région souveraine, dans un cloud privé ou dans une enclave isolée (air gap) — et présente un espace de noms unique sur l’ensemble. Pour les couches de conception décrites ci-dessus : La couche de stockage. Scality ADI couvre quatre niveaux — flash GPU-Direct avec S3 sur RDMA, QLC et NL-SSD chauds, HDD tièdes, et archivage froid sur bande ou proche du cloud — sous un modèle opérationnel unique. L’entraînement, l’affinage, le cache d’inférence, les embeddings, les checkpoints et la conservation à long terme disposent chacun du niveau dont ils ont besoin, sans obliger l’équipe à exploiter quatre systèmes de stockage distincts. L’alignement avec le calcul et le réseau. Scality ADI repose sur l’architecture désagrégée RING10, qui fait évoluer indépendamment la capacité, le débit et les opérations. Les charges de travail GPU-direct utilisent S3 sur RDMA avec une latence inférieure à 50 microsecondes au niveau GPU-Direct, et un débit de plusieurs To/s au niveau chaud. L’identité, l’accès et l’audit. La cyber-résilience CORE5 — immuabilité, durabilité par codage à effacement, protection des métadonnées, protection multisite et application des politiques — permet aux exigences de conservation et d’audit de résister à l’examen. Le fonctionnement isolé (air gap) est pris en charge pour les enclaves les plus sensibles. La couche opérationnelle. Les agents Guardian fournissent des analyses et des recommandations opérationnelles alignées sur les charges de travail, dans le cadre des politiques définies par le client. L’équipe approuve ce qui doit être mis en œuvre ; la plateforme exécute dans des limites définies. Le bénéfice se traduit par moins de tâches répétitives et moins d’opérations de maintenance perturbatrices, et non par une boîte noire qui fonctionnerait sans supervision. Scality ADI est fourni sous forme de logiciel open code, disponible en appliance logicielle ou en service managé. L’open code est important pour les environnements réglementés : les équipes de sécurité des administrations, les organismes d’accréditation et les red teams peuvent inspecter le fonctionnement de la plateforme au lieu de s’en remettre aux attestations du fournisseur. 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. Pour les responsables d’infrastructure qui conçoivent un programme devant survivre au prochain cycle de renouvellement, une couche de données unifiée est la partie qui n’a pas à être refondue tous les deux ans. Découvrez comment Scality ADI fournit une infrastructure d’IA sur site à grande échelle (en anglais) Questions fréquentes Qu’est-ce qu’une infrastructure d’IA sur site ? Une infrastructure d’IA sur site est l’ensemble des couches de calcul, de stockage, de réseau, d’identité et d’exploitation qui font fonctionner le cycle de vie de l’IA dans des installations exploitées par l’entreprise. Elle applique au niveau du plan de données le placement, l’accès, la conservation et l’inspection des données réglementées, prend en charge les charges de travail d’entraînement et d’inférence au rythme des GPU, et fait évoluer indépendamment la capacité et le calcul à mesure que le programme se développe. Quels sont les principaux avantages ? Quatre avantages fondent l’argumentaire : une souveraineté et un contrôle démontrables sur le plan de données ; des coûts prévisibles à grande échelle et dans la durée, dès que la charge de travail fonctionne en continu ou que le jeu de données atteint plusieurs pétaoctets ; l’avantage de la gravité des données lorsque les corpus d’entraînement se trouvent déjà dans l’entreprise ; et une liberté opérationnelle tout au long des cycles de renouvellement matériel, sans dépendance envers un fournisseur. Quand le sur-site est-il plus pertinent que le cloud public pour l’IA ? Le sur-site l’emporte généralement lorsque les données d’entraînement actives dépassent deux à trois pétaoctets, lorsque les frais d’egress deviennent un poste significatif, lorsque des exigences de classification ou de résidence excluent un hébergement mutualisé, ou lorsque la charge de travail fonctionne assez en continu pour que la capacité réservée l’emporte sur la tarification horaire. Les variantes isolées (air gap) s’appliquent aux enclaves classifiées ou réglementées les plus sensibles. En quoi est-ce différent d’un cloud privé ? Le cloud privé désigne un modèle de consommation — multi-locataire, en libre-service, piloté par API — qui peut fonctionner sur site ou dans une région souveraine. Le terme utilisé ici désigne l’endroit où la charge de travail s’exécute physiquement. Les deux se recoupent : de nombreux déploiements sur site sont exploités comme des clouds privés, mais les conceptions sur site sont aussi valables dans des configurations mono-locataires, classifiées ou isolées qui ne ressemblent en rien à un cloud privé. Quelle est la place de Scality ADI ? Scality ADI fournit la couche du plan de données : un espace de noms unique couvrant la flash GPU-direct, la capacité chaude, la capacité tiède et l’archivage froid, avec un placement fondé sur des politiques, S3 sur RDMA pour les charges de travail GPU, la cyber-résilience CORE5 pour la conservation et la restauration, et les analyses opérationnelles Guardian dans le cadre des politiques définies par le client. Il se déploie sur site ou en mode isolé, évolue de quelques nœuds à l’échelle de l’exaoctet grâce à l’architecture RING10, et est fourni sous forme de logiciel open code pour être inspectable dans les environnements réglementés. Pour aller plus loin Les modèles de déploiement de l’IA privée en entreprise : guide pratique L’architecture de déploiement de l’IA : modèles et schémas (en anglais) Les meilleures solutions de stockage objet sur site Sur site ou hors site La stratégie de rapatriement depuis le cloud Le problème de la gravité des données GPU Direct Storage Le stockage cloud souverain La souveraineté des données dans le cloud La stratégie de données en cloud hybride pour les charges de travail d’IA Le stockage objet distribué
