Sécurité et conformité

Sécurité et conformité

Missivia est conçue pour des environnements réglementés. Cette page liste des faits vérifiables sur la manière dont la plateforme traite les données ; elle s’adresse aux délégués à la protection des données et aux responsables de la sécurité des systèmes d’information. Elle décrit ce qui est en place, pas ce qui est prévu.

Hébergement : deux modes de déploiement

Le même produit se déploie de deux manières. Le mode standard est celui par défaut ; ce n’est pas un hébergement de données de santé.

Standard, par défaut

• Hébergement en France, dans la région de Paris, chez un hébergeur français nommé au contrat.
• Chiffrement en transit et au repos, isolation par espace, journal d’audit chaîné, sauvegardes automatiques de la base chez l’hébergeur.
• Pour tout usage sans donnée de santé.

Santé, en option, par contrat

• Le même produit, en instance dédiée, déployée chez un hébergeur certifié Hébergeur de Données de Santé (HDS).
• Le périmètre, l’environnement de déploiement et les responsabilités de chaque partie sont définis au contrat.
• La certification s’applique à l’hébergeur, pas à la plateforme : voir Hébergement de données de santé.

Sous-traitance et appels sortants

• Un seul sous-traitant ultérieur pour la plateforme : l’hébergeur. Les courriers opérationnels de la plateforme partent par le relais de messagerie de ce même hébergeur.
• Par défaut, aucun prestataire d’envoi d’e-mails tiers : la plateforme remet les messages directement aux serveurs de messagerie des destinataires, depuis ses propres adresses IP. Un espace sans donnée de santé peut confier la remise à un routeur externe, sur son propre compte : ce prestataire est alors choisi par le client. Un espace qui porte des données de santé reste sur la remise intégrée, par construction.
• Aucun outil d’analyse d’audience ni de télémétrie tiers, ni sur ce site, ni dans la plateforme, ni dans les pages publiques envoyées aux destinataires.
• Aucun stockage objet externe pour les données de la plateforme : images, exports et pièces jointes restent dans le périmètre, dans la base chiffrée du déploiement.
• Appels sortants de la plateforme elle-même : serveurs de messagerie des destinataires (remise des e-mails), autorité de certification (émission et renouvellement des certificats TLS), services de réputation des fournisseurs de messagerie (agrégats concernant nos propres adresses IP et domaines). Ce qu’un espace fait sortir par un workflow ne va que vers les connexions qu’il a déclarées, classées et journalisées (voir Workflows).

Protection des données

• Chiffrement en transit : TLS avec HSTS pour l’API, les pages publiques et ce site ; STARTTLS pour les échanges SMTP.
• Chiffrement au repos des clés de signature (DKIM), des secrets de webhooks et des adresses d’envoi de test en AES-256-GCM ; clés d’API stockées hachées ; mots de passe hachés en Argon2id.
• Sauvegardes automatiques de la base, chez l’hébergeur.
• Aucun corps de message rendu n’est conservé : l’e-mail est composé au moment de la remise, et à la demande pour sa version en ligne. La copie la plus exposée de la donnée la plus sensible n’existe pas.
• Journaux constitués par liste d’autorisation : seules les clés explicitement permises sont écrites. Ni adresse e-mail, ni sujet, ni corps, ni valeur d’attribut, y compris dans les traces d’erreur.
• Charges utiles des tâches de fond réduites à des identifiants : le contenu est relu depuis la base au moment de l’exécution, jamais transporté dans la file.
• Isolation des espaces appliquée à chaque requête ; une ressource d’un autre espace est introuvable.

Données sensibles et données de santé

Chaque attribut d’un contact porte une classe — technique, personnelle, ou de santé — déclarée par le client. La classe décide de l’endroit où la valeur est écrite, de qui peut la relire et de ce qui en est journalisé.

• Une valeur de classe santé n’est jamais écrite avec la fiche : elle va dans une table dédiée, chiffrée au niveau de la colonne en AES-256-GCM, avec la version de clé enregistrée à côté et une rotation par tâche planifiée.
• À côté de la valeur chiffrée, un index dérivé à sens unique permet la segmentation par égalité ou par appartenance à une liste de valeurs — jamais un tri, jamais une recherche partielle. Tout autre opérateur est refusé.
• Un attribut de santé est à valeurs fermées ; une valeur hors liste est refusée, et la réponse d’erreur ne répète jamais la valeur envoyée.
• La classe santé est irréversible : l’attribut ne peut être reclassé, une valeur encore portée par un contact ne peut être retirée de la liste, et la définition ne s’efface pas tant qu’un segment s’en sert.
• Consentement dédié : une finalité propre au traitement des données de santé, recueillie avec sa preuve. Sans elle, le contact n’appartient à aucun segment construit sur un attribut de santé, n’entre dans aucun parcours ni aucune audience qui en dérive. Son retrait sort immédiatement des parcours dérivés en cours.
• Minimisation : une valeur de santé n’est pas une variable de fusion — la différenciation passe par le choix du parcours, jamais par l’insertion de la valeur dans l’e-mail. Elle n’apparaît dans aucun journal, aucun export de statistiques et aucun corps de webhook, qui ne portent que des identifiants opaques.
• Seuil d’agrégation : tout compteur servi à un rôle d’exploitation de la plateforme en dessous d’un seuil (vingt personnes par défaut) est masqué, y compris zéro, ainsi que les taux qui s’en déduiraient. Un rôle du client reçoit toujours la valeur exacte.

