IA open source en local : ce que l'exécution sur site change pour les données sensibles

L'IA locale désigne l'exécution d'un modèle sur l'infrastructure de l'organisation, sans appel à un service externe. Appliquée à des données sensibles, elle supprime la transmission à un tiers — et avec elle une part des obligations qui bloquent les projets : plus de sous-traitant à encadrer au sens de l'article 28 du RGPD, plus de transfert hors Union européenne à justifier au titre du chapitre V, plus de clause à négocier. C'est précisément ce qui débloque les dossiers qui meurent en comité de sécurité.

Ce basculement est récent. En août 2026, plusieurs laboratoires ont publié des modèles exécutables sur du matériel grand public — dont un système de reconnaissance vocale dont la plus petite déclinaison pèse moins de 500 Mo et fonctionne sans carte graphique. La capacité n'est plus enfermée derrière une API payante.

Mais l'exécution locale n'est pas la conformité. La licence des poids d'un modèle diffère de celle de son code, l'exploitation revient à vos équipes, et un modèle local reste un acteur sans identité ni journal tant que vous ne lui en donnez pas. Cet article détaille ce qui change réellement, ce qui ne change pas, et comment trancher.

Ce qui a changé en août 2026

Plusieurs publications convergentes, sur une même semaine, ont déplacé le seuil d'accès :

• Un modèle de génération vidéo produisant image et bande son dans la même passe, annoncé comme fonctionnant avec 5 à 16 Go de mémoire vidéo.
• Un système d'animation de personnages annoncé sous la seconde de latence dans sa version allégée.
• Un modèle de langage parmi les plus gros connus publiquement, dont les poids sont annoncés comme ouverts.
• Un outil de reconnaissance vocale dont le plus petit modèle tient sous 500 Mo et s'exécute sans GPU.

Le point commun n'est pas la performance brute mais le support d'exécution : du matériel qu'un établissement possède déjà. Ces chiffres proviennent des communications des éditeurs et n'ont pas fait l'objet d'une vérification indépendante de notre part — ils indiquent un ordre de grandeur, pas un engagement de service.

Cloud ou exécution locale : ce que chaque option engage

Le choix ne se réduit pas à une comparaison de coût. Il déplace des obligations juridiques et opérationnelles d'un côté à l'autre du contrat.

Critère	API d'un fournisseur	Exécution locale
Statut RGPD du fournisseur	Sous-traitant, contrat art. 28 requis	Aucun tiers, pas de contrat de sous-traitance
Transfert hors UE	À justifier (chapitre V)	Sans objet
Modèle de coût	Variable, à l'usage	Fixe : matériel et exploitation
Coût marginal d'un test	Facturé	Nul
Traçabilité des traitements	Partagée avec le fournisseur	Entièrement chez vous
Mises à jour et correctifs	Assurés par le fournisseur	À votre charge
Réversibilité	Dépend des conditions d'usage	Totale, le modèle est stocké
Disponibilité	Soumise au fournisseur	Soumise à votre exploitation

Aucune colonne n'est supérieure dans l'absolu. L'API reste rationnelle pour un usage ponctuel ou exploratoire ; l'exécution locale se justifie quand le volume est régulier, ou quand la sensibilité des données l'impose.

Le point qui débloque : il n'y a plus de sous-traitant

C'est l'effet le plus immédiat et le plus sous-estimé.

Lorsqu'un traitement passe par une API externe, le fournisseur devient sous-traitant au sens de l'article 28 du RGPD. Cela suppose un contrat écrit, un encadrement des sous-traitants ultérieurs, une documentation des mesures de sécurité au titre de l'article 32, et une justification des transferts si les serveurs sortent de l'Union européenne. Pour un traitement de données de santé, s'y ajoutent les exigences d'hébergement applicables.

Un modèle exécuté sur votre infrastructure ne déclenche aucune de ces obligations, parce qu'aucune donnée ne quitte votre périmètre. Le traitement reste sous votre seule responsabilité de responsable de traitement.

C'est ce point, et non l'économie sur la facture, qui décide du sort de la plupart des projets. Une automatisation techniquement aboutie est abandonnée en comité parce que personne ne peut garantir le trajet des données — un problème de responsabilité, qu'aucune clause contractuelle ne dissipe complètement. L'exécution locale le règle par construction.

Trois limites à connaître avant de décider

La licence des poids n'est pas celle du code

« Open source » ne signifie pas « libre de tout usage ». Un modèle se compose de deux artefacts distincts, soumis à deux licences distinctes : le code d'inférence, souvent permissif, et les poids du modèle, fréquemment assortis de restrictions — usage non commercial, plafond d'utilisateurs mensuels, interdictions sectorielles, obligation d'attribution.

Lire l'annonce d'un éditeur mentionnant une licence permissive et en conclure que l'ensemble est utilisable commercialement est une erreur courante, et coûteuse dans un contexte réglementé. Les deux fichiers de licence se lisent avant tout déploiement en production, et la conclusion se consigne dans le dossier du projet.

L'exploitation revient chez vous

L'exécution locale déplace vers vos équipes ce que le fournisseur assurait : mise à jour des modèles, supervision de la charge, reprise après incident, sauvegarde, veille sur les vulnérabilités, et maintien d'une compétence interne.

