Contrat de sous-traitance des données (DPA)

Version : 1.8
Date d’entrée en vigueur : 16 octobre 2026, pour toute souscription conclue à compter de cette date. Pour les Clients ayant souscrit avant cette date, la présente version s’applique à la date prévue par l’article 16 des CGV (premier jour du Mois de facturation suivant l’expiration du préavis de trente (30) jours courant à compter de sa notification ou, pour les modifications que cet article soumet à acceptation expresse, date de cette acceptation, et au plus tôt ce même premier jour) ; la version qu’ils ont acceptée continue de s’appliquer jusque-là.
Dernière mise à jour : 16 octobre 2026

1. Objet et identification des parties

1.1 Identification du Sous-traitant

MSPLR, éditrice de la marque déposée PersoIA (ci-après « le Sous-traitant » ou « PersoIA »)

• Raison sociale : MSPLR
• Marque commerciale : PersoIA (marque déposée)
• Forme juridique : Société par actions simplifiée (SAS)
• Siège social : 127 Rue Marcel Sembat, 33130 Bègles
• RCS : Bordeaux 105 591 986 (immatriculée le 04/06/2026)
• TVA intracommunautaire : FR63105591986
• Capital social : 1 000 €
• Représentée par : Pierre MERLE, Président
• Contact protection des données : dpo@persoia.com

1.2 Identification du Responsable de traitement

Le Client (ci-après « le Responsable de traitement »)

• Tel que désigné dans le contrat principal (Conditions Générales de Vente ou contrat de service signé entre les parties)
• Représenté par la personne dûment habilitée à signer le contrat principal

1.3 Articulation contractuelle

Le présent contrat de sous-traitance des données (ci-après « DPA ») fait partie intégrante du contrat principal (Conditions Générales de Vente — CGV, ou contrat de service spécifique) conclu entre le Responsable de traitement et le Sous-traitant. En cas de contradiction sur les sujets liés à la protection des données à caractère personnel, les stipulations du présent DPA prévalent sur celles du contrat principal.

Conformément à l’article 20.2 des CGV, le présent DPA prévaut sur les CGV pour ce qui concerne le traitement des métadonnées techniques d’usage et de consommation décrites au §3.3.

Le présent DPA a pour objet d’encadrer le traitement des données à caractère personnel effectué par le Sous-traitant pour le compte du Responsable de traitement, conformément à l’article 28 du RGPD.

1.4 Répartition des rôles

PersoIA agit en qualité de sous-traitant, pour le compte du Responsable de traitement, pour les Données Client : les contenus que le Responsable et ses Utilisateurs soumettent au Service, notamment les conversations, les Artefacts générés, les documents indexés, les enregistrements et transcriptions de visioconférence et les comptes rendus de réunion. PersoIA agit également en qualité de sous-traitant pour la création, la gestion et la désactivation des Comptes, que décide l’Administrateur Client dans les conditions des CGU. Seuls ces traitements, ainsi que la mesure de la consommation technique décrite au §3.1, relèvent du présent DPA.

PersoIA agit en qualité de responsable de traitement distinct, pour ses propres finalités et au titre de ses propres obligations, pour :

• la sécurité des accès au Service (authentification des Utilisateurs) ;
• la conservation des données d’identification au titre des obligations applicables aux hébergeurs (loi n° 2004-575 du 21 juin 2004 pour la confiance dans l’économie numérique, article 6, dans sa rédaction en vigueur, et décret n° 2021-1362 du 20 octobre 2021 pris pour son application), que PersoIA applique à son Service (séquestre, §10.3), sur le fondement d’une obligation légale (article 6.1.c du RGPD) et, à titre subsidiaire, de son intérêt légitime à pouvoir répondre aux réquisitions des autorités (article 6.1.f du RGPD) ;
• le journal des connexions (adresse IP et date de chaque connexion), conservé au titre de la même obligation (article 6.1.c du RGPD) ; son exploitation pour la sécurité du Service repose sur l’intérêt légitime de PersoIA (article 6.1.f du RGPD) ;
• la facturation, le paiement et la gestion du contrat, y compris la conservation des factures et du journal des consentements (la mesure de la consommation technique prévue au §3.1, dernier tiret, restant régie par le présent DPA conformément à l’article 20.2 des CGV) ;
• le traitement des demandes adressées au support, notamment par e-mail à support@persoia.com (Annexe 2) ;
• la sécurité du Service et la prévention de la fraude.

Ces traitements sont décrits dans la Politique de confidentialité. Ils ne relèvent pas des instructions du Responsable de traitement et ne donnent à PersoIA aucun droit d’accès au contenu des Données Client. Une demande de support ne contient de Données Client que si son auteur en reprend dans sa demande ou ses pièces jointes ; PersoIA ne les utilise alors que pour traiter cette demande.

Les Parties ne sont pas responsables conjoints au sens de l’article 26 du RGPD : chacune détermine seule les finalités et les moyens des traitements dont elle est responsable. Pour les traitements dont elle est responsable, PersoIA fournit aux Utilisateurs l’information prévue aux articles 13 et 14 du RGPD par sa Politique de confidentialité, accessible à la création du Compte. Le Responsable de traitement informe ses Utilisateurs que leurs données d’identification sont communiquées à PersoIA pour l’ouverture de leur Compte et met cette politique à leur disposition.

1.5 Obligations et droits du Responsable de traitement

Le Responsable de traitement détermine les finalités des traitements qu’il confie à PersoIA, donne les instructions documentées, veille à la licéité des données qu’il injecte dans le Service (§3.3) et répond aux demandes des personnes concernées. Il dispose des droits d’instruction, d’information, d’opposition (§4.4) et d’audit (article 7).

2. Définitions

Les termes utilisés dans le présent DPA ont le sens qui leur est donné à l’article 4 du RGPD. À titre indicatif et non limitatif :

