Questions fréquentes

Pendant l’inscription, l’application reçoit du serveur une petite tâche cryptographique (Proof of Work) et la résout — c’est une protection contre les inscriptions automatiques par des bots. En parallèle sont générés des identifiants d’appareil uniques et plusieurs jeux de clés de chiffrement : des clés d’identité à long terme, des préclés signées et des préclés à usage unique (y compris post-quantiques ML-KEM-1024). Seules les parties publiques de ces clés et le résultat de la tâche PoW sont envoyés au serveur. Les clés privées ne quittent jamais l’appareil. Il n’y a pas de mot de passe : le compte est défini par les clés, et on peut le retrouver sur un nouvel appareil grâce à une clé de récupération de 12 mots.

Oui, avec la clé de récupération de 12 mots : sur un nouvel appareil ou après une réinstallation, choisissez « Restaurer » et saisissez les mots. Le compte et son adresse reviennent ; les anciens messages et sessions restent sur l’ancien appareil et ne sont pas transférés. Sans ces mots, perdre l’appareil ou supprimer l’application revient à perdre le compte définitivement.

La clé de récupération est créée automatiquement à l’inscription — vous n’avez rien à faire. Vous pouvez en enregistrer une copie (12 mots) plus tard, dans les Paramètres : l’application vous le rappellera, et l’exigera avant la déconnexion du compte. Tant que la copie n’est pas faite, les mots sont conservés sur l’appareil, chiffrés, et ne s’ouvrent qu’après Face ID, une empreinte digitale ou le code du téléphone ; une fois la copie faite, ils sont effacés de l’appareil. Notez-les et gardez-les en lieu sûr — Konstruct n’a ni votre numéro de téléphone ni votre e-mail, et c’est le seul moyen de récupérer le compte.

Le système est conçu pour qu’un inconnu ne puisse pas simplement commencer à vous écrire. Pour démarrer une conversation, l’un partage un code QR ou un lien d’invitation, et l’autre le scanne ou l’ouvre. Ils sont à usage unique : un code QR dure cinq minutes, un lien douze heures — un lien accepté une fois ne peut pas être réutilisé. Séparément, vous pouvez activer la découverte dans les paramètres et devenir trouvable par votre nom d’utilisateur ; elle est désactivée par défaut, donc tant que vous ne l’avez pas activée, l’invitation est le seul chemin.

C’est un choix délibéré. Dans la plupart des messageries, il suffit de connaître un numéro de téléphone ou un pseudo pour se mettre à inonder quelqu’un de messages. Ici, le consentement mutuel est inscrit dans l’architecture, et pas seulement déclaré dans une politique.

Le code n’est accepté qu’une seule fois : un lien qui circule ne peut donc faire entrer qu’une personne au maximum, et un lien déjà utilisé ne fait rien. De plus, le lien cesse d’être valable douze heures après sa création, et le code QR au bout de cinq minutes. Si quelqu’un a malgré tout été ajouté, vous verrez une nouvelle conversation et pourrez la bloquer immédiatement.

Tous les messages sont chiffrés sur l’appareil de l’expéditeur avant l’envoi et ne sont déchiffrés que sur l’appareil du destinataire. Le serveur ne voit qu’un flux chiffré et l’achemine — il ne peut pas en lire le contenu. Pour établir la session, on utilise X3DH, étendu par un accord de clés post-quantique (PQXDH) : l’expéditeur encapsule un secret ML-KEM-1024 dans la préclé Kyber du destinataire, et ce secret entre dans la clé initiale de la session avec les clés classiques — c’est ce qui limite le scénario « enregistrer maintenant, déchiffrer plus tard avec un ordinateur quantique ». La protection post-quantique s’applique dès le premier message, et l’application n’établira pas de session sans elle. Ensuite intervient le Double Ratchet, qui change les clés à chaque message — et chaque message a en plus sa propre clé post-quantique — de sorte que la compromission d’une clé ne dévoile ni les messages passés ni les messages futurs. L’identité de l’expéditeur est elle aussi protégée de façon post-quantique ; les appels sont protégés par DTLS post-quantique lorsque les deux applications le prennent en charge. Restent classiques : les signatures du serveur (certificats d’expéditeur, journal de transparence des clés), la connexion de l’appareil et la récupération du compte, les jetons Privacy Pass et le TLS de transport ; les groupes n’existent pas encore ; la liste complète figure dans la spécification du protocole.

