Sommaire
Commençons notre article avec un test, celui du compte rendu commercial. Une entreprise veut résumer ses échanges clients avec une IA. Son prestataire affiche « hébergé en France ». Quatre questions suffisent pourtant à fissurer l’argument : où le modèle s’exécute-t-il réellement ? Qui intervient quand un traitement échoue ? Les journaux techniques contiennent-ils des fragments de conversation ? Que récupère-t-on en cas de changement de solution ?
Ces questions déplacent le débat. On ne demande plus « est-ce souverain ? », mais « qu’est-ce qui reste sous notre contrôle, qu’est-ce qui dépend d’un tiers, et qu’est-ce qui est remplaçable ? ».
Que recouvre vraiment une IA souveraine ?
Deux solutions peuvent tourner dans le même datacenter français et offrir des niveaux de maîtrise diamétralement opposés. L’une permet de remplacer le modèle sans toucher aux intégrations ; l’autre enferme le client dans une interface propriétaire. C’est cet écart, invisible sur une fiche commerciale, qu’il faut objectiver.
Souveraineté d’État, autonomie d’entreprise : deux échelles différentes
Le terme « IA souveraine » mélange souvent deux niveaux. Nous l’avions déjà évoqué dans notre article sur la souveraineté numérique. Pour un État, il s’agit de maîtriser une filière : semi-conducteurs, calcul, modèles, talents. Pour une entreprise, l’enjeu est plus pragmatique : l’autonomie opérationnelle. Elle n’a pas vocation à concevoir ses processeurs ni à entraîner un modèle de fondation. Elle doit en revanche choisir ses dépendances en connaissance de cause et disposer d’un plan B pour ses usages critiques.
Le Cigref va dans ce sens dans son rapport prospectif 2025 : la maîtrise des maillons de la chaîne IA et la capacité de négociation contractuelle y figurent parmi les principes d’action des DSI. [1]
Traduit en exigences projet, cela donne trois questions :
- Pouvez-vous décider des traitements autorisés ?
- Pouvez-vous nommer chaque intervenant ?
- Pouvez-vous poursuivre l’activité si un fournisseur disparaît ou change ses conditions ?
Les cinq dimensions du contrôle
Ne notez jamais une offre globalement : décomposez-la. La grille ci-dessous est un outil de due diligence achat, pas une certification. Chaque ligne appelle une preuve écrite, et non une déclaration.
| Dimension | Question décisive | Preuve attendue | Signal d’alerte |
|---|---|---|---|
| Données | Où circulent les contenus, leurs copies et leurs dérivés (logs, embeddings, caches) ? | Cartographie des flux, politique de rétention | « Les données restent en Europe » sans périmètre précis |
| Modèle | Quels droits avez-vous sur son usage, sa version et son remplacement ? | Licence, model card, politique de versioning | Changement de modèle possible sans préavis |
| Infrastructure | Où s’exécutent l’inférence, les sauvegardes et la reprise d’activité ? | Schéma d’architecture, localisation par composant | Inférence ou PRA chez un tiers non nommé |
| Exploitation | Qui administre le service et qui peut lire les contenus ? | Matrice d’habilitations, procédure de support, journaux d’accès | Support « follow-the-sun » hors UE sans traçabilité |
| Réversibilité | Que récupérez-vous, dans quel format, à quel coût ? | Formats d’export, plan de réversibilité, essai de migration | Export limité à des PDF ou à un format propriétaire |
Cette décomposition évite une confusion fréquente : un engagement solide sur le stockage ne dit rien de l’exploitation ni de la sortie. Dans le dossier d’achat, chaque affirmation doit donc être rattachée à son périmètre exact. « Données hébergées dans l’UE » doit préciser quelles données, quels traitements et quelles copies.
Où en sont la France et l’Europe ?
Pour situer une offre, regardez les capacités auxquelles elle donne effectivement accès, pas le montant des investissements annoncés. Recherche, puissance de calcul et services exploitables en production sont trois réalités distinctes, avec des calendriers différents.
Un écosystème qui progresse, une diffusion qui tarde
Dans son bilan de la stratégie nationale publié en novembre 2025, la Cour des comptes reconnaît des avancées sur la structuration de la recherche, l’émergence d’acteurs de l’IA générative et les infrastructures de calcul.
Elle constate aussi que la diffusion de l’IA dans l’économie et l’accompagnement des entreprises restent en deçà des ambitions initiales. Ce diagnostic porte sur les périodes évaluées : ce n’est pas une mesure de l’adoption en 2026. [2]
La leçon pour un acheteur est simple : l’existence d’un champion national ne garantit pas la disponibilité d’un service adapté à votre cas. Une capacité de calcul annoncée n’est pas un engagement de niveau de service (SLA) pour votre application.
Les dépendances structurelles qui persistent
La chaîne de valeur de l’IA ne se résume pas au modèle. Elle inclut les puces (GPU, accélérateurs), les couches logicielles d’exécution, l’accès au calcul, les données d’entraînement et les compétences.
Dans son avis de juin 2024, l’Autorité de la concurrence identifiait précisément ces intrants comme des goulets d’étranglement potentiels. Elle analysait aussi les partenariats entre grands acteurs du numérique et startups de l’IA. [3]
Appliquez cette grille à votre propre projet en cartographiant quatre maillons : infrastructure, modèle, application, intégrations métier. Pour chacun, posez deux questions : quel événement pourrait interrompre le service ? Quelle alternative serait mobilisable, et en combien de temps ?
L’exercice révèle souvent que le verrou n’est pas là où on l’attend. Changer de modèle ne résout rien si votre CRM dépend d’un connecteur propriétaire. À l’inverse, une couche d’abstraction maîtrisée entre vos applications et le modèle (une API interne, une passerelle LLM) rend le remplacement beaucoup moins coûteux. L’objectif n’est pas de supprimer toute dépendance, mais d’éviter qu’une seule devienne impossible à contourner.
Pourquoi la localisation des serveurs ne suffit pas
Un compte rendu commercial peut être stocké à Paris et traversé, pendant son traitement, par trois ou quatre prestataires. Tant que leurs rôles et leurs accès ne sont pas documentés, l’adresse du stockage ne permet aucune conclusion sur l’ensemble du dispositif.
Accès, sous-traitants et juridictions
Cartographiez le cycle de vie complet de la donnée : collecte, transcription éventuelle, inférence, stockage du résultat, journaux techniques, sauvegardes, puis synchronisation vers les outils métier. Pour chaque étape, identifiez l’entité responsable, le lieu de traitement et les personnes susceptibles d’intervenir. C’est le registre des traitements et la liste des sous-traitants ultérieurs, au sens du RGPD, qui doivent porter cette information.
Le support technique est l’angle mort classique. Une assistance à distance peut-elle exposer des contenus ? Dans quels cas, depuis quels pays, avec quelle journalisation ? Un « break-glass access » non tracé suffit à ruiner un discours de souveraineté par ailleurs rigoureux.
Sur le terrain juridique, évitez les raccourcis dans les deux sens. Le risque extraterritorial existe : une société soumise à un droit étranger peut recevoir une injonction de communication, quel que soit le lieu de stockage. Mais l’article 48 du RGPD rappelle qu’une décision d’une autorité d’un pays tiers n’est pas, en soi, reconnue ni exécutoire dans l’Union. Y répondre suppose de vérifier une base légale et les conditions de transfert applicables. [4]
Faites analyser votre situation par votre DPO et votre direction juridique. La bonne question n’est pas « où sont les serveurs ? », mais « qui peut accéder à quoi, sous quel droit, pour quelle raison et selon quelle procédure ? ». Pour les usages les plus sensibles, une qualification comme SecNumCloud de l’ANSSI, qui intègre des critères d’immunité aux lois extra-européennes, constitue un repère plus exigeant qu’une simple localisation.
Poids ouverts, open source et licences : ne pas confondre
Un modèle aux poids téléchargeables élargit vos options de déploiement. Il ne vous confère pas pour autant tous les droits. La définition de référence de l’Open Source Initiative (OSAID) exige quatre libertés : utiliser, étudier, modifier et partager.
Elle exige aussi l’accès aux éléments qui les rendent effectives : paramètres, code, et informations suffisamment détaillées sur les données d’entraînement. Publier les poids ne suffit donc pas. [5] Beaucoup de modèles dits « open » relèvent en réalité de l’« open weights », avec des licences sur mesure.
Lors de l’évaluation, lisez la licence de la version réellement déployée, pas celle de la famille de modèles. Vérifiez quatre points :
- les usages autorisés, y compris les éventuels seuils d’utilisateurs ou restrictions sectorielles ;
- les conditions de modification et de fine-tuning ;
- les obligations de redistribution et d’attribution ;
- les composants tiers indispensables (tokenizer, runtime, outils d’orchestration) et leurs propres licences.
Confrontez ensuite ces droits à vos moyens. Disposer d’un modèle n’équivaut pas à disposer des compétences MLOps et du parc GPU pour l’exploiter. Demandez qui maintient l’ensemble, comment les mises à jour et correctifs de sécurité sont validés, et ce qui se passe en fin de support d’une version. L’ouverture crée des possibilités de contrôle ; elle ne l’exerce pas à votre place.
Quelle architecture choisir selon vos contraintes ?
Un assistant qui reformule des fiches produit publiques et un outil qui analyse des négociations confidentielles n’appellent pas les mêmes exigences. Partez de la classification des informations traitées et de l’impact d’une indisponibilité, puis seulement comparez les architectures.
Service managé, environnement dédié ou on-premise
Ces trois modèles ne forment pas une échelle automatique de souveraineté. Chacun déplace la responsabilité plutôt qu’il ne la supprime.
| Architecture | Ce qu’elle apporte | Ce qui vous incombe | Point de vigilance |
|---|---|---|---|
| Service managé (SaaS, API) | Mise en service rapide, exploitation assurée par le fournisseur | Paramétrage, gouvernance des usages, pilotage contractuel | Visibilité limitée sur les traitements et les sous-traitants ; conditions de sortie |
| Environnement privé ou dédié | Isolation, configuration ajustée au projet | Répartition précise des rôles client / prestataire (matrice RACI) | « Privé » ne dit rien, à lui seul, des accès ni des dépendances |
| Installation sur site | Maîtrise directe de l’environnement d’exécution | Capacité GPU, maintien en condition opérationnelle, sécurité, continuité | Dépendances résiduelles : licences, pilotes, mises à jour et interventions externes |
Concrètement, deux trajectoires sont possibles. Pour un usage peu sensible, vous pouvez piloter un service managé sur un corpus public, en interdisant tout document confidentiel pendant la phase de test. Pour un usage critique, exigez un périmètre de traitement contractualisé avant le moindre essai.
Coût complet, qualité et compétences
Comparer un abonnement au prix d’un serveur est une erreur de méthode. Raisonnez en coût total de possession (TCO) : intégration, exploitation, supervision, contrôle qualité, support et coût de sortie.
Pour les offres facturées à l’usage, faites lister les événements qui consomment : traitement initial, nouvelle tentative, document volumineux, fonctions complémentaires. Pour une exploitation interne, chiffrez le temps des équipes et les ressources mobilisées, y compris en période creuse, où un parc GPU sous-utilisé coûte autant qu’à pleine charge.
La bonne unité de mesure est le coût par résultat métier validé. Dans notre exemple, c’est le coût d’un compte rendu exploitable, temps de relecture et de correction compris, et non le coût d’une génération. Fixez aussi les exigences de latence et de disponibilité : une solution moins chère mais inadaptée au rythme des équipes reporte la dépense sur du travail manuel. Les arbitrages associent achats, DSI et utilisateurs, sur des critères figés avant la démonstration.
Quelles preuves exiger avant de signer ?
Un export réussi en démonstration ne prouve pas qu’une migration sera simple. Le seul test probant : une autre équipe, ou un autre outil, réutilise ce qui a été récupéré sans dépendre de l’application d’origine.
Le dossier fournisseur : cinq blocs de preuves
Constituez un dossier organisé par preuves, avec un responsable nommé pour vérifier chaque réponse. Une présentation commerciale oriente la discussion ; elle ne remplace ni le DPA (accord de traitement des données), ni les annexes techniques, ni les engagements de service.
- Périmètre des traitements : schéma des flux, catégories de données, lieux de traitement, liste des sous-traitants ultérieurs et procédure de notification en cas de changement.
- Accès et exploitation : rôles d’administration, accès du support, journalisation, gestion des incidents et droit d’audit du client.
- Usage des contenus : finalités autorisées, réutilisation éventuelle pour améliorer ou entraîner des modèles, durées de conservation, traitement des sauvegardes.
- Modèles et évolutions : versions déployées, licences, composants critiques, préavis en cas de changement de modèle affectant le service.
- Sortie et continuité : données exportables, formats, délais, assistance, coûts, et attestation de suppression en fin de contrat.
Ne laissez jamais une bonne note globale masquer un point bloquant. Si votre exigence exclut l’entraînement sur vos conversations, une réponse ambiguë impose une clarification écrite avant le pilote.
Pour chaque exigence, tenez trois statuts : documentée, testée ou à confirmer. Cette traçabilité rend la décision défendable, y compris quand une dépendance est consciemment acceptée. Faites enfin valider la traduction contractuelle des engagements déterminants : une réponse rassurante dans un questionnaire n’engage pas le fournisseur.
Côté réversibilité, le Data Act européen, applicable depuis septembre 2025, renforce les obligations des fournisseurs de services cloud en matière de changement de prestataire : c’est un levier de négociation à mobiliser.
Éprouver la qualité, la suppression et la réversibilité
Construisez un jeu de test représentatif à partir de données synthétiques ou correctement anonymisées. Pour des résumés commerciaux, incluez au moins quatre cas pièges :
- une conversation ordinaire, qui sert de référence ;
- un montant corrigé en cours d’échange ;
- une proposition explicitement refusée ;
- une prochaine étape laissée volontairement floue.
Vérifiez que le résumé distingue faits et hypothèses, n’invente aucun engagement et reste corrigeable avant diffusion. Testez aussi les situations dégradées : indisponibilité du service, ou utilisateur réclamant un document hors de ses droits. Il s’agit d’un protocole proposé, pas d’un benchmark déjà réalisé. Définissez à l’avance les erreurs éliminatoires, les corrections acceptables et qui tranche.
Complétez le pilote par un exercice de sortie grandeur nature. Exportez contenus et configurations, ouvrez-les dans un environnement indépendant, et mesurez ce qu’il faut reconstruire. Un fichier lisible mais privé de métadonnées, d’identifiants ou de contexte a une valeur limitée.
Pour la suppression, distinguez ce que vous constatez dans l’application et ce qui exige un engagement et une attestation : sauvegardes, journaux, copies chez les sous-traitants.
Clôturez par un bilan partagé : qualité obtenue, effort humain, coût constaté, dépendances résiduelles, conditions de poursuite. Vous aurez alors une base solide pour généraliser, renégocier ou arrêter.
Viser un niveau de maîtrise démontrable
Votre prochain projet IA n’a pas besoin d’une promesse d’indépendance totale. Il a besoin d’un périmètre net : un usage, des données autorisées, des dépendances identifiées et une sortie possible.
Réunissez métier, DSI, achats et DPO autour de trois questions. Que ne pouvons-nous pas exposer ? Quelle interruption ne pouvons-nous pas accepter ? Que devons-nous impérativement pouvoir récupérer ? Transformez les réponses en exigences vérifiables, puis en clauses.
Une stratégie d’IA souveraine ne se juge pas à son discours. Elle se juge à votre capacité à décider, à contrôler et, le moment venu, à changer de fournisseur.
Nos experts sont également à votre disposition, si vous avez la moindre question, sur la manière de reprendre le contrôle de vos données, notamment en matière de communication. Contactez-nous !
FAQ sur l’IA souveraine
IA souveraine et IA française : quelle différence ?
« Française » renseigne sur une origine, dont il faut préciser le périmètre : société, modèle ou infrastructure. Une démarche de souveraineté examine en plus les traitements, les intervenants, les droits et la continuité. Faites préciser ce que couvre exactement cette origine avant d’en tirer une conclusion.
Un modèle open source suffit-il ?
Non. L’ouverture du modèle ne dit rien de l’hébergement, des accès administrateurs, des connecteurs ni des pratiques d’exploitation. Le bon test : qu’êtes-vous réellement capable de modifier ou de remplacer avec vos ressources actuelles ?
Une PME doit-elle héberger son IA ?
Pas nécessairement. Comparez les garanties recherchées à votre capacité réelle d’exploitation. L’auto-hébergement se justifie pour certains usages, mais il transfère sur vous la sécurité, la maintenance et la continuité. Évaluez plusieurs configurations sur un même cas d’usage, avec les mêmes critères de qualité, de coût et de contrôle.
La souveraineté élimine-t-elle les erreurs de l’IA ?
Non. Maîtrise de l’environnement et fiabilité des résultats sont deux sujets distincts. Même sur une infrastructure contrôlée, un modèle peut halluciner. Prévoyez des tests métier et une validation humaine proportionnée aux conséquences d’une erreur : un résumé de négociation se relit avant de devenir un engagement envoyé au client.
Mentions
- [1] Cigref, rapport d’orientation stratégique 2025 : 4 archétypes de la fonction numérique pour 2040
- [2] Cour des comptes, synthèse sur la stratégie nationale pour l’IA, novembre 2025
- [3] Autorité de la concurrence, avis sur l’intelligence artificielle générative, juin 2024
- [4] EDPB, lignes directrices 02/2024 sur l’article 48 du RGPD
- [5]Open Source Initiative, Open Source AI Definition
Publié le 23 octobre 2026.
