> a propos > conditions politiques > Mesures de sécurité

Mesures de sécurité

Mesures de sécurité de ProcessMind

Date d’entrée en vigueur : 14 septembre 2026

Le présent document décrit les mesures techniques et organisationnelles (« TOM ») mises en œuvre par ProcessMind B.V. pour protéger la confidentialité, l’intégrité et la disponibilité des Données client. ProcessMind applique une approche de défense en profondeur, dans le cadre de laquelle plusieurs couches de sécurité indépendantes protègent les Données client à tous les niveaux — du réseau et de l’infrastructure à l’identité, à l’autorisation, à l’isolation des données, au chiffrement, à la surveillance et au développement logiciel. Ces mesures complètent l’Avenant relatif au traitement des données, la Politique de confidentialité et la Politique d’hébergement SaaS. ProcessMind examine et met à jour ces mesures au moins une fois par an.

Les Données client ne sont jamais vendues à des tiers, partagées avec eux ni utilisées par eux à leurs propres fins.

1. Sécurité de l’infrastructure

1.1 Plateforme cloud. ProcessMind est hébergé exclusivement sur Amazon Web Services (AWS) dans l’UE (Francfort, Allemagne, eu-central-1). AWS détient les certifications ISO 27001, ISO 27017, ISO 27018, SOC 1/2/3 et PCI DSS. Consultez Programmes de conformité AWS pour obtenir la liste complète.

1.2 Architecture sans serveur. La logique applicative de ProcessMind s’exécute sur AWS Lambda et des services gérés par AWS. ProcessMind n’exploite pas de serveurs d’application de longue durée gérés par le client, ce qui élimine une grande partie des tâches de mise à jour des systèmes d’exploitation et de renforcement de la sécurité des serveurs.

1.3 Périmètres réseau. ProcessMind gère un VPC AWS pour les contrôles de base de données et de réseau. Aurora PostgreSQL s’exécute dans des sous-réseaux privés sans sortie vers Internet, n’est pas accessible publiquement et les journaux de flux VPC sont activés. Par défaut, ProcessMind ne place pas les fonctions Lambda de l’application dans le VPC. Les fonctions Lambda accèdent à Aurora par l’intermédiaire de l’API de données AWS RDS via TLS, au moyen de l’authentification IAM et Secrets Manager.

1.4 Diffusion de contenu et contrôles en périphérie. Le site Web destiné aux clients, l’application monopage (SPA) frontale et le trafic des ressources publiques sont diffusés par Amazon CloudFront. Toutes les distributions CloudFront imposent une politique TLS minimale de TLS 1.2 (2021). Les distributions du site Web et de l’application SPA frontale ajoutent également des en-têtes de réponse de sécurité, notamment HTTP Strict Transport Security (HSTS), Content Security Policy (CSP), frame-ancestors 'none', X-Frame-Options: DENY, X-Content-Type-Options, une politique de référent et une politique d’autorisations. La distribution des ressources publiques utilise le contrôle d’accès à l’origine CloudFront afin de maintenir le compartiment d’origine privé. Le trafic API destiné aux clients est traité séparément par Amazon API Gateway : le trafic de requêtes/réponses HTTPS est diffusé par une API HTTP sur un sous-domaine API dédié, et les connexions client en temps réel sont diffusées par une API WebSocket distincte d’API Gateway sur un sous-domaine WebSocket dédié.

1.5 Séparation des environnements. Les environnements de production et de développement utilisent des comptes AWS, des bases de données et des piles d’infrastructure distincts. Les identifiants des développeurs ne donnent pas accès aux Données client de production.

2. Chiffrement des données

2.1 Chiffrement en transit. Toutes les données transmises entre les clients et les services ProcessMind sont chiffrées au moyen de TLS 1.2 ou d’une version ultérieure. Les points de terminaison destinés aux clients sont accessibles via HTTPS. Les compartiments S3, les rubriques SNS et les files d’attente SQS créés directement par ProcessMind imposent un accès exclusivement SSL. L’accès à la base de données par l’intermédiaire de l’API de données RDS et les autres appels aux services AWS utilisent HTTPS/TLS.

