Le Rapport d Infrastructure Nexun: Comment Sept Verifications Automatisees Et Un JSON Signe Prouvent Notre Politique No-Logs Chaque Semaine

La plupart des "rapports de transparence" des VPN sont des PDF annuels rediges par le meme departement marketing que la page de vente. Le notre est different. Chaque semaine, une tache planifiee sur notre infrastructure de production execute sept verifications automatisees sur le systeme en direct, ecrit le resultat comme payload JSON signe dans une ligne de base de donnees et le publie sur nexun.io/transparency/infrastructure. Le resultat est une attestation cryptographiquement verifiable de ce a quoi ressemble vraiment le backend Nexun en ce moment — et vous pouvez comparer deux semaines cote a cote pour verifier que rien n a bouge dessous.

Ce que la carte du rapport montre d un coup d oeil

En haut de /transparency/infrastructure se trouve la carte du rapport. Elle contient quatre elements: un Report ID comme 2026-W16-093318 (annee ISO, semaine ISO, horodatage), une date de generation a la seconde pres, une pastille de statut global ("Toutes les verifications reussies" ou "A examiner"), et un hash de contenu SHA-256 de 64 caracteres. Ce hash est calcule sur le payload JSON canonique du rapport. Modifiez un seul octet du payload et le hash devient une chaine completement differente. C est ainsi que vous savez que la page que vous lisez n a pas ete alteree.

Les sept verifications, expliquees

Sous l en-tete se trouve un bloc de synthese avec sept lignes, chacune marquee pass ou fail. Chaque ligne est generee par une sonde automatisee differente qui s execute sur la machine reelle — pas un fichier de config statique. Voici ce que chacune prouve:

• Aucun fichier de log sur le disque — la sonde scanne /var/log/wireguard, /var/log/nexun et /var/log/openvpn. Si l un de ces dossiers existe ou contient des fichiers, la verification echoue. Un resultat reussi signifie qu il n y a nulle part sur le disque ou les logs de connexion pourraient atterrir.
• Surface API enumeree — FastAPI inspecte sa propre table de routage et liste chaque prefixe monte avec ses methodes HTTP (/admin 33 endpoints, /beta 62, /transparency 5). L enjeu n est pas les nombres — c est que la forme complete de l API est publique. Aucune route cachee.
• Inventaire de donnees documente — la sonde lit le schema PostgreSQL en direct pour vpn_users, vpn_subscriptions, vpn_support_tickets et billing_events et classifie chaque colonne (identifier, contact, payment, operational, timestamp, credential, unknown). Si une nouvelle colonne est ajoutee en prod et n est pas documentee, la verification echoue.
• Les tables utilisateur n ont pas de colonnes IP — la sonde cherche dans chaque table utilisateur des colonnes nommees client_ip, ip_address, ip, remote_ip, created_ip, last_ip ou source_ip. Une seule occurrence ferait echouer le test. Le resultat reussi signifie que la base de donnees n a litteralement aucune colonne ou une IP pourrait etre stockee.
• Journalisation des requetes desactivee — les parametres PostgreSQL sont lus en direct: log_duration=off, log_statement=none, log_connections=off, log_disconnections=off, log_min_duration_statement=-1. Si quelqu un activait l un de ces drapeaux pour "deboguer", le rapport le capterait sous 7 jours.
• Aucun SDK analytique dans les dependances — la sonde parse les paquets Python exactement installes (22 paquets) et les compare a une liste noire: sentry-sdk, datadog, newrelic, mixpanel, segment-analytics-python, posthog, rollbar, bugsnag, google-analytics, amplitude, heap, fullstory. Un resultat reussi signifie qu aucune de ces bibliotheques de siphonnage silencieux n est dans l environnement.
• Aucune extension d audit ou de log — la sonde interroge pg_extension contre une liste noire: pgaudit, pg_stat_statements, pg_qualstats, auto_explain. Ce sont des extensions Postgres qui enregistrent silencieusement l historique des requetes. Seuls pgcrypto et plpgsql sont installes — les deux necessaires, aucune ne journalise.

Les explications de schema — pourquoi nous montrons les colonnes "inquietantes"