Consentement et droits des personnes

• Consentement par finalité, avec preuve : qui, quand, libellé présenté, source de la collecte. Un refus est conservé comme preuve.
• Deux pixels distincts : un pixel de délivrabilité (exempté, n’écrit que la date de dernière ouverture, à la journée) et un pixel de performance, inséré uniquement si un consentement de suivi valide existe au moment du rendu.
• Lien de désinscription dans chaque e-mail marketing, désinscription en un clic (RFC 8058) et en-têtes List-Unsubscribe / List-Unsubscribe-Post.
• Page de préférences à la marque du client : abonnements, autorisations de mesure, désinscription globale. Chaque changement écrit un acte de consentement avec son libellé exact, sa source et l’URL du formulaire.
• Messages de service séparés des envois de prospection : régime juridique distinct, aucune mesure de performance.
• Accès et portabilité : un appel restitue attributs, consentements, inscriptions, enrôlements, événements et messages reçus d’une personne — sans aucun corps de message. Limitation du traitement et opposition au profilage sont appliquées par le serveur (voir Droits des personnes).

Journal d’audit

• Chaque lecture d’une donnée personnelle et chaque écriture sont journalisées : acteur (clé, utilisateur nommé ou tâche automatique), rôle, action, ressource, appel, identifiant de requête, horodatage UTC.
• Seuls les noms des champs lus ou écrits sont enregistrés, jamais leur valeur — ni adresse, ni attribut, ni terme de recherche. Aucune adresse IP en clair : une empreinte tronquée et salée permet de corréler deux requêtes d’une même origine sans jamais retrouver l’adresse.
• Un marqueur distinct signale qu’un champ de santé a été touché. Une lecture par un rôle qui ne voit pas ce champ ne produit pas ce marqueur : rien n’a été consulté.
• Inaltérable : le journal est en ajout seul ; la modification et la suppression sont refusées par la base elle-même, et l’écriture passe par une fonction de la base qui n’accepte qu’un ajout en fin de chaîne. Chaque entrée porte l’empreinte de la précédente et est scellée par une clé de plateforme — l’acteur, la ressource et l’horodatage en font partie. Une vérification de chaîne quotidienne détecte toute rupture et déclenche une alerte.
• Ancré et vérifié de l’extérieur : chaque jour, la tête de chaque chaîne est déposée dans un stockage d’objets immuable (verrou de conformité de treize mois, en France), et une vérification indépendante du processus applicatif relit toutes les versions des ancrages, les confronte à la base et recalcule chaque chaîne. Un écart est traité comme un incident de sécurité potentiel.
• Export par personne concernée : tout ce qui a été fait sur une personne — lectures incluses —, par qui et quand, restituable en un appel. Cette lecture est elle-même journalisée.
• Un refus d’autorisation est enregistré avec l’opération tentée ; aucune entrée de lecture ne l’accompagne. L’historique d’une personne ne se remplit jamais d’accès qui n’ont pas eu lieu.
• Les actions menées depuis une interface d’administration sont rattachées à l’utilisateur humain qui les a déclenchées, par un en-tête signé, en plus de la clé employée. L’en-tête n’accorde aucun droit : l’autorisation reste portée par la classe de la clé.
• Les actes propres à la console d’administration — invitations, rôles, dévoilement d’une adresse, gestion des comptes — sont relayés vers ce même journal chaîné, horodatés à la réception par le serveur, avec une attestation de l’acteur, avec un acteur pseudonymisé et sans adresse e-mail ; un relais rejoué avec un contenu différent est refusé.
• Dans le journal servi aux rôles d’exploitation de la plateforme, tout identifiant rattaché à une personne est masqué.

Conservation, anonymisation et réversibilité