2.2 Chiffrement au repos. Aurora PostgreSQL est chiffré au repos au moyen de clés AWS KMS gérées par le client, avec rotation automatique des clés. Les compartiments S3 de données client et d’exploitation créés directement par ProcessMind, notamment ceux destinés aux téléversements, aux ressources et aux journaux d’accès, utilisent des clés KMS gérées par le client. Les groupes de journaux CloudWatch, les rubriques SNS et les files d’attente SQS créés directement par ProcessMind utilisent également des clés KMS gérées par le client. Les compartiments d’origine du site Web et de l’interface frontale gérés par SST utilisent le chiffrement côté serveur S3 géré par AWS (SSE-S3 / AES-256), plutôt que des clés KMS gérées par le client.

2.3 Gestion des clés et des secrets. Les clés de chiffrement de la base de données sont gérées de manière centralisée par AWS KMS, et leur accès est régi par des politiques IAM respectant le principe du moindre privilège. Les identifiants de la base de données sont stockés dans AWS Secrets Manager. Le secret principal Aurora et le secret de l’utilisateur applicatif à accès restreint font l’objet d’une rotation automatique tous les trente (30) jours. Les clés et secrets de production ne sont jamais stockés dans le code source ; les identifiants réservés au développement sont isolés de la production. Certaines ressources auxiliaires gérées par AWS/CDK/SST continuent d’utiliser le chiffrement géré par AWS lorsque le service ou le framework ne permet pas de configurer des clés gérées par le client.

3. Isolation et résidence des données

3.1 Isolation des locataires. Chaque locataire client dispose d’une instance de base de données dédiée et isolée. Les Données client ne sont jamais mélangées à celles d’autres clients au niveau de la base de données. Les métadonnées partagées (par exemple, les enregistrements de compte, la facturation et les correspondances entre utilisateurs et locataires) sont stockées dans une base de données distincte à locataires multiples, assortie de contrôles d’accès stricts. Les tables partagées dont le périmètre est défini par locataire et organisation sont en outre protégées par des politiques de sécurité au niveau des lignes (RLS) de PostgreSQL, appliquées au moyen d’un contexte de base de données défini pour chaque requête.

3.2 Résidence des données. Toutes les Données client, y compris les bases de données, les fichiers téléversés, les sauvegardes et les résultats de requêtes, sont stockées exclusivement dans l’UE (Francfort, Allemagne). Lorsqu’un sous-traitant ultérieur situé en dehors de l’EEE est engagé pour une activité de traitement spécifique (par exemple, le traitement par un modèle d’IA ou le traitement des paiements), le transfert est couvert par un mécanisme de transfert approprié, comme décrit dans l’Avenant relatif au traitement des données, et le sous-traitant ultérieur ainsi que le lieu de son traitement figurent dans la Liste des sous-traitants ultérieurs.

3.3 Conservation et suppression des données. Les délais de conservation et de suppression sont indiqués à la section 6 de l’Avenant relatif au traitement des données. Les clients peuvent supprimer leurs données à tout moment au moyen de l’application ou en contactant ProcessMind. Les copies de sauvegarde sont supprimées à l’expiration des périodes de conservation applicables aux sauvegardes (section 7.1).

4. Gestion des identités et des accès

4.1 Authentification. ProcessMind prend en charge l’authentification unique (SSO) via Microsoft Entra ID (Azure AD), Google OAuth 2.0/OIDC et LinkedIn OAuth 2.0/OIDC. ProcessMind agit en tant que partie utilisatrice et ne stocke pas les mots de passe des utilisateurs. L’authentification multifacteur est imposée par le fournisseur d’identité — par exemple, lorsqu’une organisation connecte Microsoft Entra ID (Azure AD), les propres politiques MFA et d’accès de cette organisation s’appliquent.