Très peu, et rien de tout cela ne vous concerne en personne. Pour livrer un message, le serveur a besoin de l’identifiant opaque du compte du destinataire, de la taille du texte chiffré et de l’heure de réception ; il conserve aussi vos clés publiques et, sur iOS, un jeton push. C’est toute la liste. Il ne voit ni le contenu, ni votre nom, ni votre avatar, ni votre liste de contacts — et, sur le chemin de protection de l’expéditeur, toujours activé, il ne voit pas qui a envoyé le message. Les messages ne sont conservés par le serveur que chiffrés et sont supprimés selon une durée de conservation (environ 7 jours), et non au moment de la livraison. Le nom d’utilisateur est facultatif, ne participe pas à l’acheminement et n’est stocké que sous forme de hachage à clé, dans un seul but — permettre de vous trouver ; la recherche elle-même est désactivée tant que vous n’activez pas la découverte, donc par défaut un compte ne peut pas du tout être trouvé par son nom.

C’est la partie la plus difficile. Le serveur voit toujours que quelqu’un a livré un texte chiffré à l’appareil B (destinataire, heure, taille). Avec la protection de l’expéditeur, toujours activée, il ne sait pas qui a écrit — voir la question suivante. La protection anti-censure masque en partie le chemin réseau. L’anonymat complet au niveau du routage (se cacher à la fois du destinataire et de la corrélation par IP et par horodatage) est un problème d’un autre ordre, et il n’est pas résolu aujourd’hui.

Non — le champ expéditeur n’est pas placé dans l’enveloppe, et c’est toujours activé pour le trafic ordinaire (messages, accusés de livraison, établissement des appels, échange de profils). Il n’y a aucun interrupteur qu’on puisse oublier. Votre appareil scelle un certificat d’expéditeur signé avec la clé du destinataire : le destinataire peut l’ouvrir et vérifier qui a écrit, le serveur non. Quelques chemins internes — maintien de la connexion, synchronisation de vos propres appareils, messages de service de la session — transportent encore l’expéditeur, par conception.

Il faut préciser ce qui est caché, car ce n’est pas une identité. Le serveur n’en a jamais eu : un compte, ici, c’est une paire de clés et un identifiant opaque, sans numéro de téléphone, sans e-mail ni vrai nom, donc il n’y a au départ rien à relier à une personne. La protection de l’expéditeur supprime le dernier lien entre deux de ces identifiants — qui a écrit à qui. Le niveau réseau est une autre histoire, plus haut : l’heure et l’IP restent visibles, et c’est là que travaille un observateur disposant de moyens.

Limites : la protection de l’expéditeur cache son identité au serveur, mais pas l’heure, la taille ni l’IP — cela reste visible au niveau réseau/transport. Des jetons Privacy Pass peuvent accompagner l’envoi protégé (sealed sender) pour lutter contre le spam ; le contrôle côté serveur est encore en cours de déploiement — le contrôle de débit sur les jetons est en cours d’amélioration et n’est pas terminé.

Non — aucune. Pas d’analytique, pas de métriques d’usage, pas d’événements comportementaux, pas d’envoi de rapports de plantage, pas d’identifiants publicitaires. Pas « collecté puis anonymisé » — pas collecté du tout. L’application ne contient aucun traceur tiers (ni Firebase, ni Crashlytics, ni Sentry, ni Amplitude, ni Segment) ; les seules dépendances externes sont le transport/les médias et, sur iOS, une bibliothèque locale de reconnaissance vocale. Les versions de production n’écrivent en outre aucun journal de diagnostic sur le disque et n’offrent ni écran de débogage ni export des journaux. Quand il nous faut des journaux pour corriger un bogue, c’est vous qui les envoyez avec le bouton « partager » d’une version bêta — jamais d’envoi silencieux.

