Zep vs RGPD : ce que votre DSI doit savoir avant de déployer

Zep est excellent. Mais est-il déployable sans risque en France ?

Zep (Getzep) est devenu l'une des références techniques pour la mémoire d'agents IA. Graph de connaissances, extraction automatique d'entités, recherche hybride dense et sparse, résumés de sessions — son architecture est impressionnante et sa communauté active. Pour un CTO ou un architecte IA, c'est un choix rationnel.

Mais pour un DSI d'une entreprise française traitant des données utilisateurs — collaborateurs, clients, prospects — une question précède toute décision de déploiement en production : où les données sont-elles stockées ? Et plus précisément : sont-elles hébergées sur le territoire de l'Union européenne, ou transitent-elles vers des serveurs soumis à la juridiction américaine ?

Ce n'est pas une question anodine. Depuis l'arrêt Schrems II de la CJUE en 2020, le transfert de données personnelles vers les États-Unis sans garanties suffisantes expose l'entreprise responsable de traitement à des sanctions significatives, pouvant atteindre 4 % du chiffre d'affaires mondial sous le RGPD. L'analyse qui suit est destinée aux équipes techniques et juridiques qui évaluent Zep pour un déploiement en contexte français ou européen.

Architecture Zep : hébergement US par défaut

Zep propose deux modes de déploiement : Zep Cloud, leur offre SaaS managée, et Zep Open Source que vous hébergez vous-même. L'offre Cloud est celle qui pose problème sur le plan RGPD.

Zep Cloud est hébergé aux États-Unis. Les données qui transitent par leur API — mémoires d'agents, entités extraites des conversations, embeddings, métadonnées de sessions — sont stockées sur des serveurs américains. À ce jour, Zep ne publie pas d'option EU data residency pour leur offre Cloud, ni de région EU-only sélectionnable depuis leur dashboard.

Concrètement, cela signifie que chaque appel API depuis votre backend européen constitue un transfert UE → US au sens de l'article 44 du RGPD. Ce transfert n'est pas illicite en soi — des mécanismes existent pour le légaliser — mais il crée des obligations documentaires et juridiques que beaucoup d'équipes sous-estiment.

Les données concernées par ce transfert incluent typiquement : le contenu des conversations (mémoires), les entités extraites (noms, organisations, lieux, préférences), les vecteurs d'embedding associés, les identifiants utilisateurs, et les horodatages de session. Ces éléments constituent des données personnelles dès lors qu'ils permettent d'identifier un utilisateur — ce qui est presque toujours le cas en production B2B ou B2C.

BYOC (Bring Your Own Cloud) : une option, mais lourde

Zep propose une option "Bring Your Own Cloud" (BYOC) à destination de ses clients Enterprise. Le principe : déployer Zep dans votre propre infrastructure cloud — AWS, GCP ou Azure — dans la région de votre choix. Si vous choisissez une région EU (par exemple eu-west-1 en Irlande ou eu-central-1 à Francfort), les données restent sur le sol européen et le problème de transfert est résolu.

Avantages du BYOC : contrôle total sur la localisation des données, conformité RGPD facilitée, possibilité d'isoler l'environnement dans votre VPC, intégration avec vos politiques IAM et vos outils de supervision internes.

Inconvénients réels : le BYOC n'est pas une installation en un clic. Il requiert une équipe DevOps capable de déployer et maintenir une infrastructure Kubernetes ou ECS, de gérer les mises à jour de l'application Zep, de superviser les bases de données PostgreSQL/pgvector sous-jacentes, et de s'assurer de la continuité de service. Pour une équipe de 1 à 10 personnes — ce qui représente la majorité des startups et scale-ups qui évaluent Zep — le BYOC génère un coût opérationnel disproportionné.

De plus, le BYOC Zep est réservé à l'offre Enterprise, dont la tarification n'est pas publique et nécessite une négociation commerciale. Cela allonge considérablement le cycle d'évaluation pour des équipes qui souhaitent simplement passer en production rapidement.

Analyse RGPD pour un DSI

Passons en revue les obligations concrètes créées par l'utilisation de Zep Cloud dans un contexte français. Cette analyse suppose que vos agents IA traitent des données d'utilisateurs identifiables — ce qui est le cas dans la quasi-totalité des déploiements en production.

Qualification juridique