4.2 Gestion des sessions. Les sessions de navigateur utilisent des jetons Web JSON (JWT) signés, transmis au moyen de cookies sécurisés HttpOnly comportant les attributs SameSite et Secure. Les signatures des jetons sont validées à chaque requête authentifiée.

4.3 Modèle d’autorisation. ProcessMind ne s’appuie pas sur les autorisateurs natifs d’API Gateway pour ses API applicatives principales. L’autorisation est appliquée dans des enveloppes partagées de gestionnaires Lambda qui valident l’état de la session et le périmètre du locataire avant l’exécution de la logique métier. Les routes publiques sont explicitement autorisées pour les flux non authentifiés, les webhooks, l’ingestion d’événements et les requêtes préliminaires CORS. Les points de terminaison API externes utilisent des gestionnaires d’authentification dédiés. L’accès aux Données client est limité au contexte du locataire ou de l’organisation authentifié.

4.4 Principe du moindre privilège. Les systèmes internes respectent le principe du moindre privilège. Les rôles IAM sont limités aux ressources minimales nécessaires lorsque le framework permet un périmètre précis. Certains rôles générés par SST/CDK utilisent des politiques gérées ou intégrées plus larges pour les liaisons et l’exécution ; ces cas sont examinés, limités à des ressources lorsque cela est possible et consignés comme exceptions explicites.

4.5 Contrôles d’accès des employés. L’accès des employés aux systèmes internes est géré par Active Directory avec SSO et MFA obligatoire. Le contrôle d’accès basé sur les rôles (RBAC) garantit que l’accès aux Données client est limité au personnel autorisé qui en a besoin pour exercer ses fonctions. Les droits d’accès sont examinés périodiquement.

5. Journalisation, surveillance et audit

5.1 Journalisation centralisée. La journalisation des accès à l’API HTTP et des accès WebSocket est activée avec des champs JSON structurés, et les journaux sont écrits dans Amazon CloudWatch Logs avec une durée de conservation d’un (1) an. Ces groupes de journaux d’accès sont chiffrés au moyen d’une clé AWS KMS gérée par le client. Les journaux de l’application sont centralisés dans des groupes de journaux Amazon CloudWatch chiffrés au moyen d’une clé AWS KMS gérée par le client et conservés pendant dix (10) ans. Des groupes de journaux d’audit et de télémétrie distincts sont également chiffrés au moyen d’une clé AWS KMS gérée par le client et conservés pendant dix (10) ans. Le groupe d’exportation des journaux du moteur Aurora PostgreSQL est conservé pendant une (1) semaine.

5.2 Éléments journalisés et éléments non journalisés. ProcessMind journalise les événements d’accès à l’API HTTP et aux WebSocket — l’heure de la requête, les identifiants de requête, la route ou le chemin, le statut de réponse et la latence. Les journaux d’accès ne comprennent ni l’adresse IP source de l’appelant ni son agent utilisateur. ProcessMind journalise également les événements d’authentification, les chemins d’échec asynchrones et l’activité applicative Lambda associée dans des groupes de journaux CloudWatch centralisés. Les journaux de flux VPC sont activés. ProcessMind n’active actuellement pas la journalisation standard des accès CloudFront sur le site Web, l’application monopage (SPA) frontend ou les distributions de ressources publiques.

