Sécurité

Cette page dit ce que nous protégeons, comment, et ce que nous ne protégeons pas. Le second point compte autant que le premier : une promesse de sécurité sans limites énoncées n'est pas une promesse, c'est un argument de vente.

Elle est écrite pour être lue, pas pour être opposée en cas de litige. Si un passage vous paraît obscur, écrivez à security@veritext.fr — nous le récrirons.

Les trois modes, et ce que le serveur voit dans chacun

Veritext traite vos textes de trois façons. Elles n'offrent pas les mêmes garanties, et l'interface vous dit toujours laquelle est en cours.

Vérification locale — le serveur ne reçoit rien

Le modèle d'analyse est téléchargé une fois dans votre navigateur et y reste en cache. Votre texte est analysé sur votre machine. Ni le texte, ni le score, ni la moindre statistique ne nous parviennent.

Ce que nous voyons : rien. Vous pouvez couper votre connexion après le premier chargement, la vérification continue de fonctionner.

Traitement éphémère — le texte n'existe qu'en mémoire, quelques secondes

Pour la réécriture et la vérification en « mode précision », le calcul doit avoir lieu chez nous. Votre texte est alors chiffré dans votre navigateur, avec une clé négociée directement avec le processus de traitement. Il traverse notre infrastructure sous forme chiffrée, n'est déchiffré que dans la mémoire vive d'un processus isolé, et les tampons sont effacés à la fin.

Ce que nous voyons : la taille des données chiffrées et, à la fin, un nombre de mots — celui qui sert à la facturation. Pas le texte, pas son sujet, pas sa langue.

C'est une garantie technique et organisationnelle, pas mathématique. Nous ne disposons pas d'enclave matérielle. Un attaquant qui prendrait le contrôle du serveur au moment exact d'un traitement pourrait lire le texte en cours. Nous le disons parce que c'est vrai, et parce que prétendre le contraire serait mensonger.

Stockage — nous ne pouvons pas relire votre historique

Vos documents sont chiffrés dans votre navigateur avant tout envoi, avec une clé dérivée de votre mot de passe. Nous ne stockons que des blocs illisibles.

Ce que nous voyons : des octets opaques, leur taille et leur date. Pas les titres, pas le contenu. Une copie complète de nos serveurs et de nos sauvegardes ne donnerait rien sans votre mot de passe.

Comment vos clés sont construites

Votre mot de passe ne quitte jamais votre navigateur. Il sert à dériver, sur votre machine :

• une preuve d'authentification, la seule chose que nous recevons — et dont nous ne conservons qu'une empreinte ;
• une clé de chiffrement, qui ne nous est jamais transmise.

La dérivation utilise Argon2id (64 Mio de mémoire, 3 passes, 4 fils) : elle est volontairement lente et coûteuse en mémoire, pour qu'une attaque par dictionnaire sur un mot de passe volé reste hors de portée. Les documents sont chiffrés en AES-256-GCM.

Ces choix, leurs paramètres exacts et leurs vecteurs de test sont publics : packages/crypto. Les deux implémentations — navigateur et serveur — sont vérifiées l'une contre l'autre à chaque modification.

Le second facteur, et ce qu'il protège vraiment

