Module 9 — Confidentialité des données par l'exécution locale

« Nous exécutons le modèle localement, donc nos données sont en sécurité. » Cette phrase, entendue dans presque tous les projets qui atterrissent sur un petit modèle, est à moitié vraie — et cette moitié importe. Ce module trace la ligne exacte : ce que le local protège, ce qui devient plus simple sur le plan réglementaire, et ce qu'il ne protège pas malgré l'apparence.

Ce que le local protège vraiment

Sur un modèle exécuté sur le poste de l'agent, les données de l'utilisateur ne quittent pas la machine pendant l'inférence. Aucune requête HTTP ne part vers un fournisseur externe, aucune donnée n'atterrit dans les journaux d'un tiers, aucun contrat de sous-traitance n'est en jeu pour ce flux. La donnée circule entre la RAM et le CPU/GPU du poste, et cette circulation ne franchit aucune frontière juridique ni matérielle.

Trois conséquences directes.

Pas de contrat de sous-traitance à négocier pour cette brique. Une API commerciale de grand modèle exige un DPA — accord de traitement des données — qui pose la question du transfert hors UE, de la durée de conservation, des sous-traitants ultérieurs. En local, ces questions disparaissent parce que le flux ne quitte pas votre juridiction.

Pas de risque de fuite par les journaux du fournisseur. Les incidents connus en 2023-2025 ont montré que les journaux des fournisseurs d'API pouvaient être consultés par erreur ou par abus interne. Ce vecteur n'existe pas quand il n'y a pas de fournisseur.

Pas de dépendance de disponibilité. Une panne du fournisseur, un changement tarifaire brutal, une suspension de compte : aucun de ces événements ne peut couper votre assistant. C'est un point de résilience opérationnelle, pas de confidentialité au sens strict, mais il pèse dans la décision.

Les obligations réglementaires facilitées

Sur les données à caractère personnel au sens du RGPD, exécuter localement simplifie sans supprimer trois obligations.

Base légale de traitement. L'analyse de tickets contient inévitablement des données personnelles (noms de clients, informations de compte, parfois données sensibles). L'exécution locale n'exempte pas de justifier une base légale, mais elle facilite l'analyse d'impact (AIPD) : le périmètre est le poste de l'agent, non un cloud tiers.

Transfert hors UE. L'exécution locale sur poste français élimine cette question. Une API commerciale hébergée aux États-Unis rouvrait la discussion, y compris depuis la fin des adéquations et les décisions Schrems successives.

Réutilisation par le fournisseur pour l'entraînement. Certaines API réservent le droit d'utiliser les échanges pour améliorer leurs modèles, sauf option explicite de refus. Le local supprime cette question.

Dans le secteur santé, avocat, notariat, banque, ces trois points font régulièrement la différence entre un projet qui se déploie et un projet qui reste bloqué en comité de conformité.

Ce que le local ne protège pas

C'est la partie qu'il faut savoir dire aux dirigeants, sous peine de vendre une sécurité illusoire.

Le poste lui-même n'est pas coffre-fort. Un poste utilisateur mal chiffré, sans mise à jour, dont le mot de passe est faible, exécutant un modèle local sur des données sensibles, est un risque plus grand que la même donnée envoyée à un fournisseur SOC 2 avec chiffrement au repos. Le local déplace la responsabilité de sécurité vers votre équipe informatique interne ; il ne l'annule pas.

Les journaux applicatifs. L'assistant produit un journal (numéro de ticket, catégorie, latence). Ce journal contient indirectement de l'information sensible et suit les mêmes règles que tout journal métier : conservation limitée, accès contrôlé, purge programmée. Une entreprise qui envoie fièrement ses tickets « en local » puis conserve mille jours de journaux avec le contenu intégral se piège elle-même.

Les sauvegardes. Le contenu des postes est sauvegardé, parfois hors UE selon les prestataires. Une donnée « qui reste sur le poste » finit dans le cloud du sauvegardeur, dans le magasin OneDrive de l'utilisateur, dans le versioning d'un dossier synchronisé. Cartographier ces flux invisibles est un préalable non négociable.

Le modèle lui-même peut fuiter ce qu'il a appris. Un modèle affiné sur 800 tickets clients contient, dans ses poids, une empreinte statistique de ces tickets. Une attaque d'extraction dirigée peut, dans certaines conditions, faire ressortir des noms ou des informations vues à l'entraînement. Ce risque est faible mais réel ; le contre-mesurer suppose de ne pas affiner sur des données brutes contenant des informations identifiantes directes.

L'argumentaire à préparer pour une direction

Le décideur qui doit trancher entre « nuage » et « local » ne veut pas d'un mémorandum juridique. Il veut trois lignes.

1. Ce que le local supprime comme risque : sous-traitance, transfert hors UE, journaux tiers, dépendance d'un fournisseur.
2. Ce que le local fait apparaître comme responsabilité : sécurité du poste, chiffrement des disques, gestion des journaux applicatifs, sauvegardes.
3. Le coût relatif : matériel, exploitation, mise à jour du modèle, absence de facturation à la requête.

Une décision prise sur ces trois lignes est défendable. Une décision prise sur « le local, c'est plus sûr » sans ces nuances est vulnérable au premier audit.

Le local n'est pas une baguette magique

La bonne question n'est pas « local ou nuage ? » mais « quel maillon de la chaîne fait courir le plus grand risque à quelle donnée ? ». Pour un cabinet d'avocats, c'est parfois l'assistant vocal d'un smartphone personnel qui suit l'avocat en réunion, pas le modèle central qu'on choisit avec soin.

En résumé

• Le local supprime le transfert vers un fournisseur externe, ses journaux, sa sous-traitance et sa dépendance opérationnelle.
• Il facilite l'AIPD, la question du transfert hors UE et la clause de non-réutilisation pour l'entraînement.
• Il ne protège pas contre un poste mal sécurisé, un journal applicatif verbeux, une sauvegarde qui remonte dans le cloud du sauvegardeur, ni contre l'extraction depuis les poids.
• L'argumentaire de direction tient en trois lignes : ce que le local supprime, ce qu'il fait apparaître, ce qu'il coûte.

Module suivant : le projet complet, où nous assemblons les neuf modules précédents en un assistant de tickets évalué contre l'API sur 200 exemples réels.