IA souveraine : son propre cluster ou une API ?

La souveraineté a trois axes, pas un

« IA souveraine » recouvre des promesses très différentes ; commençons donc par les séparer. Trois questions décident du contrôle réel que vous avez sur un traitement d'IA :

• La garde — qui détient physiquement vos prompts, documents et réponses pendant leur traitement, et qui pourrait les remettre à un tiers.
• La juridiction — sous le droit de quel pays opèrent les sociétés qui détiennent ces données. C'est là que se joue le CLOUD Act : un fournisseur soumis à la juridiction américaine peut être contraint de livrer les données en sa possession, sous sa garde ou sous son contrôle, où que soient les serveurs. Lieu d'hébergement et exposition juridique sont deux questions différentes.
• La dépendance — de quels logiciels, matériels, mises à jour et support vous avez besoin pour continuer à fonctionner. Un système que vous contrôlez entièrement peut cesser de progresser le jour où un fournisseur cesse de livrer.

Posséder un cluster et appeler une API ne se notent pas de la même façon sur chaque axe. Aucune des deux voies ne gagne sur les trois, et c'est pourquoi la décision mérite mieux qu'un slogan.

Ce que spécifie l'architecture de référence

La description publique la plus nette de la voie « bâtir » est la Palantir Sovereign AI Operating System Reference Architecture, publiée par Palantir et NVIDIA en mars 2026. Elle décrit une pile complète, qualifiée en laboratoire, pour faire tourner la suite logicielle de Palantir sur du matériel NVIDIA dans le datacenter du client : des serveurs NVIDIA HGX B300 à huit GPU chacun, un réseau Ethernet NVIDIA Spectrum-X, et un ensemble de serveurs CPU qui font tourner la plateforme, le tout vendu et déployé comme une solution clés en main. Le document précise que l'architecture est conçue pour des déploiements sur site et isolés du réseau, en totale autonomie après l'installation initiale.

Elle existe en trois tailles qualifiées. Les serveurs GPU se commandent par « unités » de quatre ; les « nœuds plateforme » CPU sont fixes pour chaque taille.

Taille	Serveurs plateforme (CPU)	GPU	Destinée à (selon le document)
Small	3 de contrôle + 9 de travail	32 à 128 (1 à 4 unités)	Pilotes départementaux, charges spécialisées
Medium	3 de contrôle + 21 de travail	128 à 320 (4 à 10 unités)	Production à l'échelle de l'entreprise, multi-locataire
Large	3 de contrôle + 45 de travail	320 à 640 (10 à 20 unités)	Toute l'organisation, critique, multi-charges

Pour être clair sur notre position : Frontière AI n'a aucun lien avec Palantir ni NVIDIA. Nous citons leur document public parce que c'est la réponse la plus précise disponible à une question que nos clients nous posent : que faudrait-il pour le faire nous-mêmes ?

Ce que « petit » veut dire

Le point d'entrée baptisé « Small » est une installation sérieuse. À son minimum, une seule unité, il représente :

• 4 serveurs GPU, chacun avec huit GPU B300 dotés de 288 Go de mémoire à haut débit chacun — 2,3 To de mémoire GPU par serveur, 32 GPU au total ;
• 12 serveurs CPU — trois pour le plan de contrôle Kubernetes, neuf pour les services de données de la plateforme — spécifiés chacun avec deux processeurs de 32 cœurs, 1 To de RAM et dix disques NVMe de 7,68 To ;
• trois réseaux physiques : une fabrique de calcul entre GPU jusqu'à 800 Gb/s par GPU, un réseau convergé pour le stockage et le trafic utilisateur, et un réseau d'administration isolé pour les contrôleurs de carte mère des serveurs. Le document impose Ethernet et ne prend pas en charge InfiniBand.

C'est le ratio qui est instructif. Douze des seize serveurs ne font jamais tourner de modèle. Ils font tourner l'orchestration, le déploiement, la supervision, le stockage et le contrôle d'accès : la machinerie dont tout service d'IA a besoin autour des GPU. Un fournisseur géré construit cette machinerie une fois et en répartit le coût sur tous ses clients. Quand vous bâtissez, elle est à vous seul, dimensionnée avant votre première requête.

Le document la déploie en outre dans un ordre fixe : achat du matériel, amorçage du cluster, environnement d'exécution durci, services de la plateforme, activation avec vos données, et seulement ensuite déploiement des modèles. Chaque étape est un projet avec son responsable. La puissance électrique par baie est aussi une contrainte : le document autorise à répartir les serveurs GPU sur plusieurs baies quand le datacenter ne peut pas fournir la densité de puissance requise.

