IA souveraine : exigence réelle ou argument commercial ?

Un mot devenu argument de vente

« IA souveraine » figure désormais sur beaucoup de plaquettes commerciales. Le terme rassure, il sonne sérieux, et il recouvre des réalités très différentes. Pour un fournisseur, il peut désigner un centre de données situé en France. Pour un autre, un modèle conçu par une entreprise européenne. Pour un troisième, une offre qualifiée par l'ANSSI. Ces trois promesses n'apportent pas les mêmes garanties et ne coûtent pas les mêmes efforts.

Du côté des directions, la question arrive souvent par la conformité ou par un client : « est-ce que notre IA est souveraine ? ». La bonne réponse commence par une autre question : souveraine par rapport à quel risque ? Perte de contrôle sur des données sensibles, accès d'une autorité étrangère, dépendance à un fournisseur unique, exigence d'un donneur d'ordre. Chaque risque appelle une réponse différente, et certaines réponses coûtent cher en fonctionnalités.

Cet article ne reprend pas la comparaison des hébergeurs. Nous l'avons faite dans héberger un projet IA en France, qui traite des flux de données, du lieu de traitement, du droit applicable au fournisseur et de la réversibilité. Ici, nous posons une grille pour décider si la souveraineté est une exigence réelle pour votre projet, et ce qu'elle implique dans vos choix.

Ce que recouvre la souveraineté : quatre couches distinctes

Quand un fournisseur parle de souveraineté, il parle en général d'une seule de ces couches. Les distinguer évite de payer pour une garantie dont vous n'avez pas besoin, ou de croire acquise une garantie qui ne l'est pas.

• Le lieu des données. Où sont stockées et traitées les données, y compris les requêtes envoyées au modèle, les journaux et les sauvegardes. C'est la couche la plus facile à obtenir et la plus souvent mise en avant.
• Le droit applicable au fournisseur. À quelles lois est soumise l'entreprise qui opère le service, quel que soit l'emplacement des serveurs. Un hébergement en Europe ne dit rien de la nationalité juridique de l'opérateur.
• La maîtrise du modèle. Qui détient le modèle, qui peut le modifier ou le retirer, et pouvez-vous l'exécuter vous-même. C'est la couche de la dépendance technologique.
• La qualification. Un tiers reconnu a-t-il vérifié les garanties annoncées. En France, la référence est la qualification SecNumCloud délivrée par l'ANSSI.

Les deux premières couches sont traitées en détail dans notre article sur l'hébergement. Les deux dernières sont moins souvent expliquées, et ce sont elles qui font la différence entre une souveraineté affichée et une souveraineté vérifiable.

Un point de droit s'ajoute, indépendant de la souveraineté : le RGPD encadre les transferts de données personnelles hors de l'Union. Son chapitre V exige que ces transferts ne compromettent pas le niveau de protection garanti par le règlement. Ils reposent notamment sur une décision d'adéquation de la Commission ou sur des garanties appropriées, comme les clauses types de protection des données adoptées par la Commission. Ce cadre permet un transfert légal. Il ne répond pas à la question de savoir si vous voulez que vos données sortent.

La couche du modèle : trois façons de l'utiliser

C'est la couche la plus spécifique à l'IA, et la plus mal comprise. Il existe trois façons d'utiliser un modèle de langage, avec des degrés de maîtrise très différents.

Appeler l'API d'un éditeur

Vous envoyez vos requêtes au service de l'éditeur, qui exécute le modèle sur son infrastructure. C'est le mode le plus simple et celui qui donne accès aux modèles les plus récents. Votre maîtrise dépend du contrat : lieu de traitement, durée de conservation des requêtes, réutilisation éventuelle pour l'entraînement. La CNIL, dans ses recommandations sur le déploiement de l'IA générative, invite justement à vérifier si le fournisseur peut réutiliser les données qui lui sont transmises.

Choisir un éditeur européen