• Données à caractère personnel : toute information se rapportant à une personne physique identifiée ou identifiable.
• Traitement : toute opération ou ensemble d’opérations effectuées sur des données à caractère personnel (collecte, enregistrement, organisation, conservation, modification, extraction, consultation, utilisation, communication, diffusion, rapprochement, limitation, effacement ou destruction).
• Responsable de traitement : la personne physique ou morale qui détermine les finalités et les moyens du traitement.
• Sous-traitant : la personne physique ou morale qui traite des données à caractère personnel pour le compte du Responsable de traitement.
• Sous-traitant ultérieur : tiers engagé par le Sous-traitant pour exécuter tout ou partie des activités de traitement pour le compte du Responsable.
• Personne concernée : la personne physique à laquelle se rapportent les données.
• Violation de données à caractère personnel : violation de la sécurité entraînant, de manière accidentelle ou illicite, la destruction, la perte, l’altération, la divulgation non autorisée ou l’accès non autorisé à des données.
• Instructions documentées : instructions écrites du Responsable de traitement, le contrat principal et le présent DPA valant instructions initiales.
• RGPD : Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016.
• Données Client : ensemble des données injectées par le Client ou ses Utilisateurs dans le Service (prompts, fichiers, historiques de conversation, paramètres), au sens de l’article 2 des CGV, ainsi que les Artefacts générés, les documents indexés, les enregistrements et transcriptions de visioconférence et les comptes rendus de réunion.
• Artefact généré : fichier produit par le modèle d’IA en réponse à une demande du Client ou de ses Utilisateurs, au sens de l’article 2 des CGV.
• Utilisateur, Compte, Administrateur Client : au sens des Conditions Générales d’Utilisation (CGU). L’Administrateur Client agit pour le compte du Responsable de traitement.
• Clôture du Compte : effacement du Compte à la demande de l’Utilisateur ou, pour un Compte qui n’a pas été effacé, fin du contrat du Client. Un Compte désactivé par l’Administrateur Client n’est pas clos : ses données d’identification restent dans le Service tant qu’il peut être réactivé, et au plus tard jusqu’à la fin du contrat.
• Séquestre : conservation chiffrée, à accès restreint, des données d’identification que la loi impose à PersoIA de conserver après la clôture d’un Compte ou la fin d’un contrat (§10.3).
• Gel juridique : mesure par laquelle PersoIA suspend l’effacement et la purge de données déterminées le temps d’une procédure (§10.4).
• Métadonnées techniques d’usage et de consommation : données techniques relatives à l’utilisation des ressources de calcul, à l’exclusion de tout contenu des Données Client (voir §3.3). Sont notamment visées les unités de calcul consommées et la distinction entre usage interactif et usage automatisé.

3. Description du traitement

3.1 Finalité du traitement

Le Sous-traitant traite les données à caractère personnel exclusivement aux fins de fourniture du service PersoIA, à savoir :

• la mise à disposition d’une instance d’intelligence artificielle privée (dédiée ou mutualisée selon l’offre souscrite),
• l’hébergement et le traitement des contenus que le Responsable et ses utilisateurs autorisés soumettent à l’instance,
• l’indexation documentaire (RAG — Retrieval-Augmented Generation) lorsque cette fonctionnalité est activée par le Responsable,
• la création, la gestion et la désactivation des Comptes décidées par l’Administrateur Client, et le contrôle de l’accès des Utilisateurs aux Données Client selon les droits qu’il définit (la sécurité des accès et la conservation légale relèvent du §1.4),
• la mesure de la consommation technique, la facturation des dépassements (enveloppe de calcul / Compute Units, option visioconférence) et le maintien de la qualité de service et de l’usage équitable du pool mutualisé. Ce traitement porte exclusivement sur des métadonnées techniques (§3.3) et n’implique aucune consultation du contenu des Données Client.

3.2 Nature des opérations de traitement

Les opérations effectuées par le Sous-traitant comprennent notamment :

• le stockage des données (base SQLite dédiée par tenant, dans laquelle les contenus énumérés à l’Annexe 3 §1 sont chiffrés au repos ; index de recherche des documents indexés, non chiffrés par la clé du tenant ; base de la plateforme, dans laquelle seules les synthèses de documents sont chiffrées par la clé du tenant ; détail à l’Annexe 3 §1),
• la transmission des données entre le terminal utilisateur, l’API et l’instance d’inférence (chiffrement en transit),
• le traitement par modèle de langage open-source exécuté sur l’instance,
• l’indexation vectorielle des contenus RAG le cas échéant,
• la conservation de journaux techniques de fonctionnement de l’instance (le journal des connexions relève du §1.4),
• la sauvegarde des données vers un stockage objet situé en France, dont le chiffrement est décrit à l’Annexe 3 §7,
• la mesure, l’agrégation et la conservation de métadonnées techniques d’usage (comptage de Compute Units, durées d’usage GPU et de visioconférence, comptage de requêtes) aux fins de facturation des dépassements et de régulation de la qualité de service.

3.3 Catégories de données traitées

Les catégories de données traitées sont celles que le Responsable de traitement et ses utilisateurs autorisés soumettent à l’instance PersoIA. À titre indicatif :

• contenus soumis aux conversations IA (texte libre, documents importés pour analyse, prompts) et réponses produites, y compris les Artefacts générés,
• documents indexés, enregistrements et transcriptions de visioconférence et comptes rendus de réunion,
• données des Comptes renseignées par l’Administrateur Client ou l’Utilisateur (nom, prénom, adresse e-mail, téléphone, fonction, rôle), tant que le Compte est actif,
• métadonnées techniques d’usage et de consommation : horodatages de démarrage/arrêt des ressources de calcul, volume de Compute Units consommées, durée d’usage de la visioconférence, nombre et type de requêtes (interactif/automatisé), identifiant technique de l’Utilisateur ou de la clé d’accès programmatique. À l’exclusion de tout contenu des Données Client.

Les données d’identification placées sous séquestre (§10.3), les données d’authentification, le journal des connexions (adresses IP et dates de connexion) et les données de facturation et de contrat, ainsi que les demandes de support, sont traitées par PersoIA en qualité de responsable de traitement (§1.4) et ne relèvent pas du présent DPA.

Le Responsable de traitement reste seul juge des catégories de données effectivement injectées dans l’instance. Il s’engage à ne pas soumettre à l’instance de données dont le traitement par PersoIA n’aurait pas été préalablement encadré juridiquement (notamment données de santé, données pénales, données de mineurs, sauf accord écrit préalable des parties).

3.4 Catégories de personnes concernées

Typiquement :

• les utilisateurs internes du Responsable de traitement (salariés, prestataires, sous-traitants disposant d’un accès),
• les tiers dont les données sont susceptibles d’être incluses dans les contenus soumis à l’instance par le Responsable (clients, partenaires, etc.) — sous la responsabilité du Responsable,
• les participants aux réunions enregistrées ou transcrites à la demande du Responsable.

3.5 Durée du traitement

Le traitement est effectué pendant toute la durée du contrat principal. À l’issue du contrat, et conformément à l’article 10 du présent DPA, les données sont restituées ou supprimées dans un délai de 60 jours suivant la résiliation, sous réserve des conservations légales (§10.3) et du gel juridique (§10.4).

Les métadonnées techniques d’usage et de consommation (§3.3) sont conservées sous forme opérationnelle détaillée pendant 60 jours (notamment pour permettre au Client de contester la consommation facturée), puis sous forme agrégée pour les besoins comptables et statistiques, pour la durée requise par les obligations légales applicables.

4. Obligations du Sous-traitant

Conformément à l’article 28-3 du RGPD, le Sous-traitant s’engage à :

4.1 (a) Agir uniquement sur instruction documentée du Responsable

Le Sous-traitant traite les données à caractère personnel uniquement sur instructions documentées du Responsable de traitement. Le contrat principal et le présent DPA constituent les instructions initiales.

