Sécurité

1. Nos engagements de sécurité

Souveraineté française. L'intégralité du Service est hébergée en France, sur les infrastructures OVH et Scaleway.Aucune donnée n'est transférée par PersoIA en dehors de l'Union européenne (les services tiers appelés par le formulaire de paiement de notre prestataire Lyra relèvent de Lyra, voir lapolitique de confidentialité). Les modèles d'intelligence artificielle utilisés sont open source et exécutés sur nos propres infrastructures :aucun appel n'est fait à un fournisseur d'IA tiers(OpenAI, Anthropic, Google, etc.).

Une clé de chiffrement par Client. Chaque Client dispose d'une clé de chiffrement applicative qui lui est propre. Le contenu de ses conversations, de ses fichiers générés, de ses transcriptions, de ses comptes rendus de réunion et des synthèses de ses documents est stocké chiffré en AES-256-GCM avec cette clé, et reste illisible pour tout autre Client.

Ce qui n'est pas chiffré avec cette clé. Les index qui permettent de chercher dans les documents indexés contiennent des extraits de ces documents : ils sont stockés sur notre serveur, dans un répertoire propre au Client, sans chiffrement applicatif. Les noms de fichiers, les dates, les données des comptes et les données de consommation ne sont pas chiffrés non plus. Le disque du serveur est chiffré par notre hébergeur (OVH) : cela protège les données en cas de vol du support physique, pas contre un accès au serveur en fonctionnement. La clé maîtresse qui protège les clés des Clients est une clé de PersoIA présente sur ce serveur : un administrateur habilité de PersoIA peut donc techniquement accéder à ces données. Ces accès sont limités aux personnes habilitées. Détail : DPA, Annexe 3 §1 (paragraphe mis à jour le 2 octobre 2026).

Crypto-shredding pour le droit à l'effacement.À la fin du contrat, à l'issue du délai de 60 jours laissé au Client pour exporter ses données (article 6.5 des CGV), la clé de chiffrement spécifique au Client est détruite. Les contenus chiffrés du Client deviennent alors immédiatement illisibles dans le service, sans qu'il soit nécessaire de réécrire chaque enregistrement individuellement. Ils ne peuvent pas redevenir lisibles sans restaurer une sauvegarde : la clé détruite reste, chiffrée, dans les sauvegardes de la base de la plateforme, et disparaît avec elles au plus tard environ 12 mois et demi (377 jours) après sa destruction. Ces contenus sont alors définitivement illisibles. Les données que cette clé ne chiffre pas, comme les index de recherche des documents, sont supprimées par effacement. Détail : DPA, Annexe 3 §6 et §7 (paragraphe mis à jour le 2 octobre 2026).

Authentification multi-facteurs. L'authentification par double facteur temporel (TOTP) est disponible pour tous les comptes et constitue la voie privilégiée d'accès au Service.

2. Architecture technique

PersoIA propose deux modèles d'exécution selon l'offre souscrite :

• Offre Dédiée : une instance GPU est réservée au Client, qui en a l'usage exclusif.
• Offre Mutualisée : un pool GPU est partagé entre plusieurs Clients ; la capacité de traitement est dimensionnée dynamiquement.

Dans les deux cas, l'isolation des données par Client est identique. Chaque Client dispose d'un fichier de stockage et d'un index de recherche qui lui sont propres : c'est une séparation logique. S'y ajoute le chiffrement, avec sa clé applicative, des contenus énumérés plus haut ; les autres informations du fichier de stockage (noms de fichiers, dates) ne sont pas chiffrées. Les données de la plateforme (comptes, abonnements, factures, informations sur les documents importés et leurs synthèses, chiffrées) sont, elles, dans une base de données commune à tous les Clients (DPA, Annexe 3 §3).

Client A                Client B                Client C
   |                       |                       |
   | (TLS 1.2+)            | (TLS 1.2+)            | (TLS 1.2+)
   v                       v                       v
