Andy Yen, cofondateur et directeur général de Proton, estime que l’intelligence artificielle et la vie privée peuvent coexister. Lumo, l’assistant IA lancé par Proton le 23 juillet 2025, illustre cependant une réalité moins confortable : ne pas conserver les conversations, chiffrer les échanges enregistrés et protéger les données pendant leur traitement sont trois problèmes différents — auxquels s’ajoute le risque créé par un agent trop puissant.
La promesse est donc crédible comme direction technique, mais elle ne tient pas en un seul slogan. Pour juger une IA dite privée, il faut regarder ce qui est conservé, ce qui peut être lu, ce qui sert à l’entraînement et ce qui se passe pendant l’inférence, c’est-à-dire le moment où le modèle traite la demande.
La promesse d’une IA privée
Andy Yen ne présente pas l’IA comme une technologie que Proton pourrait simplement refuser. Son approche consiste plutôt à proposer une alternative conçue autour de la confidentialité. C’est le rôle de Lumo, présenté par Proton comme un assistant IA axé sur la protection des conversations.
Cette ambition s’inscrit dans l’histoire de Proton : l’entreprise a été fondée en 2014 par des scientifiques travaillant au CERN, avec l’idée de rendre des outils chiffrés utilisables sans transformer chaque utilisateur en spécialiste de la cryptographie. Pour Lumo, le même principe est appliqué à l’IA — avec une difficulté supplémentaire : le service doit traiter la demande sur une infrastructure capable d’exécuter un modèle.
La réponse à la question « l’IA et la vie privée peuvent-elles coexister ? » est donc oui, en principe, à condition de séparer les différentes surfaces de risque. Une conversation peut être supprimée après traitement tout en ayant été visible par l’infrastructure qui l’a traitée. Un historique enregistré peut être protégé par chiffrement sans que cela dise tout de la phase d’inférence. Et un agent peut accéder à des données que le chiffrement ne pourra pas empêcher de divulguer une fois l’autorisation accordée.
Ce que Proton affirme pour Lumo
Proton affirme que Lumo ne conserve pas de journaux de conversations côté serveur et que les échanges et les entrées des utilisateurs ne servent pas à entraîner ses modèles. L’entreprise indique également que les conversations enregistrées utilisent un chiffrement à accès nul : selon cette architecture, Proton ne peut pas les lire.
Lumo est présenté comme fonctionnant avec des modèles open source dans les centres de données européens de Proton. La recherche web est facultative. Proton affirme aussi que les fichiers envoyés pour analyse ne sont pas conservés après leur traitement et propose un mode fantôme dans lequel la conversation disparaît à la fermeture, pour les utilisateurs connectés.
Ces promesses ne désignent pas toutes la même protection. Voici la grille de lecture utile :
| Couche de confidentialité | Ce que Proton affirme pour Lumo | Ce que cela signifie | Conséquence pratique |
| Conservation des conversations | Aucun journal de conversation côté serveur n’est conservé | La politique porte sur la rétention des échanges après leur traitement | Ne pas confondre absence de journal avec invisibilité de la demande pendant l’inférence |
| Historique enregistré | Les conversations sauvegardées bénéficient d’un chiffrement à accès nul | Proton affirme ne pas pouvoir lire ces historiques enregistrés | Cette protection concerne le stockage ; elle ne décrit pas à elle seule le calcul effectué par les GPU |
| Entraînement des modèles | Les conversations et les entrées des utilisateurs ne sont pas utilisées pour entraîner les modèles | Les données ne sont pas présentées comme une matière première pour l’entraînement | Il faut distinguer l’usage pour l’entraînement de l’accès nécessaire au traitement d’une requête |
| Traitement de la requête | Lumo fonctionne dans les centres de données européens de Proton avec des modèles open source | La demande est traitée dans une infrastructure distante, et non directement sur l’appareil de l’utilisateur | La confiance se déplace vers l’architecture et les règles qui entourent cette infrastructure |
| Accès d’un agent | Le chiffrement ne peut pas empêcher un agent autorisé à accéder à un appareil ou à un compte de divulguer des données | Le principal risque peut venir de l’autorisation donnée à l’agent, pas seulement du stockage | Limiter les permissions et ne jamais placer de secrets dans un contexte inutilement large |
La distinction est capitale. Dire que Lumo ne conserve pas les conversations ou ne les utilise pas pour entraîner ses modèles ne revient pas à dire que chaque étape du traitement est cryptographiquement inaccessible à Proton. Ce sont des engagements de produit et de politique distincts, pas une garantie unique qui couvrirait tout le parcours de la donnée.
La confidentialité pendant l’inférence
Le point le plus technique concerne le passage entre la requête et le GPU. Un modèle d’IA doit généralement recevoir des données sous une forme exploitable pour produire une réponse. Le chiffrement des conversations enregistrées protège alors le stockage, mais ne décrit pas automatiquement la manière dont la requête est protégée pendant le calcul.
Lors de l’entretien, Andy Yen a expliqué que l’infrastructure destinée à une protection cryptographique renforcée de Lumo était largement construite, mais que l’interface avec les GPU constituait encore la dernière pièce manquante. Cette déclaration décrit l’état évoqué à ce moment-là ; elle ne permet pas de conclure sur l’état actuel de cette couche.
C’est là que se situe la vraie difficulté. Une politique « zéro conservation » réduit le risque lié aux copies persistantes. Un chiffrement à accès nul protège l’historique enregistré. Mais la confidentialité pendant l’inférence exige de traiter la relation entre l’utilisateur, le serveur et le matériel de calcul comme une couche séparée.
La présentation d’Andy Yen sur la confidentialité de Lumo expose directement la position de Proton et ses principes de conception. Elle doit être comprise comme une présentation de l’entreprise, pas comme un audit indépendant de chaque étape technique.
La limite qu’aucun chiffrement ne peut résoudre
Même une architecture très solide ne peut pas compenser une autorisation dangereuse. Andy Yen souligne qu’un agent ayant accès à la messagerie, aux fichiers ou à d’autres comptes peut divulguer des informations si l’utilisateur lui accorde trop de latitude. Dans ce scénario, le problème n’est plus seulement de protéger une donnée stockée sur un serveur : il faut empêcher une action indésirable réalisée depuis un appareil déjà autorisé.
Cela change la manière d’évaluer les assistants IA capables d’agir. Les questions utiles deviennent très concrètes :
- L’agent peut-il seulement lire, ou aussi envoyer et publier ?
- Ses accès sont-ils limités à une tâche précise ?
- Les identifiants et clés secrètes sont-ils séparés du contexte de conversation ?
- Peut-on révoquer rapidement une permission ?
- Une confirmation humaine est-elle nécessaire avant une action sensible ?
La meilleure encryption du monde ne transforme pas une permission illimitée en permission sûre. Pour les agents, la réduction des droits compte autant que la protection des données au repos.
L’IA locale est-elle plus privée ?
L’IA locale peut réduire l’exposition à un fournisseur distant, puisque l’inférence peut rester sur l’appareil de l’utilisateur. Andy Yen la présente comme une option particulièrement prometteuse à mesure que les téléphones et les ordinateurs gagnent en puissance. Mais « local » ne signifie pas automatiquement « privé ».
Un ordinateur infecté, une application mal conçue, un réseau mal configuré ou un agent connecté à trop de services peuvent toujours exposer les données. Les modèles doivent aussi être téléchargés, mis à jour et utilisés dans un environnement dont la sécurité compte autant que celle du modèle lui-même.
La règle pratique est simple : utilisez si possible un traitement local pour les informations les plus sensibles, mais ne lui confiez pas une confiance aveugle. Pour un service cloud comme Lumo, réduisez les données envoyées, retirez les mots de passe et les clés d’API, examinez les règles de conservation et d’entraînement, puis limitez strictement les intégrations et les permissions.
Pourquoi la demande de confidentialité dépasse les clivages politiques
Andy Yen affirme que l’intérêt pour la confidentialité ne se limite pas à un camp politique. Il dit avoir observé une hausse de la demande sous les présidences de Donald Trump comme sous celle de Joe Biden. Son argument est moins électoral que structurel : les données restent exposées à des décisions et à des rapports de force qui peuvent changer.
Pour Proton, cette lecture soutient une stratégie européenne fondée sur la confiance. Pour l’utilisateur, elle conduit surtout à une conclusion plus terre à terre : la confidentialité n’est pas une préférence réservée à un type de public. C’est une question de contrôle sur des données personnelles, professionnelles ou familiales, quelle que soit l’opinion politique de leur propriétaire.
Ce qu’il faut retenir
Lumo n’est pas la preuve qu’une IA cloud peut être rendue absolument privée. C’est plutôt un cas intéressant pour comprendre les différentes couches qui composent cette promesse. Proton affirme réduire la conservation, protéger les conversations enregistrées par un chiffrement à accès nul, exclure les échanges de l’entraînement et traiter les requêtes dans ses centres de données européens. Andy Yen a toutefois décrit, lors de l’entretien, l’interface GPU d’une protection cryptographique renforcée comme incomplète à ce moment-là.
Pour évaluer une IA privée, ne vous arrêtez donc pas à la formule « aucun journal ». Vérifiez séparément la conservation, le stockage, l’entraînement, le traitement pendant l’inférence et les permissions accordées aux agents. Si une donnée serait catastrophique une fois divulguée, le choix le plus prudent reste de ne pas l’envoyer — ou de la traiter localement dans un environnement réellement maîtrisé.
La vie privée de l’IA n’est pas un interrupteur. C’est une chaîne : la protection finale dépend du maillon le plus faible.