Ce coût est réel mais rarement chiffré au moment de la décision. Il se compare à l'abonnement évité, pas au coût nul. Pour un usage occasionnel, l'arbitrage penche souvent vers l'API ; pour un traitement récurrent portant sur des données sensibles, vers l'internalisation.

Un modèle local reste un acteur non gouverné

Un modèle qui tourne dans vos murs échappe au réseau, pas à la gouvernance. Il lit des fichiers, produit des sorties, et parfois déclenche des actions. Sans identité propre, sans droits délimités et sans journal distinct, ces opérations sont indiscernables de celles de l'utilisateur qui a lancé le processus.

La disparition de l'API supprime aussi un garde-fou involontaire : la facture. Un modèle téléchargé ne laisse aucune trace d'achat, donc aucun signal pour les équipes sécurité. C'est un cas de shadow IT dont l'ampleur ne se mesure qu'en inventoriant les postes.

Ce que ça change pour le contrôle d'accès et l'IAM

Un agent automatisé qui agit dans le système d'information est un acteur, au même titre qu'un collaborateur ou qu'un compte de service. Il devrait donc relever des mêmes principes que ceux appliqués au contrôle d'accès physique et logique : une identité distincte, des droits limités à son périmètre fonctionnel, une date d'expiration, et une trace exploitable.

Dans la pratique, la plupart des agents s'exécutent sous le compte de la personne qui les a lancés. Le journal attribue alors à un humain des centaines d'opérations qu'il n'a pas réalisées — une attribution fausse, difficile à défendre lors d'une revue d'accès ou d'un audit.

Les mécanismes nécessaires existent déjà et ne sont pas propres à l'IA : modèles RBAC ou ABAC, provisionnement et révocation, revues d'habilitations périodiques, journalisation séparée. Les établissements engagés dans une trajectoire de mise en conformité, notamment sous NIS2 en milieu hospitalier (directive UE 2022/2555), disposent déjà du cadre : il reste à y inscrire les acteurs non humains.

Par où commencer

1. Inventorier l'existant. Quels modèles tournent déjà sur les postes, lancés par qui, sur quelles données. Sans cet état des lieux, toute politique d'usage est écrite à l'aveugle.
2. Choisir un processus répétitif à faible enjeu. Transcription de réunions, tri de documents entrants, comptes rendus standardisés. Le critère n'est pas la difficulté technique mais le fait qu'une erreur y soit rattrapable.
3. Mesurer avant. Combien d'heures par mois, par qui, pour quel résultat. Un gain non mesuré au départ ne sera pas démontrable à l'arrivée, et un projet non démontrable n'est pas reconduit.
4. Écrire le cadre. Données admises, données interdites, qui valide une sortie avant qu'elle produise un effet, à quel seuil un humain est alerté. Une page suffit, et c'est l'étape la plus souvent sautée.
5. Vérifier les deux licences et consigner la conclusion dans le dossier du projet.
6. Tester à petite échelle, sur des données réelles mais sans conséquence, avant tout élargissement.

Questions fréquentes

Un modèle exécuté en local dispense-t-il d'une analyse d'impact ?

Non. L'analyse d'impact relative à la protection des données relève de l'article 35 du RGPD et dépend de la nature du traitement, pas de son lieu d'exécution. Un traitement à grande échelle de données de santé la requiert, qu'il soit local ou externalisé. L'exécution locale simplifie le volet transferts et sous-traitance, elle ne supprime pas l'obligation d'analyse.

Quel matériel faut-il prévoir ?

Cela dépend entièrement du modèle retenu. Les annonces d'août 2026 mentionnent des besoins allant de l'absence de carte graphique, pour de la reconnaissance vocale compacte, à 16 Go de mémoire vidéo pour de la génération d'images animées. Beaucoup d'organisations disposent déjà d'un parc suffisant sans l'avoir identifié comme tel. L'inventaire précède l'achat.

« Open source » signifie-t-il utilisable commercialement ?

Pas nécessairement. Le code d'inférence et les poids relèvent de licences distinctes, et les poids sont fréquemment assortis de restrictions d'usage. Les deux documents se lisent séparément avant tout déploiement en production.

Faut-il abandonner les API des fournisseurs ?

Non. Les deux approches coexistent : l'API pour l'exploration et les usages ponctuels, l'exécution locale pour les traitements récurrents ou portant sur des données sensibles. Ce qui change, c'est que l'internalisation est devenue une option crédible — donc un levier de négociation et un plan de repli.

À retenir

L'écart entre l'IA propriétaire et l'IA ouverte s'est refermé plus vite que la plupart des feuilles de route ne l'anticipaient, et la contrainte qui justifiait d'attendre — le coût et l'accès — a largement disparu.

Ce qui reste est un travail d'organisation : inventorier, cadrer, attribuer une identité aux acteurs non humains, journaliser. Ce travail-là ne s'accélère pas tout seul, et c'est lui qu'un auditeur examinera. Nos engagements de conformité détaillent le cadre dans lequel nous l'accompagnons.

Les éléments d'actualité cités proviennent d'annonces publiques d'éditeurs relayées en août 2026. Les chiffres de performance et de configuration matérielle sont ceux communiqués par ces éditeurs et n'ont pas fait l'objet d'une vérification indépendante. Les références réglementaires renvoient au RGPD (règlement UE 2016/679) et à la directive NIS2 (UE 2022/2555).