Si le Sous-traitant est tenu, en vertu du droit de l’Union européenne ou du droit français, de procéder à un traitement non couvert par les instructions du Responsable, il informe le Responsable de cette obligation juridique avant le traitement, sauf si le droit applicable interdit une telle information pour des motifs importants d’intérêt public.

Si le Sous-traitant estime qu’une instruction du Responsable constitue une violation du RGPD ou de toute autre disposition du droit de l’Union ou du droit national relative à la protection des données, il en informe immédiatement le Responsable.

Instruction permanente. Le Responsable de traitement donne instruction à PersoIA de donner suite directement aux demandes d’effacement de Compte présentées par ses Utilisateurs (fermeture du Compte, effacement du profil, révocation des accès) et d’en informer l’Administrateur Client.

Conversations d’un Utilisateur dont le Compte est effacé. Lorsqu’un Utilisateur fait effacer son Compte (CGU, section 11), PersoIA ne supprime ni ses conversations ni ses Artefacts générés, qui sont des Données Client. Dès l’exécution de l’effacement, PersoIA en informe les Administrateurs Client actifs par e-mail, en indiquant le nom de l’Utilisateur lorsqu’il est disponible, la référence de la demande et sa date, et en leur rappelant que la personne concernée doit recevoir une réponse dans le délai prévu à l’article 12.3 du RGPD. La demande figure dans l’espace d’administration sous sa référence. À défaut d’Administrateur Client actif, l’information est adressée au contact désigné par le Client au contrat. Le Responsable de traitement donne alors ses instructions depuis l’espace d’administration :

• suppression des conversations et Artefacts générés de cet Utilisateur, exécutée après confirmation ;
• conservation, à laquelle une instruction de suppression peut succéder à tout moment.

Chaque instruction est horodatée et journalisée avec l’identité de l’Administrateur Client qui l’a donnée ; cette trace vaut instruction documentée au sens de l’article 28.3.a du RGPD. À défaut d’instruction du Responsable de traitement, le présent DPA vaut instruction documentée de conserver ces conversations et Artefacts générés jusqu’à la fin du contrat ; ils sont alors supprimés dans les conditions de l’article 10. Le Responsable de traitement, qui fixe la durée de conservation de ces données et répond à la personne concernée (articles 5.1.e et 12.3 du RGPD), peut donner à tout moment une instruction de suppression.

Les documents indexés, les enregistrements et transcriptions de visioconférence et les comptes rendus de réunion ne sont pas concernés par cette décision : ils sont supprimés sur instruction écrite du Responsable adressée à contact@persoia.com ou à dpo@persoia.com, ou à la fin du contrat.

Une instruction de suppression n’est différée qu’en cas de gel juridique, dans les conditions du §10.4.

4.2 (b) Confidentialité des personnes autorisées à traiter les données

Le Sous-traitant garantit que les personnes autorisées à traiter les données à caractère personnel sous son autorité :

• s’engagent à respecter la confidentialité par contrat de travail, accord de non-divulgation (NDA) ou clause spécifique,
• reçoivent la formation nécessaire à la protection des données,
• accèdent aux données uniquement sur le principe du « need-to-know ».

4.3 (c) Sécurité du traitement (art. 32 RGPD)

Le Sous-traitant met en œuvre les mesures techniques et organisationnelles décrites en Annexe 3 du présent DPA, dont notamment :

• chiffrement au repos, par AES-256-GCM, des contenus énumérés à l’Annexe 3 §1, avec une clé de chiffrement (DEK) unique par tenant, elle-même protégée par une clé maîtresse ; les données que ce chiffrement ne couvre pas sont énumérées au même paragraphe,
• isolation des tenants (une base SQLite et un index de recherche distincts par tenant ; contenus énumérés à l’Annexe 3 §1 chiffrés par une clé propre au tenant),
• chiffrement en transit par TLS 1.2 minimum (TLS 1.3 recommandé),
• hébergement exclusif sur datacenters situés en France (OVH et Scaleway),
• authentification forte (JWT à durée limitée + MFA TOTP optionnel pour les comptes administrateurs),
• journalisation des accès et événements sensibles,
• plan de continuité d’activité reposant sur des sauvegardes stockées en France chez OVH, dont le chiffrement est décrit à l’Annexe 3 §7 : réplication continue des bases des tenants (Litestream), copie quotidienne de la base de la plateforme et archive quotidienne des index de recherche des documents indexés, le détail figurant à l’Annexe 3 §7.

Ces mesures sont décrites de façon détaillée à l’Annexe 3 et peuvent évoluer pour maintenir un niveau de sécurité approprié au regard de l’état de l’art, sans toutefois diminuer le niveau de protection.

4.4 (d) Sous-traitance ultérieure

Le Responsable de traitement autorise généralement le Sous-traitant à recourir aux sous-traitants ultérieurs listés en Annexe 2 pour les finalités décrites.

Le Sous-traitant s’engage à :

• conclure avec chaque sous-traitant ultérieur un contrat écrit imposant des obligations équivalentes à celles du présent DPA en matière de protection des données,

• demeurer pleinement responsable, vis-à-vis du Responsable, de l’exécution par le sous-traitant ultérieur de ses obligations,

• notifier au Responsable, au moins 30 jours à l’avance, tout projet d’ajout ou de remplacement d’un sous-traitant ultérieur, par publication sur la page https://www.persoia.com/legal/sous-traitants et notification e-mail aux contacts désignés par le Responsable,

• permettre au Responsable de s’opposer à l’ajout ou au remplacement d’un sous-traitant ultérieur, pour des motifs légitimes liés à la protection des données, par notification écrite adressée au Sous-traitant pendant le préavis de 30 jours. Les Parties recherchent alors une solution pendant la durée restante du préavis.

  Si l’opposition est maintenue à l’expiration du préavis, le Responsable peut résilier le contrat sans pénalité ni indemnité, par simple notification écrite ou depuis son espace d’administration. La résiliation prend effet au plus tard à la date d’entrée en vigueur du changement, ou au terme du Mois de facturation en cours (au sens de l’article 2 des CGV) si celui-ci est antérieur.

  Jusqu’à la prise d’effet de la résiliation ou, si le Responsable n’exerce pas cette faculté, jusqu’au terme du Mois de facturation suivant l’expiration du préavis, le Sous-traitant s’interdit de recourir au sous-traitant ultérieur contesté pour le traitement des données du Responsable qui s’y est opposé. Passé ce terme sans résiliation, le changement s’applique au Responsable comme aux autres clients. Le Sous-traitant n’est en revanche pas tenu de maintenir durablement une configuration technique distincte pour ce seul Responsable au-delà de cette date.

4.5 (e) Assistance pour répondre aux droits des personnes concernées

