Héberger l'IA : cloud public vs cloud souverain, quel choix en 2026 ?

Le débat cloud public contre cloud souverain existe depuis une dizaine d'années, mais l'IA le transforme en profondeur : les charges GPU concentrent des volumes de données sans précédent, les modèles incorporant ces données deviennent eux-mêmes des actifs sensibles, et la réglementation française a durci ses exigences avec SecNumCloud 3.2. Notre comparatif des alternatives souveraines à AWS et Azure couvre le paysage généraliste des offres françaises ; cet article traite exclusivement de l'angle IA. À l'opposé, le guide d'installation des LLM en local traite le scénario on-premise, troisième voie hors cloud.

Ce qui distingue un workload IA d'une application classique

Héberger une application métier classique pose des questions connues : calcul CPU, stockage, bande passante, disponibilité. L'IA ajoute trois contraintes structurelles qui redessinent l'arbitrage. La première est matérielle : l'entraînement et l'inférence de modèles reposent sur des accélérateurs GPU (ou NPU) dont le coût d'acquisition dépasse dix fois celui d'un serveur CPU équivalent, dont la disponibilité reste tendue et dont la consommation électrique — jusqu'à 700 watts par carte haut de gamme — pèse sur la facture d'exploitation. La deuxième est liée aux données : un projet d'IA mobilise des jeux d'entraînement massifs, souvent composés de données personnelles ou sectorielles sensibles, et le modèle résultant incorpore statistiquement ces données — on ne peut plus séparer « l'application » de « la donnée » comme dans l'architecture classique. La troisième est économique : les workloads d'entraînement sont par nature ponctuels et intensifs, tandis que l'inférence est continue et difficile à prévoir, ce qui rend le dimensionnement des ressources beaucoup plus délicat.

Ces trois contraintes expliquent pourquoi la réponse « tout public » ou « tout souverain » échoue dans la majorité des projets réels : chaque phase du cycle de vie d'un modèle — expérimentation, entraînement, fine-tuning, inférence, surveillance — a des besoins différents.

Le cloud public : capacité quasi illimitée, mais une facture qui dérive

Les hyperscalers — AWS, Microsoft Azure, Google Cloud — dominent l'hébergement IA pour trois raisons objectives. La capacité d'abord : un abonnement Azure ou un compte AWS donne accès à des grappes de milliers de GPU synchronisés, ce qui reste hors de portée de tout autre acteur européen ; pour l'entraînement de modèles de fondation ou le fine-tuning massif, cette échelle est un argument décisif. L'écosystème ensuite : les frameworks managés (SageMaker, Vertex AI, Azure AI Foundry) encapsulent le provisionnement des GPU, l'orchestration des entraînements et le déploiement d'inférence, réduisant le besoin en compétences infrastructure. Enfin la tarification à l'usage, idéale pour l'expérimentation : lancer un entraînement ponctuel sur des H100 puis tout éteindre ne coûte que les heures consommées.

Les limites sont connues mais sous-estimées. La facture d'inférence en production grimpe mécaniquement avec le trafic, et les coûts d'egress — facturés chaque fois que les données quittent le cloud — deviennent significatifs dès qu'un modèle sert des utilisateurs distribués. Le verrouillage propriétaire s'installe progressivement : les services managés lient le modèle à l'écosystème du fournisseur, et la migration vers un autre hébergeur exige de repenser l'intégralité de la chaîne. Surtout, le droit américain (Cloud Act) s'applique aux filiales américaines opérant en Europe, ce qui expose les données hébergées aux demandes d'accès des autorités américaines — un risque incompatible avec les données classifiées ou sectorielles réglementées.

Le cloud souverain : SecNumCloud 3.2 et les offres françaises

Le cloud souverain français a mûri. Trois acteurs structurent l'offre en 2026 : OVHcloud, avec sa gamme AI Training et des instances GPU dédiées hébergées en France ; Scaleway, positionné sur le GPU à la demande et le stockage objet performant pour les jeux de données d'entraînement ; et Bleu, l'offre née de l'alliance Capgemini-Orange, construite sur la technologie Microsoft mais opérée par des capitaux et des équipes français hors de portée du droit américain. Tous trois détiennent la qualification SecNumCloud 3.2, devenue la référence exigée par les cahiers des charges publics et un critère de plus en plus présent dans les appels d'offres privés manipulant des données sensibles.

SecNumCloud 3.2 apporte trois garanties concrètes : les données sont hébergées sur le territoire national, l'opérateur est français soumis au droit français, et le contrat protège contre les demandes d'accès extraterritoriales. Pour l'IA, cela signifie que les jeux de données d'entraînement classifiés — imagerie médicale, données de défense, fichiers clients sensibles — peuvent légalement y résider, et que les modèles qui en héritent y restent servis. Le revers est réel : la capacité GPU totale demeure inférieure à celle des hyperscalers, les files d'attente apparaissent sur les configurations haut de gamme aux heures de pointe, et l'écosystème de services managés est moins riche — les équipes doivent davantage assembler elles-mêmes leur chaîne MLOps. Sur les enjeux de localisation et de maîtrise juridique des données, le guide sur le cloud souverain français et les données personnelles complète ce panorama avec un angle orienté conformité.

