Le Livre Blanc de Warren

Peu de gens lisent les livres blancs, c'est normal, c'est un peu chiant. Mais j'ai cherché à être concis, et à le rendre plus savoureux.

Je ne réclame aucune confiance ni ne fais de promesse, je te propose de faire confiance à une architecture, donc je te la livre, dépouillée et dénudée : les décisions, les mécanismes qui les tiennent, ce qu'elles coûtent, et la liste de ce que Warren ne protège pas.

#Préliminaires

• Pourquoi j'ai créé Warren, alors que le marché déborde déjà de VPN qui promettent tous la même chose.
• Pourquoi pas WireGuard, qui était pourtant le point de départ.
• Pourquoi QUIC comme fondation de toute la pile, et ce que ce geste coûte en ingénierie.
• Pourquoi le port forwarding revient ici, alors que Mullvad et IVPN l'ont supprimé en 2023.
• Pourquoi il n'y a ni compte ni mail, et ce que ça implique le jour où tu perds ta phrase de récupération.
• Pourquoi les serveurs ne gardent rien, jusque dans le choix du système de fichiers et de l'image qui démarre.
• Pourquoi je navigue à contre-courant : les paliers payants, les fonctionnalités réservées à ceux qui paient plus, la carte du monde gonflée aux serveurs virtuels, la pseudo-décentralisation non vérifiable... ça saoule.
• Ce que Warren ne protège pas. Un chapitre entier y passe, parce qu'un VPN qui prétend tout protéger raconte n'importe quoi.

#Ce qu'il y a dedans

Six parties, 33 chapitres. Les deux premières se lisent sans bagage technique ; les suivantes descendent plus profond dans le terrier. Le sommaire complet est en tête du PDF, voici la carte.

#Partie I. Pourquoi Warren

Les raisons avant l'architecture. Ce que vaut réellement une promesse no-log, ce que le sacrifice du port forwarding en 2023 dit du métier, et pourquoi un tunnel qui se fait repérer se fait bloquer bien avant d'arriver.

• Le no-log, et pourquoi la parole ne suffit pas
• Mai 2023 : quand le port forwarding est devenu indésirable
• L'obfuscation comme condition d'existence
• Trois propriétés, une conviction

#Partie II. La genèse de la stack

L'historique des choix, y compris les détours. On y explique pourquoi WireGuard a été écarté, pourquoi l'application de bureau est un fork de celle de Mullvad, et ce que le pari QUIC nous a coûté.

• Pourquoi pas WireGuard
• Le détour par Iroh, le pivot vers QUIC
• Pourquoi forker Mullvad
• Le pari QUIC, et son prix

#Partie III. WarrenGuard, le moteur

La partie la plus technique : le cœur unique qui tourne sur toutes les plateformes, le chemin des paquets, l'obfuscation, le multi-hop, le port forwarding durci, le comportement en cas de panne. C'est là que se vérifient les promesses de WarrenGuard.

• WarrenGuard : un seul cœur, toutes les plateformes
• Le datapath QUIC, et le fork de Quinn
• L'obfuscation native
• Le multi-hop et le relais aveugle
• La défense contre l'analyse de trafic
• Le port forwarding, durci
• Kill-switch et fail-closed
• Sécurité mémoire et hygiène des secrets

#Partie IV. Le réseau

Ce qu'il y a dans un serveur de sortie, et surtout ce qu'il n'y a pas. Image immuable, état en mémoire vive, aucune partition de données : une saisie physique ne rend rien. Le pendant grand public de cette partie, c'est aucun journal et le réseau machine par machine.

• Les serveurs de sortie : rien à saisir
• Anatomie d'un serveur de sortie
• Le relais aveugle et l'annuaire signé
• Le plan de contrôle
• Le no-log, vérifié par la machine
• Opérer la flotte sans casser le no-log
• Le blocage DNS : opt-in, uniforme, public, sans détournement

#Partie V. Identité, paiement et applications

Comment je peux te donner accès sans savoir qui tu es. La clé vit sur ton appareil, le paiement est décorrélé de l'usage, les sessions s'ouvrent avec des jetons anonymes, et même le forum se passe d'email et d'adresse IP.

• L'identité : un wallet, pas un compte
• Prouver son abonnement sans compte
• Le paiement, décorrélé de l'usage
• Les crédentiels de session anonymes
• Les applications : deux chemins, une même exigence de vérité
• Le forum, sans mail ni adresse IP

#Partie VI. Sécurité et limites

Le chapitre qu'on trouve difficilement : ce qui est garanti, ce qui l'est partiellement, ce qui est hors de portée par nature, et qui contrôle quoi. Puis la trajectoire, avec les chantiers qui ne sont pas terminés.

• Modèle de menace synthétique
• Trajectoire
• Conclusion, glossaire et références

#Trois extraits

Sur le port forwarding, supprimé par les concurrents et restauré dans le Warren :

Un VPN doit servir ses utilisateurs plutôt que se protéger d'eux, et la bonne réponse à l'abus combine des mesures techniques et juridiques au lieu d'amputer une fonctionnalité.

Sur les limites, dans le modèle de menace :

Il ne garantit pas l'anonymat absolu face à un adversaire qui observe à la fois votre accès à Internet et la sortie du réseau et recoupe les deux, ni face à un logiciel qui contrôle votre appareil. Aucun VPN ne le peut, et un VPN qui le prétend, ment.

Sur ce qui tranche, en conclusion :

Le code fait foi. Le moteur et le kit client sont ouverts et auditables, et les propriétés décrites ici y sont vérifiables directement.

#Qui l'a écrit, et ce qu'il vaut

Le document est signé par l'équipe Warren, publié en version 1.0.20, daté du 14 juillet 2026. Il est public et versionné : quand l'architecture bouge, le livre blanc bouge avec elle, et le numéro de version change. Rien dedans n'est sous embargo, rien n'est réservé à un prospect.

Il reste un document, c'est-à-dire du texte. Ce qui fait foi, c'est le code : le moteur et le kit client sont ouverts, et chaque propriété décrite dans le document s'y vérifie ligne à ligne. Si tu trouves un écart entre les deux, écris-nous à bula@warren.ro, je corrige le document ou le code.

Bonne lecture. J'espère te régaler.