+--------------------------------------------------------+
|              API PersoIA (chiffrement)                 |
|     +---------+    +---------+    +---------+         |
|     | DEK A   |    | DEK B   |    | DEK C   |  ...    |
|     +---------+    +---------+    +---------+         |
|         |              |              |               |
|    [stockage A]   [stockage B]   [stockage C]         |
|     AES-256-GCM   AES-256-GCM    AES-256-GCM          |
+--------------------------------------------------------+
                          |
                          v
              GPU (modèles open source)
            Dédié ou pool mutualisé
            

Sauvegardes. La base de chaque client est copiée en continu, et la base de la plateforme ainsi que les index de recherche des documents une fois par jour, vers un stockage objet OVH situé en France. Dans les copies des bases des clients, les contenus chiffrés avec la clé du client restent chiffrés et les autres informations (noms de fichiers, dates) ne le sont pas ; celles de la base de la plateforme et les archives des index sont chiffrées avant de quitter le serveur et verrouillées contre l'effacement. Un test de restauration automatique les vérifie chaque mois. Détail et durées de conservation : DPA, Annexe 3 §7 (paragraphe mis à jour le 2 octobre 2026).

3. Conformité RGPD

Dans le cadre du Service, PersoIA agit en qualité desous-traitant au sens de l'article 28 du règlement (UE) 2016/679 (RGPD). Le Client demeureresponsable de traitement des contenus qu'il injecte dans son instance.

• Contrat de sous-traitance (DPA) fourni à la souscription, conforme à l'article 28 RGPD :consulter le DPA.
• Registre des activités de traitement (article 30 RGPD) maintenu en interne et communicable aux Clients sur demande motivée.
• Notification des violations de données au Client sous 48 heures à compter de la connaissance effective de l'incident, conformément au DPA §5.1. Un runbook formalisé encadre la procédure interne de détection, qualification et notification.
• Sous-traitants ultérieurs listés publiquement et à jour :page Sous-traitants. Toute modification est notifiée 30 jours à l'avance avec faculté d'opposition.
• Délégué à la protection des données (DPO) : Pierre MERLE, Président de PersoIA, est désigné DPO (désignation volontaire, art. 37 §4 RGPD). Contact dédié :dpo@persoia.com.

4. Mesures techniques et organisationnelles

Les mesures ci-dessous sont effectivement déployées à la date de dernière mise à jour de la présente page.

Chiffrement

• Chiffrement en transit : TLS 1.2 minimum sur l'ensemble des endpoints publics.
• Chiffrement au repos : AES-256-GCM applicatif avec une clé de chiffrement (DEK) distincte par Client, pour le contenu des conversations, des fichiers générés, des transcriptions, des comptes rendus de réunion et des synthèses de documents. Les index de recherche des documents, les noms de fichiers et les données des comptes ne sont pas chiffrés par cette clé. Le disque du serveur est chiffré par l'hébergeur : cela protège contre le vol du support physique, pas contre un accès au serveur en fonctionnement.
• Cycle de vie des clés géré côté serveur ; les clés ne sont jamais exposées en clair dans les journaux ni dans les sauvegardes.

Authentification et contrôle d'accès

• Mots de passe stockés sous forme de hash résistant au brute-force.
• Authentification multi-facteurs TOTP disponible pour tous les comptes.
• Limitation du nombre de tentatives infructueuses (verrouillage temporaire après 5 échecs sur 15 minutes).
• Sessions JWT révocables ; un nouvel accès invalide les sessions actives précédentes pour le même utilisateur.
• Renforcement de l'obligation MFA pour les comptes administrateurs en cours de finalisation.

Protection du moteur d'inférence

