Dans un précédent article, nous décrivions un glissement : l’IA passe de l’outil qu’on interroge au composant qui aiguille, au cœur des processus. Ce glissement a une conséquence que l’on mesure mal. Le composant qui trie les courriels voit chaque courriel ; celui qui note les dossiers voit chaque dossier ; celui qui contrôle les résultats d’analyse voit chaque résultat. Le sujet « IA et RGPD », longtemps traité comme une formalité de contrat, devient alors une question d’architecture : celle de savoir où ce composant tourne, et qui le voit travailler.
De l’assistant au composant : ce qui change pour vos données
Avec un assistant conversationnel, l’utilisateur choisit ce qu’il colle dans la fenêtre. Ce choix est imparfait, souvent fait à la hâte, mais il existe : chaque envoi est un geste, et une politique d’usage peut l’encadrer.
Dans un workflow, ce geste disparaît. C’est le processus qui envoie, automatiquement, tout ce qui le traverse. Personne ne décide plus, message par message, de ce qui part chez le fournisseur du modèle. La décision a été prise une fois, au moment de brancher l’étape, et elle s’applique ensuite à tout le flux, en continu.
Le volume change aussi de nature. Un assistant reçoit quelques requêtes par personne. Une étape de décision reçoit tout ce que l’entreprise traite : chaque demande client, chaque pièce jointe, chaque résultat. Et chaque appel peut laisser une trace chez le fournisseur, sous forme de journaux conservés pour le débogage, la facturation ou la sécurité, selon ses conditions. Ce qui était une exposition ponctuelle devient une exposition structurelle.
Jev, le modèle de décision présenté par TypeSafe AI en septembre 2026, illustre bien ce basculement, sans qu’il y ait de reproche à lui faire. Il est conçu pour être appelé des milliers de fois, à chaque étape d’un programme, et s’utilise à travers le service de l’éditeur. TypeSafe indique que ce service est aujourd’hui opéré depuis la côte Ouest des États-Unis. Le modèle renvoie des probabilités sans justification, ce qui rend une décision difficile à expliquer après coup, comme le relève DataCamp.
C’est un cas d’école, pas une cible. Le même raisonnement vaut pour toute API d’intelligence artificielle, quel que soit le pays de son éditeur. Ce qui change, au fond, c’est l’échelle de l’exposition : un assistant voit des extraits, un composant de décision voit le flux métier entier.
IA et RGPD, Cloud Act : ce que dit vraiment le cadre
Deux textes se croisent dès qu’une donnée européenne part chez un fournisseur d’IA.
Le Cloud Act, loi américaine adoptée en mars 2018, permet aux autorités américaines d’exiger d’un fournisseur soumis à leur droit les données qu’il a en sa possession, sa garde ou son contrôle, qu’elles soient stockées aux États-Unis ou ailleurs. Le critère n’est pas le lieu du serveur, mais la juridiction de l’opérateur. Un centre de données installé en Europe, exploité par une société relevant du droit américain, ne place donc pas les données hors de portée de ces demandes.
Le RGPD, de son côté, qualifie le fournisseur. Lorsqu’un modèle traite des données personnelles pour le compte d’une entreprise, son fournisseur est en principe un sous-traitant au sens de l’article 28 : il faut un contrat qui encadre le traitement, des garanties suffisantes, et une autorisation préalable pour tout sous-traitant ultérieur. Nous détaillons ces clauses dans notre article sur l’article 28 du RGPD.
Si les données quittent l’Union européenne, les règles du chapitre V sur les transferts s’appliquent en plus. Vers les États-Unis, le cadre actuel repose sur une décision d’adéquation du 10 juillet 2023, validée par le Tribunal de l’Union le 3 septembre 2025 ; le dispositif précédent avait été invalidé par la Cour de justice en 2020.
Le sujet « IA et RGPD » ne se résume donc pas à savoir si un outil est conforme. Il se pose flux par flux : quelles données passent, sur quelle base, chez qui, et sous quel droit. Le règlement européen sur l’intelligence artificielle, le règlement (UE) 2024/1689, ajoute ses propres obligations selon les usages ; il ne remplace aucune de ces questions.
Pour une étape de décision, ces principes se traduisent en questions très concrètes, à poser au fournisseur avant de signer. Les données envoyées sont-elles conservées, et combien de temps ? Servent-elles à entraîner ou à améliorer le modèle ? Quels sous-traitants interviennent, et dans quels pays ? Les réponses figurent en principe dans le contrat et ses annexes ; quand elles n’y figurent pas, c’est déjà une réponse.
Exécuter le modèle chez soi : ce que cela recouvre
L’IA locale consiste à faire tourner le modèle sur une infrastructure que l’on maîtrise — c’est ce que l’on appelle en anglais un private LLM — : ses propres machines, dans ses locaux, ou celles d’un hébergeur de confiance qui les opère pour son compte. Les données envoyées au modèle, et les décisions qu’il renvoie, ne passent alors par aucun tiers que l’on n’a pas choisi.
Le mot « local » ne veut donc pas forcément dire « dans ses murs ». Une PME n’a pas toujours la place, les compétences ou l’envie d’exploiter une machine de calcul. Confier cette exploitation à un prestataire reste de l’IA locale au sens qui compte, à trois conditions : que ce prestataire relève du droit européen, qu’il ne s’appuie pas lui-même sur un sous-traitant soumis à une loi extraterritoriale, et que le modèle qu’il exécute soit identifié et figé.
Deux souverainetés se cachent derrière ce mot, et on les confond souvent. La souveraineté de l’infrastructure dit où tournent les calculs, et sous quel droit est leur opérateur. La souveraineté du modèle dit qui l’a conçu, ce que l’on sait de lui, et si l’on peut l’inspecter. Un modèle fermé hébergé en France reste une boîte noire ; un modèle ouvert exécuté chez un fournisseur soumis au Cloud Act reste exposé. Les deux conditions sont nécessaires.
C’est pourquoi un LLM local repose presque toujours sur un modèle dit open-weight, dont les paramètres sont publiés. Ce type de modèle permet de figer une version précise, de la faire tourner à l’identique pendant des mois, et de rejouer une décision passée avec la même version pour comprendre ce qui l’a produite. Des modèles de ce type existent chez des éditeurs européens : le français Mistral AI en publie plusieurs sous licence ouverte.
Ce que l’exécution locale ne règle pas
L’IA exécutée chez soi n’est pas une solution universelle, et la présenter ainsi lui rendrait un mauvais service.
Les performances. Sur certaines tâches complexes, comme le raisonnement long ou la rédaction très spécialisée, les plus grands modèles fermés gardent l’avantage. Un modèle local suffisant n’est pas un modèle équivalent.
L’exploitation. Un modèle qui tourne chez soi demande ce que demande tout système : des mises à jour, des sauvegardes, une sécurité physique et logique, des accès gérés, et quelqu’un de responsable. Sans exploitation, la machine locale devient un risque de plus.
Le choix des flux. Tout ne mérite pas le local. Un flux de données publiques ou peu sensibles peut très bien passer par un service en ligne bien encadré. L’effort se concentre sur les flux où la donnée ne doit pas sortir.
C’est là que la distinction entre réflexe et rédaction devient utile. Les décisions réflexes (trier, aiguiller, noter, contrôler) sont souvent celles qu’un modèle plus petit, exécuté localement, traite bien : la réponse est fermée, le contexte court, et il n’est pas nécessaire de disposer du plus grand modèle du marché pour choisir entre quatre catégories. Les flux les plus sensibles se prêtent ainsi souvent le mieux au local.
Trois questions à poser avant de brancher une IA sur vos processus
Ces questions se posent étape par étape, pas outil par outil. Un même fournisseur peut convenir pour une étape et pas pour une autre, selon ce qui y transite.
- Quelles données transitent par cette étape, et quel est leur niveau de sensibilité ?
- Sous quelle juridiction est le fournisseur, et où tournent les calculs ?
- Peut-on figer la version du modèle et expliquer une décision après coup ?
Si la réponse à la troisième question est non, la décision n’est pas auditable. Pour une structure soumise à un contrôle, réglementaire ou scientifique, cela peut suffire à écarter l’outil, quelles que soient ses performances.
La première question est souvent la plus révélatrice. En la posant, beaucoup d’entreprises découvrent qu’une étape jugée anodine voit passer des données de santé, des coordonnées bancaires ou des informations couvertes par le secret des affaires, simplement parce qu’elles figurent dans les pièces jointes.
Notre approche
Maeliom a fait le choix d’une infrastructure dédiée, opérée en France, avec un modèle européen à poids ouverts. L’argument de souveraineté porte ainsi sur toute la chaîne : le matériel, son opérateur et le modèle. Aucun tiers ne se trouve dans le trajet des données.
Nous ne prétendons pas que ce modèle rivalise avec les plus grands modèles fermés. Il n’en a pas besoin pour trier, aiguiller, noter ou contrôler. Pour certaines rédactions exigeantes, l’écart existe, et c’est un compromis que nous exposons à chaque structure plutôt que de le taire.
Cette offre est ouverte en accès anticipé à un cercle restreint de structures qui manipulent des données sensibles : recherche, santé, juridique, conformité. Elle est présentée, avec ses trois formules dont la Safe Room, sur notre page IA souveraine.
La question n’est plus de savoir si l’IA prendra des décisions dans vos processus. Elle en prend déjà, ou en prendra bientôt, parce que c’est là que se trouvent les gains. La question est de savoir sous quelles conditions : qui voit passer ces décisions, sous quel droit, avec quel modèle, et avec quelle possibilité de les expliquer. Ces conditions se fixent au moment de brancher l’étape, rarement après.
Reste à voir comment cela s’applique dans une structure de taille modeste. C’est l’objet d’un cas de veille réglementaire, découpé étape par étape.
Questions fréquentes
Qu’est-ce qu’une IA souveraine ?
Une IA souveraine est un système d’intelligence artificielle dont on maîtrise toute la chaîne : l’infrastructure sur laquelle tourne le modèle, le droit auquel est soumis son opérateur, et le modèle lui-même, de préférence à poids ouverts pour pouvoir l’inspecter et le figer. L’hébergement en Europe n’en est qu’une condition.
Qu’est-ce qu’un LLM local ?
Un LLM local est un grand modèle de langage exécuté sur une infrastructure que l’on contrôle, dans ses locaux ou chez un hébergeur de confiance, plutôt qu’appelé chez un fournisseur en ligne. Les données envoyées au modèle ne passent par aucun tiers non choisi. Il repose généralement sur un modèle open-weight.
Le Cloud Act s’applique-t-il aux données hébergées en Europe ?
Oui, si le fournisseur relève du droit américain. Le Cloud Act vise les données qu’un fournisseur soumis à ce droit a en sa possession, sa garde ou son contrôle, où qu’elles soient stockées. Le critère déterminant est la juridiction de l’opérateur, pas l’emplacement du serveur.
Une IA locale est-elle conforme au RGPD par défaut ?
Non. Elle facilite la conformité en supprimant certains transferts et certains sous-traitants, mais elle ne la garantit pas. Il faut toujours une base légale, une information des personnes, une durée de conservation, des mesures de sécurité et, le cas échéant, une analyse d’impact. Le local réduit l’exposition ; il ne dispense d’aucune obligation.
Sources : ministère américain de la Justice, Cloud Act ; 18 U.S.C. § 2713 ; RGPD, article 28 et chapitre V (CNIL) ; décision d’adéquation (UE) 2023/1795 ; Tribunal de l’UE, T-553/23, 3 septembre 2025 ; règlement (UE) 2024/1689 ; TypeSafe AI (15 septembre 2026) ; DataCamp ; Mistral AI, liste des modèles.