Le Sous-traitant aide le Responsable, par des mesures techniques et organisationnelles appropriées et dans la mesure du possible, à s’acquitter de son obligation de donner suite aux demandes des personnes concernées exerçant leurs droits (accès, rectification, effacement, limitation, opposition, portabilité — articles 15 à 22 du RGPD).

À cette fin, le Sous-traitant met à disposition du Responsable :

• une fonctionnalité d’export des données utilisateur (format JSON ou équivalent),
• dans l’espace d’administration, la suppression des conversations et Artefacts générés d’un Utilisateur dont le Compte est effacé (§4.1),
• la suppression, sur instruction écrite du Responsable, de données déterminées d’un Utilisateur (§4.1) ; l’effacement de l’ensemble des Données Client en fin de contrat relève du §4.7,
• un point de contact pour les demandes ne pouvant être traitées via l’interface (contact@persoia.com ou dpo@persoia.com).

Les demandes émanant directement des personnes concernées et portant sur des Données Client sont réorientées vers le Responsable de traitement. Les demandes portant sur les données dont PersoIA est responsable de traitement (§1.4), notamment l’effacement d’un Compte, sont traitées directement par PersoIA. Lorsqu’une telle demande porte aussi sur des Données Client, PersoIA en informe sans délai l’Administrateur Client, qui décide (§4.1), et indique à la personne concernée de s’adresser à lui pour ces données.

4.6 (f) Assistance pour la sécurité, la notification de violation, l’AIPD et la consultation préalable

Le Sous-traitant aide le Responsable, compte tenu de la nature du traitement et des informations à sa disposition, à se conformer à ses obligations au titre des articles 32 à 36 du RGPD :

• mise en place et maintien des mesures de sécurité (article 32),
• notification au Responsable de toute violation de données dans les conditions de l’article 5 ci-dessous (article 33),
• communication d’informations utiles à la réalisation d’une analyse d’impact relative à la protection des données (AIPD — article 35),
• assistance à la consultation préalable de l’autorité de contrôle si nécessaire (article 36).

4.7 (g) Sort des données à la fin du contrat

Au choix du Responsable de traitement et selon les modalités décrites à l’article 10 du présent DPA, le Sous-traitant supprime ou restitue toutes les données à caractère personnel à l’issue du contrat, et détruit les copies existantes, sauf obligation légale de conservation (§10.3) ou gel juridique (§10.4).

4.8 (h) Audit

Voir l’article 7.

5. Notification de violation de données

5.1 Délai de notification

Le Sous-traitant notifie au Responsable de traitement toute violation de données à caractère personnel dans les meilleurs délais et au plus tard 48 heures après en avoir pris connaissance, afin de permettre au Responsable de respecter son obligation de notification à la CNIL dans les 72 heures (article 33 RGPD).

5.2 Contenu de la notification

La notification précise au minimum, dans la mesure des informations disponibles :

• la nature de la violation (catégories et nombre approximatif de personnes et d’enregistrements concernés),
• les conséquences probables de la violation,
• les mesures prises ou envisagées pour remédier à la violation et atténuer ses effets,
• les coordonnées du point de contact PersoIA pour obtenir des informations complémentaires.

Si toutes ces informations ne peuvent être fournies immédiatement, elles le sont de manière échelonnée et sans retard injustifié.

5.3 Canal de notification

La notification est adressée par e-mail au(x) contact(s) désigné(s) par le Responsable lors de la souscription, avec accusé de réception. Le Sous-traitant maintient un registre interne des violations.

6. Sous-traitance ultérieure et localisation des traitements

6.1 Liste des sous-traitants ultérieurs autorisés

Les sous-traitants ultérieurs autorisés à la date d’effet du présent DPA sont listés en Annexe 2. La liste à jour est publiée publiquement à l’adresse https://www.persoia.com/legal/sous-traitants.

6.2 Localisation des traitements

L’ensemble des sous-traitants ultérieurs autorisés sont établis dans l’Union européenne, et les traitements qu’ils opèrent pour le compte de PersoIA ont lieu exclusivement dans des datacenters situés en France (ou dans l’Union européenne pour les services accessoires).

6.3 Transferts hors UE

Aucun transfert de données à caractère personnel hors de l’Union européenne n’est effectué dans le cadre du service PersoIA, sauf demande explicite et documentée du Responsable.

Si une telle demande devait être satisfaite, elle ne pourrait l’être que sur le fondement d’un mécanisme conforme au chapitre V du RGPD (décision d’adéquation, clauses contractuelles types — CCT — adoptées par la Commission européenne, règles d’entreprise contraignantes, etc.) et ferait l’objet d’un avenant écrit au présent DPA.

Si le Responsable décide d’activer une intégration optionnelle vers un modèle d’IA propriétaire hébergé hors UE (par exemple Anthropic, OpenAI, Mistral cloud, etc., non activé par défaut), il en assume la responsabilité au regard de la conformité RGPD et conclut le cas échéant les contrats de sous-traitance complémentaires nécessaires directement avec lesdits fournisseurs.

7. Audit et inspection

7.1 Droit d’audit

Le Sous-traitant met à la disposition du Responsable toutes les informations nécessaires pour démontrer le respect des obligations prévues à l’article 28 du RGPD et permet la réalisation d’audits.

7.2 Modalités

Le Responsable peut, à ses frais et au maximum une fois par an (sauf incident de sécurité avéré), procéder à un audit ou mandater un tiers indépendant soumis à un engagement de confidentialité, sur préavis écrit de 30 jours.

L’audit ne peut perturber le fonctionnement normal du service ni la confidentialité des données d’autres clients. Le Responsable et son auditeur s’engagent à respecter la confidentialité de toutes les informations obtenues.

7.3 Documentation alternative

Le Sous-traitant met à disposition, sur demande, toute documentation pertinente attestant de la conformité (rapports d’audit interne, certifications, attestations de sous-traitants ultérieurs, et le cas échéant, rapports SOC 2 ou ISO 27001 lorsque ces certifications seront acquises).

8. Responsabilité et indemnisation

Conformément à l’article 82 du RGPD, le Sous-traitant ne répond du dommage causé par le traitement que s’il n’a pas respecté les obligations que le RGPD impose spécifiquement aux sous-traitants ou s’il a agi en dehors des instructions licites du Responsable de traitement ou contrairement à celles-ci ; s’il détermine en violation du RGPD les finalités et les moyens du traitement, il est considéré comme responsable de ce traitement (article 28.10 du RGPD).

Ces stipulations ne limitent pas les droits des personnes concernées prévus à l’article 82.4 du RGPD. Entre les Parties, la charge définitive de la réparation est répartie selon la part de responsabilité de chacune (article 82.5 du RGPD).

