IA souveraine : bâtir son propre cluster, ou passer par une API ?

« Souverain » recouvre trois questions distinctes

Le mot sert à vendre des promesses très différentes. Avant de comparer les deux voies, séparez-le en trois questions : chacune a sa propre réponse, et aucune voie ne gagne sur les trois.

• La garde — qui détient physiquement vos prompts, vos fichiers et les réponses pendant le traitement, et pourrait les remettre à un tiers.
• La juridiction — quels tribunaux peuvent ordonner aux sociétés qui détiennent ces données de les produire. En vertu du CLOUD Act américain, un fournisseur doit communiquer les données en sa « possession, custody, or control », où qu'elles soient stockées (18 U.S.C. § 2713). L'emplacement d'un serveur et le contrôle de son opérateur sont deux faits différents.
• La dépendance — de quels logiciels, matériels, mises à jour et supports vous avez besoin pour que le système continue de tourner et de progresser.

La page souveraineté d'Evanesca applique ce découpage à son propre trajet.

Ce que décrit le plan de Palantir et NVIDIA

La réponse publique la plus détaillée à la question « que faudrait-il pour le faire nous-mêmes ? » 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 — le logiciel de Palantir sur des serveurs NVIDIA HGX B300 à huit GPU chacun, reliés en Ethernet NVIDIA Spectrum-X, plus des serveurs CPU qui font tourner la plateforme — conçue, selon le document, pour des déploiements sur site et coupés du réseau, avec une autonomie complète après l'installation initiale.

Les serveurs GPU vont par « unités » de quatre et se commandent par multiples de quatre. Les serveurs CPU de la plateforme sont en nombre fixe pour chacune des trois tailles qualifiées :

La plus petite configuration, serveur par serveur

À son minimum, une seule unité, la taille « Small » est déjà un projet de centre de données :

• 4 serveurs GPU, chacun avec huit GPU B300 portant 288 Go de mémoire HBM3e : 2,30 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 —, chacun avec au moins deux processeurs Intel Xeon 6530P de 32 cœurs, 1 To de mémoire vive et dix disques NVMe de 7,68 To (des Dell PowerEdge R670 dans la configuration de référence).
• Trois réseaux distincts : une matrice de calcul qui donne 800 Gb/s à chaque GPU, un réseau convergé pour le stockage et les utilisateurs, et un réseau d'administration physiquement isolé pour les contrôleurs des cartes mères. Le tout est en Ethernet : InfiniBand n'est pas pris en charge.

Le rapport est parlant : douze des seize serveurs ne font jamais tourner de modèle. Ils portent l'orchestration, le stockage, la supervision et le contrôle d'accès — la machinerie dont tout service d'IA a besoin autour de ses GPU. Un fournisseur mutualisé la bâtit une fois pour de nombreux clients ; si vous bâtissez, elle n'est qu'à vous, dimensionnée avant votre première requête.

L'installation suit ensuite six étapes dans un ordre fixe, de l'achat du matériel aux services de la plateforme et à l'activation avec vos données ; les modèles viennent en dernier. L'alimentation des baies est une contrainte à part entière.

Pourquoi 32 GPU sont un plancher, pas un luxe

Le plan prévient lui-même qu'au-delà d'environ 120 milliards de paramètres, un modèle peut demander plus d'un B300, et qu'héberger des modèles de fondation impose de dépasser huit GPU, sur plusieurs serveurs. En précision 8 bits (FP8), les poids seuls occupent environ un gigaoctet par milliard de paramètres, sans compter le contexte des utilisateurs simultanés.

• DeepSeek V4.1 Flash, le plus grand modèle à poids ouverts du catalogue d'Evanesca avec 763 milliards de paramètres, demande environ 763 Go pour ses poids : au moins 3 B300.
• Kimi K3, avec 2 800 milliards de paramètres, demande environ 2,8 To — plus que les 2,30 To d'un serveur complet à huit GPU : il ne tient sur aucune machine seule (Evanesca ne le sert pas : aucun opérateur européen ne l'exécute pour elle).

Une quantification en 4 bits divise ces chiffres par deux, au prix d'une perte de qualité à mesurer sur vos propres tâches. Dans tous les cas, les grands modèles à poids ouverts d'aujourd'hui sont taillés pour des clusters. Ce que sont les poids ouverts applique le même calcul à des modèles plus petits.

Ce que posséder apporte, et ce qui reste ouvert

Ce que vous gagnez

Sur un site coupé du réseau que vous exploitez, aucune société extérieure ne détient vos données : aucune ne peut donc être contrainte de les produire. C'est la garde la plus forte qui soit, et certains travaux de défense ou classifiés n'en tolèrent pas d'autre. Posséder permet aussi les poids sur mesure ou affinés, l'entraînement, une capacité qui n'est qu'à vous, et aucune facture au token une fois le matériel payé.

Ce qui reste ouvert

La dépendance, elle, demeure. Dans ce plan, le logiciel de plateforme vient de Palantir, les GPU et le réseau de NVIDIA, les configurations de serveurs de référence de Dell — trois sociétés américaines —, et le support passe par leurs contrats. Sur un site déconnecté, vos données restent hors d'atteinte ; mais vos licences, vos correctifs de sécurité et votre prochaine génération de matériel dépendent de fournisseurs que vous ne contrôlez pas.

