Architecture comparée — ce que chaque acteur voit
Ce que construire un tunnel enseigne
Implémenter un VPN SSL from scratch — TUN/TAP, AES-CBC, HMAC-SHA256, échange de clés via OpenSSL — pose une question que les utilisateurs de VPN commercial ne se posent jamais : que voit le serveur ? La réponse est précise et dérangeante. Le serveur voit l'adresse IP source de chaque connexion entrante, le timestamp de chaque paquet, le volume de données échangé, et selon la configuration DNS, les domaines résolus par le client.
Il ne voit pas le contenu des communications — le tunnel chiffre le payload. Mais les métadonnées sont là, disponibles pour quiconque a accès aux logs du serveur. Quand vous gérez vous-même le serveur, vous savez exactement ce qui est loggué parce que vous l'avez configuré. Quand vous utilisez un service commercial, cette configuration est dans les mains de l'éditeur.
# Access log minimal — informations disponibles par défaut 2026-03-14T09:12:33Z CONNECT client_ip=203.0.113.42 vpn_ip=10.8.0.4 session_id=a3f7c1 2026-03-14T09:12:33Z DNS_QUERY client=10.8.0.4 domain=example.com # si DNS via le serveur VPN 2026-03-14T09:45:11Z BYTES client=10.8.0.4 rx=2847291 tx=184293 2026-03-14T09:45:11Z DISCONNECT client_ip=203.0.113.42 duration=1958s # Un vrai no-logs signifie que ces lignes n'existent pas — pas qu'elles sont supprimées après.
Cette distinction est fondamentale. Un service qui affirme "ne pas conserver de logs" peut soit ne pas en générer du tout — ce qui nécessite une architecture spécifique — soit les générer et les supprimer régulièrement. Ces deux configurations sont radicalement différentes en termes de risque : dans le second cas, une injonction judiciaire émise au bon moment peut capturer des logs qui "n'existaient plus".
Cette réalité technique a une conséquence directe sur la façon d'évaluer un VPN commercial. Les critères marketing — "le plus rapide", "le plus sécurisé", "des milliers de serveurs" — sont invérifiables. Les critères techniques — quelle daemon tourne sur le serveur, quels flags de logging sont actifs, le disque est-il persistent ou RAM-only — sont vérifiables par audit. La différence entre un service qui a passé un audit Cure53 avec rapport public intégral et un service qui prétend être no-logs sans justification n'est pas une différence de communication. C'est une différence d'architecture.
Auto-hébergé vs commercial — les vrais arbitrages
Contrôle total, responsabilité totale
Vous êtes l'opérateur. Vous configurez ce qui est loggué, choisissez le protocole, gérez les mises à jour de sécurité. Personne d'autre n'a accès à votre infrastructure — sauf votre hébergeur.
- Pas de tiers entre vous et le serveur
- Configuration fine du protocole et du chiffrement
- Hébergeur connaît vos métadonnées de connexion
- Maintenance et mises à jour à votre charge
- IP fixe — identifiable dans le temps
- Pas de réseau de serveurs distribués
Infrastructure mutualisée, confiance déléguée
Vous déléguez l'opération à un tiers. La qualité de cette délégation dépend de l'architecture technique du service et de sa transparence — pas de ses affirmations marketing.
- Réseau de serveurs dans de nombreux pays
- Maintenance et sécurité gérées par l'éditeur
- IP partagée entre utilisateurs — moins identifiable
- Politique de logs non vérifiable sans audit
- Audits indépendants possibles — rares
- Kill switch, protection DNS intégrés
La question n'est pas "lequel est meilleur" — c'est "quel modèle de confiance correspond à votre situation". Un VPN auto-hébergé sur un VPS chez Hetzner en Finlande vous protège de votre FAI français mais expose votre activité à Hetzner. Un VPN commercial sérieux avec architecture RAM-only et audit Cure53 récent offre des garanties documentées que l'auto-hébergement standard ne peut pas reproduire facilement.
Protocoles : WireGuard, OpenVPN, IPsec
Quiconque a implémenté un tunnel TLS/SSL from scratch comprend ce que signifie comparer WireGuard (environ 4 000 lignes de code) à OpenVPN (environ 70 000 lignes). La surface d'attaque est proportionnelle à la complexité. WireGuard est auditrable par un humain en quelques jours — OpenVPN ne l'est pas. Cette asymétrie a des conséquences pratiques sur la confiance qu'on peut accorder à chaque protocole.
OpenVPN reste le protocole le plus flexible et le plus configuré — il supporte TCP et UDP, peut tourner sur le port 443 pour contourner les filtres réseau, et est disponible sur toutes les plateformes depuis des années. WireGuard est plus performant, cryptographiquement plus moderne (Curve25519, ChaCha20, Poly1305), et son code compact facilite la vérification formelle. En pratique, les deux sont sûrs pour un usage courant. La différence est dans la surface d'attaque et dans la facilité de maintenance.
WireGuard identifie les pairs par clé publique — par conception, il loggue les adresses IP dans le kernel. Les implémentations commerciales qui affirment un WireGuard no-logs utilisent des adaptations (comme l'implémentation de Mullvad ou la double NAT de ProtonVPN) qui régénèrent les clés et les IPs assignées à intervalles réguliers. Ce n'est pas le WireGuard standard — c'est une couche d'anonymisation par-dessus.
La question des logs — architecture, pas promesse
Avoir configuré soi-même les logs d'un serveur OpenVPN permet de comprendre exactement ce que signifie "no-logs" : ce n'est pas une décision de politique, c'est une décision d'architecture. Un serveur VPN qui ne génère pas de logs nécessite une configuration active pour les désactiver — le comportement par défaut de la plupart des daemons réseau est de tout loguer.
Les services VPN sérieux qui vont au-delà de la promesse marketing utilisent des serveurs RAM-only — sans disque persistent, les logs ne peuvent pas survivre à un redémarrage. Ils font auditer cette architecture par des cabinets indépendants dont les rapports complets sont publics. Ils publient des rapports de transparence qui documentent les demandes d'autorités reçues et, surtout, ce qu'il n'a pas été possible de transmettre faute de données disponibles.
Ces critères sont vérifiables — pas au niveau du code source du client, mais au niveau des rapports d'audit et de l'historique des interactions avec les autorités. C'est la grille d'évaluation que quelqu'un qui a monté son propre serveur VPN peut appliquer avec rigueur.
Tableau de comparaison — critères techniques
| Critère | Auto-hébergé | VPN commercial sérieux | Vérifiable comment |
|---|---|---|---|
| Contrôle de la config logs | Total | Délégué | Audit public |
| Protocole | Au choix | Selon éditeur | Documentation client |
| IP partagée entre utilisateurs | Non | Oui | Architecture réseau |
| Serveurs RAM-only | Non (VPS standard) | Selon éditeur | Audit Cure53 / SEC Consult |
| Kill switch intégré | Manuel (iptables) | Client intégré | Test technique |
| Rapport de transparence | N/A | Selon éditeur | Site éditeur |
| WireGuard no-logs natif | Non (kernel logs IP) | Adaptation requise | Code source / audit |
| Maintenance sécurité | À votre charge | Éditeur | Changelog / CVE |
Infrastructure des VPN commerciaux — ce que l'opérateur doit gérer
Monter un serveur VPN sur un VPS donne une compréhension immédiate de ce qu'implique opérer une infrastructure à l'échelle commerciale. Un service qui annonce 5 000 serveurs dans 90 pays gère des milliers de machines physiques ou virtuelles, un réseau BGP anycast pour le routage optimal, des certificats TLS renouvelés automatiquement, des mises à jour de sécurité déployées en continu, et une surface d'attaque distribuée que chaque nœud compromis peut partiellement exposer.
La promesse RAM-only — serveurs sans disque persistent, logs impossibles à conserver au-delà du redémarrage — est architecturalement solide mais opérationnellement complexe. Elle nécessite une infrastructure de déploiement qui recrée l'état du serveur à chaque boot depuis une image centrale vérifiée. Mullvad a documenté publiquement cette architecture. ProtonVPN utilise une approche différente avec des clés WireGuard régénérées toutes les 10 minutes pour limiter la corrélation temporelle.
Ces détails d'implémentation ne sont pas accessibles à un utilisateur standard — ils le sont à quelqu'un qui a monté son propre serveur et comprend ce que ces choix impliquent concrètement. C'est précisément pourquoi la question des logs et de la confiance mérite une analyse technique plutôt qu'une lecture des fiches produits.
WireGuard loggue les adresses IP des pairs dans le kernel Linux par défaut — /proc/net/dev expose les interfaces actives. Les implémentations commerciales sérieuses utilisent une couche de routage interne qui isole les IPs clients des IPs de sortie, régénère les clés à intervalles réguliers, et tourne dans des namespaces réseau séparés. Ce n'est pas le WireGuard que vous avez configuré sur votre VPS — c'est une adaptation substantielle.