Découverte & modèle de menace
Modèle de menace (contre qui l'utilisateur se défend — FAI, annonceur, attaquant Wi-Fi public), invariants sans logs, cartographie de posture RGPD + CCPA, examen des droits VPN sur App Store et Google Play.
Étude de cas · Confidentialité grand public · Mobile
LiMP — VPN grand public WireGuard pour iOS et Android
Comment nous avons livré un VPN grand public en production — sur l'App Store et Google Play, actif aux États-Unis et dans l'Union européenne — développé sur WireGuard avec un plan de contrôle sans logs, une connexion en un tap et une architecture prête à l'audit qui résiste aux exigences RGPD et CCPA dès le premier jour.
Le brief — un VPN grand public qui résiste à l'audit
L'équipe produit de LiMP souhaitait un VPN grand public qui ne rappelle pas les icônes de barre des tâches volumineuses et les connexions laborieuses de 2015. Le constat fondamental était que l'acheteur moderne de confidentialité aux États-Unis et dans l'Union européenne ne veut pas seulement du chiffrement — il veut une posture sans logs défendable, une connexion en un tap de moins d'une seconde, et une carte des serveurs qu'il peut réellement comprendre. Les SDK VPN en marque blanche existants ont échoué deux tests d'acceptation immédiatement : leurs bundles dépassaient les seuils d'installation cellulaire de l'App Store, et leurs configurations de journalisation par défaut ne pouvaient pas passer un audit de confidentialité indépendant. Nous avons développé LiMP depuis les principes fondamentaux en tant qu'application iOS et Android native : un client léger encapsulant le protocole WireGuard, un plan de contrôle Go avec une séparation stricte entre l'identité de facturation et l'identité du tunnel, et une flotte de serveurs fonctionnant en mode RAM uniquement afin que la saisie d'un nœud ne produise aucun état persistant. Le résultat est un VPN grand public disponible sur l'App Store et Google Play, accessible sur limpvpn.com, conçu pour les audiences aux États-Unis et dans l'UE sous les exigences RGPD et CCPA dès le premier jour.
Points clés du projet
Tunneling WireGuard de bout en bout
NetworkExtension iOS natif
VpnService Android natif
Plan de contrôle zéro-log en Go
Connexion en un tap en moins d'une seconde
Carte des serveurs avec latence en direct
Coupe-circuit & reconnexion automatique
App Store + Google Play actifs · États-Unis & UE
Chiffres clés
Un aperçu de ce que le build LiMP a permis de réaliser sur iOS, Android et un plan de contrôle renforcé au cours de son premier cycle de production.
2plateformes natives — iOS et Android, codebases entièrement séparées optimisées par plateforme
<100mshandshake WireGuard typique sur réseau mobile LTE et Wi-Fi dans les réseaux US et UE
0journal de session persistant — les nœuds VPN en périphérie fonctionnent en mode RAM uniquement par conception
~4klignes de code de référence du protocole WireGuard — auditable en une seule après-midi
2stores d'applications actifs — Apple App Store et Google Play dans les espaces de vente US et UE
12–18 wkfenêtre de livraison typique pour un MVP VPN grand public comparable sur les deux stores
Pourquoi WireGuard plutôt qu'OpenVPN, IKEv2 et les stacks propriétaires
Le choix du protocole domine toutes les autres décisions architecturales dans le développement d'un VPN. Nous avons choisi WireGuard plutôt qu'OpenVPN et IKEv2 parce que les compromis correspondent parfaitement à un produit grand public développé de zéro en 2024. L'implémentation de référence de WireGuard représente environ 4 000 lignes de code avec une seule suite cryptographique moderne — Curve25519 pour l'échange de clés, ChaCha20-Poly1305 pour le chiffrement symétrique, BLAKE2s pour le hachage — et est auditable en une seule après-midi. OpenVPN, en revanche, est une base de code bien plus volumineuse avec des suites de chiffrement négociées et une surface d'attaque plus étendue que toute assertion sincère de zéro-log doit prendre en compte. IKEv2 est mature et bien pris en charge nativement sur iOS, mais sa sémantique de reprise de session sur les appareils en itinérance est moins élégante que le modèle de clés de session de WireGuard, conçu précisément pour les scénarios de transfert d'opérateur que les utilisateurs mobiles rencontrent chaque jour.
Les stacks VPN propriétaires — ceux fournis avec les SDK en marque blanche — ont été éliminés rapidement : leurs termes de licence exigeaient une télémétrie côté serveur incompatible avec la posture sans logs, et leurs primitives cryptographiques sont souvent non documentées. Adopter le protocole du livre blanc WireGuard signifiait que l'ensemble du stack — tunnel client, plan de contrôle, rotation des clés — est ouvert et citable de bout en bout.
Compromis de protocole
WireGuard vs OpenVPN vs IKEv2 vs proprietary VPN stacks — at a glance
| Dimension | WireGuard (LiMP) | OpenVPN | IKEv2 / proprietary |
|---|---|---|---|
| Taille du code du protocole | ~4 000 lignes — auditable en une séance | ~70 000+ lignes dont la surface OpenSSL | Stack OS volumineux ou binaire propriétaire |
| Suite cryptographique | Primitives modernes fixes — Curve25519, ChaCha20-Poly1305, BLAKE2s | Négociée — surface d'attaque plus large | Définie par le vendeur ; souvent opaque |
| Latence du handshake (typique) | Moins de 100 ms sur réseau mobile LTE | Plusieurs centaines de ms — handshake TLS plus mise en place du tunnel | Variable ; IKEv2 rapide, propriétaire variable |
| Comportement en itinérance | Intégré via les clés de session — pas de redémarrage du tunnel | Redémarrage du tunnel requis lors du changement de réseau | MOBIKE sur IKEv2 ; propriétaire variable |
| Intégration noyau (Linux) | Noyau principal depuis 5.6 — débit maximal en ligne | Espace utilisateur — plus lent à débit élevé | Noyau/espace utilisateur mixte |
| Compatibilité App Store / Play Store | Enveloppe légère sur NetworkExtension / VpnService | Bundle plus volumineux ; dépendances espace utilisateur | IKEv2 natif adapté ; SDK propriétaire alourdit |
| Auditabilité sans logs | Tunnel sans état — la configuration pair est le seul état | État par session — doit être activement supprimé | Contrôlé par le vendeur — opaque |
Protocol references: WireGuard whitepaper (Donenfeld), Apple NetworkExtension documentation, Android VpnService reference.
Build iOS — Swift, NetworkExtension et connexion en un tap
Le client iOS est développé en Swift avec SwiftUI pour la couche interface et une extension Packet Tunnel Provider construite sur le framework NetworkExtension d'Apple. L'ensemble de la surface visible par l'utilisateur se résume à une machine à états unique — inactif, connexion en cours, connecté, reconnexion — et l'écran d'accueil est une grande cible de tap qui la pilote. La sélection de région se trouve à un tap du bouton de connexion, avec une liste triée par latence mise en cache localement afin que le sélecteur ne soit jamais bloqué par un aller-retour réseau. Le Packet Tunnel Provider héberge l'implémentation espace utilisateur de WireGuard ; le processus principal de l'application ne gère que l'interface, l'état de facturation et le pont IPC vers l'extension.
Le chemin tap-vers-connexion est là où la plupart des VPN grand public perdent du temps, et là où nous avons concentré un effort d'ingénierie disproportionné. Le flux est le suivant : tap, validation du jeton de session mis en cache (pas d'aller-retour réseau si valide), démarrage du Packet Tunnel Provider, transmission de la configuration pair via le pont NETunnelProviderProtocol, et exécution du handshake WireGuard. Sur les réseaux mobiles typiques des États-Unis et de l'UE, l'ensemble du chemin se termine en moins d'une seconde du point de vue de l'utilisateur. Le même client iOS intègre le comportement de coupe-circuit que l'examinateur de l'App Store attend — lorsque le tunnel tombe, tout le trafic non tunnelisé est bloqué au niveau de la couche NetworkExtension jusqu'à ce que l'utilisateur se déconnecte explicitement. La surface iOS de bout en bout est fournie dans le cadre de notre pratique de développement d'applications mobiles.
Build Android — Kotlin, VpnService et la carte des serveurs
Le client Android est développé en Kotlin avec Jetpack Compose pour l'interface et un service de premier plan construit sur l'API VpnService d'Android. Le service de premier plan est indispensable : sur les familles d'appareils Samsung, Xiaomi, OnePlus et Pixel, les optimiseurs de batterie agressifs terminent les processus de tunnel en arrière-plan en quelques minutes, rompant le contrat de reconnexion automatique que l'utilisateur accepte implicitement. Le service affiche une notification persistante minimale qui maintient le processus de tunnel actif entre les cycles du mode Doze, et WorkManager gère les opérations non urgentes — actualisation de la liste des serveurs, vidange des compteurs de télémétrie, rotation des certificats — avec une sémantique de backoff qui respecte les états d'économie de batterie d'Android 10 à Android 14.
La carte des serveurs est là où le client Android démontre sa valeur. Les utilisateurs voient une liste organisée de régions couvrant les Pays-Bas, l'Allemagne, la France, la Suède, l'Irlande, ainsi que les côtes Est et Ouest des États-Unis, avec des sondes RTT en direct s'actualisant en arrière-plan et une liste de favoris épinglée en haut. Le moteur de recommandation fonctionne côté client : lorsque le schéma de trafic DNS de l'appareil indique un usage intensif de streaming, la carte affiche en premier les nœuds optimisés pour le débit ; lorsque la latence prime (jeux, appels vidéo), les nœuds à faible RTT remontent. Après un transfert de réseau Wi-Fi vers LTE, le client restaure automatiquement le dernier nœud fonctionnel — le modèle d'itinérance de WireGuard en fait un échange de clés de session plutôt qu'une reconstruction complète du tunnel. La même équipe d'ingénierie maintient iOS et Android en parallèle dans le cadre de notre pratique d'ingénierie iOS et Android.
Architecture zéro-log, nœuds RAM uniquement et posture prête à l'audit
La posture sans logs déclarée de LiMP était une décision d'architecture avant d'être une affirmation marketing. Les nœuds VPN en périphérie — les machines qui transportent réellement les paquets utilisateur — fonctionnent en mode RAM uniquement : leur système de fichiers racine est une superposition éphémère, et un cycle d'alimentation ou une saisie ne produit aucun état de session persistant. Le plan de contrôle Go réside sur un plan renforcé séparé et ne conserve que le strict nécessaire : les clés publiques des pairs, l'habilitation d'abonnement et une vue par compteurs de la capacité par région. Il n'existe ni table de session par utilisateur, ni journal de connexion, ni canal de métadonnées vers une pile d'observabilité centralisée. Les compteurs sont agrégés en périphérie et transmis sous forme de séries numériques anonymes ; les identifiants ne quittent pas le nœud.
L'identité de facturation est délibérément séparée de l'identité du tunnel. Les enregistrements de paiement résident dans le coffre-fort de Stripe sous un ID client que les nœuds VPN ne voient jamais ; les nœuds ne reçoivent que des jetons de session à durée de vie courte qui se mappent de façon opaque à l'habilitation. Les politiques d'infrastructure-en-tant-que-code appliquent les invariants sans logs — toute demande de tirage qui introduirait un journal de session, une trace par utilisateur ou un identifiant de longue durée dans le plan tunnel échoue en intégration continue. La posture est conçue pour s'aligner sur les obligations RGPD pour les utilisateurs dans l'Union européenne et sur les obligations CCPA / CPRA pour les utilisateurs en Californie et aux États-Unis — afin que tout futur audit de conformité sans logs soit un exercice de documentation, non une refonte architecturale.
Posture de conformité : Conforme RGPD · prêt ISO 27001 · SOC 2 Type II en cours · compatible HIPAA · CCPA reconnu.
Méthodologie de livraison
Un build en cinq phases qui a conduit LiMP de la spécification produit à la production sur iOS, Android et un plan de contrôle sans logs.
Protocole & plan de contrôle
Sélection du protocole WireGuard, squelette du plan de contrôle Go, génération de configuration pair, politique de rotation des clés, identité de facturation isolée Stripe, images de nœuds en périphérie RAM uniquement.
Builds des plateformes
Client iOS Swift / SwiftUI sur NetworkExtension Packet Tunnel Provider ; client Android Kotlin / Jetpack Compose sur VpnService ; connexion en un tap, coupe-circuit, reconnexion automatique.
Renforcement prêt à l'audit
Politiques d'infrastructure-en-tant-que-code bloquant les régressions de journalisation, approvisionnement des nœuds RAM uniquement, assurance qualité coupe-circuit et fuite DNS, mise en place d'évaluation de conformité par des tiers.
Lancement & télémétrie
Soumission sur App Store + Google Play dans les espaces de vente US et UE, déploiement de la flotte de serveurs aux Pays-Bas, en Allemagne, en France, en Suède, en Irlande et sur les côtes Est et Ouest des États-Unis.
Facturation anonyme, état de l'abonnement et pont d'habilitation
La couche de monétisation de LiMP a été conçue pour maintenir de façon vérifiable la séparation entre l'identité de paiement et l'identité du tunnel, car la prétention sans logs s'effondre dès qu'une seule base de données relie un ID client Stripe à un jeton de session. L'abonnement est vendu via Apple StoreKit sur iOS, Google Play Billing sur Android et Stripe pour le paiement web qui retransmet un code d'habilitation aux clients mobiles. La validation des reçus côté serveur s'effectue contre le point de vérification de chaque store et écrit un seul enregistrement d'habilitation indexé par un identifiant opaque et rotatif — jamais par Apple ID, compte Google ou adresse e-mail. À l'intérieur des nœuds VPN, la seule chose visible est un jeton porteur à courte durée de vie qui se mappe à l'habilitation et expire rapidement ; le nœud n'a aucun chemin de retour vers une identité de paiement même s'il est compromis. Le comportement du coupe-circuit, la reconnexion automatique lors d'un transfert réseau et la sélection de tunnel fractionné par application (Android) lisent tous le même enregistrement d'habilitation, de sorte qu'un seul état d'abonnement se résout proprement lors des réinstallations, des échanges d'appareils et du futur client de bureau. L'ensemble du sous-système a été conçu en vue de son extensibilité : ajouter un forfait famille, une habilitation multi-appareils ou un niveau B2B avec gestion d'équipe est un changement de configuration du service d'habilitation, non une mise en production de code.
Lancement aux États-Unis et dans l’Union européenne
LiMP a été lancé sur l'Apple App Store et Google Play avec des espaces de vente actifs aux États-Unis et dans l'Union européenne. La version en langue anglaise dessert les utilisateurs en Californie, New York, Texas, Floride et Washington aux États-Unis, ainsi que les utilisateurs aux Pays-Bas, en Allemagne, en France, en Irlande et en Suède dans l'UE, sans base de code distincte par région. Les flux de consentement sont sensibles à la région au niveau du client : les utilisateurs dans l'UE et l'EEE reçoivent un écran de consentement granulaire de style RGPD avec des bascules distinctes pour les analyses de produit optionnelles ; les utilisateurs en Californie reçoivent une divulgation de style CCPA « Ne pas vendre ou partager mes informations personnelles » dans le même flux. Les pratiques de traitement des données sont alignées sur le RGPD pour les utilisateurs européens et sur l'ensemble de lois américaines sur la confidentialité — CCPA/CPRA (Californie), VCDPA (Virginie), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) et Oregon CPA. Comme l'architecture sans logs supprime les données par utilisateur qui préoccupent davantage cet ensemble de lois, la conformité régionale se réduit à une divulgation honnête plutôt qu'à une ségrégation des données par juridiction.
La flotte de serveurs a été déployée en parallèle dans les centres de données de l'UE et des États-Unis — Pays-Bas, Allemagne, France, Suède et Irlande pour la couverture UE ; côtes Est et Ouest des États-Unis pour l'Amérique du Nord — les nœuds de chaque région étant approvisionnés de façon identique à partir d'images RAM uniquement. Le service de correspondance qui sélectionne le nœud à RTT le plus faible par utilisateur exécute des workers sans état qui peuvent être attachés indépendamment aux régions UE ou US pour de futurs engagements de résidence des données. La classification par âge de l'App Store et la classification de contenu de Google Play ont toutes deux été calibrées pour l'ensemble des fonctionnalités VPN, et la politique de confidentialité intégrée à l'application a été rédigée pour documenter précisément l'architecture ci-dessus, citant directement les obligations RGPD et les obligations CCPA de Californie. L'équipe d'ingénierie à l'origine du build travaille sur le fuseau CET avec un chevauchement côte Est US (9h–13h ET) pour les stand-ups, la coordination des soumissions en store et la gestion des incidents — le fuseau horaire qui permet à une équipe produit américaine et une équipe d'ingénierie européenne de partager quatre heures de chevauchement en direct chaque jour.
Stack technique et feuille de route
Swift
SwiftUI
NetworkExtension
Packet Tunnel Provider
Kotlin
Jetpack Compose
Android VpnService
WireGuard
Go
PostgreSQL
Redis
Stripe
Apple StoreKit
Google Play Billing
Docker
Kubernetes
Terraform
Prometheus
Grafana
La feuille de route active de développement logiciel sur mesure pour LiMP inclut le tunnel fractionné par application sur Android (Pixel et Samsung en premier), un niveau de relai MultiHop pour les utilisateurs souhaitant un saut dans une deuxième juridiction, un transport d'obfuscation pour les réseaux restrictifs où les handshakes WireGuard classiques sont bloqués, et un client de bureau développé sur Tauri pour partager la logique métier avec la base de code mobile. Un niveau B2B avec domaine personnalisé, gestion d'équipe et SSO est prévu pour les petites entreprises américaines et européennes, le sous-système d'habilitation étant déjà structuré pour l'attribution multi-sièges. Les plans d'infrastructure incluent une automatisation plus poussée de la flotte de serveurs, un harnais de vérification continue sans logs en interne et une future évaluation de conformité indépendante intégrée à la feuille de route cloud & DevOps.
Créer un VPN grand public similaire — parlons-en
Si vous planifiez un VPN grand public, un produit d'ingénierie de la confidentialité ou toute application mobile où la prétention sans logs doit résister à l'examen d'un auditeur externe pour des audiences aux États-Unis et dans l'UE, nous avons livré ce stack de bout en bout et pouvons réduire sensiblement le délai de développement. Le produit en production est disponible sur limpvpn.com sur iOS et Android, et l'équipe d'ingénierie derrière lui fait partie de YuSMP Group. Nous travaillons au prix fixe pour les MVP bien définis et avec des équipes de développement dédiées pour la livraison continue, avec une journée de travail CET et une fenêtre garantie de chevauchement côte Est US (9h–13h ET) pour les stand-ups, les démonstrations et la gestion des incidents.
Foire aux questions
Quel est le coût de développement d'une application VPN grand public comme NordVPN ou Mullvad ?
Un MVP VPN grand public couvrant les clients iOS et Android avec le tunneling WireGuard, un plan de contrôle de base et les soumissions aux stores coûte généralement entre 120k et 260k USD. L'ajout d'une flotte de serveurs multi-régions, d'un coupe-circuit, du tunnel fractionné, de transports d'obfuscation, de la facturation anonyme et de politiques de journalisation prêtes à l'audit porte un produit complet à 300k–650k USD. Les principaux facteurs de coût sont l'automatisation de la flotte de serveurs, le travail de renforcement sans logs et la coordination des soumissions sur l'App Store et Google Play concernant les droits VPN.
Pourquoi utiliser WireGuard plutôt qu'OpenVPN ou IKEv2 pour une nouvelle application VPN ?
WireGuard est un protocole d'environ 4 000 lignes avec une seule suite cryptographique moderne (Curve25519, ChaCha20-Poly1305, BLAKE2s), tandis qu'OpenVPN est une base de code bien plus volumineuse avec des suites de chiffrement négociées et une surface d'attaque plus large. Les handshakes WireGuard se terminent généralement en moins de 100 ms, l'itinérance entre réseaux est intégrée au protocole via des clés de session plutôt que par des redémarrages du tunnel, et l'implémentation en module noyau est dans le noyau Linux principal depuis la version 5.6. Pour un nouveau développement sans clients hérités, WireGuard est le choix à moindre risque.
Comment développer une véritable architecture VPN sans logs ?
Une posture sans logs défendable est une décision d'architecture, pas une affirmation marketing. Les nœuds VPN en périphérie fonctionnent en mode RAM uniquement ou disque éphémère afin qu'une saisie ne produise aucun état persistant. Le plan de contrôle sépare l'identité de facturation de l'identité du tunnel — Stripe conserve l'enregistrement de paiement, les nœuds VPN ne voient que des jetons de session à courte durée de vie. Les événements de connexion sont agrégés en compteurs et supprimés ; aucune table de session par utilisateur n'existe. Les politiques d'infrastructure-en-tant-que-code empêchent la réintroduction accidentelle de journalisation lors de la gestion des incidents.
Quelles sont les règles de l'App Store et de Google Play pour les applications VPN ?
Apple exige que les applications VPN utilisent le framework NetworkExtension avec un droit Personal VPN ou Packet Tunnel et publient une politique de confidentialité claire. Google Play exige que les applications VPN utilisent l'API VpnService, déclarent clairement l'objectif VPN et passent une revue des autorisations supplémentaires. Les deux stores exigent un comportement de coupe-circuit fonctionnel, une divulgation transparente de toute collecte de données et — pour les applications desservant les utilisateurs de l'UE et de Californie — un mécanisme de consentement granulaire satisfaisant le RGPD et le CCPA / CPRA dans le même flux.
Combien de temps faut-il pour livrer une application VPN sur iOS et Android ?
Un MVP ciblé avec le tunneling WireGuard, un pool de serveurs à région unique, la connexion en un tap et les soumissions aux deux stores prend généralement 12 à 18 semaines. L'ajout d'une carte de serveurs multi-régions avec latence en direct, d'un coupe-circuit, du tunnel fractionné et d'un transport de secours d'obfuscation ajoute 6 à 10 semaines. Le passage de renforcement prêt à l'audit — nœuds RAM uniquement, application des politiques d'infrastructure-en-tant-que-code, évaluation de conformité par des tiers — est fréquemment sous-estimé et devrait être budgétisé à 4 à 6 semaines de travail dédié.
Cas associés
Autres réalisations mobiles et plateformes grand public
ANT
Marketplace PropTech + admin pour promoteurs immobiliers — grilles d'inventaire par appartement, workflows multi-rôles, résidence des données US + UE.
Voir le cas →
JoyJet
Plateforme sociale native iOS + Android avec découverte géo-radar, chat en temps réel et économie de pièces virtuelles aux États-Unis & UE.
Voir le cas →
REHAU
Outils numériques d'entreprise pour un fabricant multinational — portails partenaires, configurateurs et déploiement UE + États-Unis.
Voir le cas →Services associés
Développement d’applications mobiles
Applications iOS, Android et multiplateforme natives avec des pipelines de publication prêts pour les stores.
En savoir plus →
Développement logiciel sur mesure
Plateformes sur mesure conçues selon votre modèle économique, évolutives de l’MVP à des millions d’utilisateurs.
En savoir plus →
Augmentation d’équipes IT
Ingénieurs seniors intégrés à votre Jira et standup en deux semaines. Journée de travail CET avec chevauchement côte Est US.
En savoir plus →Planifier un projet similaire
Réserver un appel découverteDemander une proposition
Partagez quelques détails et un consultant senior vous répondra dans un délai d’un jour ouvrable.