Les limitations et exclusions de responsabilité prévues au contrat principal s’appliquent entre les Parties au titre du présent DPA, sous réserve des cas où le RGPD ou toute autre disposition d’ordre public les écarte. L’exclusion de la perte de données prévue à l’article 12.2 des CGV ne s’applique pas à la perte résultant d’un manquement du Sous-traitant aux mesures de sécurité de l’Annexe 3 ou au présent DPA ; ce dommage reste soumis au plafond de l’article 12.3 des CGV. Les traitements dont PersoIA est responsable (§1.4) relèvent de sa seule responsabilité.

9. Convention de preuve

Les parties conviennent que les éléments suivants, conservés par le Sous-traitant, constituent des moyens de preuve de l’exécution du présent DPA :

• les journaux applicatifs (authentification, accès, opérations administratives),
• les instructions de l’Administrateur Client sur les conversations et Artefacts générés d’un Utilisateur dont le Compte est effacé (§4.1),
• les traces des accès au séquestre et des gels juridiques posés et levés (§10.3 et §10.4),
• les enregistrements de consentement (consent_log),
• les rapports de violation éventuels,
• les notifications de changement de sous-traitants ultérieurs,
• les attestations de suppression / crypto-shredding émises en fin de contrat,
• les enregistrements de mesure de consommation (Compute Units, durées GPU et visioconférence, comptage de requêtes) servant de base à la facturation des dépassements.

10. Durée, fin du contrat et sort des données

10.1 Durée

Le présent DPA prend effet à la même date que le contrat principal et reste en vigueur pendant toute la durée d’exécution de celui-ci.

10.2 Restitution ou suppression

Au choix du Responsable de traitement notifié par écrit dans les 60 jours suivant la fin du contrat :

• Option A — Restitution : le Sous-traitant met à disposition du Responsable un export complet des données dans un format structuré et couramment utilisé (JSON ou équivalent), pendant une fenêtre de récupération de 60 jours suivant la résiliation. Au-delà, suppression sécurisée selon l’option B.
• Option B — Suppression : le Sous-traitant procède à la suppression sécurisée des données via crypto-shredding (destruction de la clé de chiffrement du tenant rendant les données chiffrées immédiatement inintelligibles dans le service, et définitivement inintelligibles au plus tard 377 jours après, à l’expiration des sauvegardes de la base de la plateforme où cette clé subsiste chiffrée, puis suppression du fichier de base) et à l’effacement des données que cette clé ne chiffre pas, dont les index de recherche — voir Annexe 3 §6 ; pour les copies de sauvegarde, voir Annexe 3 §7. Une attestation de suppression est délivrée au Responsable.

À défaut d’instruction du Responsable dans le délai de 60 jours, l’option B (suppression) s’applique par défaut. Les deux options s’appliquent sous réserve des §10.3 et §10.4.

Les mêmes règles s’appliquent à l’issue du délai de soixante (60) jours suivant une suspension pour défaut de paiement non régularisée (article 5.4.3 des CGV), sous réserve des §10.3 et §10.4.

10.3 Obligations légales de conservation

Sont exclues de la suppression les données que PersoIA conserve en qualité de responsable de traitement (§1.4), soit au titre d’une obligation légale qui lui est propre (article 17.3.b du RGPD), soit, pendant le délai de prescription, pour la constatation, l’exercice ou la défense de droits en justice (article 17.3.e du RGPD). Ces données ne sont pas des Données Client. Elles sont conservées de manière isolée, avec un accès strictement limité, jusqu’à expiration de la durée indiquée, puis détruites :

• séquestre des données d’identification (loi n° 2004-575 du 21 juin 2004, article 6, et décret n° 2021-1362 du 20 octobre 2021 ; article 17.3.b du RGPD) : pour un Utilisateur, nom, prénom, adresse e-mail et téléphone pendant cinq (5) ans à compter de la Clôture du Compte, identifiant pendant un (1) an à compter de la Clôture du Compte ; pour le Client, raison sociale, SIRET et adresse pendant cinq (5) ans à compter de la fin du contrat, et données de paiement (type, référence, montant, date) pendant un (1) an à compter de la fin du contrat, sans préjudice de la conservation des factures et sans aucune donnée de carte bancaire. La fin du contrat s’entend de la date à laquelle le Service a été définitivement suspendu. Le séquestre est chiffré par une clé propre à la plateforme, indépendante de celle des Données Client : il n’est donc pas atteint par le crypto-shredding. Il n’est consulté que par des administrateurs habilités de PersoIA, sur motif journalisé comportant la référence de la réquisition, pour répondre à une réquisition d’une autorité judiciaire ou administrative habilitée, et n’est utilisé à aucune autre fin. Il est supprimé automatiquement à l’échéance ;
• journal des connexions (adresse IP et date de chaque connexion ; article 17.3.b du RGPD) : un (1) an à compter de chaque connexion, puis suppression automatique ;
• factures et pièces comptables : dix (10) ans à compter de la clôture de l’exercice auquel elles se rapportent (article L123-22 du Code de commerce ; article 17.3.b du RGPD), puis suppression. Les métadonnées d’usage agrégées à des fins comptables (§3.5) relèvent de ce régime ;
• journal des consentements (preuve de l’acceptation des documents contractuels ; article 17.3.e du RGPD) : cinq (5) ans à compter de la fin du contrat, durée de la prescription applicable (article 2224 du Code civil et article L110-4 du Code de commerce), au titre de l’intérêt légitime de PersoIA à prouver les acceptations (articles 6.1.f et 7.1 du RGPD).

Les e-mails reçus ou envoyés par la boîte support@persoia.com et les demandes de support, que PersoIA traite en qualité de responsable de traitement (§1.4), sont conservés au plus trois (3) ans après le dernier échange, puis supprimés (Annexe 2).

Ces durées sont rappelées à titre d’information et ne relèvent pas des instructions du Responsable de traitement ; ces traitements, dont PersoIA est seule responsable, sont décrits dans la Politique de confidentialité. Toute modification de ces durées qui affecterait le Responsable de traitement lui est notifiée dans les conditions du §10.5.

10.4 Gel juridique

En cas de litige, de procédure ou de réquisition, PersoIA peut geler les données dont elle est responsable de traitement (§1.4 et §10.3) relatives à un Compte ou à un Client : tant que le gel est actif, elles ne sont ni effacées par PersoIA ni purgées automatiquement, même au-delà des durées du §10.3, et restent à accès restreint (article 17.3.b et 17.3.e du RGPD).

Les Données Client ne peuvent faire l’objet d’un gel que si une disposition légale, une réquisition ou une décision d’une autorité judiciaire ou administrative l’impose (article 28.3.a et g du RGPD) : ce n’est qu’à cette condition que le Sous-traitant diffère leur suppression, y compris lorsqu’elle résulte d’une instruction du Responsable ou de la fin du contrat. Un gel posé pour un litige propre à PersoIA ne diffère jamais la suppression des Données Client. Le Sous-traitant en informe préalablement le Responsable de traitement, sauf si le droit applicable l’interdit, ainsi que de la levée du gel. Les Données Client concernées sont isolées, à accès restreint, et ne font l’objet d’aucun autre traitement. Le gel ne fait pas obstacle à la restitution des Données Client au Responsable (§10.2, option A).