5.3 Surveillance et alertes. Les alarmes et tableaux de bord CloudWatch surveillent l’état du système, les files d’attente de lettres mortes et les défaillances pertinentes pour la sécurité. Les échecs de traitement asynchrone sont acheminés vers des files d’attente de lettres mortes chiffrées (conservation de quatorze (14) jours ; deux (2) jours pour les files d’attente de miniatures et d’index de recherche), et les alarmes DLQ déclenchent des notifications SNS aux fins d’enquête. En outre, ProcessMind utilise Sentry pour le suivi en temps réel des erreurs de l’interface, la surveillance des performances et la relecture des sessions. Les relectures de session sont enregistrées uniquement pour les sessions au cours desquelles une erreur se produit ; le texte, les champs de formulaire et les médias sont masqués ou bloqués dans les relectures. Les données Sentry sont ingérées dans l’UE (Francfort) et se limitent aux données d’utilisation de ProcessMind (erreurs de navigateur, traces de performance, métadonnées de l’appareil et enregistrements de relecture masqués). Sentry figure dans la liste des sous-traitants ultérieurs.

5.4 Protection des journaux. Les journaux sont stockés dans des groupes de journaux CloudWatch dédiés, soumis à des contrôles d’accès et chiffrés au repos. Les journaux de production et de développement sont séparés par environnement et par compte.

6. Validation automatisée des contrôles et gestion des vulnérabilités

6.1 Mesures prises par ProcessMind. ProcessMind exécute cdk-nag dans le cadre de son flux de travail de synthèse et de déploiement de l’infrastructure, en utilisant plusieurs ensembles de règles du secteur (notamment AWS Solutions, NIST 800-53 et PCI DSS). Des rapports par pile sont générés et examinés dans le cadre de la gestion des modifications de l’infrastructure. Les constats sont classés comme corrigés, comme risques acceptés ou comme améliorations prévues.

6.2 Gestion des exceptions. Lorsque le framework le permet, les suppressions sont consignées dans un registre central, limitées aux piles concernées et assorties d’une justification écrite ; lorsqu’une pile contient une suppression intégrée, celle-ci est documentée avec la pile concernée. Lorsqu’un constat est corrigé, la suppression correspondante est mise à jour ou supprimée. ProcessMind ne considère pas une suppression comme une dispense générale d’examen.

6.3 Mesures que ProcessMind ne prend pas actuellement. ProcessMind suit et examine les exceptions importantes aux contrôles de l’infrastructure. Les principales sont les suivantes :

par défaut, les Lambdas de l’application ne sont pas placées dans le VPC ; elles accèdent à Aurora via l’API de données RDS, au moyen de TLS, avec une authentification IAM et Secrets Manager
aucune partie du service n’est protégée par AWS WAF : AWS WAF ne prend pas en charge les API HTTP d’API Gateway, et les autres points d’entrée ne sont pas non plus protégés par WAF (les connexions WebSocket utilisent des jetons HMAC à courte durée de vie ; les restrictions géographiques liées aux paiements sont appliquées dans le système de paiement) ; les distributions statiques ne disposent pas non plus de la journalisation standard des accès CloudFront
la reprise de la base de données repose sur les sauvegardes automatisées d’Aurora et la restauration à un instant donné, plutôt que sur un plan AWS Backup distinct ou sur Aurora Enhanced Monitoring
il n’existe ni réplication S3 entre régions ni S3 Object Lock pour les compartiments modifiables
certaines ressources de support gérées par AWS/CDK/SST utilisent le chiffrement géré par AWS ou des politiques IAM générées plus larges lorsque le service ne propose pas d’alternative contrôlable par le client

Le registre complet des suppressions est tenu à jour avec le code d’infrastructure et est disponible sur demande. L’utilisation de cdk-nag ensembles de règles constitue une validation des contrôles d’ingénierie, et non une certification externe, une opinion d’audit ou une attestation juridique de conformité à HIPAA, NIST ou PCI DSS.

6.4 Gestion des dépendances. Les dépendances logicielles font l’objet d’une surveillance continue afin de détecter les vulnérabilités connues. Les vulnérabilités critiques et de gravité élevée sont corrigées dans un délai cible de sept (7) jours. Les dépendances sont mises à jour selon un cycle régulier.

6.5 Cycle de développement logiciel sécurisé (SDLC). ProcessMind applique une approche de défense en profondeur au développement logiciel. Toute modification destinée à la production doit franchir plusieurs niveaux indépendants de validation automatisée avant son déploiement :