Ce que le document ne contient pas, c'est un prix. Le matériel de cette classe se chiffre au cas par cas, et nous n'allons pas inventer un montant. Si vous voulez la méthode pour comparer une machine louée ou achetée à une tarification au token, notre analyse du coût de l'auto-hébergement la déroule avec des chiffres datés.

Pourquoi le minimum n'est pas surdimensionné

Trente-deux GPU peuvent sembler excessifs pour un premier projet. La taille des modèles dit le contraire. L'architecture de référence note qu'au-delà d'environ 120 milliards de paramètres, un modèle peut devoir être réparti sur plusieurs GPU, et que l'hébergement de modèles de fondation demande plus de huit GPU répartis sur plusieurs serveurs.

Appliquons cela aux modèles qu'on veut réellement faire tourner. À un octet par paramètre (FP8), les poids seuls occupent environ un gigaoctet par milliard de paramètres :

• Mistral Large 4, le plus grand modèle de notre catalogue souverain UE avec 1 000 milliards paramètres, réclame environ 1 000 Go pour ses poids — au moins 4 B300 avant qu'il reste la moindre mémoire pour le contexte des utilisateurs simultanés.
• Kimi K3, avec 2 800 milliards paramètres, réclame environ 2,8 To — plus que les 2,3 To d'un serveur complet à huit GPU. Il ne tient pas sur une seule machine : c'est un déploiement multi-serveurs dès le premier jour.

Une quantification plus agressive réduit ces chiffres, au prix d'une perte de qualité qu'il faut mesurer sur vos propres tâches. Dans tous les cas, les modèles à poids ouverts de pointe sont dimensionnés pour des clusters, et la configuration minimale en tient compte plutôt qu'elle ne gonfle le besoin. (Pour ce que les poids ouverts vous donnent ou non, voir ce que signifie une IA à poids ouverts.)

Ce que bâtir vous apporte

Posséder le matériel est la forme de garde la plus forte qui existe. Sur un site isolé que vous exploitez, aucun fournisseur extérieur ne détient vos données, et aucun fournisseur extérieur ne peut être contraint de les produire. Cela compte pour le travail classifié, pour certains contextes de défense et de santé, et pour les organisations dont l'analyse de risque exclut tout tiers sur le chemin des données.

Cela apporte aussi des capacités qu'une API partagée n'offre pas :

• Des poids personnalisés — des modèles affinés, ou des modèles à poids ouverts qu'aucun fournisseur ne sert ;
• L'entraînement et l'affinage, pour lesquels l'architecture est explicitement dimensionnée ;
• Une capacité garantie — les GPU sont à vous, aucun trafic tiers ne passe devant le vôtre ;
• Pas de facture au token — une fois le matériel payé, l'usage marginal coûte de l'électricité et des personnes.

Ce que bâtir laisse ouvert

La garde n'est pas tout. Dans cette architecture précise, le logiciel de plateforme vient de Palantir, les GPU et le réseau de NVIDIA, les serveurs de référence de Dell — trois sociétés américaines — et le support passe par leurs contrats respectifs. Sur un site isolé, cette dépendance ne met vos données à la portée de personne, mais votre feuille de route, vos licences, vos mises à jour de sécurité et votre prochaine génération de matériel dépendent de fournisseurs que vous ne contrôlez pas. C'est l'axe de la dépendance, distinct de la question de juridiction. Traitez-les séparément dans une analyse de risque.

Viennent ensuite les coûts qu'aucune fiche technique ne liste : un espace en datacenter avec assez de puissance électrique et de refroidissement pour des baies GPU, les ingénieurs qui exploitent une plateforme Kubernetes et une fabrique GPU, les astreintes, et le travail de redéploiement chaque fois qu'un meilleur modèle à poids ouverts sort. Notre article sur les coûts explique pourquoi c'est le taux d'utilisation, pas le prix du matériel, qui décide en général si posséder est rentable.

La voie API, et ce qu'il faut vérifier

L'autre voie consiste à envoyer vos requêtes à des modèles exploités par des sociétés sous juridiction européenne. Vous renoncez à la garde — le fournisseur traite vos données — mais vous pouvez choisir qui est ce fournisseur. La souveraineté dépend alors entièrement de la chaîne ; vérifiez donc chaque maillon :

1. Qui exploite les serveurs qui font tourner le modèle, et qui contrôle cette société ? Une région UE d'un fournisseur américain reste un fournisseur américain.
2. Qui exploite la passerelle ou la plateforme intermédiaire, et stocke-t-elle les prompts ?
3. Que conserve chaque maillon, pendant combien de temps, et avec quelles exceptions ?
4. L'étiquette est-elle posée modèle par modèle ? Un catalogue qui mélange les fournisseurs doit dire quel modèle tourne où.