Le gel est revu au moins tous les six (6) mois et levé à la fin de la procédure ou à l’expiration du délai de prescription applicable ; les durées et instructions applicables s’exécutent alors de nouveau.

10.5 Évolution du DPA

Le présent DPA évolue dans les conditions de l’article 16 des CGV, y compris l’acceptation expresse que cet article exige pour les modifications visées à son quatrième alinéa. Toute nouvelle version est notifiée au Responsable par e-mail avec un préavis de trente (30) jours, pendant lequel il peut s’y opposer et résilier le contrat dans les conditions de l’article 6.2 des CGV. En cas d’opposition, la version antérieure continue de s’appliquer jusqu’à la prise d’effet de la résiliation ; à défaut, elle s’applique jusqu’à l’entrée en vigueur de la nouvelle version à l’égard du Responsable.

11. Loi applicable et juridiction

Le présent DPA est soumis au droit français et au droit de l’Union européenne, en particulier au RGPD (UE 2016/679) et à la loi française n° 78-17 du 6 janvier 1978 modifiée relative à l’informatique, aux fichiers et aux libertés.

En cas de litige, les tribunaux compétents sont ceux désignés au contrat principal. À défaut de stipulation, les tribunaux du ressort du siège social du Sous-traitant sont compétents, sous réserve des règles d’ordre public.

Annexe 1 — Description du traitement (à compléter par le Client)

Le Responsable de traitement complète les informations suivantes pour les besoins de sa propre cartographie des traitements :

Annexe 2 — Liste des sous-traitants ultérieurs autorisés

Liste à jour : https://www.persoia.com/legal/sous-traitants (consultable en permanence).

Sous-traitants explicitement non utilisés par défaut : Anthropic, OpenAI, Mistral cloud (API hébergée hors UE pour OpenAI / Anthropic) et tout autre fournisseur d’IA propriétaire externe à l’instance PersoIA. PersoIA exécute des modèles open-source sur ses propres GPU ; aucune donnée client n’est transmise à un tiers d’inférence externe sans activation explicite par le Responsable.

Si le Responsable choisit d’activer une intégration optionnelle vers un de ces fournisseurs (cf. §6.3 ci-dessus), ce fournisseur devient un sous-traitant ultérieur additionnel pour ce Client uniquement, à inscrire à l’Annexe 2 du DPA bilatéral signé entre les parties. La présente Annexe 2 publique ne le liste pas tant que l’activation reste optionnelle et au cas par cas.

Si le Responsable active une intégration optionnelle vers un service tiers d’IA, celui-ci devient un sous-traitant supplémentaire et un avenant au présent DPA est requis.

Lyra Network (PayZen) intervient pour PersoIA, pour la facturation et le paiement, traitements dont PersoIA est responsable (§1.4) : il figure sur cette liste par transparence et ne traite aucune Donnée Client.

Scaleway envoie principalement des e-mails liés aux Comptes et aux factures. Pour cet envoi, il traite l’adresse e-mail et le nom du destinataire, ainsi que le contenu des e-mails et de leurs pièces jointes. Il ne traite des Données Client que lorsque le Service envoie un contenu par e-mail (par exemple un compte rendu de réunion).

La messagerie d’OVH reçoit et conserve les e-mails adressés à une adresse en @persoia.com, dont ceux que le Responsable adresse à contact@persoia.com ou à dpo@persoia.com (§4.1 et §4.5). Pour ces e-mails, OVH traite l’adresse e-mail et le nom de l’expéditeur, l’objet, le contenu et les pièces jointes. Ces e-mails ne contiennent de Données Client que si l’expéditeur en reprend dans son e-mail ou ses pièces jointes. Les e-mails adressés à support@persoia.com sont conservés dans une boîte de cette messagerie, d’où partent aussi les réponses du support. PersoIA lit automatiquement cette boîte depuis son serveur de production, hébergé chez OVH, et ouvre une demande de support pour chaque e-mail reçu, hors réponses automatiques. La demande reprend l’adresse e-mail de l’expéditeur, l’objet et le texte de l’e-mail ; les pièces jointes n’y sont pas importées et restent dans la boîte. Les e-mails de cette boîte et les demandes de support sont conservés au plus trois (3) ans après le dernier échange, puis supprimés. Le traitement des demandes de support est un traitement dont PersoIA est responsable (§1.4).

Toute modification de la liste est notifiée au Responsable au moins 30 jours à l’avance, avec faculté d’opposition motivée (voir article 4.4).

Annexe 3 — Mesures techniques et organisationnelles (TOM)

1. Chiffrement au repos

• Données chiffrées par la clé du tenant. Le contenu des conversations (messages et titres), le contenu des Artefacts générés, les transcriptions et les comptes rendus de réunion, ainsi que les synthèses de documents, sont chiffrés au niveau applicatif, champ par champ, par un mécanisme AEAD AES-256-GCM, avant d’être écrits sur disque. Les conversations, les Artefacts générés, les transcriptions et les comptes rendus sont stockés dans une base SQLite dédiée au tenant ; les synthèses de documents, dans la base de la plateforme (§3).
• Une clé de chiffrement de données (DEK) unique est générée par tenant. Cette DEK est elle-même chiffrée (« wrappée ») par une clé maîtresse et n’est stockée que sous cette forme.
• Clé maîtresse. La clé maîtresse est une clé de l’opérateur PersoIA. Elle est fournie à l’application par la configuration chiffrée du serveur de production : elle est donc présente sur ce serveur, et seuls les administrateurs PersoIA habilités y ont accès. Aucun service externe de gestion de clés (KMS) n’est en service à ce jour ; le recours à OVH KMS est étudié, sans engagement de date.
• Données non chiffrées par la clé du tenant. Ce qui n’est pas énuméré au premier alinéa n’est pas chiffré par la clé du tenant, notamment :
  • les index de recherche des documents indexés (base vectorielle ChromaDB, §3.2) : ils contiennent des extraits du texte de ces documents, leurs vecteurs et des identifiants techniques (Utilisateur, conversation, document). Ils sont stockés sur le serveur de production, dans un répertoire propre au tenant, sans chiffrement applicatif ;
  • dans la base SQLite du tenant : le nom et le type des Artefacts générés, l’adresse et le titre des réunions, les dates, les identifiants techniques, le nom du modèle utilisé et les compteurs de consommation. Le fichier de la base n’est pas chiffré dans son ensemble : seuls les champs énumérés au premier alinéa le sont ;
  • dans la base de la plateforme (§3) : le nom, la taille et le type des documents importés, les données des Comptes (nom, prénom, adresse e-mail, téléphone, photo de profil), les données d’abonnement et de facturation, les demandes de support et les journaux. Les mots de passe y sont stockés sous forme hachée (§4) ; les secrets d’authentification à deux facteurs et le séquestre (§6) y sont chiffrés.