Analyse statique et sûreté des types : le mode strict de TypeScript et ESLint imposent, au moment de la compilation, la correction des types, la sécurité contre les valeurs nulles et les pratiques de codage pertinentes pour la sécurité.
Revue de code assistée par l’IA : l’analyse assistée par l’IA apporte un point de vue supplémentaire lors de la revue des demandes de fusion afin de repérer les risques de sécurité, les erreurs logiques et les écarts par rapport aux conventions, en complément des tests automatisés.
Tests unitaires et d’intégration : une suite complète de tests Vitest valide la logique métier, les modes d’accès aux données, le comportement de l’API et la gestion des erreurs au moyen de ressources AWS réelles dans l’environnement de développement.
Tests de bout en bout : les tests de navigateur basés sur Playwright vérifient les flux de travail essentiels des utilisateurs, notamment l’authentification, le téléversement de données, la modélisation des processus, la simulation et l’isolation multi-tenant.
Analyse de conformité de l’infrastructure : cdk-nag valide le code d’infrastructure par rapport à plusieurs référentiels de conformité à chaque modification.
Analyse des vulnérabilités des dépendances : les audits automatisés des dépendances empêchent les vulnérabilités connues critiques et de gravité élevée d’atteindre la production.

La revue humaine porte principalement sur l’architecture, les limites de sécurité et les décisions de conception, plutôt que sur l’inspection du code ligne par ligne. Lorsque des modifications structurelles, sensibles du point de vue de la sécurité ou liées à l’infrastructure sont concernées, une approbation humaine explicite est requise en plus de la validation automatisée.

Toutes les couches de validation sont appliquées par l’intermédiaire de l’intégration continue (CI), en tant que contrôles obligatoires avant fusion pour les modifications apportées à l’application et à l’infrastructure sur la branche principale. Le contenu du site Web et les mises en production des ressources statiques suivent un processus de mise en production distinct et documenté, assorti de contrôles au moment du déploiement — notamment un contrôle automatisé visant à vérifier que les documents juridiques sont à jour — plutôt que le contrôle CI de l’application. Les correctifs urgents en production peuvent contourner le contrôle CI, mais doivent être suivis de l’exécution complète du pipeline et d’un examen post-incident dans les vingt-quatre (24) heures.

7. Sauvegarde et reprise après sinistre

7.1 Sauvegardes automatisées. Amazon Aurora effectue des sauvegardes continues et automatisées, conservées pendant sept (7) jours. Les sauvegardes sont chiffrées à l’aide des mêmes clés KMS gérées par le client que les bases de données sources.

7.2 Restauration à un instant donné. Aurora permet une restauration à un instant donné, à n’importe quelle seconde comprise dans la période de conservation des sauvegardes, ce qui permet une restauration rapide en cas de corruption de données ou de suppression accidentelle.

7.3 Durabilité et gestion des versions S3. Les fichiers téléversés et les artefacts opérationnels sont stockés dans Amazon S3, qui offre une durabilité de 99,999999999 % (11 neuf). La gestion des versions est activée sur le compartiment de téléversement et les compartiments de ressources afin de faciliter la récupération et les retours à une version antérieure. Les compartiments de déploiement du site Web et du frontend contiennent des artefacts de compilation reproductibles et ne sont pas considérés comme un système de sauvegarde. ProcessMind n’active actuellement pas la réplication S3 interrégionale.

7.4 Continuité des activités. Les procédures de reprise après sinistre sont documentées et testées périodiquement. Un résumé est disponible dans le document Reprise après sinistre, continuité des activités et réponse aux incidents. L’architecture repose sur des services gérés AWS au sein de la région eu-central-1, qu’AWS exploite dans plusieurs zones de disponibilité ; le cluster Aurora exécute actuellement une seule instance d’écriture. La reprise de la base de données repose donc sur des sauvegardes automatisées et une restauration à un instant donné, plutôt que sur une instance de secours dans la région. Les sauvegardes Aurora, la durabilité de S3, les files d’attente de lettres mortes et les ressources statiques pouvant être reconstruites à partir de leur source font partie de la stratégie de reprise.

