(Confiance)
Sécurité chez Verne Software
Verne Software fonctionne sur des serveurs d'OVHcloud, dans un centre de données en France. La plateforme est donc hébergée dans l'UE. L'entreprise elle-même est enregistrée en Serbie, hors de l'UE et de l'EEE : notre propre accès aux données est donc un transfert vers un pays tiers ; /gdpr et /dpa expliquent comment ce transfert est couvert.
Cette page liste ce qui est en place au 5 novembre 2026. Chaque mesure ci-dessous figure aussi à l'annexe II de l'accord de traitement des données (DPA), qui est la version qui nous engage. Si une mesure ne figure pas dans la liste, ne présumez pas qu'elle existe.
Où elle fonctionne
- Serveurs : OVHcloud, un centre de données en France.
- Sauvegardes : OVHcloud Object Storage, région de Paris, sur un site différent de celui des serveurs.
- E-mails sortants (codes de connexion, liens de récupération, avertissements de suppression) : Scaleway Transactional Email, Paris.
- Chaque société qui touche aux données des clients figure sur /subprocessors, avec le lieu et la garantie de chacune.
Ce qui est en place
| Sujet | Ce que nous faisons |
|---|---|
| Chiffrement en transit | Les sites web et l'API sont servis en TLS avec des certificats Let's Encrypt, gérés par le reverse proxy. Le HTTP simple est redirigé vers HTTPS, et les navigateurs reçoivent l'instruction de n'utiliser que HTTPS (HSTS, un an). |
| Exposition réseau | Le trafic web et API atteint la plateforme par un seul reverse proxy. En dehors de lui, seuls les ports de notre propre serveur de messagerie sont ouverts sur internet. Les bases de données, le cache et les services internes se trouvent sur des réseaux de conteneurs internes, et leurs ports ne sont pas publiés. |
| Passerelle | Chaque requête d'API passe par une seule passerelle edge. Elle vérifie la clé d'API et la limite de débit avant que la requête n'atteigne un service. Une clé porte un ensemble de scopes (Relay, Gate, Clockwork, Passepartout) ; une clé sans le scope voulu est refusée avec un 403. |
| Filtrage des attaques | Les requêtes sont limitées en débit à la périphérie et filtrées par CrowdSec, qui bloque les adresses associées à des attaques. Si CrowdSec lui-même est injoignable, le trafic passe : nous avons choisi de ne pas bloquer nos propres clients pendant un redémarrage. |
| Isolation des clients | Chaque identité d'utilisateur final est liée au client qui la possède. La clé d'un client ne voit que ses propres utilisateurs. La même adresse e-mail chez deux clients correspond à deux personnes différentes, chacune avec son propre mot de passe, ses propres sessions et ses propres e-mails. |
| Clés d'API | Générées à partir de 32 octets aléatoires et stockées uniquement sous forme de hachages SHA-256. Nous ne pouvons pas relire une clé. |
| Mots de passe | Stockés par Ory Kratos sous forme de hachages bcrypt, avec un facteur de coût de 12. Un hachage qu'un client importe depuis un autre système est conservé dans la forme dans laquelle il a été importé. |
| Jetons de bot Telegram | Chiffrés avec AES-256-GCM. |
| Second facteur | Les utilisateurs finaux et les comptes du tableau de bord peuvent activer une application d'authentification (TOTP) et des codes de récupération. C'est facultatif. |
| Journaux | Le service d'identité est réglé pour ne pas écrire de valeurs sensibles dans ses journaux. Les journaux d'accès du reverse proxy, qui contiennent des adresses IP, font l'objet d'une rotation quotidienne et sont conservés 14 jours au plus. |
| Accès aux serveurs | Les serveurs sont administrés par notre opérateur en SSH, avec authentification par clé. Les déploiements s'exécutent depuis un pipeline CI doté de sa propre clé. La clé utilisée pour la supervision automatisée ne peut exécuter qu'une liste fixe de commandes. |
| Panneau d'administration | Servi sur un hôte distinct (jules.vernesoft.com). Il exige une identité d'administrateur, séparée des comptes clients. |
| Actions du personnel | Ce que notre personnel fait sur le compte d'un client depuis le panneau d'administration est inscrit dans le journal d'audit de ce client, avec le type d'acteur staff. |
| Contrôle des changements | La suite de tests automatisés doit réussir avant que les images ne soient construites et publiées. Le déploiement est effectué par le pipeline, pas à la main. |
Journal d'audit
Les actions importantes sont consignées dans un journal qui ne peut pas être modifié par le service : la base de données refuse toute mise à jour, et refuse toute suppression autre que le retrait programmé des entrées au-delà de la durée de conservation et la suppression du compte d'un client. Une action faite dans le tableau de bord ou avec une clé d'API est écrite dans la même transaction de base de données que l'action elle-même : aucune des deux n'est enregistrée sans l'autre.
Ce qu'il contient : clés d'API créées et révoquées, paramètres de projet, membres et rôles, organisations, leurs rôles et leurs membres, fournisseurs de connexion et paramètres de sécurité, endpoints de webhook, règles de suppression automatique, domaine d'expédition des e-mails des utilisateurs finaux, connexions et changements de mot de passe des utilisateurs finaux, exports des utilisateurs finaux faits à la demande du titulaire du compte, et le réglage de conservation du journal lui-même. Chaque entrée contient des identifiants, l'heure, l'adresse IP et le user agent. Elle ne contient ni adresse e-mail, ni nom, ni mot de passe.
Deux limites, indiquées parce qu'elles comptent pour un auditeur. Les échecs de connexion ne sont pas enregistrés, parce que le service d'identité ne les signale pas. Les connexions par Telegram ne le sont pas non plus.
Conservation : 7 jours avec Free, 30 avec Pro, 90 avec Advanced ; avec une offre sur contrat, la durée convenue, ou 90 jours si le contrat ne dit rien. Le titulaire du compte peut raccourcir la fenêtre, pas l'allonger. À lire dans le tableau de bord ou par l'API : Journal d'audit dans la documentation.
Sauvegardes
Trois bases de données contiennent des données personnelles de clients : les comptes et la configuration, les identités et identifiants des utilisateurs finaux, et la configuration des webhooks. Chacune fait l'objet d'un export (dump) une fois par jour et est chiffrée sur le serveur avec une clé publique avant que la copie ne le quitte. La clé privée n'est détenue que par notre opérateur et ne se trouve pas sur le serveur. Les copies chiffrées vont dans OVHcloud Object Storage, région de Paris, où OVHcloud les chiffre aussi au repos.
Chaque copie est verrouillée contre la suppression et l'écrasement pendant 30 jours, puis supprimée par une règle d'expiration, au plus tard 35 jours après sa création. La clé d'accès propre au serveur ne peut ni supprimer ni écraser une copie : un attaquant qui prend le serveur ne peut donc pas effacer les sauvegardes avec lui.
Non sauvegardés : le contenu des e-mails, les boîtes de messagerie du support, les statistiques d'utilisation et la télémétrie opérationnelle.
La fraîcheur des sauvegardes est vérifiée automatiquement ; une alarme se déclenche si la dernière copie réussie date de plus de 26 heures. Une restauration d'une sauvegarde de production a été testée le 15 octobre 2026 : le nombre de lignes des 70 tables correspondait à celui des bases en service.
Supervision et statut
- Un contrôle de santé externe automatisé s'exécute toutes les 3 heures.
- Un watchdog sur le serveur s'exécute toutes les 3 minutes.
- /status affiche 90 jours de disponibilité quotidienne pour six composants (API, tableau de bord, Relay, Gate, Clockwork, Passepartout) et l'historique des incidents.
Incidents
Si une violation de données à caractère personnel touche les données d'un client, nous en informons ce client, en nous adressant au contact en matière de protection des données désigné dans le DPA, dans les meilleurs délais après en avoir pris connaissance. La notification indique ce qui s'est passé, quelles catégories de personnes concernées et combien d'enregistrements environ sont touchés, les conséquences probables, et ce que nous avons fait ou proposons de faire. Nous en disons plus à mesure que nous l'apprenons. Nous ne donnons pas de nombre d'heures : le DPA dit « dans les meilleurs délais ». À titre de comparaison, un responsable du traitement dispose de 72 heures à partir du moment où il a pris connaissance d'une violation pour la notifier à son autorité de contrôle (article 33 du RGPD).
Pour les clients sans DPA, la politique de confidentialité dit la même chose : les clients sont informés dans les meilleurs délais.
Signaler une vulnérabilité
Écrivez à security@vernesoft.com ; la même adresse figure dans /.well-known/security.txt. Indiquez ce que vous avez trouvé, où, et comment le reproduire. Testez uniquement sur votre propre compte, et arrêtez-vous dès que vous voyez les données d'un autre client.
Ce que cette page ne couvre pas
- Nous ne détenons aucune certification de sécurité.
- Le trafic entre conteneurs sur un même serveur n'est pas chiffré avec TLS.
- Les webhooks et les requêtes HTTP planifiées vont à l'adresse que le client définit. Ils ne sont chiffrés que si cette adresse commence par
https://. - Les fournisseurs de connexion qu'un client active (Telegram, Google, GitHub) fonctionnent selon leurs propres conditions.
Dernière vérification : 5 novembre 2026. Questions : support@vernesoft.com.