Voici notre chaîne, dite clairement. Les modèles étiquetés souverains UE — 15 des 24 modèles en ligne aujourd'hui — tournent chez OVHcloud et Scaleway, des sociétés françaises, dans des datacenters en France, ce qui place le fournisseur du modèle hors de portée directe du CLOUD Act. Aucun de ces deux services d'IA n'est qualifié SecNumCloud. Notre passerelle tourne dans la région de Paris de Vercel, une société américaine, en simple transit : Frontière AI ne stocke pas vos prompts, et notre politique de confidentialité indique la rétention de chaque fournisseur. Les 9 autres modèles en ligne tournent chez des sociétés américaines ; notre catalogue et l'API les étiquettent « accès rapide (US) », jamais souverains.

C'est moins de garde qu'un cluster dans votre sous-sol, et nous le disons. Ce que vous obtenez en échange, c'est la réponse sur la juridiction, une API standard compatible OpenAI et un catalogue sélectionné de modèles ouverts, dès le premier appel.

Côte à côte

	Cluster à soi (architecture de référence)	API souveraine UE (Frontière AI)
Engagement minimal	16 serveurs, 32 GPU, trois réseaux	Une recharge prépayée de 10 €, sans abonnement
Garde des données	La vôtre, isolation réseau possible	Le fournisseur du modèle les traite ; Frontière AI ne stocke pas les prompts
Juridiction de l'exploitant	Vous	Sociétés françaises pour les modèles souverains ; sociétés américaines pour les modèles « accès rapide »
Dépendance fournisseurs	Fournisseurs de logiciel, matériel et support (américains dans cette architecture)	Fournisseurs de modèles et notre passerelle (hébergée par une société américaine, en transit)
Modèles	Ce que vous déployez, poids personnalisés compris	Un catalogue sélectionné de modèles ouverts, pas de poids personnalisés
Affinage	Oui	Non
Délai avant la première requête	Achat, puis un déploiement en six étapes	Quelques minutes : créer une clé, changer l'URL de base
Forme du coût	Fixe, payé que la machine travaille ou non	Au token, rien quand vous n'appelez pas

Comment choisir

Bâtissez quand au moins une de ces conditions est vraie :

• il vous faut un réseau isolé, ou votre analyse de risque exclut tout tiers du chemin des données ;
• vous faites tourner des poids personnalisés ou affinés, ou vous entraînez des modèles ;
• vous avez un volume soutenu et saturant et une équipe qui exploite déjà de l'infrastructure à cette échelle ;
• le modèle dont vous avez besoin n'est servi par aucun fournisseur que vous pouvez accepter.

Sinon, commencez par une API dont vous avez vérifié la chaîne, et mesurez. Les volumes réels de tokens sont la donnée d'entrée de toute décision de construction, et la plupart des équipes n'en ont aucune avant de commencer. Vous pourrez changer plus tard : avec une API compatible OpenAI, la bascule tient en une URL de base et une clé, pas en une réécriture. Si vous préférez exploiter vous-même la couche de routage au-dessus de fournisseurs que vous choisissez, notre revue des passerelles open-source auto-hébergées couvre cette voie intermédiaire.

Nous nous appliquons la même règle. Pour les modèles de pointe tout juste sortis qu'aucun catalogue géré souverain ne sert encore, notre plan est de louer des serveurs UE dédiés — aucun ne sert de trafic à ce jour : le premier est prévu, pas en service. Kimi K3, dont la variante souveraine est prévue sur exactement cette voie, pas encore en service, en est le cas d'école : trop grand pour une seule machine, trop récent pour les catalogues gérés souverains. Nous engageons une machine quand la demande le justifie, pas avant. Si vous préparez aussi l'AI Act, notre page sur la préparation à l'AI Act sépare ce que l'infrastructure peut documenter de ce qui reste de votre responsabilité.

L'avenir du cloud est-il sur site ?

L'architecture de référence se termine sur une phrase : « The future of cloud is on-prem » — l'avenir du cloud est sur site. Pour les organisations capables d'en absorber le point d'entrée — même la taille qu'elle qualifie pour les petites entreprises démarre à 16 serveurs — c'est peut-être vrai : à cette échelle, posséder toute la pile est une réponse raisonnable aux trois axes de souveraineté à la fois.

Pour une entreprise de dix personnes, un groupe hospitalier régional ou le premier projet d'IA d'une administration, le premier pas vers une IA souveraine est un choix de fournisseur, pas un datacenter. Choisissez des fournisseurs sous juridiction européenne, vérifiez la chaîne maillon par maillon, gardez votre code portable, et décidez du matériel quand vous aurez les volumes pour le justifier.

FAQ