Les mémoires stockées dans Zep contiennent des données personnelles au sens de l'article 4(1) du RGPD : informations relatives à des personnes identifiées ou identifiables. Préférences d'un utilisateur, historique de conversation, comportements, contexte professionnel — tout cela constitue un traitement de données personnelles dès lors qu'un user_id ou tout autre identifiant indirect est associé.

Dans ce cadre, Zep devient un sous-traitant au sens de l'article 28 RGPD, et votre entreprise reste le responsable de traitement. C'est vous qui êtes exposé en cas de contrôle CNIL ou de plainte d'un utilisateur.

Obligations découlant du transfert hors UE

Le transfert vers les serveurs US de Zep Cloud nécessite l'un des mécanismes de l'article 46 RGPD. En pratique, cela signifie des Standard Contractual Clauses (SCCs) signées avec Zep, accompagnées d'un Transfer Impact Assessment (TIA) documenté. Ce TIA doit évaluer si les SCCs offrent une protection suffisante compte tenu du droit américain — et notamment de la section 702 du FISA (Foreign Intelligence Surveillance Act), qui autorise des injonctions gouvernementales aux fournisseurs US pour accéder aux données, y compris celles d'étrangers.

La CJUE a précisément jugé dans Schrems II que cette disposition du droit américain pouvait rendre les SCCs insuffisantes dans certains cas. L'autorité de protection des données autrichienne (et depuis lors plusieurs autres autorités EU) a appliqué ce raisonnement pour interdire l'utilisation de services américains dans des cas similaires.

Questions à poser à Zep avant de signer

• Disposez-vous d'un DPA (Data Processing Agreement) Art. 28 RGPD disponible pour signature ?
• Où sont précisément hébergées les données en mode Cloud ? Dans quelle région AWS/GCP ?
• Pouvez-vous garantir la suppression complète des données d'un utilisateur spécifique en 72 heures, sur demande ?
• Êtes-vous soumis au FISA 702 ou à des injonctions CLOUD Act équivalentes ?
• Disposez-vous d'un mécanisme de notification de violation de données conforme à l'Art. 33 RGPD (72h) ?

Ce qu'un DSI doit vérifier avant de signer

Avant d'autoriser l'intégration d'une API mémoire tierce dans vos systèmes de production, voici les points de contrôle minimum à valider avec votre équipe juridique et votre DPO :

• ☐DPA Art. 28 disponible et signé. Sans DPA signé, vous ne pouvez légalement pas sous-traiter le traitement de données personnelles à ce prestataire.
• ☐Données hébergées en UE — ou SCCs + TIA documenté. Si le prestataire héberge hors UE, exigez les SCCs en version modulaire (2021) et réalisez un TIA formalisé.
• ☐Mécanisme d'effacement par user_id en production. Le droit à l'effacement (Art. 17 RGPD) s'applique. Vous devez pouvoir effacer toutes les données d'un utilisateur spécifique — mémoires, entités, embeddings — en un seul appel ou avec une procédure documentée.
• ☐Logs d'accès disponibles pour audit. En cas de contrôle, vous devez pouvoir produire un registre des traitements conforme à l'Art. 30 RGPD, incluant les flux vers ce sous-traitant.
• ☐Support de la procédure de notification de violation (Art. 33, 72h). Si une violation de données survient chez le sous-traitant, il doit vous notifier sans délai pour vous permettre d'informer la CNIL dans le délai légal de 72 heures.

Alternative EU-native : Kronvex

Si votre contrainte principale est la conformité RGPD sans charge opérationnelle, Kronvex a été conçu pour répondre précisément à ce cas d'usage : une API de mémoire persistante pour agents IA, hébergée en Europe, avec tous les mécanismes de conformité intégrés dès la première ligne de code.

• Frankfurt (AWS eu-central-1) — aucun transit hors UE, résidence des données certifiable
• DPA Art. 28 disponible pour signature sur simple demande à [email protected]
• Effacement complet en 1 appel : DELETE /api/v1/agents/{id}/memories/user/{user_id} — suppression de toutes les mémoires, entités et embeddings associés à un utilisateur
• API REST simple, SDK Python et Node disponibles, intégration en moins d'une heure
• Pas d'infrastructure à maintenir — SaaS managé, disponibilité 99.9%, mises à jour transparentes
• Tarification prévisible : depuis €49/mois, sans frais cachés sur les appels vectoriels

Questions fréquentes des DSI et DPO