Table des matières
Les plateformes de gestion des traductions occupent une position critique dans le cycle de vie du développement logiciel. Elles gèrent des textes produits non publiés, des campagnes marketing, des mentions légales et des communications internes — du contenu qui, s'il est exposé prématurément, peut nuire aux marques, violer des accords de confidentialité (NDA) et compromettre des lancements de produits. Pourtant, la sécurité dans le domaine de la localisation a historiquement été une réflexion secondaire.
Chez Better i18n, nous avons adopté une approche différente. La sécurité n'est pas une fonctionnalité ajoutée après coup. Elle est intégrée dans chaque couche de la plateforme, de la façon dont les utilisateurs s'authentifient à la façon dont les chaînes de traduction sont stockées et transmises. Dans cet article, nous détaillons l'architecture de sécurité qui protège vos flux de traduction.
Authentification : Quatre Méthodes, Un Principe
Le principe est simple : offrir aux équipes la méthode d'authentification adaptée à leur posture de sécurité, sans compromis sur la protection.
E-mail et Mot de Passe avec Vérification
La base. Chaque compte créé avec un e-mail et un mot de passe passe par une vérification obligatoire de l'adresse e-mail avant que l'accès soit accordé. Cela élimine les comptes fantômes et garantit que chaque utilisateur de votre organisation est un être humain vérifié avec une vraie boîte de réception.
Nous imposons des exigences strictes en matière de mot de passe et hachons toutes les informations d'identification avec des algorithmes de hachage modernes et salés. Les mots de passe en clair n'atteignent jamais notre base de données.
OAuth : Google & GitHub
Pour les équipes déjà investies dans Google Workspace ou GitHub Organizations, l'authentification unique (SSO) OAuth supprime entièrement la gestion des mots de passe. Les utilisateurs s'authentifient via leur fournisseur d'identité existant, héritant des politiques MFA et de session déjà en place.
C'est particulièrement utile pour les équipes de développement. Les développeurs vivent déjà dans GitHub — les laisser s'authentifier avec la même identité réduit les frictions et élimine encore un ensemble d'identifiants à gérer.
Codes à Usage Unique par E-mail
L'OTP par e-mail offre une authentification sans mot de passe aux utilisateurs qui ont besoin d'un accès sans la contrainte de gérer des identifiants. Chaque code est à usage unique et limité dans le temps, ce qui le rend idéal pour les collaborateurs externes, les traducteurs freelance ou les parties prenantes qui examinent les traductions occasionnellement.
Pas de mot de passe signifie pas de mot de passe à hameçonner, réutiliser ou attaquer par force brute.
Clés d'Accès WebAuthn (Passkeys)
Les passkeys sont l'avenir de l'authentification, et Better i18n les prend en charge dès aujourd'hui. Construits sur la norme WebAuthn, les passkeys utilisent la cryptographie à clé publique où la clé privée ne quitte jamais l'appareil de l'utilisateur. Il n'y a pas de secret partagé à intercepter, pas de code à hameçonner, et pas de mot de passe à voler.
Pour les équipes d'entreprise qui imposent une authentification résistante au phishing, les passkeys offrent la garantie la plus solide disponible dans les applications web modernes.
Gestion des Organisations et des Équipes
L'authentification permet aux utilisateurs d'entrer. L'autorisation détermine ce qu'ils peuvent faire une fois à l'intérieur.
Better i18n prend en charge plusieurs organisations par compte, chacune avec son propre ensemble isolé de projets, de membres et de facturation. C'est important pour les agences gérant plusieurs clients, les entreprises avec des unités commerciales distinctes, et les consultants travaillant dans plusieurs organisations.
Contrôle d'Accès Basé sur les Rôles
Trois rôles définissent des limites de permissions claires :
- Owner — Contrôle total sur l'organisation, y compris la facturation, la gestion des membres et les opérations destructives comme la suppression de l'organisation.
- Admin — Gestion des projets et des membres sans accès à la facturation ni aux actions destructives au niveau de l'organisation.
- Member — Travail de traduction quotidien au sein des projets assignés. Pas d'accès administratif.
C'est délibérément simple. Les systèmes RBAC complexes avec des dizaines de permissions granulaires créent de la confusion et des erreurs de configuration. Trois rôles, clairement définis, réduisent la surface d'attaque pour les erreurs de sécurité liées aux permissions.
Invitations de Membres
Les nouveaux membres rejoignent via une invitation par e-mail avec une page d'acceptation dédiée à /invite/{inviteId}. Les invitations sont limitées à une organisation spécifique et expirent après une période définie. Pas d'inscription ouverte, pas d'adhésion en libre-service — chaque membre est explicitement invité par quelqu'un qui en a l'autorité.
Sécurité des Clés API : Défense en Profondeur
Les pipelines CI/CD, les systèmes de build et les scripts d'automatisation ont besoin d'un accès programmatique. Les clés API rendent cela possible, mais elles constituent également l'un des vecteurs les plus courants d'exposition accidentelle (pensez aux fichiers .env qui fuient et aux secrets commités).
Better i18n applique trois couches de protection :
Portée au niveau de l'organisation. Chaque clé API est liée à une seule organisation. Une clé créée pour l'Organisation A ne peut pas accéder aux données de l'Organisation B, même si les deux organisations partagent le même propriétaire. Cela empêche les mouvements latéraux en cas de compromission d'une clé.
Stockage haché. Les clés API sont hachées avant d'être écrites dans la base de données. Nous stockons le hachage, pas la clé. Si un attaquant obtient d'une façon ou d'une autre un accès en lecture à notre base de données, il obtient des hachages — pas des clés utilisables. La clé brute est affichée une seule fois au moment de la création et jamais plus.
Révocation instantanée. Lorsqu'une clé est compromise — ou même soupçonnée de l'être — elle peut être révoquée immédiatement depuis le tableau de bord. La révocation est instantanée et permanente. Il n'y a pas de période de grâce, pas d'accès mis en cache, pas de sessions persistantes.
Infrastructure : Renforcée depuis la Périphérie
La plateforme fonctionne sur une pile choisie spécifiquement pour ses caractéristiques de sécurité :
Cloudflare Workers gère tout le calcul en périphérie (edge). Cela signifie une atténuation automatique des DDoS, une terminaison TLS et une distribution géographique sans gestion de serveurs. Il n'y a pas de ports ouverts, pas d'accès SSH, et pas de surface d'attaque traditionnelle.
PlanetScale fournit la couche base de données avec un chiffrement automatique au repos, des contrôles d'accès précis et une journalisation des audits. Les branches de base de données permettent de réviser les changements de schéma avant le déploiement — le même flux de travail de pull request que les développeurs utilisent pour le code.
Cloudflare R2 stocke les actifs avec chiffrement au repos et en transit. Les contrôles de résidence des données permettent aux organisations de conserver leurs données dans des régions spécifiques, ce qui compte pour le RGPD et les exigences de souveraineté des données.
Conformité : SOC 2, ISO 27001, RGPD
Les équipes d'approvisionnement des entreprises ont besoin de documentation, pas de promesses. Better i18n est aligné sur trois grands cadres de conformité :
SOC 2 Type II fournit une vérification indépendante par un tiers de nos contrôles de sécurité. L'audit couvre la sécurité, la disponibilité et la confidentialité — les trois critères de service de confiance les plus pertinents pour une plateforme de gestion des traductions.
La certification ISO 27001 signifie que notre système de management de la sécurité de l'information (SMSI) suit la norme internationale pour identifier, évaluer et gérer les risques de sécurité de manière systématique.
La conformité au RGPD couvre les accords de traitement des données, le droit à l'effacement, la minimisation des données et le consentement transparent. Pour les équipes européennes et toute organisation traitant des données d'utilisateurs de l'UE, c'est non négociable.
Chiffrement : En Transit et Au Repos
Toutes les données circulant entre vos systèmes et Better i18n sont chiffrées avec TLS 1.3 — la dernière version du protocole, offrant des poignées de main plus rapides et des suites de chiffrement plus solides que ses prédécesseurs.
Les données au repos sont chiffrées avec AES-256 sur toutes les couches de stockage. Cela inclut la base de données, le stockage d'objets et tous les caches temporaires. Les clés de chiffrement sont gérées via les systèmes de gestion de clés des fournisseurs d'infrastructure avec rotation automatique.
Les sessions d'authentification utilisent des cookies sécurisés, HttpOnly et SameSite gérés par Better Auth. Cette combinaison empêche le cross-site scripting (XSS) d'accéder aux jetons de session, bloque les attaques de cross-site request forgery (CSRF) et garantit que les cookies ne sont transmis que via HTTPS.
Conclusion
La sécurité dans la localisation ne consiste pas à cocher des cases — bien que nous cochions celles-là aussi. Il s'agit de reconnaître que le contenu de traduction est une propriété intellectuelle sensible qui mérite la même protection que le code source et les données clients.
Better i18n offre quatre méthodes d'authentification (dont des passkeys résistantes au phishing), une isolation au niveau de l'organisation avec contrôle d'accès basé sur les rôles, une gestion renforcée des clés API, une infrastructure chiffrée sur le réseau de périphérie de Cloudflare, et un alignement sur SOC 2, ISO 27001 et le RGPD.
Vos traductions méritent une meilleure sécurité. Maintenant, elles l'ont.