• Durées paramétrables par espace pour les contacts, les événements, le journal d’audit, les livraisons de webhooks, les fichiers d’export et les envois de test, appliquées par purge automatique.
• Le journal d’audit est soumis à un plancher contractuel — la durée des contacts augmentée d’un an. Une valeur inférieure est refusée, jamais remontée en silence : un réglage qui ne fait pas ce qu’il annonce est pire qu’un refus.
• Anonymisation irréversible des contacts inactifs, en une transaction : adresse, empreinte d’adresse, noms, identifiant externe, attributs personnels, valeurs de santé, actes de consentement et appartenances sont détruits ; le pseudonyme dérive de l’identifiant interne et non de l’adresse. La fiche reste lisible, vide, pour que son historique d’audit garde un sens, et elle est exclue par construction de tout segment, donc de tout envoi.
• Les agrégats statistiques ne sont pas touchés : ils n’ont jamais porté que des identifiants et des nombres.
• Export de réversibilité : archive complète, un fichier par table, chiffrée membre par membre pour la clé publique fournie par le client. La plateforme ne reçoit jamais de clé privée. L’archive est accompagnée de l’inventaire des tables et de la raison de chaque exclusion ; l’opération est journalisée avec le nombre de personnes concernées.
• Suppression définitive en deux étapes : un premier appel vérifie qu’un export récent existe et délivre un jeton de confirmation à durée courte ; le second déclenche l’effacement. Le compte-rendu — noms de tables, comptes, horodatages, signature — est écrit avant la purge du journal et survit à l’espace supprimé. Il ne contient aucune donnée personnelle.
• Ce qui n’est jamais purgé : les preuves de consentement des contacts encore actifs, les agrégats, et les empreintes de la liste de suppression — ne plus jamais écrire à une adresse est une obligation qui survit à la fiche dont elle provient. Les adresses de cette liste sont conservées chiffrées, liées à leur ligne, jamais en clair.

Exploitation et déploiement

• Aucune opération manuelle en production : les migrations de schéma sont du code embarqué dans la version et exécutées au déploiement, jamais une commande lancée à la main.
• Déploiement par artefact de build vérifié — sans historique, sans tests, sans outillage de développement — publié seulement après une intégration continue verte. Le retour arrière consiste à redéployer la version précédente.
• Intégration continue bloquante : analyse statique, vérification de types, contrat d’API régénéré et comparé, tests unitaires, d’intégration et d’isolation entre espaces, détection de secrets, audit des dépendances, démarrage réel de l’artefact.
• Environnement de préproduction distinct, avec base dédiée et données synthétiques générées, où chaque version est validée avant la production. Aucune donnée de production hors production : ni copie de sauvegarde, ni restauration ailleurs, ni extrait dans un artefact d’intégration.
• Aucun secret dans les dépôts : toutes les variables sensibles sont posées dans l’environnement d’exécution. Le démarrage refuse une valeur vide, une valeur d’exemple, une longueur insuffisante ou deux secrets identiques.
• Coffre de secrets d’exploitation : les secrets sont conservés dans le gestionnaire de secrets de l’hébergeur et projetés à l’exécution ; ils ne figurent ni dans les manifestes de déploiement ni dans les images.
• Les clés d’accès à l’infrastructure sont soumises à une rotation annuelle programmée.

Sécurité opérationnelle

• Protection contre la force brute sur les clés d’API : limitation des échecs d’authentification par adresse IP. Limitation de débit par jeton sur les pages publiques.
• Journalisation des événements de sécurité : authentifications refusées, clés révoquées, dépassements de seuils, rupture de chaîne d’audit, écart d’ancrage.
• Fichiers d’export chiffrés au repos, livrés par un lien signé valable quinze minutes et limité en nombre de téléchargements ; le lien ne figure jamais dans le journal des livraisons de webhooks.
• Messages signés DKIM par la plateforme au moment de l’envoi (les clés ne quittent pas le périmètre), adresses de retour signées : un rebond ou une plainte forgés sont refusés avant lecture. Webhooks reçus des prestataires signés avec horodatage, rejeu refusé.
• Supervision et alertes : disponibilité des services, sondes publiques et certificats TLS surveillés en continu, alertes adressées à l’exploitation.
• Courriers opérationnels de la plateforme émis depuis un domaine dédié, distinct des domaines d’envoi des clients, authentifié en SPF, DKIM et DMARC, par un relais qui exige TLS.
• Garde contre les cibles internes (SSRF) pour les webhooks, les connexions des workflows et leur vérification : adresses canonisées avant décision, connexion épinglée sur l’adresse validée, redirections jamais suivies.
• Bornes de taille sur ce qui entre et ce qui se calcule : archives importées, fichiers des workflows, enregistrements CSV, valeurs produites par un rendu ; expressions régulières exécutées par un moteur linéaire, sous budget.
• Surveillance des dépendances logicielles et des vulnérabilités publiées.
• Procédure de gestion des incidents de sécurité écrite : qualification, confinement, notification à la CNIL dans les 72 heures, information des clients concernés.
• Signalement responsable d’une vulnérabilité : security@dataventure.com.

Hébergement de données de santé (HDS)

Dernière mise à jour : 2026-10-13 · Questions et signalements : security@dataventure.com