--- title: "La connexion d'une app web suisse, sans cloud américain" summary: "Ce qu'il faut vérifier avant de confier la connexion de vos utilisateurs à un fournisseur, et les réponses d'EAuth : hébergement, export, contrat, exception." author: "Samuel Krauss" author_title: "Founder" publisher: "Elchi Studios" published: 2026-10-03 updated: 2026-10-09 url: https://elchi.dev/fr/journal/la-connexion-d-une-app-web-suisse-sans-cloud-americain language: fr translation_of: https://elchi.dev/en/journal/sign-in-for-a-swiss-web-app-without-a-us-cloud tags: ["eauth","hosting","data-protection","switzerland"] words: 1290 --- # La connexion d'une app web suisse, sans cloud américain *Par Samuel Krauss, Founder. Publié le 3 octobre 2026.* > Ce qu'il faut vérifier avant de confier la connexion de vos utilisateurs à un fournisseur, et les réponses d'EAuth : hébergement, export, contrat, exception. Si vous développez une application web en Suisse et confiez la connexion à un fournisseur, les adresses e-mail et les hashes de mots de passe de vos utilisateurs vivent là où vit ce fournisseur. Pour la plupart des plus connus, c'est une entreprise américaine, soumise au droit américain, sur des serveurs que vous ne choisissez pas. Ce n'est pas forcément un problème. C'est une question à laquelle votre déclaration de protection des données doit répondre, et qu'un client d'entreprise posera dans son questionnaire de sécurité avant de signer. Nous exploitons EAuth, un fournisseur OpenID Connect, depuis la Suisse, sur eauth.me. Cet article est la liste de contrôle que j'utiliserais pour juger n'importe quel fournisseur de connexion, le nôtre compris, avec ce que fait EAuth sur chaque point. Y compris le seul point où notre réponse n'est pas « uniquement en Europe ». ## Où sont les serveurs, et qui les exploite Demandez les serveurs et les entreprises qui sont derrière, pas un badge. Depuis le 3 octobre 2026, EAuth tourne sur notre propre cluster : huit serveurs chez cinq fournisseurs dans quatre pays. - Deux entrées, là où se termine la connexion chiffrée d'un navigateur : Hetzner à Falkenstein et UpCloud à Amsterdam. Quand l'une tombe, l'autre reprend le trafic. - Deux nœuds applicatifs, qui servent tous deux des connexions en même temps : Infomaniak à Genève et Scaleway à Amsterdam. - Trois nœuds PostgreSQL : Tavuru à Francfort, Hetzner à Nuremberg et Scaleway à Paris. La réplication vers les deux réplicas est synchrone : une modification ne compte comme écrite qu'une fois que les trois la détiennent. - Un observateur chez Infomaniak à Genève, qui contrôle les autres depuis l'extérieur. Les photos de profil et les logos sont dans un stockage objet chez Infomaniak, avec une copie nocturne chez Scaleway. Aucun proxy tiers n'est placé devant tout cela : la connexion d'un navigateur se termine sur une entrée que nous exploitons, et de là, elle circule entre les nœuds sur notre propre réseau chiffré. Chaque connexion utilise TLS 1.3 et rien de plus ancien, et les domaines envoient HSTS avec preload. Deux services DNS voient les résolutions de noms et rien d'autre : Cloudflare héberge nos zones, et ClouDNS répond pour le seul nom qui pointe vers les entrées en bonne santé. Aucun des deux ne voit une requête ou une connexion. ## L'exception : les mails EAuth envoie des mails : le lien qui confirme une adresse, la réinitialisation du mot de passe, les invitations, l'avis qu'une passkey a été ajoutée. Ces mails partent via Resend, une entreprise américaine. Notre envoi est réglé sur sa région UE, que Resend situe en Irlande, mais sa propre documentation indique que les données du compte restent aux États-Unis, quelle que soit la région. L'adresse du destinataire et le texte de chaque mail passent donc par une entreprise américaine. Depuis le 3 octobre, ce n'est plus un cas marginal. Aucune application ne reçoit de compte dont l'adresse n'a pas été confirmée, donc chaque nouveau compte reçoit au moins un mail via Resend. Je préfère que vous le lisiez ici plutôt que de le découvrir dans une réponse à un questionnaire. ## Ce qui est stocké, et sous quelle forme Demandez ce que contient la base de données et sous quelle forme. EAuth stocke les hashes de mots de passe avec Argon2id (64 MiB de mémoire, trois itérations), les refresh tokens, codes et codes de récupération uniquement sous forme de condensés SHA-256, et les clés de signature et identifiants de tiers chiffrés en AES-256-GCM sous une clé qui ne se trouve pas dans la base. Un dump de celle-ci ne donne que du texte chiffré et des condensés. Les sessions enregistrent le navigateur et la plateforme, « Firefox on Windows », jamais l'en-tête User-Agent brut, et le pays en deux lettres, jamais une adresse IP. Les limites de débit ne conservent une adresse que pour la durée de leur fenêtre. La liste complète de ce qui est traité et pour combien de temps figure à l'annexe A des conditions : sept lignes dans un tableau. ## Ce que vous pouvez emporter C'est là que la plupart des fournisseurs sont les plus faibles. Demandez : si je pars, mes utilisateurs doivent-ils réinitialiser leur mot de passe ? Avec EAuth, la réponse est non. La console exporte une application avec ses utilisateurs, ses organisations et ses réglages en JSON, à tout moment, sans nous demander, et l'export contient les hashes des mots de passe sous leur forme d'origine : Argon2id pour toute personne qui s'est connectée chez nous, ou le hash avec lequel elle a été importée si elle ne l'a pas encore fait. Un fournisseur qui accepte Argon2id peut les importer, et vos utilisateurs se connectent comme avant. Cela fonctionne aussi dans l'autre sens : EAuth importe Argon2id, bcrypt, scrypt et PBKDF2-SHA256, et remplace chacun par Argon2id à la connexion suivante de la personne. Pour moi, pouvoir partir est une fonctionnalité. Un fournisseur qui garde en otage les hashes de vos utilisateurs ne vous offre pas un service, il vous offre un bail. ## Ce que dit le contrat Un contrat de sous-traitance au sens de l'art. 28 du RGPD et de la LPD suisse n'est pas un document supplémentaire à négocier. C'est l'annexe B des conditions d'EAuth, et il s'applique dès que vous avez un compte. Les conditions disent que les données ne sont traitées qu'en Suisse et dans l'Espace économique européen, ce qui est conservé et pour combien de temps, que chaque version reste publiée avec sa date, qu'une modification importante est annoncée 30 jours à l'avance, que l'ajout d'un sous-traitant l'est aussi, et qu'aucun audit de sécurité indépendant n'a encore été réalisé. Cette dernière phrase y figure parce que l'alternative serait de vous laisser supposer le contraire. Lisez la clause sur les transferts à côté du paragraphe sur les mails plus haut. La région d'envoi des mails est dans l'UE ; l'entreprise qui l'exploite ne l'est pas, et c'est l'écart que j'ai nommé. ## Ce que la technique doit faire de toute façon L'emplacement des données ne remplace pas les bases. Quel que soit le fournisseur que vous choisissez, il devrait exiger PKCE sur chaque requête d'autorisation, comparer les redirect URIs à l'identique, renouveler les refresh tokens à chaque utilisation et mettre fin à toute la chaîne quand un token déjà renouvelé est présenté à nouveau, proposer les passkeys et un second facteur, et compter chaque tentative de mot de passe par adresse et par compte avant de la vérifier. Il devrait aussi refuser de remettre à votre application un compte dont personne n'a confirmé l'adresse e-mail : une adresse non confirmée est un nom que n'importe qui pourrait taper. EAuth fait chacune de ces choses, et `email_verified` vaut toujours true dans ses ID tokens. L'annexe C des conditions liste les mesures telles qu'elles sont mises en œuvre, avec leurs chiffres. ## Les limites Les limites sont les mêmes pour toutes les applications : 25 applications par compte, 20 redirect URIs par application, et 120 requêtes de token par minute et par application, qu'un développeur relève à 600 dans la console. Au-delà, demandez, et nous relevons la limite. Il n'y a pas de contrat de niveau de service : la clause 4.1 des conditions le dit en une phrase, parce qu'un chiffre que nous ne pouvons pas assumer est pire que pas de chiffre du tout. ## Ce qui n'est pas fait EAuth n'a pas été audité par un tiers indépendant. La page de statut status.elchi.dev est en ligne, et la disponibilité mesurée du cluster y figurera une fois qu'un mois complet aura été mesuré ; d'ici là, il n'y a pas de chiffre à citer, et je n'en citerai pas. Les deux seront publiés ici quand ils existeront, quel que soit le résultat. ## Sources 1. [Federal Act on Data Protection (FADP)](https://www.fedlex.admin.ch/eli/cc/2022/491/en), Swiss Confederation, consulté le 2026-10-03 2. [Art. 28 GDPR, Processor](https://gdpr-info.eu/art-28-gdpr/), gdpr-info.eu, consulté le 2026-10-03 3. [Password Storage Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html), OWASP, consulté le 2026-10-03 4. [Choosing a Region](https://resend.com/docs/dashboard/domains/regions), Resend, consulté le 2026-10-03 5. [RFC 9700: Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/rfc/rfc9700), IETF, consulté le 2026-10-03 6. [HSTS Preload List Submission](https://hstspreload.org/), hstspreload.org, consulté le 2026-10-03