Réponse aux incidents
Que se passe-t-il si quelqu’un ouvre le lien en premier ?
Que faire lorsqu’un lien sensible ou un mot de passe a pu parvenir à la mauvaise personne.
Publié le: 15 avril 2026
Limites de l’implémentation actuelle
Le client actuel chiffre le texte dans le navigateur et place le contenu chiffré dans l’URL. Le mot de passe transmis séparément ne fait pas partie du lien. Aucun serveur applicatif ne stocke, ne récupère, ne supprime ou ne consomme les messages une seule fois.
Contexte complémentaire
Réponse directe : Collogue ne peut pas montrer qui a ouvert un lien. Si le lien et le mot de passe transmis séparément ont pu parvenir à la mauvaise personne, considérez les identifiants comme potentiellement exposés : révoquez-les ou remplacez-les, vérifiez le destinataire par un autre canal et créez un nouveau message au lieu de renvoyer la même valeur.
Collogue ne possède aucun événement de lecture côté serveur et ne peut donc pas prouver qu’une personne a ouvert un message ni identifier cette personne. Un lien défectueux ou un déchiffrement échoué peut aussi être dû à une URL incomplète ou modifiée, ou au mauvais mot de passe.
Si le message contenait un mot de passe, une clé API, un jeton de session, un code de récupération ou un lien d’accès, considérez cette valeur comme exposée.
- Révoquez-la ou remplacez-la.
- Ne renvoyez pas la même valeur.
- Confirmez le destinataire prévu.
- Créez si possible une nouvelle valeur temporaire.
- Envoyez un nouveau lien Collogue.
- Examinez le chemin de distribution si le problème se répète.
Un identifiant permanent crée un incident plus important qu’un identifiant temporaire. C’est pourquoi la distribution et la conception des identifiants doivent être pensées ensemble.
Tous les messages privés ne contiennent pas un identifiant d’accès.
Si le contenu était une note sans importance critique, l’expéditeur peut créer un nouveau message après avoir confirmé le destinataire. Le risque dépend de la sensibilité du texte et des conséquences de sa divulgation.
Le service ne peut pas prendre cette décision à la place de l’utilisateur. Il peut en revanche expliquer clairement l’état observé.
Seulement si le service collecte intentionnellement des éléments pertinents et peut les interpréter de manière fiable – et même dans ce cas, l’attribution peut rester incertaine.
- le destinataire prévu ;
- un proxy d’entreprise ;
- un opérateur mobile ;
- un VPN ;
- un analyseur d’e-mails ;
- un réseau partagé ;
- un attaquant.
Un user-agent peut décrire un logiciel, pas une personne.
Ne laissez pas entendre qu’une piste d’audit identifie un être humain si le système ne comprend pas une identité de destinataire authentifiée et si cette affirmation n’est pas étayée.
En cas d’échecs répétés de distribution au sein d’une organisation, testez des liens non sensibles via le même chemin de messagerie et examinez la politique de la passerelle de sécurité avec l’administrateur. N’utilisez pas un véritable identifiant comme message de test.
- évaluez les conséquences de la divulgation ;
- confirmez si le destinataire a ouvert le lien ;
- ne répétez pas plus de contexte que nécessaire ;
- utilisez le processus d’incident prévu pour les informations réglementées.
Non. Le client actuel ne collecte pas les événements de lecture et une requête d’URL n’identifie pas une personne.
Si un lien contenant un mot de passe ne se déchiffre pas, vérifiez l’URL et le mot de passe. Remplacez l’identifiant dès que les deux éléments ont pu être exposés.
Collogue ne peut pas distinguer de manière fiable un analyseur d’une personne. Ne publiez que les capacités de diagnostic réellement fournies par le code.