• Les fichiers d’origine des documents importés ne sont pas conservés sur le serveur de production après leur indexation.
• Disque du serveur. Le volume de stockage du serveur de production est chiffré au repos par l’hébergeur (OVH, Annexe 2), qui en gère la clé. Ce chiffrement protège les données contre le vol ou la récupération du support physique. Il ne protège pas contre un accès au serveur en fonctionnement : les données qui ne sont pas chiffrées au niveau applicatif y restent lisibles par une personne disposant d’un accès d’administration à ce serveur. Elles sont protégées par le contrôle d’accès à ce serveur (§4 et §9).
• Les sauvegardes qui sortent du serveur sont chiffrées dans les conditions du §7.

2. Chiffrement en transit

• Connexions entre le client et l’API, et entre l’API et l’instance d’inférence, chiffrées par TLS 1.2 minimum (TLS 1.3 recommandé).
• Certificats émis et renouvelés automatiquement par Let’s Encrypt (acme-companion).

3. Isolation des tenants

• Une base SQLite et un index de recherche distincts par tenant (offres dédiée et mutualisée bénéficient du même schéma cryptographique).
• DEK distincte par tenant : une compromission théorique d’une DEK n’expose qu’un seul tenant. La clé maîtresse, elle, protège les DEK de tous les tenants (§1).
• Niveau plateforme : PostgreSQL contient les données de la plateforme (utilisateurs, abonnements, facturation, journaux, séquestre), les informations sur les documents importés et leurs synthèses, ces dernières chiffrées par la DEK du tenant, ainsi que les DEK elles-mêmes, chiffrées par la clé maîtresse. Les conversations et les autres contenus métier des tenants sont dans leur base SQLite.

4. Authentification, autorisation, contrôle d’accès

• Authentification par JWT signé (access token courte durée, refresh token à durée limitée).
• Principe de session unique : une nouvelle connexion invalide la précédente.
• MFA TOTP optionnel, recommandé pour tous les comptes à privilèges administratifs.
• Rôles : admin_persoia (opérateurs internes), admin_client (administrateurs côté Responsable), user (utilisateurs finaux). Principe du moindre privilège.
• Mots de passe stockés sous forme hachée (algorithme à coût ajustable : bcrypt ou Argon2id).
• Limitation du taux de tentatives de connexion (verrouillage temporaire après échecs répétés).

5. Journalisation et audit

• Journaux applicatifs : connexions, opérations administratives, modifications de configuration sensible.
• Journal de consentement (consent_log) horodaté.
• Enregistrements de mesure de consommation (Compute Units, durées GPU et visioconférence, comptage de requêtes interactif/automatisé), métadonnées techniques uniquement, sans contenu des Données Client.
• Journal des connexions (adresse IP et date de chaque connexion, traitement dont PersoIA est responsable, §1.4) : un (1) an à compter de chaque connexion, puis suppression automatique. Adresses IP et agents utilisateurs des journaux d’administration : effacés au-delà d’un (1) an. Métadonnées d’usage : 60 jours sous forme détaillée, puis agrégées (cf. §3.5).
• Accès aux journaux strictement limité au personnel autorisé.

6. Suppression sécurisée et crypto-shredding

• Procédure de fin de vie d’un tenant : ShredDEK(tenant) détruit la DEK protégeant la base SQLite du tenant (la clé n’existe plus ni dans la base de la plateforme ni dans aucun cache applicatif), puis rm <tenant_uuid>.db supprime le fichier de la base.
• Conséquence cryptographique : les données chiffrées par AES-256-GCM sont inintelligibles sans la DEK ; elles le deviennent donc immédiatement dans le service, et ne peuvent redevenir lisibles sans la restauration d’une sauvegarde. La DEK détruite subsiste toutefois, chiffrée par la clé maîtresse, dans les sauvegardes de la base de la plateforme jusqu’à leur expiration (§7) : les contenus chiffrés des copies de la base du tenant, y compris de ses sauvegardes, deviennent donc définitivement inintelligibles au plus tard 377 jours après la destruction de la DEK ; les champs non chiffrés de ces copies (§1) disparaissent avec l’effacement des copies (§7). Les index de recherche et les autres données que la DEK ne chiffre pas (§1) ne sont pas atteints par le crypto-shredding : PersoIA les supprime en effaçant leurs fichiers ou leurs enregistrements, sous réserve des conservations légales (§10.3). Les archives des index de recherche (§7) ne sont pas chiffrées par la DEK non plus : elles sont supprimées à leur expiration, au plus tard 22 jours après leur création.
• Une attestation de suppression est émise au Responsable.
• Les conservations légales (§10.3) sont stockées hors de la base du tenant, dans la base de la plateforme : le crypto-shredding du tenant ne les atteint pas. Le séquestre des données d’identification y est chiffré ligne par ligne, par une clé protégée par la clé maîtresse (§1) ; sa suppression à l’échéance détruit la donnée.
• Un gel juridique actif (§10.4) suspend les purges automatiques des données concernées et, pour les Données Client, leur suppression dans les seuls cas prévus au §10.4, deuxième alinéa.

7. Sauvegardes

