Quel VPN propose des applications open source ou un code vérifiable ? J’ai appris à distinguer le dépôt public du binaire que j’installais

Le VPN ne me demandait pas simplement de cliquer sur « Mettre à jour ».

Il voulait mon mot de passe administrateur.

Une nouvelle version devait remplacer une partie du logiciel qui gérait la connexion réseau de mon ordinateur. Quelques minutes plus tard, j’allais ouvrir un dépôt professionnel depuis le Wi-Fi d’un espace de travail partagé.

J’avais déjà accepté ce genre de demande des dizaines de fois.

Cette fois, le curseur est resté au-dessus du bouton.

Deux semaines plus tôt, Proton avait annoncé le déploiement d’une nouvelle base de code côté client pour ses protocoles VPN, avec l’objectif d’améliorer les performances, la fiabilité et la résistance à la censure.

Rien dans cette annonce ne m’inquiétait.

Elle m’a simplement rappelé ce que le cadenas vert me faisait oublier : un VPN n’est pas une petite extension anodine. Son application obtient une position privilégiée sur ma machine et prend en charge une partie essentielle de mon trafic.

Je voulais donc pouvoir vérifier ce que j’installais. J’ai tapé : VPN open source. Je pensais que la réponse consisterait à trouver un lien GitHub. C’était seulement le début.

Proton m’a d’abord donné presque exactement ce que je cherchais

Sur ce critère, Proton est difficile à ignorer.

Ses applications pour Windows, macOS, Android, iOS et d’autres plateformes sont publiées en open source, et l’entreprise accompagne cette ouverture de rapports d’audit indépendants. Sa page consacrée au sujet a encore été mise à jour fin 2025 avec les audits récents.

Je pouvais donc ouvrir le dépôt. Lire les changements. Voir les problèmes signalés. Observer les contributions.

Pour quelqu’un capable de lire le code — ou simplement de compter sur le fait que d’autres puissent le faire — c’est déjà très différent d’une application dont le fonctionnement reste entièrement derrière la porte de l’éditeur.

J’ai presque considéré ma recherche comme terminée. Puis une question m’a arrêté. Comment savais-je que l’application installée sur mon appareil était réellement celle produite par ce code ? Un dépôt public prouve qu’un code existe publiquement.

Il ne prouve pas, à lui seul, que le fichier téléchargé a été construit exactement à partir de ce code, sans autre modification au moment de la compilation ou de l’empaquetage.

En mars 2026, un utilisateur de r/degoogle formulait pratiquement la même interrogation à propos d’une application Proton : pouvait-il vérifier que l’APK proposé au téléchargement correspondait réellement au code publié sur GitHub, plutôt que seulement vérifier que le fichier avait été signé par Proton ?

C’était exactement la nuance qui manquait à ma recherche. Je ne voulais plus seulement voir le plan. Je voulais savoir si je pouvais relier ce plan au bâtiment qu’on me livrait.

« Open source » et « vérifiable » ne sont pas le même niveau de preuve

C’est là que les builds reproductibles ont commencé à m’intéresser.

Le principe est simple : avec le même code, les mêmes instructions et le même environnement de compilation, une autre personne doit pouvoir recréer un fichier identique bit par bit.

La différence m’est apparue immédiatement.

Avec une application open source, je peux examiner la recette.

Avec un build reproductible, quelqu’un peut refaire la recette et comparer le résultat avec le fichier distribué.

Si les deux correspondent, la distance entre : « voici notre code » et « voici le programme que nous vous demandons d’installer » devient beaucoup plus courte.

Pour un logiciel qui va manipuler mon réseau, ce lien me semblait soudain plus intéressant que le simple nombre d’étoiles d’un dépôt.

C’est ce qui m’a conduit à Mullvad.

Sur Android, Mullvad rend cette vérification beaucoup plus concrète

Le code de l’application Mullvad est public depuis longtemps.

Mais depuis la version Android 2025.2, le service propose également des builds reproductibles afin de permettre de vérifier que l’application téléchargée a bien été construite à partir du code source publié.

La procédure est publique elle aussi.

On prend la version officielle, on reconstruit la même version depuis le dépôt, puis on compare les fichiers de manière à vérifier qu’ils correspondent.

Je n’allais probablement pas transformer mon passage au coworking en séance de compilation Android. Mais ce n’était pas le point. Le test pouvait être fait. Par moi, si j’en avais l’envie et les compétences.

Ou par des chercheurs, des développeurs et d’autres utilisateurs capables de contrôler ce que je n’allais pas vérifier personnellement.

Mullvad ne s’est d’ailleurs pas arrêté à publier le code. En juin 2026, l’entreprise a publié les résultats d’une nouvelle évaluation de sécurité de son application Android. Plusieurs problèmes mineurs relevés pendant l’évaluation avaient été corrigés avant la version suivante.

