Architecture de sécurité
Confidentialité par l'architecture
Schweizerform est un système zero-knowledge. Chaque soumission est verrouillée dans le navigateur du répondant avant de quitter la page, et les clés qui la déverrouillent n'existent jamais en dehors de la session du propriétaire. Cette page explique comment — et ce que cela nous interdit de faire.
Chiffrement symétrique
AES-256-GCM
Chiffrement asymétrique
RSA-OAEP 2048, SHA-256
Dérivation de clé
PBKDF2-SHA-256 · 100 000
Juridiction d'hébergement
Suisse — Infomaniak
Premiers principes
Trois piliers de confiance.
La sécurité n'est pas une fonctionnalité ajoutée par-dessus un outil de formulaire. C'est la forme autour de laquelle l'outil a été construit.
Principe 01
Infrastructure suisse
Pas « ne le fera pas ». Ne peut pas. Un opérateur de confiance est un point unique de défaillance — et un aimant à injonctions, à menaces internes et à identifiants volés. Notre système nous retire totalement du chemin de déchiffrement.
Principe 02
Conforme à la nFADP
Une clause de « résidence des données » dans un contrat n'est que du papier — changer de juridiction tient à un avenant. Nous exploitons toute la pile — application, base de données, stockage, e-mail — sur une infrastructure suisse. Aucun prestataire américain ou européen ne se trouve jamais sur le chemin des données.
Principe 03
Le navigateur du répondant appartient au répondant.
La page publique du formulaire ne charge aucun script tiers. Pas de Google Analytics, pas de Sentry, pas de Mixpanel, pas d'Intercom, pas de pixel publicitaire. Le seul réseau que le répondant touche est le nôtre.
Hiérarchie des clés
Quatre couches de clés. Aucune sur nos serveurs.
Votre Access Code, saisi dans votre navigateur, produit en mémoire une Master Key. Cette Master Key ouvre la Form Key de chaque formulaire. La Form Key ouvre la clé privée du formulaire. Cette clé privée ouvre la clé à usage unique de chaque soumission. La chaîne se termine dans votre tête — jamais dans notre base de données.
Couche 01 · Secret du propriétaire
Access Code
Origin: Une phrase secrète que vous choisissez (6 caractères minimum)
Storage: Uniquement dans la tête du propriétaire — jamais transmis
↓ PBKDF2-SHA-256 · 100 000 itérations · sel de 32 octets
Couche 02 · Dérivée
Master Key
Algorithm: AES-256-GCM (utilisé comme clé de chiffrement de clé)
Storage: Uniquement en mémoire du navigateur · effacée à la déconnexion
↓ déballe
Couche 03 · Par formulaire
Form Key
Algorithm: AES-256-GCM · lié à form_key_creation
Storage: Stockée dans la base de données — mais uniquement la version scellée, jamais en clair
↓ déballe
Couche 04 · Par formulaire
Clé privée RSA du formulaire
Algorithm: RSA-OAEP 2048 · SHA-256 · lié à form_private_key
Storage: Dans la base de données, scellée sous la Form Key
↓ déballe
Couche 05 · Par soumission
Submission Key
Algorithm: AES-256-GCM · lié à formId:submissionId
Storage: Scellée sous la clé publique RSA du formulaire
Cycle de vie de la soumission
Le texte en clair entre dans le navigateur du répondant. Le texte en clair sort du navigateur du propriétaire. Entre les deux, uniquement des octets brouillés.
Navigateur du répondant
Chiffrer → envoyer
- 1Charge la page publique du formulaire. Reçoit uniquement le verrou public du formulaire (une clé publique RSA) — jamais la clé qui l'ouvre.
- 2Si le formulaire est protégé par mot de passe, les questions restent sur le serveur jusqu'à vérification du mot de passe — la liste des questions n'atteint même pas le navigateur avant cela.
- 3Remplit les réponses. Sélectionne les fichiers à joindre.
- 4Le navigateur génère une Submission Key AES-256 neuve via l'API Web Crypto intégrée — la même que celle livrée avec Chrome, Firefox et Safari.
- 5Chiffre la charge utile des réponses avec AES-GCM, lié à l'ID du formulaire et à l'ID de la soumission, pour qu'il ne puisse pas être rejoué ailleurs.
- 6Chiffre chaque fichier séparément. Génère un nom de fichier aléatoire pour chacun.
- 7Scelle la Submission Key avec le verrou public RSA du formulaire (OAEP, SHA-256).
- 8Envoie la clé scellée, le vecteur d'initialisation et les blobs chiffrés à notre API.
Serveur Schweizerform
Persister → oublier
- 1Vérifie la taille de la requête, les limites de fréquence et la vérification du mot de passe le cas échéant.
- 2Écrit les blobs chiffrés dans le stockage compatible S3 d'Infomaniak sous {userId}/forms/{formId}/submissions/{submissionId}/.
- 3Enregistre la clé scellée et le vecteur d'initialisation dans MySQL sur la ligne de soumission. C'est la seule donnée « en forme de clé » que nous conservons — et elle est inutile sans votre Access Code.
- 4Incrémente le compteur de réponses du formulaire.
- 5Renvoie 201 Created. Fin de l'implication du serveur.
- 6Nous ne voyons jamais le texte en clair. Nous ne dérivons jamais de clé. Nous ne détenons jamais de clé privée.
Déchiffrement — côté propriétaire
Lorsque vous ouvrez une soumission, votre navigateur parcourt la chaîne de quatre clés à l'envers : Access Code → Master Key → Form Key → Clé privée du formulaire → Submission Key → contenu lisible. Tout se passe localement ; rien de déchiffré ne quitte jamais votre appareil.
Modèle de menace
Ce qu'un attaquant devrait faire pour lire vos formulaires.
Nous avons documenté ces scénarios pour que nos clients et leurs équipes sécurité puissent les examiner. Si vous identifiez un cas que nous n'avons pas couvert, écrivez à support@schweizerform.ch.
| Adversaire | Ce qu'il obtient | Ce que nous faisons pour y répondre |
|---|---|---|
| Fuite ou vol d'un dump de base de données | Blobs de données scellés et blobs de clés scellés. Aucun contenu lisible. | Tout est chiffré avec AES-256-GCM. Sans l'Access Code du propriétaire, aucune ligne ne se déchiffre. |
| Administrateur serveur ou initié compromis | Idem. Notre code côté serveur ne voit jamais la Master Key ni aucun texte en clair. | Un journal d'audit en mode append-only consigne en interne chaque action privilégiée. La production suit le principe du moindre privilège ; nos ingénieurs ne peuvent pas lire les soumissions via le tableau de bord. |
| Injonction / ordonnance légale de divulgation | Blobs de texte chiffré et métadonnées (date de création, IP, ID de requête). | Nous pouvons nous conformer à une injonction valide tout en ne livrant rien de lisible. Nous le documentons sur la page publique. |
| Vol du cookie de session du propriétaire | Accès à l'enveloppe du tableau de bord — mais chaque formulaire reste verrouillé derrière l'Access Code, que nous ne conservons pas dans la session. | Les sessions sont courtes et glissent avec l'activité. L'Access Code doit être saisi à chaque session et vit uniquement en mémoire du navigateur. |
| Phishing / extension de navigateur malveillante | Tout ce que l'utilisateur saisit. Cela se situe en dehors de notre périmètre de confiance. | Content Security Policy stricte sur la page publique. Aucun script tiers autorisé. Lors de l'onboarding, nous mettons les propriétaires en garde contre les appareils partagés ou non fiables. |
| Force brute sur l'Access Code | Un mur lent de 100 000 itérations PBKDF2 entre eux et chaque tentative de devinette. | Chaque tentative coûte environ 80 ms dans un navigateur moderne. Nous limitons les connexions côté serveur, verrouillons le compte après plusieurs échecs et orientons les propriétaires vers des Access Codes longs et difficiles à deviner. |
| Soumission falsifiée / rejouée | Des octets parasites qui échouent à l'authentification au moment du déchiffrement. | Chaque texte chiffré est lié à son ID de formulaire et de soumission. Un blob rejoué contre un autre formulaire échoue tout simplement à l'authentification et est rejeté. |
Infrastructure
Chaque octet, chaque serveur, en Suisse.
Serveurs applicatifs, base de données MySQL, stockage de fichiers compatible S3 et e-mail transactionnel fonctionnent tous chez Infomaniak — hébergeur 100 % suisse, contrôlé par ses employés. Les seuls appels externes depuis nos serveurs sont une brève recherche d'IP (timeout de 3 secondes, fail-closed) et Stripe pour la facturation des propriétaires.
Stripe ne touche jamais aux données des répondants. Il ne voit que les coordonnées de facturation du propriétaire pour l'abonnement lui-même.
Serveurs applicatifs (Next.js)
Infomaniak · CH
Base de données MySQL
Infomaniak · CH
Stockage objet (compatible S3)
Infomaniak · CH
Messagerie transactionnelle (SMTP)
Infomaniak Mail · CH
DNS / bordure réseau
Infomaniak Envoy · CH
Résolution Geo IP
ipinfo.io · serveur-à-serveur uniquement
Facturation (propriétaires uniquement)
Stripe · propriétaires uniquement, jamais les données des répondants
Limites honnêtes
Des choses que nous ne pouvons pas faire — et que nous ne prétendrons pas faire.
Le zero-knowledge tranche dans les deux sens. Voici ce que cela vous coûte, dit clairement.
Récupérer un Access Code perdu.
Votre Access Code est le point de départ de chaque clé qui protège vos formulaires. Nous ne le recevons jamais, ne le stockons jamais, ne l'envoyons jamais par e-mail. S'il est perdu, les données scellées sous lui le sont aussi. Vous pouvez le changer depuis votre compte — chaque formulaire est alors rechiffré sous le nouveau code.
Réinitialiser un mot de passe et "déchiffrer vos données automatiquement."
Certains services « chiffrés » le font — ce qui signifie tacitement qu'ils avaient les clés depuis le départ. Pas nous. Une réinitialisation de mot de passe vous remet dans le tableau de bord, mais il vous faut toujours votre Access Code pour lire un formulaire.
Consulter le contenu d'une soumission pour le support.
Si vous nous écrivez « qu'a soumis untel mardi ? », nous ne pouvons honnêtement pas répondre. Notre équipe support voit les mêmes octets brouillés que tout le monde. Nous pouvons aider sur les métadonnées : compteurs, horodatages, facturation.
Exécuter de l'IA / des analyses sur le contenu des soumissions.
Nous n'entraînons pas de modèles d'IA sur vos données de formulaire — car nous ne les détenons sous aucune forme exploitable pour cela. Les chiffres agrégés proviennent des métadonnées côté serveur, jamais des réponses elles-mêmes.
Ce qui est chiffré, ce qui ne l'est pas
Visibilité totale sur notre visibilité.
Certaines données doivent rester lisibles pour que le système fonctionne — votre adresse e-mail (pour la réinitialisation du mot de passe) et le verrou public du formulaire (pour que les répondants puissent y chiffrer). Tout le reste reste opaque.
| Données | Visible pour nous | Pourquoi / comment protégé |
|---|---|---|
| Réponses au formulaire (textes, nombres, choix) | Partiel | AES-256-GCM. La clé ne quitte jamais le navigateur du propriétaire. |
| Téléversements de fichiers (PDF, images, etc.) | Partiel | Chaque fichier est chiffré avec la même Submission Key à usage unique. Les noms d'origine sont remplacés côté serveur par des identifiants aléatoires. |
| Titres de formulaires, libellés des questions | Partiel | Stockés sur l'enregistrement du formulaire pour que la page publique puisse l'afficher. Masqués aux répondants derrière la protection par mot de passe tant qu'il n'est pas accepté. |
| E-mail + nom du propriétaire | Partiel | Nécessaires pour la connexion, la facturation, les codes à usage unique et la réinitialisation du mot de passe. Traitées comme des données personnelles selon la nLPD et le RGPD. |
| Hachage du mot de passe du propriétaire | Partiel | bcrypt avec 12 itérations. Nous ne voyons jamais le mot de passe lui-même, seulement son hachage. |
| Horodatages de soumission + IP du répondant | Partiel | Nécessaires pour la limitation de fréquence et l'audit. L'IP est consignée dans le journal d'audit ; elle n'apparaît jamais en clair dans la charge utile du formulaire. |
| Texte chiffré de la soumission + clé enveloppée | Partiel | Stockés sur S3 et MySQL. L'un comme l'autre sont inutiles sans la chaîne de clés qui se termine dans votre Access Code. |
| Évènements d'analyse du site (côté opérateur) | Agrégé | Pseudonymes (empreinte hachée), hébergées par nous sur nos serveurs suisses. Utilisées uniquement pour le site marketing et notre observabilité interne — jamais pour les réponses des répondants. |
Conformité
Alignée sur les règles qui comptent pour les données sensibles.
Schweizerform n'est pas un outil case-à-cocher de conformité, mais son architecture est pensée pour rendre la conformité significativement plus simple pour nos clients.
nLPD
Loi suisse révisée sur la protection des données
En vigueur depuis le 1er septembre 2023. Nous alignons sur ses exigences : résidence des données en Suisse, capacité de notification des incidents, droits des personnes concernées, et chiffrement des données personnelles au repos comme en transit.
Architecture alignée · Conforme dès la conceptionRGPD
Règlement général sur la protection des données de l'UE
Architecture compatible : base légale pour les données limitées côté propriétaire que nous conservons ; les données des répondants ne quittent jamais la Suisse (pas de clauses contractuelles types nécessaires) ; un contrat de sous-traitance est disponible sur demande pour les clients professionnels.
Architecture alignée · DPA sur demandeHIPAA
Loi américaine sur la portabilité et la responsabilité de l'assurance maladie
Nos primitives cryptographiques sont compatibles avec la Security Rule HIPAA (chiffrement, contrôle d'accès, audit). Nous ne signons pas de Business Associate Agreement pour l'instant — parlons-en si vous en avez besoin, nous vous montrerons où cela se situe dans la feuille de route.
Primitives compatibles · BAA sur la feuille de routeAu-delà du chiffrement
Les contrôles ennuyeux qui soutiennent tout le reste.
Journal d'audit append-only (côté opérateur)
Nous tenons un journal interne et inviolable de chaque connexion, code à usage unique, publication de formulaire et événement de facturation — avec IP, navigateur et identifiant de requête — utilisé pour la revue de sécurité et la réponse aux incidents. C'est un outil interne, pas un tableau de bord client.
Session & OTP
Les sessions glissent jusqu'à 7 jours, avec des jetons opaques de 128 caractères dans des cookies HttpOnly + Secure + SameSite. Code à usage unique à 6 chiffres lors de l'inscription et de la réinitialisation du mot de passe.
Limitation de débit
Limitations token-bucket persistantes sur la connexion, les codes à usage unique, les tentatives de mot de passe et d'Access Code. Survit aux redémarrages et fonctionne sur plusieurs instances.
Protection CSRF
La cross-site request forgery est bloquée par un jeton double-submit sur toute la surface authentifiée. La route publique du formulaire en est exemptée par conception (pas de session), mais elle est soumise à la limitation de fréquence.
CSP & en-têtes stricts
La page publique du formulaire interdit les scripts tiers au niveau du navigateur via la Content Security Policy. HSTS, X-Frame-Options et X-Content-Type-Options sont appliqués partout.
Journal d'erreurs & analyse du site, en interne
Notre logger d'erreurs et nos statistiques du site marketing tournent sur nos propres serveurs suisses. Sentry, Google Analytics et Mixpanel n'entrent pas en jeu — et les données de soumission ne sont jamais touchées par l'un ou l'autre.
Divulgation
Vous avez trouvé quelque chose ?
Nous prenons les signalements au sérieux et répondons dans un délai d'un jour ouvré. Veuillez procéder de manière responsable — nous créditons les chercheurs sur demande.
Contact
support@schweizerform.chClé PGP sur demande. Incluez les étapes de reproduction, l'impact et les éventuels journaux — et n'incluez pas de données client réelles dans votre rapport.
Questions courantes