• Couche anti-injection de requêtes, dans l'interface de conversation : détection des formulations connues de détournement des garde-fous du modèle (jailbreak, usurpation de rôle, exfiltration de l'invite système), en français comme en anglais. Le message n'est ni bloqué ni modifié : les consignes de sécurité données au modèle sont renforcées et un événement technique, sans le texte du message, est journalisé. Les requêtes adressées directement à l'API par clé d'accès ne bénéficient ni de cette détection ni des consignes de sécurité de l'interface de conversation.
• Cette couche est un dispositif de sécurité interne du moteur ; elle ne constitue pas une modération automatique des contenus utilisateurs, qui demeurent sous la responsabilité du Client en tant que responsable de traitement.

Journalisation et traçabilité

• Journal applicatif des événements d'authentification (succès, échec, déclenchement MFA) et des actions administratives.
• Conservation des journaux de connexion : 12 mois.
• Rapports d'erreur techniques de l'application (message d'erreur, page, navigateur), conservés sur l'infrastructure de PersoIA : 60 jours, puis suppression automatique.
• Journal des consentements contractuels (CGV, DPA, demande de démarrage immédiat ou, pour les souscriptions antérieures à la version 1.3 des CGV, renonciation au droit de rétractation, enregistrement de la carte bancaire), avec la date, l'adresse IP et l'agent utilisateur (navigateur), conservé 5 ans à des fins de preuve.

Sécurité du cycle de développement

• Revue de code obligatoire avant intégration sur la branche principale.
• Analyse statique de sécurité (SAST) automatisée en intégration continue (lint, analyse de vulnérabilités, détection de courses entre routines).
• Mise à jour régulière des dépendances et correction des vulnérabilités publiées (CVE) sur l'image de base et les bibliothèques applicatives.
• Tests d'analyse dynamique (DAST) en cours de déploiement dans la chaîne d'intégration continue.

5. Infrastructure et sous-traitants ultérieurs

L'ensemble des sous-traitants ultérieurs de PersoIA sont établis dans l'Union européenne et exécutent leurs traitements en France métropolitaine.

• OVH (France) — hébergement compute, services DNS, stockage objet des sauvegardes ; messagerie du domaine, dont la boîte du support (support@persoia.com), qui reçoit les demandes et envoie les réponses, lue automatiquement par la plateforme.
• Scaleway (France) — capacité GPU ; envoi des courriels transactionnels, sans suivi des ouvertures ni des clics.
• Lyra / PayZen (France) — encaissement des paiements par carte bancaire.

La liste détaillée et opposable est publiée sur la pageSous-traitants.

6. Reporting de vulnérabilité

PersoIA accueille les signalements de vulnérabilités selon une démarche deresponsible disclosure. Les chercheurs en sécurité, intégrateurs et Clients sont invités à transmettre leurs constats à l'adresse dédiée :

security@persoia.com

En l'attente de la mise en service de cette adresse, les signalements peuvent être adressés à privacy@persoia.com(objet : vulnérabilité).

Engagements de PersoIA :

• Accusé de réception sous 72 heures ouvrées.
• Qualification initiale et plan de correction communiqués au déclarant.
• Délais cibles de correction selon la criticité : critique (P1) sous 7 jours, élevée (P2) sous 30 jours, modérée (P3) sous 90 jours.
• Reconnaissance publique du déclarant possible, avec son accord.

À la date des présentes, PersoIA n'opère pas de programme debug bounty rémunéré.

7. Ce que nous ne prétendons pas (encore)

Par souci de transparence, PersoIA précise les éléments quine sont pas en place à la date des présentes :

• Aucune certification (ISO 27001, SOC 2, HDS) n'est détenue à ce stade. Une évaluation de l'opportunité d'engager ces démarches est prévue à moyen terme.
• Le niveau de service mentionné dans nos CGV (99,5 %) constitue unobjectif de service (SLO) et non un engagement contractuel assorti d'un avoir automatique ; il sera promu en SLA contractuel lorsque le dispositif de mesure et d'avoir client sera opérationnel.
• Aucun test d'intrusion (pentest) externe n'a été conduit à ce jour ; un audit externe est planifié après la mise en service commerciale.