Comment nous avons construit email.eu · Partie 1 sur 7

Aucun fournisseur américain : la règle qui a construit email.eu

Une phrase dans notre documentation interne a tranché plus de débats que tout ce que nous avons écrit depuis : uniquement des fournisseurs européens, aucun américain, ni dans le produit ni dans ce dont il dépend. Ce que cette règle a exclu, ce qu'elle a rapporté, et comment nous la tenons. Partie 1 d'une série sur la construction d'email.eu.

Très tôt, nous avons écrit une phrase dans notre documentation interne, et cette phrase a tranché plus de débats que tout ce que nous avons écrit depuis : uniquement des fournisseurs européens. Aucun fournisseur américain, nulle part dans le produit ni dans ce dont il dépend.

Pas « hébergé en Europe ». Pas « conforme au RGPD », ce que tout fournisseur affirme. Aucune entreprise américaine où que ce soit dans la chaîne, point final. Cet article explique ce qu'il coûte réellement de tenir cette phrase, et pourquoi nous y voyons la seule version de « souverain » qui signifie quelque chose. C'est aussi la première partie d'une série sur la façon dont nous avons construit email.eu, car presque chaque décision technique de la suite découle de cette seule règle.

La localisation n'est pas la juridiction

La version confortable de la souveraineté consiste à louer une région à Francfort chez un hyperscaler américain et à poser un drapeau européen sur la page des tarifs. Les octets sont en Allemagne. L'entreprise qui les contrôle répond à Washington, CLOUD Act compris. Où vos données se trouvent physiquement et qui peut être juridiquement contraint de les remettre sont deux questions distinctes, et seule la seconde compte le jour où cela compte.

Notre règle ne porte donc pas sur la géographie. Elle porte sur la juridiction, tout au long de la chaîne de fournisseurs. Si une entreprise américaine peut atteindre les données, le drapeau sur le centre de données est un décor.

Ce que la règle a exclu

Une règle qu'on ne sent jamais n'est pas une règle. Voici les endroits où le choix commode, celui par défaut dans le secteur, était américain, et ce que nous avons fait à la place.

Le choix par défautNotre réponse
Cloudflare devant toutRien devant. Le réseau et la protection anti-DDoS propres à OVHcloud, et des services conçus pour être exposés directement.
reCAPTCHA ou hCaptcha à l'inscriptionAltcha, une preuve de travail que votre navigateur résout localement. Rien n'appelle un service de vérification.
Stripe pour les paiementsMollie, depuis les Pays-Bas.
SendGrid ou SES pour les e-mails transactionnelsRemails, un fournisseur européen, open source et respectueux de la vie privée.
Google AnalyticsUmami, auto-hébergé et sans cookies, sur notre propre cluster.
Datadog ou Grafana Cloud pour la supervisionDes sondes auto-hébergées et une page de statut publique alimentée par elles.
Google FontsDes polices téléchargées une fois à la compilation et servies depuis nos propres serveurs.

Chaque ligne fut une vraie décision avec un vrai coût. L'option américaine est en général la plus soignée, avec la meilleure documentation et la plus grande communauté. Dire non à toutes, chaque fois, sans laisser d'exceptions s'installer « juste pour cette fois », voilà le véritable travail. Une seule installation Cloudflare « temporaire » ou un extrait d'analytics, et l'affirmation en page d'accueil devient discrètement fausse.

Ce qu'elle a rapporté

Le bénéfice tient dans un chiffre : trois. C'est la liste complète des entreprises qui traitent des données clients chez email.eu. OVHcloud pour l'infrastructure, Mollie pour les paiements, Moneybird pour la facturation. Française, néerlandaise, néerlandaise. Nous avons publié la liste entière, cas limites inclus, et c'est la même que dans notre contrat de sous-traitance.

La plupart des suites collaboratives ont une liste de sous-traitants longue de plusieurs dizaines d'entreprises, car chaque service cloud commode greffé au fil des ans y figure. La nôtre est courte pour une raison structurelle : tout ce qui touche votre courrier, vos fichiers ou votre identité est un logiciel que nous exploitons nous-mêmes, et non un service auquel nous envoyons vos données. La règle l'a imposé. Quand on ne peut pas acheter le service américain, on finit par faire tourner l'équivalent open source sur ses propres machines, et vos données cessent de voyager.

Soyons francs sur les angles, car une affirmation de transparence avec des angles morts vaut moins que rien. Notre code source et notre chaîne de compilation vivent sur GitHub, qui est américain. Du code, pas des données clients, mais nous le disons plutôt que d'espérer que personne ne demande. La liste honnête complète figure dans l'article sur les sous-traitants.

Nous l'exploitons donc nous-mêmes

La règle signifie que les parties difficiles nous incombent. Pas d'API de messagerie externalisée, pas de service d'identité externalisé, pas de support tiers contenant nos données. Nous exploitons les serveurs de messagerie, le fournisseur d'identité, le stockage de fichiers, la couche vidéo, le moteur de facturation, tout cela, sur une infrastructure que nous contrôlons chez OVH.

C'est là le but de la règle, pas son prix. Un fournisseur qui exploite sa propre couche la comprend, peut la réparer à trois heures du matin, et peut regarder un client dans les yeux en lui disant où va chaque octet. Le reste de cette série est une visite guidée de son fonctionnement concret :

Si la destination vous convient et que vous vous interrogez sur le trajet, la réponse pratique est plus courte qu'on ne le croit : la plupart des équipes déménagent en un week-end, et rien ne change pour le monde extérieur jusqu'à un seul enregistrement DNS, tout à la fin.