• Bases des tenants : réplication continue de chaque base SQLite, via Litestream, vers un stockage objet OVH (Object Storage, région de Gravelines, France). Les copies sont identiques à la base : les contenus énumérés au §1 y restent chiffrés par la DEK du tenant, et les autres champs de la base (§1) n’y sont pas chiffrés par PersoIA. Tant que le tenant est actif, ses états passés sont conservés 30 jours (720 heures glissantes) ; la purge ayant lieu une fois par jour, ils peuvent subsister jusqu’à 31 jours.
• Base de la plateforme (PostgreSQL, §3) : une copie complète chaque jour, chiffrée sur le serveur avant d’en sortir, par des clés dont aucune partie privée n’est présente sur ce serveur (alinéa « Clés de chiffrement des sauvegardes » ci-dessous), puis stockée chez OVH (Object Storage, région de Gravelines, France). Quatorze copies quotidiennes glissantes sont gardées ; chacune est supprimée au plus tard 22 jours après sa création. La première copie de chaque mois est aussi gardée comme copie mensuelle (douze copies glissantes), supprimée au plus tard 377 jours après sa création.
• Index de recherche des documents indexés (base vectorielle ChromaDB de l’indexation documentaire, §3.2) : une archive complète chaque jour, chiffrée sur le serveur avant d’en sortir, par les mêmes clés que la copie de la base de la plateforme, puis stockée chez OVH (Object Storage, région de Gravelines, France), dans le même espace de stockage que les copies quotidiennes de cette base. Chaque archive est verrouillée 14 jours dès son dépôt, dans les conditions de l’alinéa suivant, et supprimée au plus tard 22 jours après sa création. Il n’y a pas d’archive mensuelle des index.
• Protection contre l’effacement : chaque copie de la base de la plateforme et chaque archive des index est verrouillée dès son dépôt, pendant 14 jours pour une copie quotidienne ou une archive des index et 365 jours pour une copie mensuelle ; pendant ce délai, aucun utilisateur du stockage, PersoIA compris, ne peut l’effacer ni raccourcir son verrouillage. Le serveur de production peut déposer ces copies, mais ne peut ni les effacer ni les déchiffrer.
• Clés de chiffrement des sauvegardes : les copies de la base de la plateforme et les archives des index sont chiffrées pour deux clés, dont aucune partie privée n’est présente sur le serveur de production : la clé de l’opérateur PersoIA, qui sert à restaurer le service, et une clé réservée au test mensuel de restauration (§11). Ce test est exécuté sur un poste d’administration de PersoIA, avec un accès en lecture seule au stockage, dans un environnement jetable dont les données restent en mémoire et sont détruites à la fin du test.
• Les enregistrements audio ou vidéo des réunions ne font pas partie de ces sauvegardes.
• Les sauvegardes servent uniquement à reconstruire le service après un incident. Elles ne sont jamais restaurées pour retrouver les données d’une personne. En cas de restauration, les effacements effectués depuis la date de la sauvegarde sont refaits avant la remise en service.
• Une donnée effacée peut subsister, sans être utilisée, dans une sauvegarde jusqu’à l’expiration de celle-ci, soit au plus tard 377 jours après son effacement (22 jours pour les index de recherche).
• À la suppression des données d’un tenant (§6), PersoIA efface ses copies Litestream du stockage objet ; les contenus chiffrés de celles qui subsisteraient deviennent définitivement inintelligibles au plus tard 377 jours après la destruction de la DEK (§6). Ses index de recherche disparaissent des sauvegardes à l’expiration des archives qui les contiennent, au plus tard 22 jours après leur suppression du service.

8. Gestion des secrets

• Aucun secret n’est codé en dur dans le code source.
• Les secrets de production (clés API, identifiants base de données, etc.) sont injectés par variables d’environnement et stockés hors du dépôt de code source.
• Rotation possible des secrets sensibles.

9. Personnel

• Accès aux environnements de production restreint aux opérateurs PersoIA habilités, sur principe du moindre privilège et du « need-to-know ».
• Engagement de confidentialité signé par toute personne ayant accès aux données ou systèmes de production.
• Sensibilisation à la protection des données et à la sécurité.

10. Réponse aux incidents

• Procédure interne de gestion des violations de données documentée.
• Notification au Responsable dans un délai maximal de 48 heures après prise de connaissance (voir article 5).
• Notification à la CNIL dans les 72 heures par le Responsable, avec assistance technique du Sous-traitant.
• Revue post-incident et plan de remédiation.

11. Plan de continuité d’activité

• Sauvegardes décrites au §7 : réplication continue des bases des tenants (Litestream), copie quotidienne chiffrée de la base de la plateforme et archive quotidienne chiffrée des index de recherche.
• Capacité de redémarrage d’une instance compromise sur une infrastructure de secours en France.
• Test de restauration automatique chaque mois (§7) : la dernière copie de la base de la plateforme, des copies de bases de tenants tirées au hasard et la dernière archive des index sont restaurées et contrôlées, puis détruites.

12. Souveraineté

• Hébergement exclusif sur infrastructures françaises (OVH, Scaleway).
• Aucune dépendance technique à un fournisseur cloud hyperscaler non européen pour le traitement des contenus client.
• Modèles d’IA exécutés en local sur GPU PersoIA (pas d’appel à une API d’inférence tierce hors UE par défaut).

Version 1.8, en vigueur le 16 octobre 2026 pour les souscriptions conclues à compter de cette date et, pour les Clients existants, à la date prévue par l’article 16 des CGV. Reprend le DPA v1.0-draft (05/06/2026), y intègre le traitement des métadonnées techniques d’usage et de consommation (v1.1-draft, 28/07/2026), puis le sort de l’opposition à un sous-traitant ultérieur prévu à l’article 4.4 (d) (v1.2 : corrections de la relecture du 05/09/2026, en vigueur le 09/09/2026). La version 1.3 précisait la répartition des rôles (§1.4 et §1.5), les instructions du Responsable sur les conversations d’un Utilisateur dont le Compte est effacé (§4.1), l’assistance aux demandes des personnes (§4.5), la responsabilité (article 8), les conservations légales, le gel juridique et l’évolution du DPA (§10.3 à §10.5) (entrée en vigueur le 25 septembre 2026). La version 1.4 décrivait les sauvegardes réellement en place : stockage chez OVH en France, durées de conservation, verrouillage des copies et effet du crypto-shredding sur les sauvegardes (Annexe 2 ; Annexe 3 §3, §6, §7 et §11) (entrée en vigueur le 28 septembre 2026). La version 1.5 ajoutait l’archive quotidienne chiffrée des index de recherche des documents indexés et le test mensuel de restauration (§4.3 ; Annexe 3 §6, §7 et §11) (entrée en vigueur le 29 septembre 2026). La version 1.6 corrigeait la description du chiffrement au repos : elle énumérait ce qui est chiffré par la clé du tenant et ce qui ne l’est pas, dont les index de recherche, précisait que le volume du serveur est chiffré par l’hébergeur et décrivait la clé maîtresse réellement utilisée (§3.2, §4.3, §10.2 ; Annexe 2 ; Annexe 3 §1, §3, §6 et §7) (entrée en vigueur le 2 octobre 2026). La version 1.7 alignait l’Annexe 2 sur la liste des sous-traitants ultérieurs alors en vigueur : Scaleway envoyait les e-mails transactionnels, par le service Transactional Email, région de Paris, sans suivi des ouvertures ni des clics ; Brevo ne faisait plus que recevoir les e-mails adressés au support, y compris ceux envoyés à support@persoia.com ; la ligne OVH citait la messagerie du domaine persoia.com, qui redirigeait support@persoia.com vers la réception des demandes de support (Annexe 2) (entrée en vigueur le 16 octobre 2026). La version 1.8 retire Brevo de l’Annexe 2 : les e-mails adressés à support@persoia.com sont reçus et conservés dans une boîte de la messagerie d’OVH, d’où partent aussi les réponses du support, et que PersoIA lit automatiquement pour ouvrir une demande de support ; il n’y a plus de redirection ni d’adresse en @support.persoia.com. Elle range le traitement des demandes de support parmi les traitements dont PersoIA est responsable (§1.4 et §3.3) et en donne la durée de conservation (§10.3 et Annexe 2).