Vous nous confiez des données professionnelles et personnelles sensibles. Voici, en toute transparence, les mesures techniques et organisationnelles qui les protègent.
Chaque carte correspond à une mesure réellement en place dans la plateforme.
Chaque point ci-dessous correspond à un contrôle effectivement implémenté.
Nous traitons la sécurité comme un processus continu. Certains renforcements sont en cours (authentification à double facteur, règles de complexité du mot de passe) : nous préférons les présenter honnêtement comme des axes d'amélioration plutôt que de sur-promettre. Notre dossier complet détaille l'ensemble de nos mesures et répond aux questionnaires de sécurité.
Hébergement, chiffrement, sauvegardes, sous-traitants (DPA), registre RGPD, disponibilité, réponses aux questionnaires de sécurité : nous partageons ces documents avec les prospects et clients qui en font la demande.
Demander le dossier completNotre infrastructure fonctionne chez Amazon Web Services, en région Paris (eu-west-3). Les serveurs applicatifs et la base de données sont isolés dans un réseau privé dédié, sans exposition directe à Internet : la base n'est accessible que via un accès dédié sécurisé (bastion géré). L'essentiel de l'infrastructure est décrit sous forme de code, versionné et reproductible, ce qui limite le risque de configuration manuelle divergente entre environnements.
Les données sont chiffrées au repos avec l'algorithme AES-256, à l'aide de clés gérées par AWS KMS, pour la base de données comme pour les sauvegardes. En transit, les échanges sont protégés par TLS : le trafic HTTP non chiffré est automatiquement redirigé vers HTTPS, et la connexion entre l'application et la base de données est elle-même forcée en TLS. Les secrets (identifiants, clés d'API, clé de signature des jetons) sont stockés dans un coffre géré (AWS Secrets Manager) et injectés à l'exécution, jamais écrits en clair dans le code source.
Deux instances applicatives sont déployées derrière un répartiteur de charge, ce qui permet de maintenir le service en cas de défaillance isolée d'une instance. La base de données est répartie sur plusieurs zones de disponibilité, avec bascule automatique en cas d'incident sur une zone. Les mises en production se font par déploiements progressifs, avec retour arrière automatique si les contrôles de santé échouent après une nouvelle version. Un pare-feu applicatif (WAF) filtre en amont le trafic malveillant et limite le débit par adresse IP.
Trois mécanismes de sauvegarde se complètent : une sauvegarde continue (point-in-time), une sauvegarde quotidienne conservée 35 jours, et une sauvegarde mensuelle conservée 12 mois. Une copie est répliquée chaque jour vers une seconde région européenne (Irlande). Ces sauvegardes sont testées par des restaurations réelles, documentées par une attestation à chaque exercice.
Un tableau de bord centralise en temps réel les indicateurs techniques : erreurs, latence, trafic, échecs de sauvegarde, avec des alertes automatiques envoyées à l'équipe. Les tentatives de connexion échouées sont journalisées (horodatage, adresse IP, cause) et analysées, avec l'identifiant tenté conservé sous forme masquée. Ce journal d'audit est conservé 12 mois glissants, puis purgé automatiquement.
L'authentification repose sur un jeton signé JWT (HMAC-SHA512), sans session serveur classique. Les mots de passe sont hachés avec BCrypt, jamais stockés en clair, et les tentatives de connexion sont limitées par compte et par adresse IP sur une fenêtre glissante de 15 minutes : au-delà de quelques échecs, la tentative suivante est refusée sans même vérifier le mot de passe. Ce blocage est temporaire et se lève de lui-même. Les autorisations sont appliquées par rôles à chaque point d'accès de l'API, et un changement de mot de passe ou la désactivation d'un compte révoque les jetons déjà émis, avec une propagation effective en moins d'une minute entre les instances applicatives.
Le lien de connexion à usage unique, envoyé par e-mail, permet de se connecter sans saisir, transmettre ni stocker de mot de passe. Ce mode réduit, sur notre plateforme, les risques liés au stockage, à la réutilisation ou à une attaque par force brute d'un mot de passe. Sa sécurité dépend en revanche de celle de la messagerie de l'utilisateur. Les demandes de lien sont elles-mêmes limitées en fréquence, par adresse e-mail et par adresse IP, pour empêcher les abus.
Chaque organisation dispose d'un périmètre de données cloisonné. Les contrôles d'autorisation restreignent l'accès d'un utilisateur aux seules données de sa société et de ses établissements, à chaque appel d'API. Les points d'accès qui manipulent des données rattachées à une organisation sont recensés et intégrés à une suite de tests automatisés, rejouée à chaque mise en production, qui reproduit notamment des tentatives d'accès inter-organisations. Aucune vulnérabilité connue permettant un accès non autorisé aux données d'une autre organisation n'est identifiée à ce jour.
Nos collaborateurs suivent une sensibilisation continue aux enjeux de sécurité, et les accès administrateur sont volontairement restreints à un nombre réduit de personnes. Le code fait l'objet d'audits périodiques, avec un plan de remédiation suivi dans le temps, en complément d'une analyse de sécurité statique (SAST) exécutée en continu. Une assurance cyber-risques est souscrite, couvrant notamment l'assistance en cas d'incident (expertise sécurité, communication de crise, récupération de données). Un contact dédié permet de nous signaler une vulnérabilité de façon responsable.