Comment fonctionnent les liens secrets LinkPilot.

1. Vue d’ensemble

LinkPilot fait tourner deux chaînes de traitement distinctes sur la même plateforme : les liens intelligents, des URL courtes sur votre propre domaine avec statistiques de clics, et les liens secrets, qui transmettent un contenu sensible une seule fois, avec expiration et phrase de passe. Les deux sont séparées au niveau des données, du code et du produit, pour que le contenu d’un secret ne puisse jamais se retrouver dans les tableaux de bord de statistiques, les exports de données ou les fonctions d’IA.

Cette page décrit uniquement la chaîne des liens secrets : comment un secret est créé, comment il est affiché, ce qui se passe après son ouverture et quelles métadonnées sont journalisées au passage.

2. Fonctionnement des liens secrets

1. L’expéditeur crée un secret, avec en option une phrase de passe, une durée d’expiration et un nombre maximal d’ouvertures avant destruction.
2. Le navigateur de l’expéditeur chiffre le contenu avant tout envoi. Ce qui nous parvient est du texte chiffré, écrit dans une table dédiée secret_links, isolée des tables de statistiques de clics.
3. LinkPilot renvoie une URL courte (par exemple shrd.link/s/<slug>#k=<key>) à transmettre au destinataire. La partie située après le # est la clé de déchiffrement : elle est générée dans le navigateur de l’expéditeur et ne nous est jamais transmise. Nous ne pouvons pas reconstituer cette URL par la suite.
4. Quand le destinataire ouvre le lien, l’application appelle la fonction de périphérie secret-reveal. Une requête GET ne renvoie que des métadonnées (le statut, et si une phrase de passe est requise). C’est une requête POST accompagnée de la phrase de passe qui renvoie le texte chiffré. Le navigateur du destinataire le déchiffre ensuite avec la clé tirée du fragment de l’URL. La fonction d’affichage elle-même ne déchiffre jamais rien, et elle en serait incapable même si elle le voulait.
5. Un affichage réussi est enregistré de façon atomique et peut faire passer immédiatement le secret à l’état burned, selon le nombre d’ouvertures autorisé avant destruction.

3. Modèle de chiffrement

Nous tenons à être précis, car les mots « chiffré » et « zero-knowledge » sont souvent employés à la légère.

• En transit : tout le trafic est chiffré par TLS de bout en bout entre le destinataire, notre infrastructure de périphérie et notre base de données managée.
• Dans votre navigateur, avant l’envoi : depuis le 29 septembre 2026, le contenu est chiffré côté client en AES-GCM-256 avec une clé de 256 bits générée dans votre navigateur. Nous stockons le texte chiffré et rien d’autre. La clé voyage dans le fragment du lien de partage, après le #, que les navigateurs n’envoient à aucun serveur, ni à nous, ni à Cloudflare, qui sert la page d’affichage.
• Au repos : le texte chiffré se trouve dans une colonne séparée logiquement des données de statistiques, sur une instance Postgres managée qui dispose en plus d’un chiffrement au niveau du disque.
• Phrases de passe : quand vous en définissez une, elle est convertie dans une forme Unicode standard (NFKC), pour que la même phrase de passe tapée sur un autre clavier ou avec une autre méthode de saisie produise la même clé. Elle est ensuite étirée avec PBKDF2-SHA256 (210 000 itérations) puis combinée à la clé du lien par HKDF-SHA256, si bien que ni le lien seul ni la phrase de passe seule ne déchiffre le secret. En parallèle, un hash SHA-256 de la phrase de passe est envoyé, pour que le serveur puisse refuser purement et simplement de renvoyer le texte chiffré à quiconque ne la connaît pas. La phrase de passe en clair n’est jamais écrite dans notre base de données ni dans nos journaux.
• Ce que cela protège et ce que cela ne protège pas : nous, notre base de données et notre infrastructure de périphérie sortons du périmètre de confiance. Cela ne protège pas un secret dont le lien complet a été transféré, capturé en image ou journalisé par un outil du côté du destinataire, car ce lien contient la clé.
• Les deux exceptions, dites clairement : les secrets créés avant le 29 septembre 2026 sont stockés en texte en clair. Ils ne sont jamais réécrits en silence, continuent de fonctionner exactement comme avant et disparaissent à leur expiration. Les pièces jointes sont elles aussi chiffrées dans le navigateur, avec une clé dérivée de celle du secret, si bien qu’un seul lien ouvre les deux et que nous ne détenons aucune clé pour l’un ni pour l’autre. Nous voyons encore le nom, la taille et le type d’un fichier : ce sont des colonnes de métadonnées, pas du contenu. Les pièces jointes importées avant le 29 septembre 2026 restent stockées sous forme de fichiers en clair.

La conséquence pratique mérite d’être dite clairement : comme nous ne détenons jamais la clé, nous ne pouvons pas récupérer un secret pour vous. Si le lien de partage est perdu, le contenu est perdu.

Vérifiez par vous-même. Vous n’avez pas à croire sur parole que le chiffrement se fait dans le navigateur. Le même code de chiffrement est publié dans notre dépôt open source linkpilot-cli (licence MIT), qui contient la CLI, le SDK TypeScript et le serveur MCP. Le dépôt contient aussi les vecteurs de test sur lesquels l’application web est vérifiée : vous pouvez lire la dérivation de clé, exécuter les vecteurs et confirmer que ce qui quitte un client est du texte chiffré et que la clé ne va que dans le fragment du lien. Si vous constatez un écart entre ce code et cette page, signalez-le.

4. Ce qui se passe après l’ouverture d’un secret

• L’ouverture est enregistrée de façon atomique par une fonction de la base de données. Des tentatives d’affichage simultanées ne peuvent donc pas divulguer le secret deux fois.
• Si le nombre maximal d’ouvertures est atteint, le statut du secret passe à burned et le contenu stocké est remplacé par [REDACTED].
• Les tentatives d’affichage suivantes reçoivent une réponse explicite, « déjà ouvert et détruit », avec le code HTTP 410.
• L’historique d’audit enregistre chaque ouverture, destruction et révocation avec une IP hachée, ce qui sert en cas d’incident et pour savoir quels identifiants renouveler.

5. Expiration et révocation

• Chaque secret peut avoir une expiration dans le temps (1 heure, 24 heures ou 7 jours sur tous les forfaits, ou une date et une heure personnalisées avec le forfait Pro) et, en option, un nombre maximal d’ouvertures.
• Un secret expiré passe à l’état expired lors de l’accès suivant, et son contenu est supprimé dans la même opération d’écriture.
• Le propriétaire peut révoquer un secret manuellement à tout moment depuis le tableau de bord. Un secret révoqué refuse immédiatement tout affichage et renvoie le code HTTP 410.
• Une fois un secret détruit, expiré ou révoqué, son contenu ne peut plus être récupéré par le produit. Il n’existe volontairement aucune action « annuler la révocation » ou « restaurer ».

6. Protection par phrase de passe

• Les phrases de passe sont facultatives, mais recommandées pour tout secret que vous ne voulez pas voir consommé par un visiteur de passage.
• La phrase de passe est hachée en SHA-256 dans le navigateur, envoyée via TLS et comparée par son hash sur le serveur. La valeur brute n’atteint jamais notre base de données.
• Nous limitons les tentatives de phrase de passe à 5 par IP, par minute et par secret, avec un limiteur en mémoire et une fenêtre glissante stockée en base de données.
• Chaque tentative échouée est écrite dans le journal d’audit avec une IP hachée, pour que les propriétaires de l’espace de travail puissent repérer une activité suspecte.
• Nous recommandons d’envoyer la phrase de passe par un autre canal que le lien, par exemple le lien par e-mail et la phrase de passe par message privé Slack ou par SMS.

7. Protection contre les scanners de liens et les robots d’aperçu

Les scanners de sécurité des e-mails et les outils d’aperçu de liens des messageries (Slack, LinkedIn, iMessage, Outlook) consultent les URL dès qu’elles apparaissent. Pour un lien détruit après lecture, une conception naïve laisserait le tout premier aperçu détruire le secret avant que le destinataire ne le voie.

LinkPilot l’empêche de trois façons :

• Des points d’accès distincts pour les métadonnées et l’affichage. Une requête GET sur le point d’accès d’affichage ne renvoie que le statut et l’indication qu’une phrase de passe est requise ou non. Une ouverture n’est enregistrée que sur une requête POST explicite, c’est-à-dire l’action d’une personne qui clique sur le bouton Afficher.
• Le verrou de la phrase de passe. Quand une phrase de passe est définie, aucun contenu n’est renvoyé à qui que ce soit, robot ou humain, sans le bon hash.
• Cache-Control: no-store sur chaque réponse d’affichage, pour que les intermédiaires ne mettent pas en cache le contenu des secrets.

8. Métadonnées journalisées

Pour chaque tentative d’affichage, nous n’enregistrons que ce qui est nécessaire pour fournir aux propriétaires d’espaces de travail une piste d’audit fiable :

• Horodatage de la tentative.
• IP hachée : SHA-256 de l’IP du client combinée à un sel renouvelé chaque jour, tronqué à 32 caractères. L’IP brute n’est jamais stockée.
• Géolocalisation approximative (pays et ville) fournie par le serveur de périphérie, quand le fournisseur en amont la communique.
• Chaîne User-Agent transmise par le client.
• Type d’événement : created, viewed, failed_passphrase, burned, expired, revoked.

Nous ne journalisons pas : le contenu des secrets, la phrase de passe brute, l’adresse IP brute, des cookies chez le destinataire (il n’y en a aucun) ou des pixels de suivi tiers.

9. Différences entre les liens secrets et les liens à statistiques

Les deux chaînes partagent la même marque, le même tableau de bord et les mêmes réglages d’équipe, mais leurs flux de données ne se croisent pas.

10. Pièces jointes

• Les fichiers sont chiffrés dans le navigateur avec une clé dérivée de celle du secret : un seul lien ouvre à la fois le texte et le fichier.
• Ils sont servis par des URL signées de courte durée, derrière les mêmes protections que le texte : phrase de passe, expiration et destruction.
• Le nom, la taille et le type d’un fichier restent visibles pour nous en tant que métadonnées. Son contenu, non.
• Les pièces jointes importées avant le 29 septembre 2026 restent stockées en clair jusqu’à leur expiration ; elles ne sont jamais réécrites.

11. Conservation

• Le contenu d’un secret est écrasé quand le secret se détruit, expire ou est révoqué. Il n’existe volontairement aucune restauration, et nous ne pouvons pas le récupérer pour vous.
• Les données du compte sont conservées tant que l’espace de travail est actif, puis 30 jours après sa suppression, pour qu’une suppression accidentelle puisse être annulée.
• Au bout de 90 jours, les statistiques de clics des liens courts sont agrégées en décomptes anonymisés.
• Les événements de l’historique d’audit ne conservent que les valeurs hachées et salées décrites à la section 8 : il n’existe aucune adresse brute à conserver.

12. Secrets anonymes et secrets d’espace de travail

Le générateur gratuit de liens secrets crée des secrets sans compte. La destruction après lecture y est toujours active, l’expiration est de 1 heure, 24 heures ou 7 jours, le formulaire est protégé par Turnstile contre les abus automatisés, et le même chiffrement dans le navigateur s’applique.

Un secret créé dans un espace de travail ajoute l’historique d’audit, la révocation depuis le tableau de bord, les pièces jointes et, avec le forfait Pro, les phrases de passe et une date et une heure d’expiration personnalisées. Le modèle de chiffrement est identique dans les deux cas.

13. Les limites, dites clairement

• Un lien transféré, c’est un secret transféré. Rien dans la conception ne peut empêcher un destinataire de transmettre le lien avant de l’ouvrir. Une expiration courte et une phrase de passe envoyée par un second canal sont les parades.
• Un lien perdu, c’est un secret perdu. Nous ne détenons jamais la clé, il n’y a donc rien à récupérer.
• L’exception d’avant le 29 septembre. Les secrets créés avant cette date étaient stockés en texte en clair jusqu’à leur expiration.
• Ni open source, ni auto-hébergeable. Le client de chiffrement est publié avec ses vecteurs de test dans le dépôt de la CLI, sous licence MIT ; le service lui-même est un produit hébergé. Si l’auto-hébergement est indispensable, consultez les alternatives open source.
• Une ouverture n’est pas une personne. L’historique indique quand et, approximativement, d’où un secret a été ouvert, jamais par qui. Si la mauvaise personne l’a ouvert, renouvelez les identifiants.

14. Signaler une vulnérabilité

Les failles de sécurité et les liens abusifs se signalent sur /report et arrivent directement à l’équipe. Les demandes liées à la confidentialité et aux données sont à envoyer à privacy@uselinkpilot.com et reçoivent une réponse sous 30 jours ; la page RGPD indique ce que nous traitons et sur quelle base.

15. Questions fréquentes