8. Réponse aux incidents

8.1 Notification des incidents. En cas d’incident de sécurité (tel que défini dans l’APD), ProcessMind notifiera les clients concernés dans les meilleurs délais et, lorsque cela est possible, dans les soixante-douze (72) heures suivant la prise de connaissance de l’incident.

8.2 Gestion des incidents. ProcessMind dispose de procédures documentées de réponse aux incidents couvrant leur identification, leur confinement, leur éradication, la reprise et l’examen après incident. Un résumé est disponible dans le document Reprise après sinistre, continuité des activités et réponse aux incidents. Les enseignements tirés des incidents sont intégrés aux contrôles et processus de sécurité.

8.3 Communication. Les notifications d’incident indiquent la nature et l’étendue de l’incident, les catégories de données concernées, les mesures prises pour le contenir et les actions recommandées au client.

9. Mesures organisationnelles

9.1. Gestion de la sécurité de l’information. ProcessMind maintient un système de gestion de la sécurité de l’information conforme aux principes de la norme ISO 27001. ProcessMind a choisi la voie de certification pour la certification ISO 27001 et l’attestation SOC 2 Type II ; le processus formel de certification n’a pas encore commencé.

9.2 Sensibilisation à la sécurité. Tout le personnel ayant accès aux Données client reçoit une formation de sensibilisation à la sécurité. Les bonnes pratiques de sécurité sont intégrées à l’intégration des nouveaux employés, aux flux de travail de développement et aux procédures opérationnelles.

9.3 Gestion des fournisseurs et des sous-traitants ultérieurs. Les sous-traitants ultérieurs sont contractuellement tenus de respecter des normes de protection des données équivalentes à celles décrites dans le présent document. ProcessMind tient à jour une liste publique des sous-traitants ultérieurs et donne un préavis d’au moins trente (30) jours avant de faire appel à un nouveau sous-traitant ultérieur. La conformité des sous-traitants ultérieurs est examinée chaque année.

9.4 Confidentialité. Tout le personnel autorisé à traiter les Données client est soumis à des obligations écrites de confidentialité.

10. Conformité et certifications

Cadre / norme	Statut
RGPD (Règlement général sur la protection des données de l’UE)	Conforme
Résidence des données dans l’UE (Francfort, Allemagne)	Appliquée
Certifications de l’infrastructure AWS (ISO 27001, SOC 2, PCI DSS)	Héritées d’AWS
ISO 27001 (ProcessMind)	Prévue — parcours de certification sélectionné ; processus formel pas encore commencé
SOC 2 Type II (ProcessMind)	Prévue — parcours de certification sélectionné ; processus formel pas encore commencé
Validation automatisée des contrôles d’infrastructure (`cdk-nag` sur AWS Solutions, HIPAA Security, NIST 800-53 R4/R5, PCI DSS 3.2.1, Serverless)	Mise en œuvre à titre de validation des contrôles d’ingénierie, et non de certification
Clauses contractuelles types (CCT) pour les transferts internationaux	Mises en œuvre (voir l’DPA)
Avenant relatif au traitement des données (DPA)	Disponible publiquement

L’utilisation de cdk-nag ensembles de règles ne signifie pas que ProcessMind est formellement certifiée ou qu’elle a fait l’objet d’un audit indépendant au regard de HIPAA, NIST ou PCI DSS. Ces ensembles de règles servent de garde-fous d’ingénierie pour valider la conception de l’infrastructure et suivre explicitement les lacunes.

Pour toute question concernant la sécurité ou la conformité, ou pour demander des documents tels que des rapports d’audit ou des questionnaires de sécurité remplis, veuillez contacter support@processmind.com.