Ce détail m’a davantage rassuré qu’un rapport où tout aurait semblé parfait.

Un audit utile n’est pas celui qui ne trouve jamais rien.

C’est celui qui permet de voir ce qui a été trouvé et ce qui a changé ensuite.

À ce stade, ma réponse devenait beaucoup plus précise.

Proton propose des applications open source accompagnées d’audits publics ; Mullvad va plus loin sur Android avec une chaîne de vérification fondée sur des builds reproductibles.

IVPN appartient lui aussi clairement à cette famille de services transparents : ses applications desktop disposent de dépôts publics sous licence libre, avec les instructions nécessaires pour compiler le client.

Mais je ne cherchais désormais plus seulement un VPN autorisant la lecture de son code.

Je voulais savoir jusqu’où je pouvais suivre le chemin entre le dépôt public et le programme qui tournait réellement sur mon appareil.

C’est précisément là que le petit VPN n’était pas censé gagner

J’avais également OnlydogVPN sur une autre machine. J’ai cherché les mêmes éléments. Un dépôt public complet. Une procédure permettant de reconstruire l’application. Une méthode permettant de comparer le fichier distribué avec une compilation indépendante.

Je n’ai pas trouvé le même niveau de vérification publique.

Le service est également beaucoup plus récent et possède moins de recul indépendant que Proton ou Mullvad.

Sur le critère strict de cette recherche, la différence est réelle.

Si ma condition est :

« Je veux pouvoir examiner le code du client et relier le binaire installé à ce code »,

ce n’est pas le service que je choisirais pour obtenir le maximum d’auditabilité publique.

Curieusement, une fois cette limite posée clairement, j’ai mieux compris pourquoi je continuais malgré tout à garder l’application.

Je lui demandais autre chose.

Je n’avais pas besoin que tous mes appareils répondent au même modèle de confiance

Sur mon téléphone Android personnel, où je voulais pousser la vérification aussi loin que possible, les builds reproductibles de Mullvad avaient une valeur concrète.

Sur mon ordinateur de voyage, le problème quotidien était différent.

Je voulais ouvrir l’application, choisir ce que j’essayais de faire et établir une connexion sans passer plusieurs minutes à arbitrer entre protocoles, serveurs et réglages.

C’est là que le plus petit service restait installé.

Son interface est davantage organisée autour de situations d’usage et d’une connexion en quelques actions que d’un tableau rempli de paramètres réseau.

Le lendemain, dans un hôtel, cette différence est redevenue très concrète. Je devais ouvrir un espace client depuis le Wi-Fi de la chambre. J’ai lancé le service. Choisi la situation adaptée. Connecté. Le portail a chargé.

J’ai récupéré le document dont j’avais besoin et je suis revenu à mon travail. Je n’avais pas obtenu au passage un dépôt open source ou un build reproductible. Je n’en avais pas besoin pour comprendre pourquoi l’application restait utile sur cette machine.

Mullvad me donnait davantage de matière à vérifier. Le petit service me demandait moins de choses à décider avant d’accomplir une tâche. Ce ne sont pas deux versions de la même qualité.

Ce sont deux réponses à deux manières différentes d’accorder sa confiance.

Et pour mes déplacements, cette simplicité avait une valeur très immédiate : je pouvais me concentrer sur ce que j’étais venu faire au lieu de transformer chaque connexion en petite séance d’administration réseau.

Je regarde désormais trois questions différentes

Quand un VPN dit que son application est open source, je regarde d’abord si le dépôt correspond réellement au client que j’utilise.

Ensuite, je cherche des audits récents.

Enfin, lorsque je veux aller plus loin, je regarde s’il existe une méthode permettant de relier le fichier distribué au code publié.

C’est ce troisième niveau qui me manquait. Proton apporte une forte transparence avec ses applications ouvertes et ses audits. IVPN permet lui aussi d’examiner et de compiler ses clients publics.

Sur Android, Mullvad rend la vérification encore plus concrète grâce aux builds reproductibles.

Le petit service que je garde pour mes déplacements n’offre pas aujourd’hui la même chaîne publique de vérification. En revanche, lorsque mon besoin est de me connecter vite, avec peu de décisions intermédiaires, son approche centrée sur l’usage reste celle que j’ai le plus naturellement envie d’ouvrir.

Je ne cherche donc plus un seul VPN capable de gagner toutes les comparaisons.

Pour le code, je veux pouvoir suivre la chaîne de confiance.

Pour le voyage, je veux parfois simplement que cette chaîne ne devienne pas une chaîne de réglages.

Et depuis ce jour, lorsqu’un VPN me demande mon mot de passe administrateur pour remplacer son composant réseau, je ne cherche plus seulement le bouton GitHub : je cherche jusqu’où je peux relier ce dépôt au binaire auquel je suis sur le point de donner ces droits.