Des instructions de montage consultées la veille à travers des lunettes connectées, qu’on retrouve le lendemain sur son ordinateur portable, sans rien avoir demandé. Voilà la scène que Google DeepMind met en avant pour présenter, le 23 septembre, la nouvelle mémoire persistante de sa plateforme Private AI Compute.
La promesse est ambitieuse : la mémoire part dans le cloud, tout en restant aussi protégée que si elle n’avait jamais quitté votre téléphone. Aucun utilisateur ne peut pourtant le constater par lui-même. Il faut croire l’éditeur sur parole, et sur la donnée la plus sensible qu’un assistant IA puisse accumuler.
Un coffre dans le cloud, des clés dans votre poche
Google DeepMind décrit un mécanisme en trois temps. Chaque utilisateur dispose d’une base de données dédiée, chiffrée, dont les clés sont dérivées de ses propres appareils et, selon l’éditeur, conservées exclusivement sur eux. Personne d’autre n’y aurait accès, « pas même Google ».
Quand le modèle a besoin d’un souvenir pour répondre, l’appareil ouvre un canal authentifié et chiffré vers une enclave sécurisée (une zone de calcul isolée au niveau matériel). La donnée y est déchiffrée en mémoire isolée, le temps de traiter la requête. Le nouveau contexte est enregistré, puis tout est rechiffré aussitôt.
Sur le papier, l’architecture est soignée. Elle répond aussi à une limite bien réelle : jusqu’ici, Private AI Compute comme les solutions comparables du secteur fonctionnaient en mode « stateless » (sans état), en effaçant tout à la fin de chaque tâche. Google juge lui-même insuffisant le bricolage habituel, qui consiste à faire tenir à l’IA une liste de faits et de préférences sur vous.
Le moment où la donnée redevient lisible
Regardez de près le cycle décrit. Vos clés restent sur l’appareil, soit. Mais pour que le modèle exploite votre mémoire, celle-ci doit bien être déchiffrée quelque part, et ce quelque part se trouve dans un centre de données de Google, sur du matériel de Google, exécutant du code choisi par Google.
Toute la promesse repose donc sur une hypothèse : l’enclave fait exactement ce qu’on dit qu’elle fait. Le code qui y tourne ne copie rien, ne journalise rien, ne garde rien au-delà de la requête. Le chiffrement protège la donnée au repos et en transit, l’isolation matérielle la protège pendant le calcul. Aucun des deux ne vous permet, à vous, de vérifier ce qui se passe dans la boîte.
La confiance ne disparaît pas, elle se déplace. Elle quitte les conditions d’utilisation pour se loger dans une puce et dans un binaire.
Une mémoire qui dresse votre portrait
Une requête isolée révèle peu de chose. Une mémoire persistante, par construction, accumule : vos conversations reprises d’un appareil à l’autre, ce que vous avez regardé, ce que vous préparez, vos habitudes. Plus l’assistant devient utile, plus ce dépôt ressemble à un portrait complet de son propriétaire.
L’essor des agents IA rend ce dépôt plus précieux encore. Ces assistants agissent désormais en votre nom, réservent, rédigent, achètent, et leur pertinence dépend de ce qu’ils retiennent. Leur mémoire devient leur actif central, donc la cible la plus rentable pour quiconque voudrait en abuser.
Un point technique aggrave l’enjeu. Dans une architecture stateless, une erreur ou une compromission meurt avec la session. Avec une mémoire qui persiste et se synchronise entre appareils, un contenu malveillant glissé une fois peut ressurgir des semaines plus tard, sur un autre terminal, dans un autre contexte. Le souvenir devient une surface d’attaque durable.
Transparence : un livre blanc ne vaut pas un audit
Google a anticipé l’objection. L’éditeur écrit que la confiance de l’utilisateur dans la confidentialité du système compte autant que la technique, et qu’elle commence par la transparence. Il publie pour l’occasion une version mise à jour de son livre blanc technique.
Le réflexe est bon, et il faut le saluer. Mais un document qui décrit une architecture reste une description. Pour qu’une telle promesse pèse, il faut pouvoir établir que le code déployé en production est bien celui qui a été décrit, et que des tiers indépendants peuvent le contrôler dans la durée. Les éléments publiés à ce stade ne suffisent pas à trancher ce point pour l’utilisateur final.
Apple a placé la barre plus haut avec son Private Cloud Compute : les iPhone n’envoient leurs requêtes qu’aux serveurs dont le logiciel figure dans un journal public des versions déployées, et un environnement de recherche virtuel permet aux chercheurs en sécurité de faire tourner ce logiciel pour l’inspecter. C’est à cette aune que la mémoire de Google sera jugée.
D’autres zones restent à éclaircir. Si les clés sont dérivées des appareils, que devient la mémoire quand vous les perdez tous ? Comment l’effacer pour de bon, et comment savoir qu’elle l’a été ? Qui décide de ce qui mérite d’être retenu : vous, ou le modèle ?
Clés, code, effacement : trois exigences avant d’y confier ses souvenirs
Si vous concevez des agents ou des produits qui s’appuient sur une mémoire à long terme, l’annonce de Google fixe un étalon utile. Séparer strictement le stockage chiffré du calcul, laisser la garde des clés à l’utilisateur, déchiffrer au dernier moment et le moins longtemps possible : ces principes valent pour n’importe quelle architecture, hébergée chez Google ou ailleurs.
Côté utilisateur ou décideur, trois questions permettent de juger ce type d’offre sans se laisser porter par le vocabulaire :
- qui détient réellement les clés, et peut-on le démontrer ;
- quel code s’exécute là où la donnée est déchiffrée, et qui peut le vérifier ;
- que peut-on consulter, corriger et supprimer de ce que l’assistant a retenu.
Google a résolu la moitié du dilemme qu’il décrit lui-même : donner de la continuité à un assistant sans renoncer à la confidentialité. Il lui reste l’autre moitié, celle qui permettrait à chacun de s’en assurer sans devoir croire l’éditeur. Tant que cette preuve manquera, la mémoire la plus intime de nos assistants restera gardée par une promesse.
Sources
- Private AI Compute
- Private Cloud Compute
- environnement de recherche virtuel
- Advancing Private AI Compute with secure, server-side memory
Ils m’ont fait confiance
« Il ne se contente pas de corriger les symptômes, il cherche à comprendre l'origine des problèmes et à sécuriser les modifications effectuées. J'ai réellement le sentiment d'avoir trouvé un développeur qui comprend à la fois la technique et les enjeux globaux du projet. »
Évaluation client · projet WordPress · septembre 2026
5,0/5 sur 16 évaluations
Faire appel à mes services →
