Le 22 octobre 2026, le directeur financier de SAP, Dominik Asam, explique à Reuters que les clients de l’éditeur allemand demandent de plus en plus d’où vient l’intelligence artificielle logée dans leurs logiciels de gestion. Selon l’agence, les contrôles à l’exportation et le débat européen sur la souveraineté pèsent désormais sur des décisions qui se prenaient jusque-là sur le prix et la performance. La question type qu’il dit entendre régulièrement tient en 1 phrase : les données utilisées par ce modèle peuvent-elles être acheminées vers des endroits où elles ne devraient pas aller ?
L’enjeu tient à l’architecture de SAP. Selon Reuters, le groupe intègre plus de 70 modèles de fournisseurs différents dans les logiciels qui font tourner la comptabilité et la chaîne d’approvisionnement d’un grand nombre des plus grandes entreprises mondiales, plutôt que de construire les siens. La veille de l’interview, le 21 octobre, SAP publiait un troisième trimestre au chiffre d’affaires cloud de 6,7 milliards d’euros, en hausse de 26 %, et un carnet de commandes cloud courant de 24,1 milliards.
Quand un éditeur assemble des dizaines de modèles d’IA, la provenance de chacun s’écrit désormais dans le contrat : le client n’achète plus seulement une fonction, il achète la preuve de l’endroit où elle s’exécute.
Ce que SAP et son directeur financier affirment
Les propos d’Asam rapportés par Reuters dessinent une gradation plutôt qu’une règle. « Si vous êtes le ministère de la Défense d’un grand pays, vous y pensez autrement qu’un petit commerce », dit-il. Un client américain peut refuser des composants développés avec des modèles chinois, tandis que des travaux de back-office, y compris ceux de SAP, peuvent tourner sur des modèles ouverts « d’où qu’ils viennent ». Comprendre les exigences précises de chaque client en matière de gouvernance technologique, quand plusieurs modèles cohabitent, serait devenu « un art ». Le directeur financier ajoute que le débat européen sur un possible « bouton d’arrêt » dans l’infrastructure cloud américaine a nourri le marché des solutions souveraines, que SAP a récemment signé des contrats avec des gouvernements et des industriels de la défense, et qu’il préfère disposer de modèles de toutes les régions, Europe et Canada compris.
Les pièces de SAP confirment la stratégie de portefeuille. Le 4 juin 2024, le groupe a ouvert l’accès aux modèles de Mistral AI dans le « generative AI hub » de sa plateforme SAP AI Core, en revendiquant un accès « à un fournisseur européen ». La documentation publique de son kit de développement cite des modèles d’OpenAI, d’Amazon, de Google, d’Anthropic, de Mistral AI, de Perplexity et de Cohere, et renvoie pour la liste complète à une note réservée aux clients. Le 18 novembre 2025, SAP a étendu ce partenariat avec Mistral AI et annoncé plus de 20 milliards d’euros consacrés au cloud et à l’IA souverains. Le 27 novembre 2025, il a lancé l’EU AI Cloud, qui propose 4 modes de déploiement : son infrastructure dans des centres de données européens, une installation exploitée par SAP chez le client, des hyperscalers sélectionnés par marché et Delos Cloud pour le secteur public allemand. Les modèles de « Cohere, Mistral AI, OpenAI et d’autres » y sont proposés.
Ce que l’interview ne permet pas d’établir
Le chiffre de 70 modèles provient de Reuters ; aucune des pièces de SAP consultées ne le publie, ni sa répartition par fournisseur, par pays d’origine ou par lieu d’hébergement. Aucun client n’est nommé, aucun contrat perdu ou gagné sur ce critère n’est cité, et la préoccupation décrite n’est pas mesurée : c’est le témoignage d’un dirigeant, utile mais non quantifié. Les contrats avec des gouvernements et des industriels de la défense ne sont pas identifiés.
Le portrait d’un éditeur purement agnostique mérite aussi une nuance. SAP a racheté en 2026 Prior Labs, spécialiste des modèles de fondation entraînés sur des données tabulaires, pour environ 518 millions d’euros, afin, selon ses comptes, d’accélérer le développement de modèles conçus pour les données d’entreprise. Le groupe assemble des modèles tiers, et commence à en produire.
Surtout, rien dans ce dossier n’établit qu’un modèle intégré à SAP ait fait sortir des données là où il ne fallait pas. La question des clients exprime un risque perçu, pas un incident constaté. Et l’origine américaine ou chinoise d’un modèle ne dit, à elle seule, rien de l’endroit où ses calculs s’exécutent ni des données qui circulent.
Le mécanisme : 4 questions que le mot « origine » confond
Quand un acheteur demande « d’où vient ce modèle ? », il pose en réalité 4 questions distinctes, qui n’appellent ni les mêmes réponses ni les mêmes pièces.
D’abord, l’origine du fournisseur : qui a entraîné le modèle, dans quel pays il est établi, à quel régime d’exportation il est soumis. C’est le critère du client américain qui peut écarter les modèles chinois. Le règlement européen sur l’IA lui donne une traduction juridique depuis le 2 août 2025 : les fournisseurs de modèles d’IA à usage général établis hors de l’Union doivent désigner, par mandat écrit, un mandataire établi dans l’Union (article 54), et tous doivent remettre une documentation technique aux entreprises qui intègrent leur modèle dans leurs systèmes (article 53).
Ensuite, le lieu d’exécution : le modèle tourne-t-il sur l’infrastructure de l’éditeur, dans une région choisie, ou est-il appelé chez son fournisseur ? C’est ici que la remarque d’Asam sur les modèles ouverts prend sa portée. Un modèle dont les poids sont publiés peut être exécuté dans un centre de données européen sans qu’aucune donnée ne reparte vers son concepteur. À l’inverse, un modèle européen consommé par interface distante chez un hébergeur étranger fait voyager les requêtes.
Puis le droit applicable à l’opérateur de l’infrastructure, qui peut différer de la nationalité du modèle comme de la localisation du serveur. Le RGPD prévoit qu’une décision d’une autorité d’un pays tiers exigeant la communication de données personnelles n’est reconnue que si elle repose sur un accord international (article 48). Le règlement sur les données, applicable depuis le 12 septembre 2025, étend une logique comparable aux données non personnelles détenues dans l’Union (article 32) et oblige les fournisseurs de services de traitement de données à publier sur leur site les juridictions dont dépend leur infrastructure (article 28).
Enfin, les flux : quelles données quittent l’environnement du client, vers qui, pour combien de temps, sur quelle base. Un transfert de données personnelles hors de l’Union n’est pas interdit en soi ; il est encadré par le chapitre V du RGPD, dont l’article 44 couvre aussi les transferts ultérieurs. Les États-Unis bénéficient d’une décision d’adéquation de la Commission du 10 juillet 2023, dont le Tribunal de l’Union a rejeté la contestation le 3 septembre 2025. Déduire de l’origine d’un modèle qu’un transfert illicite a lieu serait donc une erreur de raisonnement.
Ces 4 questions se croisent. Un même modèle peut être proposé par SAP en exécution européenne pour un client et chez un hyperscaler pour un autre ; un portefeuille de 70 modèles multiplie les combinaisons. L’interview de Reuters décrit un marché qui commence à exiger que chaque combinaison soit nommée. Dans un logiciel qui assemble des dizaines de modèles, la souveraineté ne s’achète pas en une fois : elle se vérifie à chaque changement de modèle.
L’arbitrage déplacé : qui répond de la chaîne
Jusqu’ici, le choix des modèles relevait de l’éditeur. Le client achetait une fonction, une prévision de trésorerie ou un assistant d’achat, et ignorait souvent quel modèle la servait. La demande décrite par Asam déplace cette décision. Elle remonte du service informatique vers les achats, le juridique et la sécurité, et elle oblige l’éditeur à répondre d’une chaîne qu’il n’a pas entièrement construite.
SAP a fait son choix : un portefeuille ouvert à toutes les régions, combiné à des options de déploiement souveraines, plutôt qu’un modèle unique labellisé européen. Ce choix reporte une partie de l’arbitrage sur le client, qui doit classer ses usages. Le ministère de la Défense et le petit commerce de la citation d’Asam n’ont ni les mêmes exigences ni le même besoin de preuve. Pour l’État français, la doctrine « cloud au centre » a déjà tranché une partie de la question : les systèmes qui traitent des données d’une sensibilité particulière doivent reposer sur une offre qualifiée SecNumCloud, ou de niveau européen au moins équivalent, « immunisée contre tout accès non autorisé par des autorités publiques d’État tiers » (règle 9).
L’arbitrage le plus délicat oppose performance et maîtrise. Le modèle le plus performant pour un usage donné peut ne pas être proposé dans l’option souveraine retenue. Nous montrions, à propos du discours de Christine Lagarde à Vienne, qu’un modèle « suffisamment bon » opérant sur une infrastructure européenne réduit la crédibilité d’une menace d’interruption, même sans égaler le meilleur. Le même raisonnement vaut à l’échelle d’une entreprise : accepter un léger écart de performance sur un usage sensible peut acheter une continuité que le contrat ne garantirait pas autrement.
Le contrat devient l’instrument de cet arbitrage. L’article 53 du règlement sur l’IA oblige le fournisseur du modèle à documenter son modèle pour l’éditeur qui l’intègre, pas pour le client final : celui-ci n’obtient ces informations que s’il les exige de l’éditeur. Lorsque le fournisseur d’un modèle traite des données personnelles pour le compte du client, il devient un sous-traitant ultérieur, et le RGPD impose d’informer le client de tout ajout ou remplacement, en lui laissant la possibilité de s’y opposer (article 28). Remplacer un modèle exécuté chez son fournisseur peut donc déclencher une procédure contractuelle ; remplacer un modèle ouvert exécuté par l’éditeur lui-même, non. L’origine d’un modèle est un indice ; le lieu d’exécution, le droit applicable et les flux sont des faits qui se prouvent par pièces.
Ce que diront les prochains mois
La lecture proposée ici se vérifiera sur des faits observables. Si la provenance devient un critère d’achat, SAP et ses concurrents publieront, ou remettront à la demande, des registres de modèles indiquant pour chaque fonction le fournisseur, le lieu d’exécution et l’opérateur, au-delà de la note réservée aux clients. Les résultats annuels de SAP, attendus début 2027 à une date que le groupe n’a pas encore confirmée dans les pièces consultées, diront si l’éditeur chiffre la part de ses contrats signés sur ses options souveraines ; il prévoit pour 2026 un chiffre d’affaires cloud vers le haut d’une fourchette de 25,8 à 26,2 milliards d’euros à changes constants. Le 2 août 2027, les modèles à usage général mis sur le marché avant le 2 août 2025 devront à leur tour se conformer au règlement sur l’IA, ce qui étendra la documentation disponible à l’ensemble du stock. Si, d’ici là, aucun éditeur ne publie de registre par fonction et qu’aucun appel d’offres public ne l’exige, la préoccupation décrite par Asam sera restée un discours, pas une clause.
Les propos de Dominik Asam proviennent de l’interview publiée par Reuters le 22 octobre 2026 ; la dépêche de Leo Marchandon, publiée à 11 h 39 (heure de Paris), a été lue dans son texte intégral. Les citations, traduites de l’anglais par ELMARQ, et le chiffre de plus de 70 modèles sont attribués à Reuters. Les chiffres financiers proviennent du communiqué du troisième trimestre 2026 de SAP, déposé auprès de la SEC (formulaire 6-K), non audité. Les offres souveraines et les partenariats proviennent des communiqués de SAP du 4 juin 2024, des 18 et 27 novembre 2025, et de la documentation publique de son kit de développement ; la liste officielle des modèles, réservée aux clients, n’a pas été consultée. Le cadre juridique provient des textes publiés au Journal officiel de l’Union (règlements 2024/1689, 2016/679 et 2023/2854, version initiale pour le premier), de l’arrêt du Tribunal T-553/23 et de la doctrine « cloud au centre » publiée par la DINUM. La grille et son exemple chiffré sont des constructions d’ELMARQ.