Le vrai arbitrage : données, coûts à douze mois, compétences

La question ne se pose jamais « en général » : elle se pose workload par workload, avec trois filtres à appliquer dans l'ordre.

Le premier filtre est réglementaire et ne se discute pas : si les données d'entraînement sont classifiées ou si le cahier des charges impose SecNumCloud, la question du cloud public est tranchée. Le deuxième filtre est économique et se calcule sur douze mois de consommation réelle, jamais sur les tarifs catalogue. Le troisième est organisationnel : un cloud souverain exige davantage de maîtrise technique, tandis que le public pardonne une équipe réduite au prix d'une dépendance croissante.

Les architectures hybrides, compromis dominant en 2026

La pratique qui s'impose dans les déploiements mûrs est hybride, avec une répartition nette des rôles. L'entraînement lourd — celui qui exige des milliers de GPU et manipule des données anonymisées ou synthétiques — se fait en cloud public, où la capacité et les frameworks managés dominent. Le fine-tuning sur les données réelles et sensibles se déplace ensuite vers le cloud souverain, dans le périmètre SecNumCloud. L'inférence en production, enfin, rejoint le souverain dès que le trafic se stabilise : les instances réservées y ramènent les coûts GPU de 30 à 50 %, la sortie des données est libre, et la latence vers les utilisateurs français est excellente.

Cette répartition suppose une discipline d'ingénierie : les jeux de données doivent être partitionnés dès la conception entre ce qui peut quitter le territoire et ce qui ne le peut pas, et les pipelines doivent supporter la mobilité des modèles — formats ouverts, conteneurs, infrastructure as code — pour éviter que l'hybridité ne devienne une complexité ingérable. Les entreprises qui réussissent cette bascule partagent un trait : elles ont standardisé leur chaîne MLOps sur des briques portables avant de diversifier leurs hébergeurs.

Calculer le TCO d'un projet d'IA hébergé

Le coût total de possession d'un projet d'IA se décompose en cinq postes, dont trois sont systématiquement sous-estimés dans les business cases. Le poste GPU — le plus visible — représente en réalité 40 à 60 % du total à douze mois pour un projet d'inférence, et jusqu'à 80 % pour un entraînement unique. Le stockage des jeux de données d'entraînement, souvent plusieurs dizaines de téraoctets, grimpe mécaniquement avec le nombre de jeux versionnés. L'egress — la sortie des données — se paie à chaque requête d'inférence servie hors du périmètre du fournisseur : à fort trafic, il dépasse parfois le coût du GPU lui-même en cloud public, et il est nul en souverain si les utilisateurs restent sur le territoire. Les services managés (orchestration, monitoring, base vectorielle) ajoutent 15 à 25 % en public, contre un coût d'assemblage interne en souverain. Enfin, l'ingénierie : temps d'adaptation des équipes, montée en compétence sur l'écosystème choisi, coût de la sortie éventuelle.

Une règle empirique issue des déploiements observés : en dessous de 500 euros mensuels de consommation GPU, le cloud public managé reste le choix le plus rationnel ; entre 500 et 5 000 euros, le souverain devient compétitif sur les charges stables ; au-delà, l'hybridité et la négociation d'engagements pluriannuels s'imposent dans les deux cas.

Qui choisit quoi : quatre profils types

Quatre situations couvrent la majorité des projets. La startup en phase d'expérimentation choisit le cloud public : capacité immédiate, tarification à l'usage, aucune donnée sensible — le moment de migrer viendra avec la traction. La PME qui industrialise un cas d'usage métier (chatbot documentaire, scoring, aide à la décision) sur des données clients bascule tôt vers le souverain : la conformité RGPD se structure dès le départ, et les coûts d'inférence se maîtrisent en instances réservées. Le grand compte ou l'acteur public soumis à SecNumCloud n'a pas le choix sur le périmètre sensible, et réserve le cloud public aux workloads anonymisés. Enfin, l'organisation soucieuse de souveraineté maximale — hôpitaux, cabinets d'avocats, acteurs de la défense — évalue la troisième voie : l'inférence locale de modèles open source sur serveur dédié, hors cloud, pour les cas d'usage où la latence et la confidentialité priment sur l'échelle.

Pour replacer cet arbitrage dans la stratégie cloud globale de l'entreprise — multicloud, edge, compétences — notre guide du cloud computing pour les entreprises détaille les fondations, et notre prospective 2026 sur l'avenir du cloud dessine les trajectoires à trois ans. L'arbitrage IA n'est jamais qu'un chapitre de la stratégie d'ensemble — mais c'est désormais le chapitre qui pèse le plus lourd dans la facture.