Vous pouvez ajouter à votre mot de passe un code à six chiffres (application d'authentification) ou une clé d'accès — votre empreinte, votre visage, ou le code de votre appareil. La clé d'accès ne quitte jamais l'appareil : nous n'en recevons que la partie publique, qui ne permet pas de se faire passer pour vous.

Tant que le second facteur n'a pas été présenté, la session n'ouvre rien : elle existe, et aucune de vos données ne lui est accessible. En particulier, l'enveloppe qui contient votre clé de compte n'est pas transmise avant cette étape.

Ce que le second facteur ne fait pas : il protège l'accès à votre compte, pas le contenu de vos documents. Ceux-ci sont chiffrés par une clé dérivée de votre mot de passe seul. Ajouter une clé d'accès ne les protège pas davantage, et perdre votre mot de passe reste irréversible, second facteur ou non. Nous préférons l'écrire que de vous laisser le croire.

Le retirer exige de le présenter. Sans cela, une session volée suffirait à le désactiver, et il ne serait plus qu'un ornement.

Un code ne sert qu'une fois, et les essais sont comptés. Un code à six chiffres n'offre qu'un million de possibilités : sans plafond, quelqu'un qui aurait déjà votre mot de passe finirait par tomber dessus en essayant. Après cinq essais infructueux, le second facteur est bloqué quinze minutes, et le compteur est attaché à votre compte — se reconnecter ne le remet pas à zéro. Un code déjà utilisé est également refusé, afin qu'il ne puisse pas être rejoué par quelqu'un qui vous aurait vu le saisir.

Conséquence à connaître : si vous vous trompez cinq fois, vous devrez patienter un quart d'heure. C'est volontaire, et c'est le prix de la protection précédente.

Le traitement éphémère, et l'empreinte à vérifier

Quand vous demandez une réécriture, votre texte part chiffré pour un seul destinataire : le conteneur qui le traite. Ni notre serveur web, ni notre interface de programmation, ni notre base de données ne peuvent l'ouvrir — et pas davantage la réponse, qui revient chiffrée sous une clé que seuls votre navigateur et ce conteneur savent calculer.

Ce conteneur est le seul endroit où votre texte existe en clair. Il tourne sans accès à Internet, sans accès à notre base, en lecture seule, sa mémoire verrouillée pour qu'aucune page n'atteigne le disque, et sans possibilité de produire un fichier de diagnostic — celui-ci contiendrait votre texte.

L'empreinte que votre client vérifie

7e70a3a9945a8e58f6ea881d52fc9de8e8cbaec25834ae0fbe1fb88278ad616d

C'est l'empreinte de la clé avec laquelle nous signons les clés de chiffrement éphémères. Votre navigateur et nos bibliothèques la vérifient à chaque demande, et refusent de chiffrer si elle ne correspond pas.

Pourquoi elle est ici, et pas seulement dans la réponse de notre interface de programmation : sans cette vérification, quiconque se placerait entre vous et nous pourrait répondre à votre place avec sa clé, et lire tout ce que vous envoyez. La publier sur cette page rend la vérification non circulaire.

Si cette empreinte change un jour sans annonce de notre part, ne l'acceptez pas et écrivez-nous.

Elle a changé une fois, le 25 septembre 2026 — et voici l'ancienne

Le processus qui traite les textes a été déplacé sur la machine qui porte les cartes graphiques. Nous en avons profité pour lui donner une clé neuve, créée directement sur cette machine et qui n'en est jamais sortie — plutôt que d'y recopier l'ancienne.

L'ancienne empreinte n'est plus acceptée par nos clients. Si quelque chose vous la présente aujourd'hui, refusez-la.

Nous publions néanmoins l'ancienne clé publique, et nous continuerons de le faire : elle sert à vérifier les marquages de provenance émis avant cette date. Une signature ne devient pas fausse parce que la clé a été remplacée — elle devient invérifiable si l'on cesse de publier de quoi la contrôler.

Vérifier ce qu'on accepte aujourd'hui et pouvoir vérifier ce qui a été signé hier sont deux choses différentes, et elles n'ont pas la même durée de vie.

Ce que nous ne garantissons pas

Un mot de passe perdu sans kit de récupération rend votre historique définitivement irrécupérable. Nous ne pouvons pas le restaurer : c'est la contrepartie exacte de « nous ne pouvons pas le lire ». Le kit de 24 mots vous est montré une fois, à l'inscription. Conservez-le.

Depuis le 12 septembre 2026, un relais américain voit vos métadonnées. Le parc dont Veritext fait partie a migré son DNS vers Cloudflare, et cinq de nos six noms sont désormais relayés par lui : veritext.fr, www, app, docs, support.

Ce qu'il peut voir : votre adresse IP, l'heure de vos visites, les en-têtes de vos requêtes, vos jetons de session. Ce qu'il ne peut pas voir : vos textes. Ils sont chiffrés dans votre navigateur avant tout envoi, et la clé n'existe que chez vous — un relais qui déchiffre le TLS ne trouve dessous que des octets opaques.

Nous avons obtenu une exception pour api.veritext.fr, qui n'est pas relayé : les appels applicatifs vont directement à nos serveurs, en France.

Nous ne présentons pas ce changement comme neutre. Il ne l'est pas : une société américaine est entrée dans le chemin, par une décision d'infrastructure à l'échelle du parc et non par un choix propre à Veritext. Nous préférons l'écrire ici, sur la page qui promet de dire ce que nous ne protégeons pas.

Notre journal d'intégrité ne résiste pas à tout. Chaque action est chaînée à la précédente par un condensat : modifier une entrée, ou en retirer une au milieu, se voit immédiatement.

Deux altérations, en revanche, ne se voient pas : tronquer la fin du journal — en retirer les dernières entrées laisse une chaîne parfaitement valide — et le recalculer entièrement, ce que peut faire quiconque obtient un accès en écriture à notre base.

C'est la limite d'un chaînage sans ancrage extérieur, et nous la mesurons plutôt que de l'ignorer : des tests vérifient à chaque construction que ces deux cas passent bel et bien inaperçus, pour que la limite reste écrite le jour où quelqu'un voudra s'appuyer sur ce journal.

Et une troisième, que nous avons trouvée chez nous le 16 septembre 2026. Jusqu'à cette date, deux actions enregistrées au même instant pouvaient se chaîner toutes les deux sur la même entrée précédente — et casser la chaîne sans que personne n'y ait touché. Quatre maillons de notre journal sont dans ce cas, datés du 15 septembre à 08:14:55, pendant une mesure de charge que nous menions nous-mêmes. Les enregistrements sont exacts ; c'est leur chaînage qui ne l'est pas.

Les écritures sont désormais sérialisées, ce qui empêche le cas de se reproduire. Nous ne recalculons pas la chaîne pour la « remettre droite » : ce serait précisément l'altération que ce journal doit rendre visible. Une rupture se documente, elle ne s'efface pas — et toute rupture postérieure à cette date est à traiter comme une altération jusqu'à preuve du contraire. Un contrôle complémentaire repère qu'une chaîne a raccourci, ce qui attrape l'accident — une restauration partielle, un bogue — mais pas un adversaire qui aurait déjà la base.

Y remédier demanderait de publier régulièrement un condensat signé hors de nos serveurs. Ce n'est pas fait.

La sécurité dépend de l'intégrité du code livré à votre navigateur. C'est vrai de tout service chiffré de bout en bout sur le web, y compris des plus réputés. Nos correctifs : politique de sécurité de contenu stricte, publication du code source, et builds reproductibles dont les empreintes sont publiées — n'importe qui peut vérifier que le code servi est bien celui publié.

Notre site est servi par un serveur mutualisé. Le certificat TLS de veritext.fr est terminé sur un serveur qui héberge d'autres services. Votre contenu reste protégé quoi qu'il arrive — il est chiffré de bout en bout jusqu'au processus de traitement — mais le code de l'application vous est livré par cette machine. Les empreintes publiées ci-dessus existent précisément pour que vous n'ayez pas à nous croire sur parole.

Nous n'avons pas de protection contre les attaques par saturation. Une attaque en déni de service peut rendre Veritext injoignable. Aucune donnée n'est en jeu ; c'est la disponibilité qui l'est.

Nous sommes hébergés sur un site unique, en France. Pas de redondance géographique à ce jour. Nos sauvegardes sont chiffrées et conservées en deux endroits distincts, tous deux en France.

Aucun détecteur de texte généré par IA n'est fiable à 100 % — ni le nôtre, ni aucun autre. Nos scores sont des indices probabilistes accompagnés d'un intervalle de confiance. Ils ne constituent jamais une preuve, et ne doivent jamais fonder à eux seuls une décision concernant une personne. Nous publions nos taux de faux positifs par domaine.

Où sont vos données

Nous ne plaçons aucun traceur tiers. Il n'y a donc pas de bandeau à accepter.

Signaler une faille

security@veritext.fr — voir aussi /.well-known/security.txt.

Nous nous engageons à accuser réception sous 72 heures, à ne poursuivre personne pour une recherche menée de bonne foi sans dégradation ni accès à des données de tiers, et à créditer publiquement toute personne qui le souhaite.

Journal des changements de cette page