Votre nom affiché et votre avatar vivent sur l’appareil ; ils ne font pas partie du profil public et personne ne peut les retrouver. Quand vous démarrez une nouvelle conversation, votre interlocuteur ne voit qu’un pseudonyme généré — déterministe, toujours le même pour un ID donné. Pour montrer votre vrai nom et votre photo, ouvrez le profil de l’interlocuteur et activez « Partager mon profil » : les deux passent par le canal chiffré. Une exception : quand vous envoyez une demande de contact, votre nom d’utilisateur et votre nom affiché y sont joints, afin que le destinataire comprenne qui le sollicite. Le serveur conserve cet instantané chiffré, mais sous sa propre clé — ce n’est pas du chiffrement de bout en bout ; l’avatar n’y figure jamais.

Un nom vide serait peu pratique : dans la liste des discussions, vous verriez des lignes sans visage et ne pourriez pas distinguer un contact d’un autre. Le nom généré est stable — « Faucon rapide » restera toujours « Faucon rapide » pour cet ID, sur n’importe quel appareil.

Oui. Priorité d’affichage : nom affiché (s’il l’a partagé) → nom d’utilisateur → nom généré. Si quelqu’un s’est inscrit avec le nom d’utilisateur @john, vous verrez justement celui-ci, et non « Baleine paisible ».

• Envoi en cours en cours de chiffrement sur votre appareil
• Envoyé parti de l’appareil, le serveur l’a accepté
• Remis l’appareil du destinataire l’a déchiffré et a renvoyé une confirmation
• En file d’attente pas encore parti — l’application continue d’essayer d’elle-même ; touchez si vous ne voulez pas attendre
• Échec de l’envoi rejeté pour une raison qu’une nouvelle tentative ne corrigera pas, donc rien ne se passera de lui-même ; touchez pour réessayer

Il n’y a pas de statut « lu », et c’est voulu : un accusé de lecture indiquerait à l’expéditeur quand vous avez ouvert l’application — une information sur vous dont le message n’a pas besoin. « Remis » est un accusé chiffré de l’appareil du destinataire, et non un message du serveur disant qu’il a transmis quelque chose.

Oui, la modification est prise en charge. Après modification, le message porte la mention « modifié ». La modification est transmise à l’appareil du destinataire par le même mécanisme de livraison que les messages ordinaires.

Sur iOS, les notifications passent par l’Apple Push Notification Service (APNs) : il faut une connexion internet stable, et si le téléphone est en mode avion, derrière un VPN à filtrage agressif, ou si Apple juge le push « à faible priorité », la notification peut être retardée ou ne pas arriver. Sur Android, il n’y a aucun service push : l’application maintient sa propre connexion, ce que signale une notification permanente ; une économie de batterie agressive ou un réseau bloqué peuvent retarder les messages. Quand l’application se rouvre, les messages se synchronisent automatiquement.

L’application dispose d’un mode de protection anti-censure : il modifie la façon dont elle accède au réseau lorsque la connexion directe est bloquée. Dans les Paramètres, il s’agit d’un seul sélecteur à trois positions (désactivée, automatique, activée), et la valeur par défaut est « automatique » : tant que la connexion directe fonctionne, c’est elle qui est utilisée, et le basculement n’a lieu qu’après un échec avéré. Il n’y a rien à configurer, aucune adresse à saisir, tout se passe en arrière-plan. L’implémentation est ouverte, de sorte que n’importe qui peut en étudier la conception.

Par défaut, c’est automatique : la connexion directe est plus rapide, donc tant qu’elle fonctionne, elle est utilisée, et le basculement n’a lieu qu’en cas d’échec avéré. Vous pouvez aussi forcer l’activation ou la désactivation. Ce que nous ne publions volontairement pas : quelles techniques sont actuellement opérationnelles, et où elles passent ou non à l’heure actuelle ; un état des lieux public et à jour sur ce sujet serait un retour d’information gratuit pour ceux qui bloquent. Pour la même raison, l’application elle-même ne l’affiche pas non plus.

L’échange de messages s’arrête jusqu’à son retour. L’alpha fonctionne sur un seul serveur de confiance, et il n’y a aujourd’hui aucun second chemin — ni relais, ni connexions directes, ni autre nœud sur lequel s’appuyer. Tout ce qui est chiffré reste chiffré, rien n’est perdu — simplement, rien ne circule. La feuille de route existe précisément pour que cela cesse d’être vrai, et rien n’en a encore été livré.

