Une règle est une promesse. Une architecture est un fait.

Peu de métiers ont autant écrit sur la protection de leurs données que ceux qui vivent du secret. Un médecin, un avocat, un expert-comptable, un banquier, un notaire, une agence qui détient les accès et les comptes de ses clients : chacun a un code, un ordre ou un régulateur, une obligation de confidentialité que le droit pénal sanctionne [1], et depuis 2018 un règlement européen qui lui impose de ne confier ses données qu’à des sous-traitants « présentant des garanties suffisantes » [2]. Depuis deux ans, l’intelligence artificielle a produit à son tour des guides, des chartes, des recommandations d’autorités, des clauses types.

Posez pourtant à l’une de ces structures une question simple : quand un collaborateur soumet un document à un outil d’intelligence artificielle, sur quelle machine le modèle s’exécute-t-il, et qui la possède ? Dans la plupart des cas, personne ne sait. La réglementation est dense. L’architecture est absente.

Ce texte porte sur cet écart, et sur la raison pour laquelle il ne se comble pas avec une règle de plus.

Le cadrage existe, et il est fait par les bonnes personnes.

Il faut commencer par dire ce qui va bien. Les guides publiés par les ordres et les régulateurs ces deux dernières années sont, pour la plupart, des documents sérieux. Ils interdisent de transmettre à un outil d’intelligence artificielle le nom d’un client ou d’un patient, une information confidentielle, une pièce du dossier. Ils imposent la vérification de chaque sortie. Ils listent les critères d’un outil acceptable : lieu d’hébergement, nationalité du prestataire, chiffrement, absence de réutilisation des données. Ils recommandent une charte interne.

Des délégués à la protection des données, des juristes spécialisés, des responsables de conformité passent leurs semaines à écrire ce qu’une organisation a le droit de faire, ce qu’elle doit interdire, ce qu’elle doit documenter. Ce travail est nécessaire, et chez Helmo Solutions, on essaie d’y contribuer à notre place, avec des textes qui traduisent ces cadres en décisions concrètes. On n’est pas juristes. Notre métier est ailleurs, et c’est de là que vient ce texte.

Car tout ce cadrage partage une nature. Une charte, une politique de confidentialité, une clause de non-réutilisation des données, une attestation d’hébergement en Europe : ce sont des engagements. Des textes qui décrivent ce qui doit se passer. Ils obligent celui qui les signe. Ils ne décident pas de ce qui se passe réellement dans la machine.

Une règle est une promesse. Une architecture est un fait.

Une règle dit ce qui sera fait des données une fois qu’elles sont quelque part. Elle demande qu’on fasse confiance à celui qui les détient : à son équipe de sécurité, à ses sous-traitants, à sa juridiction, à chaque décision future qu’il prendra sur son activité.

Cette confiance se casse de quatre façons qui n’ont rien à voir avec la bonne foi de celui qui a signé. Une intrusion. Un rachat par une société d’un autre pays. Un raccourci de conformité pris un jour de charge. Une injonction d’une autorité étrangère, que le droit américain autorise depuis 2018 indépendamment du lieu où le serveur se trouve [3]. Dans les quatre cas, la clause est toujours là. Elle n’a simplement rien empêché.

Il y a une chose que ces clauses ont en commun : aucune ne peut être vérifiée par celui qui les signe. « Nous ne réutilisons pas vos données pour entraîner nos modèles » est une phrase que vous lisez ; vous n’avez aucun moyen de la tester. Le règlement vous demande des garanties suffisantes, et vous ne pouvez produire, si on vous le demande, qu’une déclaration de votre prestataire.

Une architecture décide autre chose : si les données sont quelque part, tout court. Un serveur qui n’a jamais reçu le dossier ne peut pas le divulguer, quoi qu’il arrive à son propriétaire. Et cela, vous pouvez le vérifier vous-même.

Un métier dont l’exercice consiste à distinguer un fait établi d’une déclaration devrait être le premier à voir la différence. Un contrat avec un éditeur est une déclaration. Une machine dans vos murs, sans connexion sortante, est un fait.