Le rapport contient aussi une courte section d explications. Certains de nos noms de colonnes paraissent alarmants a cote d une promesse "aucun log", et plutot que de les cacher en coulisse, nous les expliquons toutes sur la meme page. Les cacher detruirait le but de la page.

• vpn_support_tickets.log_data — un paquet de debug qu un utilisateur peut volontairement attacher a un ticket de support. Conditionne par le booleen include_logs sur la meme ligne. N est jamais ecrit pour le trafic VPN normal; rempli uniquement quand l utilisateur coche "inclure les logs" dans le formulaire de support lui-meme.
• vpn_users.test_password — un mot de passe en clair pour les comptes de review App Store et Google Play. Apple et Google exigent un login de test fonctionnel pour approuver les mises a jour d application. Une contrainte CHECK de la base (chk_test_password_only_for_test) rend physiquement impossible d ecrire cette colonne sur une ligne ou is_test_account est false.
• vpn_users.notes — un champ libre pour les notes de l operateur (contexte de remboursement, suivi support). Jamais visible pour les autres utilisateurs; lisible uniquement par les admins niveau 9. Toute demande d acces RGPD inclut ce champ dans l export.
• vpn_subscriptions.raw — le payload webhook exact recu de Stripe / Apple / Google pour chaque evenement d abonnement, stocke tel quel pour pouvoir reconcilier les litiges de facturation. Ne contient aucune information au-dela de ce que le fournisseur de paiement possede deja sur la meme transaction.

Le payload JSON complet et comment le verifier vous-meme

Au bas de la page du rapport nous rendons le document JSON exact sur lequel le SHA-256 a ete calcule. N importe qui peut y faire defiler: les verifications, les tableaux de resultats, chaque table et chaque colonne de l inventaire, les parametres Postgres, les extensions installees, la liste des dependances et la synthese. Le format est stable (schema_version: 2), donc deux rapports de semaines differentes peuvent etre compares directement. Pour verifier le hash vous-meme, canonisez le JSON (cles triees, sans whitespace supplementaire) et calculez un SHA-256 sur les octets. Si votre resultat correspond au hash dans la carte d en-tete, le rapport est intact. Sinon, quelque chose ne va pas et nous voulons le savoir.

Ce qui change d une semaine a l autre

Puisque le rapport est genere automatiquement a partir du systeme reel, il changera quand le systeme change vraiment. Une semaine typique peut voir total_packages bouger quand nous mettons a jour des dependances, ou endpoint_count sous /beta changer quand nous ajoutons ou retirons des fonctionnalites beta. Ce qui ne devrait jamais changer, c est l ensemble des categories ("aucune colonne IP", "aucun log de requete", "aucun SDK analytique", "aucune extension d audit") — tout changement la-dessus passerait overall_pass a false et afficherait une pastille rouge "A examiner" au lieu de verte. Si cela arrive, nous vous devons une explication, et le rapport est concu pour rendre l explication inevitable.

Pourquoi c est plus honnete qu un PDF annuel

Un PDF annuel est un instantane ecrit par des humains. Il peut etre reedite, reformule et silencieusement reuploade. Une attestation signee hebdomadaire generee par la machine elle-meme ne le peut pas. La ligne de base de chaque rapport est clee par semaine ISO; le hash est fixe a la creation; et chaque ligne du payload est une lecture directe de l infrastructure. Si nous devions un jour adoucir silencieusement une promesse, les verifications echoueraient et la page le montrerait. C est la vraie difference entre promettre la vie privee et la prouver.

Comment utiliser le rapport en tant qu utilisateur

Ouvrez nexun.io/transparency pour voir la semaine en cours d un coup d oeil: couleur du canary, pastille de statut, empreinte SHA-256. Cliquez vers /transparency/infrastructure pour lire chaque verification. Mettez la page en favori et rouvrez-la une semaine plus tard — le Report ID (2026-Wxx-...) et le hash doivent avoir change, prouvant que l attestation est en direct. Si quelque chose change dans la section "never-log" ou dans la liste des verifications sans annonce publique, traitez-le comme une raison de poser des questions. C est exactement a ca que sert ce rapport.