Olvid

Chiffrement de bout en bout ✅ Bon

Tous les échanges (messages, pièces jointes, appels) sont chiffrés de bout en bout, dans toutes les discussions, privées ou en groupes, sans possibilité de désactivation. Les clés sont renouvelées en continu, ce qui assure la confidentialité persistante dont parle le critère.

Authentification de bout en bout ✅ Bon

C’est la propriété fondatrice d’Olvid, et aucune autre solution du comparatif ne la valide. Aucun contact ne peut être ajouté sans que le lien entre ce contact et sa clé ait été établi par l’un des moyens suivants :

• en présentiel, par un double scan de QR code, où le face-à-face garantit naturellement que l’échange est authentique ;
• à distance, par l’échange de deux codes de 4 chiffres (le protocole SAS de Vaudenay^archivé), sur un canal dont on reconnaît l’authenticité — ces 8 chiffres suffisent à limiter la probabilité de succès d’une attaque à environ une sur cent millions par tentative ; chaque échec est visible, et retenter exige une nouvelle invitation et un nouvel échange de codes : impossible d’itérer à l’insu des utilisateurs, qui renonceraient après quelques échecs ;
• par l’intermédiaire d’un contact commun, qui présente l’un à l’autre deux de ses contacts déjà authentifiés ;
• ou en rejoignant un groupe, dont les membres sont mis en relation les uns avec les autres.

Dans les quatre cas, la chaîne de confiance ne repose jamais sur l’opérateur, qui relaie l’échange sans en être un maillon. Par défaut, il n’existe pas d’annuaire à interroger, donc pas de clé à substituer.

Ces quatre voies ont un point commun, elles transposent au numérique des gestes du monde physique : échanger une carte de visite, présenter une personne à une autre. C’est là que se joue une distinction souvent passée sous silence. Authentifier un correspondant, on l’a vu, suppose d’ancrer la confiance quelque part : soit en un tiers, soit en soi-même. Les solutions imposant un annuaire demandent à l’utilisateur de faire confiance à quelque chose : un serveur, une infrastructure, un mécanisme de transparence qu’il ne peut pas inspecter. Olvid, elle, demande de faire confiance à quelqu’un : la personne qu’il rencontre, ou le contact qui l’introduit. On peut objecter qu’un contact commun reste, formellement, un tiers, au même titre qu’un serveur. Mais un utilisateur sait bien mieux juger à qui il peut se fier qu’à quoi : décider si l’on fait confiance à un ami qui nous présente quelqu’un est une opération sociale ordinaire, que chacun pratique depuis toujours ; évaluer si l’on peut se fier à l’annuaire d’un opérateur et à sa chaîne d’acheminement de SMS ne l’est pas. Olvid ne prétend pas supprimer toute forme de tiers, mais le remplacer par un tiers dont l’utilisateur est réellement en mesure d’apprécier la fiabilité.

Le recours à un contact commun n’est d’ailleurs pas toujours une simple commodité. C’est parfois la seule façon d’entrer en contact avec quelqu’un. Lorsqu’on ne connaît une personne que par l’intermédiaire d’un ami, tout ce que l’on sait d’elle, c’est ce que cet ami nous en a dit : ce contact n’existe pour nous que parce qu’un ami commun nous l’a présenté. C’est la situation ordinaire d’une présentation dans le monde physique, et c’est aussi sa limite : la confiance que l’on accorde à un inconnu qu’on nous présente ne peut jamais être plus solide que la confiance que l’on accorde à celui qui le présente. Aucun dispositif technique ne peut dépasser cette borne, car elle ne tient pas à la technique. Une solution numérique ne saurait rendre une rencontre plus sûre qu’elle ne l’est dans le monde tangible. Ce qu’une messagerie peut faire, en revanche, c’est ne pas dégrader cette sécurité, ne pas y substituer la confiance en un serveur. Olvid s’y emploie en transposant le geste de la présentation, dont elle conserve, dans le monde numérique, la structure de confiance — au détail près, inévitable, que l’introducteur y agit par l’intermédiaire de son appareil, et que la confiance qu’on lui accorde englobe désormais celui-ci. Elle ne se déplace, en revanche, jamais vers un serveur.

Sécurité de bout en bout ✅ Bon

Les deux composantes du critère composite sont réunies : chiffrement systématique et authentification de bout en bout.

Pas de substitution d'identité ✅ Bon

L’identité étant la paire de clés long terme elle-même, il n’existe aucun identifiant externe (numéro, email) qu’un mécanisme de récupération pourrait réassocier à une nouvelle clé. Un changement de clé est, par construction, un changement d’identité. La règle tient jusque dans l’annuaire d’entreprise optionnel : une nouvelle clé n’y remplace jamais l’ancienne sur les appareils des contacts — elle ne peut apparaître que comme un nouveau contact, l’ancien devant être supprimé à la main. Personne ne peut donc se substituer à un utilisateur en faisant enregistrer une nouvelle clé à sa place.

Client open source ✅ Bon