Viennent ensuite les coûts qu'aucune fiche technique ne mentionne : l'alimentation et le refroidissement des baies GPU, des ingénieurs pour la plateforme et la matrice GPU, des astreintes, et un redéploiement à chaque nouveau modèle ouvert plus performant. C'est le taux d'utilisation qui décide de la rentabilité : un GPU inactif coûte autant qu'un GPU occupé.

La voie API : vérifier la chaîne, maillon par maillon

Avec une API, vous renoncez à la garde — l'opérateur traite vos données — mais vous choisissez qui est cet opérateur. La souveraineté dépend alors de chaque société de la chaîne ; posez-lui quatre questions :

1. Qui exploite les serveurs qui font tourner le modèle, et qui contrôle cette société ? La région européenne d'un cloud américain reste exploitée par une société américaine.
2. Qui exploite la couche intermédiaire — l'application, la passerelle —, et garde-t-elle les prompts ?
3. Que conserve chaque maillon, combien de temps, avec quelles exceptions ?
4. La réponse est-elle donnée modèle par modèle ? Un catalogue qui mélange les opérateurs doit dire quel modèle tourne où.

Les réponses d'Evanesca, sans détour. Ses modèles tournent chez Scaleway à Paris (avec OVHcloud à Gravelines en relais), chez Mistral AI dans sa région UE, chez AKI.IO en Allemagne et chez Infomaniak en Suisse. OVHcloud, Scaleway, Mistral AI et Infomaniak sont des sociétés européennes sans maison mère américaine, ce qui les place hors de portée directe du CLOUD Act ; OVHcloud et Scaleway ont des entités aux États-Unis, d'où l'importance du mot « directe ». AKI.IO est une société allemande dont les actionnaires ne sont pas publiés. Evanesca ne garde aucune trace de vos prompts ni des réponses : ils restent en mémoire le temps d'écrire la réponse, et votre historique vit dans votre navigateur. Ce que gardent les opérateurs relève d'eux : Scaleway peut conserver et lire les requêtes qui provoquent des erreurs ou paraissent abusives, jusqu'à 14 jours, et Mistral AI garde les entrées et sorties de ses modèles 30 jours pour surveiller les abus. Les serveurs d'Evanesca tournent chez Vercel, société américaine, dans sa région de Paris, et ne gardent aucune trace des prompts.

Evanesca ne sert aucun modèle hors d'Europe, et un modèle n'est jamais redirigé ailleurs : si son opérateur tombe, la requête échoue. C'est moins de garde qu'un cluster à vous — et le passeport sous chaque réponse montre le trajet qu'elle a suivi.

Les deux voies côte à côte

Sur Evanesca, chaque modèle a son prix par million de tokens, TVA comprise : voir les tarifs et les modèles. Comptes et clés ouvrent avec le service ; d'ici là, ce site montre comment il fonctionnera.

Comment choisir

Bâtissez si au moins une de ces conditions est remplie :

• il vous faut un isolement réseau, ou votre analyse de risques exclut tout tiers sur le trajet des données ;
• vous utilisez des poids sur mesure ou affinés, ou vous entraînez des modèles ;
• vous avez un volume soutenu, qui sature les machines, et une équipe qui exploite déjà une infrastructure de cette taille ;
• le modèle dont vous avez besoin n'est servi par aucun opérateur acceptable pour vous.

Sinon, commencez par une API dont vous avez vérifié la chaîne, et mesurez. Toute décision d'achat a besoin des volumes réels de tokens, que peu d'équipes connaissent au départ. Changer plus tard coûte peu quand l'API suit le format d'OpenAI : une nouvelle URL de base et une nouvelle clé, pas une réécriture. Pour exploiter vous-même la couche de routage au-dessus d'opérateurs de votre choix, voyez les passerelles d'IA auto-hébergées ; pour le volet réglementaire, ce que demande l'AI Act.

Le plan se termine sur une phrase : « The future of cloud is on-prem » — l'avenir du cloud est sur site. Pour une organisation capable d'absorber seize serveurs, c'est peut-être vrai. Pour une entreprise de dix personnes ou le premier projet d'IA d'une collectivité, le premier pas vers une IA souveraine est le choix d'un fournisseur, pas d'un centre de données.

Questions fréquentes

À lire aussi

• Fournisseurs d'inférence européens : qui exécute vraiment les modèles d'IA en EuropeQui exécute les modèles d'IA en Europe : OVHcloud, Scaleway, Mistral AI, IONOS, STACKIT, AKI.IO, Infomaniak, Nebius… Société, centres de données, prompts.
• OpenAI est-il conforme au RGPD ? Ce que ChatGPT et l'API font de vos donnéesOpenAI propose des contrats européens et des clauses de transfert, mais reste une société américaine à portée du CLOUD Act. Ce que cela change pour vous.
• RGPD et CLOUD Act : pourquoi héberger votre IA dans l'UE ne suffit pasLe RGPD encadre les transferts ; le CLOUD Act suit la société. Pourquoi un datacenter européen d'un groupe américain reste exposé, et que vérifier.