Le réflexe existe ailleurs. Il n’est pas encore entré chez vous.

Dans les métiers d’où vient l’équipe de Helmo Solutions, l’infrastructure d’intelligence artificielle, la vidéosurveillance, les systèmes de permissions, une règle tient pour acquise : tout serveur qu’on ne contrôle pas est un risque par défaut, et la première question posée à un outil n’est pas « que promet l’éditeur » mais « peut-on l’exécuter chez nous ». Cette culture a un nom, l’auto-hébergement, et un écosystème : des logiciels dont le code est public, qu’on installe sur ses propres machines, qu’on audite, et qui continuent de fonctionner le jour où l’éditeur disparaît.

Cet écosystème couvre aujourd’hui l’essentiel de ce qu’une organisation demande à l’intelligence artificielle. Transcrire une consultation ou un rendez-vous. Résumer une chaîne de courriels. Chercher dans ses propres archives. Extraire les dates et les montants d’un jeu de pièces. Pseudonymiser un document avant de le partager. Pour chacune de ces tâches, il existe des outils dont le code est ouvert et des modèles qui tournent sur une machine de bureau, sans envoyer un octet dehors.

Les professions du secret, elles, sont restées dans la culture inverse : l’outil est un service qu’on souscrit, les données vont où l’éditeur les met, et la protection tient dans le contrat. Ce n’est pas un défaut de sérieux, c’est un défaut d’exposition. Personne ne leur a montré que l’autre culture existe, qu’elle est mature, et qu’elle répond à leur obligation de secret mieux que n’importe quelle clause. C’est, à notre sens, la conscience qui manque, et elle manque précisément aux métiers qui en auraient le plus l’usage.

Pourquoi ces métiers, plus que d’autres.

Deux raisons font que l’écart entre règle et architecture coûte plus cher à un professionnel tenu au secret qu’à une entreprise ordinaire.

La première est juridique. Le secret professionnel ne se contractualise pas. Une clause de confidentialité signée par un éditeur engage l’éditeur ; elle ne transforme pas une divulgation en non-divulgation. Celui qui a révélé une information couverte par le secret l’a révélée, quelle que soit la qualité du contrat qui devait l’en protéger [1].

La seconde est humaine. Une entreprise qui subit une fuite gère un incident. Un médecin, un avocat, un comptable qui a envoyé un dossier à un serveur qu’il ne contrôle pas répond personnellement, devant son ordre ou son régulateur, de ce qui en a été fait. La promesse de l’éditeur ne comparaît pas à sa place.

Ce que « en local » veut dire, et ce que ça ne veut pas dire.

Le mot est devenu un argument de plaquette. Il faut donc le définir.

Un déploiement local, au sens où on le pratique chez Helmo Solutions, réunit trois conditions. Le modèle s’exécute sur une machine que l’organisation possède ou contrôle. Aucune copie des données ne transite par un serveur tiers : ni les documents, ni les requêtes, ni les journaux techniques, ni les sauvegardes « de confort » chez l’éditeur. Et l’organisation peut le vérifier elle-même, en débranchant le réseau et en constatant que tout fonctionne encore.

Ce que ce n’est pas mérite d’être dit aussi. « Hébergé en Europe » ne suffit pas : un serveur mutualisé d’un éditeur, situé en Europe, reste un serveur que vous ne contrôlez pas, et la nationalité de l’entreprise qui l’opère compte autant que le lieu. Ce qui compte est de savoir qui possède la machine, qui détient les clés, et si elle est partagée. « Chiffré de bout en bout » n’est pas local : le modèle doit lire le texte en clair pour travailler, et il le fait là où il s’exécute. « Vos données ne servent pas à l’entraînement » n’est pas local : c’est précisément la promesse que vous ne pouvez pas vérifier.

Il y a une manière simple de le formuler. Dans un déploiement local, votre fournisseur d’intelligence artificielle, c’est vous.

Poids ouverts et licence ouverte, ce sont deux questions.