Les applications sont publiées sous licence open source (AGPLv3)^archivé, la documentation cryptographique est publique^archivé, et le code du serveur est également ouvert^archivé, sous la même licence (ce que le critère n’exige pas, puisque le serveur ne joue aucun rôle dans la sécurité).

Les builds reproductibles permettent de vérifier que l’application distribuée correspond au code publié. En septembre 2026, celles-ci sont disponibles pour l’application Android distribuée sur F-Droid^archivé, mais pas encore pour celle du Play Store.

Multi-appareil de bout en bout ✅ Bon

Tous les appareils d’un utilisateur partagent la même identité cryptographique. Un contact qui a authentifié cette identité fait ainsi confiance à l’ensemble des appareils, sans vérification supplémentaire et sans qu’aucune opération ne lui soit demandée quand un appareil est ajouté ; en interne, un canal sécurisé est établi entre chaque paire d’appareils à partir de la clé commune. Le serveur distribue la liste des identifiants d’appareils d’un utilisateur, et pourrait donc tenter d’y ajouter un appareil de son choix ; mais cette injection est sans effet : un tel appareil ne détiendrait pas la partie privée de l’identité de l’utilisateur ciblé, sans laquelle il ne peut établir de canal sécurisé avec aucun contact. Il ne pourrait donc ni recevoir, ni envoyer, le moindre message. L’ajout malveillant d’un appareil est donc sans conséquence sur la confidentialité des échanges. Le retrait malveillant d’un appareil de la liste, lui, ne ferait que priver cet appareil des messages : une question de disponibilité, non de sécurité, et qui affecte toutes les messageries utilisant un serveur (celui-ci peut simplement cesser d’acheminer les messages qu’on lui confie).

L’ajout légitime d’un appareil, lui, répond aux exigences que pose le critère. La procédure ne peut être déclenchée que depuis l’appareil qui détient déjà le profil, par une action délibérée dans les réglages : rien — ni message, ni lien, ni QR code — ne peut déclencher un ajout d’appareil de l’extérieur. L’utilisateur doit ensuite saisir deux codes de 8 chiffres, un sur chaque appareil : le premier permet aux deux appareils de se retrouver sur le serveur, le second (de type SAS) authentifie le canal chiffré établi entre eux — le serveur qui relaie le transfert ne peut ni le lire ni s’y interposer. Rien dans ce parcours ne peut être validé machinalement.

Données personnelles minimales ✅ Bon

Olvid s’utilise sans fournir la moindre donnée personnelle — ni nom, ni adresse email, ni numéro de téléphone, ni accès au carnet d’adresses. Le serveur ne connaît que ce qui lui est strictement nécessaire pour acheminer des messages, l’envoi étant même « anonyme » de son point de vue. Comme tout serveur de relais, il peut en revanche observer le graphe social de ses utilisateurs ; la minimisation garantit que les nœuds de ce graphe restent des pseudonymes. Sur Android, un réglage permet en outre de renoncer aux notifications de Google au profit d’une connexion permanente aux serveurs d’Olvid : disparaît alors le jeton de notification, et avec lui le pont qu’un tiers peut établir vers l’identité réelle. Pour une entreprise, cette absence de collecte réduit d’autant les traitements à documenter au titre du RGPD.

Pas de découverte d'utilisateurs ni de spam ✅ Bon

Il n’existe, par défaut, aucun annuaire ni identifiant permettant de retrouver un utilisateur : on ne peut pas « chercher » quelqu’un sur Olvid (l’annuaire d’entreprise optionnel n’ouvre cette recherche qu’aux membres d’une même organisation). Mais surtout, un utilisateur ne reçoit jamais le moindre message d’un tiers sans avoir explicitement accepté la mise en relation au préalable — la seule chose qui puisse lui parvenir d’un inconnu est la demande de mise en relation elle-même.

Un inconnu ne peut donc solliciter un utilisateur qu’à la condition de détenir déjà son identité, qui ne peut être ni cherchée ni découverte et ne circule que si l’utilisateur (ou l’un de ses contacts) l’a transmise. Et cette sollicitation se réduit à une demande de mise en relation portant un simple nom : une courte chaîne choisie par l’émetteur, affichée comme du texte brut — le minimum incompressible, puisqu’il faut bien indiquer au destinataire qui l’invite. Aucun message, aucun média, aucun appel n’est traité par l’application avant acceptation : le spam et l’hameçonnage par message non sollicité sont écartés, et la surface exposée aux attaques « 0-click » — qui supposent de pouvoir livrer du contenu traité automatiquement par l’application — se réduit à l’analyse et à l’affichage d’un nom.

Chiffrement post-quantique ❌ Mauvais

Olvid n’intègre pas encore de chiffrement post-quantique : ses canaux sécurisés reposent aujourd’hui sur des mécanismes d’encapsulation de clé (KEM) classiques, construits sur les courbes Curve25519 et MDC. Un KEM post-quantique hybride fondé sur ML-KEM doit y être ajouté en 2027. Il protégera l’établissement initial des canaux comme leur renouvellement périodique (le « full ratchet »), et donc aussi les discussions de groupe, qui reposent sur ces mêmes canaux entre appareils.