Un modèle conçu par une entreprise européenne, appelé via son API, règle une partie de la question du droit applicable à l'éditeur. Mistral AI, éditeur français, en est l'exemple le plus connu. Il faut toutefois regarder où et par qui le modèle est effectivement exécuté : un modèle européen servi par une plateforme soumise à un droit étranger ne donne pas les mêmes garanties que le même modèle servi en Europe par un opérateur européen.

Héberger soi-même un modèle à poids ouverts

Certains éditeurs publient les poids de leurs modèles sous une licence qui permet de les télécharger, de les modifier et de les déployer. La documentation de Mistral AI indique par exemple plusieurs modèles sous licence Apache 2.0. Vous les exécutez alors sur votre infrastructure ou chez un hébergeur de votre choix. Aucune requête ne quitte votre périmètre, et personne ne peut retirer ou modifier le modèle sans vous. La CNIL recommande d'ailleurs, pour un organisme, de privilégier des systèmes locaux, sécurisés et spécialisés quand c'est possible.

En contrepartie, vous devenez exploitant : mise à jour, supervision, capacité de calcul, sécurité de la chaîne. Et le catalogue est plus restreint que celui des API commerciales. C'est le cœur du compromis, et nous y revenons plus bas.

SecNumCloud : ce que dit l'ANSSI, et ce qu'on lui fait dire

SecNumCloud est un référentiel élaboré par l'ANSSI en 2016 pour qualifier des prestataires de services d'informatique en nuage. D'après la foire aux questions de l'agence, la qualification vise à protéger contre des menaces isolées, contre une cybercriminalité de bon niveau, et à assurer une immunité aux lois extra-européennes. Elle concerne des offres d'infrastructure, de plateforme, de conteneurs ou de logiciel en tant que service.

La protection contre les lois extra-européennes repose sur des exigences juridiques précises, détaillées par l'ANSSI : siège social établi dans un État membre de l'Union, actionnariat extra-européen limité, recours encadré à des services de pays tiers, autonomie opérationnelle. Côté données, doivent être situés sur le territoire de l'Union le stockage et le traitement des données des clients, mais aussi les annuaires des administrateurs et des utilisateurs, et les données techniques comme les journaux.

Trois précisions de l'ANSSI sont utiles pour lire les discours commerciaux :

• La qualification porte sur une offre, pas sur une entreprise. L'ANSSI l'écrit explicitement : SecNumCloud reconnaît une offre de cloud spécifique, pas un fournisseur ni une infrastructure. Un hébergeur peut avoir une offre qualifiée et d'autres qui ne le sont pas.
• Elle a une durée de validité. Elle vaut trois ans, avec des audits de surveillance annuels, puis doit être renouvelée.
• Elle ne remplace pas votre analyse de risque. L'ANSSI demande aux prestataires qualifiés de rappeler à leurs clients que SecNumCloud répond à des menaces précises et que chaque client reste responsable de la gestion de ses propres risques.

Il faut aussi distinguer les offres qualifiées de celles en cours de qualification, que l'ANSSI publie séparément avec l'accord des prestataires. « En cours » n'est pas « qualifié ». Avant de signer, vérifiez le nom exact de l'offre dans la liste publiée par l'agence.

Enfin, SecNumCloud qualifie un service d'hébergement. Si vous y faites tourner un modèle à poids ouverts, vous obtenez une infrastructure qualifiée. Si votre application appelle ensuite une API externe, cet appel sort du périmètre qualifié. La souveraineté d'un système se juge sur son maillon le plus exposé.

Quand la souveraineté est une exigence réelle

Dans notre pratique, trois situations justifient de traiter la souveraineté comme une contrainte de conception, et non comme une option.

Des données sensibles passent par le modèle

Données de santé, dossiers de ressources humaines, informations financières non publiques, secrets industriels, données de défense ou de sécurité. Si l'agent doit lire ces contenus pour être utile, la question du lieu de traitement, du droit applicable et de la conservation des requêtes devient centrale. Une fuite ou un accès non maîtrisé aurait des conséquences lourdes, et vous devez pouvoir démontrer vos garanties.

Vous travaillez pour ou avec le secteur public