Devenir son propre fournisseur suppose de pouvoir télécharger un modèle et l’exécuter. Plusieurs le permettent aujourd’hui. Mais « ouvert » recouvre deux choses distinctes, et il faut poser les deux questions.

La première est technique : les poids du modèle sont-ils publiés ? Si oui, le modèle peut tourner sur une machine que vous possédez, sans appel réseau. C’est ce qu’on appelle un modèle à poids ouverts.

La seconde est juridique : sous quelle licence ? Certains modèles à poids ouverts sont publiés sous licence Apache 2.0, qui autorise l’usage, la modification et la redistribution sans condition de taille ni de secteur [4]. D’autres sont publiés sous une licence propre à l’éditeur, qui restreint certains usages et peut changer d’une version à la suivante. L’Open Source Initiative a publié en octobre 2024 une définition de l’intelligence artificielle open source précisément pour séparer les deux [5].

Pourquoi s’en soucier : parce que la licence est la seule promesse qui subsiste dans un déploiement local, et qu’il vaut mieux qu’elle soit irrévocable. Un modèle sous Apache 2.0, téléchargé aujourd’hui, restera utilisable dans dix ans aux mêmes conditions, quoi qu’il arrive à son éditeur. Vous figez la version, vous l’auditez, vous la documentez dans votre registre, et personne ne peut vous la retirer. C’est une garantie d’architecture, pas de contrat.

Ce que ça coûte, et pourquoi c’est notre métier.

Il faut être honnête sur le prix, sinon ce texte est une plaquette de plus.

Un déploiement local a un coût réel : une machine dimensionnée pour le modèle, sa sauvegarde, ses mises à jour, le contrôle de son accès physique. Les modèles à poids ouverts ont quelques mois de retard sur les meilleurs modèles fermés [6]. Sur les tâches d’une organisation, trier des échanges, extraire les dates d’un jeu de pièces, préparer une synthèse sourcée, ce retard ne se voit pas. Mais le risque n’a pas disparu, il a changé de nature : d’un risque juridique que vous ne maîtrisez pas vers un risque d’exploitation que vous maîtrisez.

C’est aussi la raison pour laquelle la culture de l’auto-hébergement n’est pas entrée toute seule dans ces métiers. Elle suppose quelqu’un qui sache dimensionner la machine, choisir le modèle et sa licence, l’installer sans connexion sortante, journaliser les accès, écrire la procédure de mise à jour, et remettre à l’organisation la documentation qui lui permet ensuite de se passer de lui. Une structure de deux à vingt personnes n’a pas cette personne, et n’a pas à l’avoir.

C’est exactement le travail qu’on fait chez Helmo Solutions : sur votre matériel, ou sur un serveur dédié hébergé en Europe, un par client, que l’on opère pour vous. On vient d’entreprises où l’infrastructure d’intelligence artificielle et les systèmes de permissions étaient le produit lui-même. Ce savoir-faire ne s’écrit pas dans une charte. Il s’installe.

La règle dit ce qui doit se passer. L’architecture fait que ça se passe.

Il ne s’agit pas d’opposer les deux. Une organisation a besoin des deux, et dans cet ordre.

La charte fixe les usages autorisés, forme les collaborateurs, documente les décisions, prévoit le contrôle. Sans elle, l’architecture la plus étanche est utilisée n’importe comment. C’est le travail de ceux qui cadrent les professions, et il est bien fait.

L’architecture, elle, fait que la charte n’a pas besoin d’être crue. Quand les données ne sortent pas de vos murs, l’interdiction d’envoyer un dossier à un serveur tiers n’est plus une règle à respecter : c’est un état de fait. Personne ne peut l’enfreindre un soir de charge, personne ne peut la renégocier, aucune juridiction étrangère ne peut la contourner.

Les métiers du secret ont fini d’écrire leurs règles, ou presque. Ce qui leur reste à faire ne s’écrit pas. Ça se construit, une machine à la fois, dans chaque structure qui décide que ses dossiers sont protégés par la façon dont elle est équipée, et non par ce qu’on lui a promis.