Oui — sans condition. L’envoi de messages, la réception de messages, E2EE et toutes les fonctions de sécurité ne passeront jamais derrière un accès payant. Les modèles reposant uniquement sur les dons se sont historiquement révélés fragiles pour les projets de confidentialité, c’est pourquoi Konstruct prévoit une combinaison : dons volontaires, fonctions premium optionnelles (fichiers volumineux, historique étendu, thèmes — jamais des fonctions de sécurité) et hébergement B2B pour les organisations. Le cœur sera toujours gratuit.

Sans publicité, sans revente de données, sans télémétrie — la contrepartie est que Konstruct vit de dons volontaires. Ils vont directement au développement et au serveur. Si vous tenez à la confidentialité, préférez Monero (XMR) : contrairement à Bitcoin, sa chaîne n’est pas publique. Avant tout envoi, vérifiez toujours l’adresse auprès du dépôt du projet, au cas où une page aurait été falsifiée.

• Monero (XMR) — recommandé :
  496i5qvPzRtJPQjiPXnLvEGutjHFth4pWDQaJwbbMreyaTYg4qfbo48MXrTnYH32MHiAn5GcSEN1c48EYBvVkrx9Pi5BWvn
• Bitcoin (BTC) :
  bc1q5cthgu6k9utg9hk2mx2xshdtsrhvu54ysmqhmm
• Ko-fi — pratique, mais pas privé : le service de paiement sait qui vous êtes :
  ko-fi.com/construct_msg

Le mode P2P est prévu, mais pas encore implémenté : pour l’instant, tout le trafic passe par le serveur central. Conception visée : lorsque les deux interlocuteurs sont en ligne en même temps et connectés à un serveur Konstruct, le serveur leur signale de passer à une connexion P2P directe sur QUIC. Une fois celle-ci établie, le serveur quitte le chemin de livraison : le trafic circule directement entre les appareils. Si l’un des deux passe hors ligne, la livraison repasse par le serveur.

Pour cela, l’application propose le « Mode verrouillage ». Lorsqu’il est activé, les notifications et les alertes ne proviennent que des personnes qui figuraient dans vos contacts au moment de son activation. Les messages de nouveaux expéditeurs sont tout de même conservés : ils ne vous dérangent simplement pas. Ce mode est utile si vous êtes une personnalité publique et souhaitez vous fermer temporairement aux nouveaux contacts.

Si un même expéditeur envoie un nombre anormalement élevé de messages en peu de temps (plus de ~10 en 30 secondes), le client affiche automatiquement un avertissement et coupe les notifications de cet expéditeur. Vous pouvez alors l’autoriser ou le bloquer. Important : cette protection agit côté destinataire et fonctionne quel que soit le client utilisé par l’expéditeur.

Une session est un canal chiffré établi entre deux appareils. Elle repose sur des clés à usage unique, qui ne peuvent pas être réutilisées, et les clés changent à chaque message. Si l’application est restée longtemps inactive, si l’appareil a été réinstallé ou si votre interlocuteur a supprimé la conversation, un message entrant peut devenir illisible. L’application du destinataire indique alors à l’expéditeur sur quel état de session ce message a été écrit ; l’application de l’expéditeur ouvre un nouvel état et renvoie le message. En règle générale, l’utilisateur ne remarque rien : le message arrive simplement.

Il n’est pas encore possible de lier un deuxième appareil dans les versions publiques. Le client de bureau natif est gelé ; un client en console (TUI) est en cours de développement. Comme l’identité est liée aux clés et non à un compte sur le serveur, la prise en charge de plusieurs appareils exige un mécanisme distinct de liaison des clés : nous y travaillons.

Les messages en direct passent par un MessageStream gRPC bidirectionnel : un seul flux durable pour les heartbeats, les messages entrants et les accusés de réception, sans polling requête/réponse. Sur les versions iOS actuelles, le chemin de production est QUIC (construct-transport) ; si QUIC est bloqué ou si le handshake échoue, le client bascule automatiquement sur gRPC au-dessus de HTTP/2 + TLS 1.3. Le chiffrement de bout en bout ne dépend pas du transport : seul du texte chiffré scellé circule sur le réseau.