Administrations, collectivités, établissements publics et leurs prestataires traitent des données dont la protection relève de l'intérêt général. Des exigences d'hébergement ou de qualification peuvent figurer dans les cahiers des charges. Si vous êtes prestataire d'une entité publique, lisez les clauses d'hébergement avant de choisir votre architecture, pas après.

Un contrat vous l'impose

C'est le cas le plus fréquent et le plus concret. Un grand compte, un donneur d'ordre industriel ou un client réglementé inscrit dans son contrat une exigence de localisation, d'opérateur européen ou d'offre qualifiée. La question n'est plus de savoir si la souveraineté est utile : elle est due. Il faut alors lire précisément le texte, car « hébergement en France », « opérateur soumis exclusivement au droit européen » et « offre qualifiée SecNumCloud » sont trois obligations différentes.

Quand c'est surtout un argument commercial

À l'inverse, certains signaux indiquent que le mot est utilisé pour vendre plus qu'il ne protège.

• Le fournisseur parle de souveraineté sans préciser laquelle des quatre couches il garantit.
• Il met en avant un centre de données français sans dire à quel droit est soumise l'entreprise qui l'exploite.
• Il se dit « SecNumCloud » sans nommer l'offre qualifiée, ou en confondant qualification et qualification en cours.
• L'offre souveraine appelle en réalité un modèle hébergé ailleurs, sans que ce soit clair dans la documentation.
• Le surcoût est justifié par la souveraineté alors que votre cas d'usage ne traite aucune donnée sensible.

Ce dernier point est le plus courant. Un agent qui aide à rédiger des fiches produits à partir d'un catalogue public, ou qui répond aux questions fréquentes à partir de pages déjà en ligne, ne manipule rien qui justifie une infrastructure qualifiée. Exiger la souveraineté maximale partout revient à renoncer à des outils utiles là où le risque est faible.

Ce que la souveraineté coûte en choix

La souveraineté n'est pas gratuite, et le coût n'est pas seulement financier. Il se paie en renoncements qu'il vaut mieux connaître avant de s'engager.

• Le catalogue de modèles. Plus vous montez en exigence, plus le choix se réduit. Les modèles disponibles en poids ouverts ou sur des offres qualifiées ne sont pas toujours les plus performants sur votre tâche. Il faut le mesurer sur vos propres cas, pas sur des classements généraux.
• Les fonctions annexes. Les API commerciales apportent souvent des outils intégrés : recherche, lecture de fichiers, exécution de code, mise en cache. En hébergement autonome, vous les reconstruisez ou vous vous en passez.
• La capacité d'exploitation. Héberger un modèle, c'est gérer du calcul, des mises à jour, de la supervision et de la sécurité. Il faut une équipe ou un partenaire pour le faire dans la durée.
• Le rythme d'évolution. Chaque nouvelle version de modèle doit être évaluée, déployée et testée chez vous. Vous gagnez en stabilité, vous perdez en vitesse d'accès aux nouveautés.
• Le coût de fonctionnement. Une capacité de calcul réservée se paie même quand personne ne s'en sert. Selon les volumes, ce modèle économique est plus ou moins favorable qu'une facturation à l'usage.

Ces arbitrages se chiffrent au cas par cas. Notre cadre CADRE de pilotage des coûts IA aide à les poser proprement, et l'article sur le coût d'un agent IA en production détaille les postes à prévoir.

Une méthode pour trancher sans dogme

La plupart des organisations n'ont pas besoin d'une réponse unique. Elles ont besoin d'une réponse par flux de données. Voici le déroulé que nous suivons.

• Cartographier les flux. Pour chaque cas d'usage, lister les données qui passent réellement par le modèle, pas celles qui dorment dans la base.
• Classer par sensibilité. Public, interne, confidentiel, sensible ou réglementé. La classification existe souvent déjà dans la politique de sécurité de l'entreprise.
• Relire les contrats. Identifier les clauses d'hébergement, de localisation et de qualification imposées par vos clients et partenaires.
• Affecter un niveau d'exigence par flux. API d'un éditeur avec engagements contractuels pour le public et l'interne, opérateur européen pour le confidentiel, modèle hébergé sur une offre qualifiée pour le sensible, par exemple.
• Isoler techniquement les niveaux. Une couche d'abstraction entre l'application et les modèles permet d'orienter chaque requête vers le bon fournisseur, et de changer de fournisseur sans tout réécrire.

Cette architecture mixte est souvent la plus raisonnable : elle réserve l'effort de souveraineté aux flux qui le justifient et garde l'accès aux meilleurs outils pour le reste. Elle demande en revanche une discipline de conception, en particulier pour éviter qu'une donnée sensible emprunte par erreur le mauvais chemin. C'est un travail d'ingénierie autant que de conformité, que nous menons avec nos profils AI engineer et sécurité et conformité IA.

La souveraineté ne dispense pas non plus des autres obligations. Un modèle hébergé en France reste soumis au RGPD et, selon son usage, au règlement européen sur l'IA, que nous résumons dans ce qui s'applique déjà à votre PME.

Les questions à poser à un fournisseur qui se dit souverain

Pour sortir des formules, posez ces questions par écrit et demandez des réponses contractuelles.

• Où sont stockées et traitées nos données, y compris les requêtes, les journaux et les sauvegardes ?
• À quel droit est soumise l'entreprise qui opère le service, et sa maison mère ?
• Quel modèle est exécuté, par qui, et où ? Des requêtes peuvent-elles être envoyées à un service tiers ?
• Nos données peuvent-elles servir à entraîner ou améliorer un modèle ?
• L'offre utilisée est-elle qualifiée SecNumCloud, sous quel nom exact, et jusqu'à quand ?
• Comment récupérer nos données et changer de fournisseur ?

Un fournisseur sérieux répond précisément à chacune. Un flou sur l'une d'elles est une information en soi. Ces questions s'inscrivent dans la démarche décrite sur notre page IA responsable.

Vous hésitez entre plusieurs niveaux d'exigence pour vos projets IA ? Le diagnostic IA permet de cartographier vos flux de données, de les classer et de décider où la souveraineté est nécessaire et où elle ne l'est pas.

Sources

• ANSSI, FAQ avant de se lancer dans la qualification SecNumCloud
• ANSSI, prestataires de services d'informatique en nuage en cours de qualification SecNumCloud
• CNIL, Comment déployer une IA générative ? Premières précisions
• RGPD, chapitre V : transferts de données vers des pays tiers
• Mistral AI, documentation des modèles et licences

Questions fréquentes

Un hébergement en France suffit-il pour parler d'IA souveraine ?

Il couvre une seule couche, le lieu des données. Le droit auquel est soumis l'opérateur, la maîtrise du modèle et l'existence d'une qualification restent des questions ouvertes. Demandez au fournisseur de répondre sur chacune avant d'utiliser le mot.

Un modèle à poids ouverts est-il forcément moins bon ?

Pas forcément, mais l'écart dépend de la tâche. Sur certaines tâches bien délimitées, un modèle ouvert bien choisi suffit largement. La seule façon de le savoir est de le tester sur un jeu de cas réels issus de votre activité.

Faut-il une offre SecNumCloud pour respecter le RGPD ?

Non, le RGPD ne l'exige pas. Il impose ses propres règles, notamment sur les transferts hors de l'Union. SecNumCloud répond à d'autres objectifs, comme la protection contre les lois extra-européennes, et devient nécessaire quand un contrat ou votre analyse de risque le demande.

Peut-on commencer avec une API américaine et migrer plus tard ?

Oui, à condition de l'avoir prévu dans l'architecture. Une couche d'abstraction entre l'application et les modèles, des prompts et des tests indépendants du fournisseur rendent la bascule réaliste. Sans cette précaution, la migration revient souvent à réécrire une partie du système.

La souveraineté protège-t-elle contre les attaques ?

Elle réduit certains risques, comme l'accès par une autorité étrangère ou la dépendance à un fournisseur. Elle ne protège pas contre une injection de consignes, une fuite par l'agent lui-même ou une mauvaise gestion des droits. La sécurité applicative de l'agent reste à construire, quel que soit l'hébergement.