Contacter l’assistance

Comment les demandes sont priorisées, et ce qu’on n’envoie jamais

La priorité suit l’impact et l’urgence, pas la formulation. Et aucune demande ne doit jamais porter un mot de passe, un jeton d’accès, un secret d’API, un en-tête Authorization ou un contenu QR privé — ni dans le message, ni dans une capture, ni dans un journal joint.

Vérifié le 20 août 2026

Étapes

1. Indiquez combien de personnes et quels codes sont touchés, et s’il existe un contournement. C’est ce qui fixe l’ordre.
2. Attendez-vous au critique d’abord — panne généralisée, risque de perte de données, ou problème de sécurité — puis une fonction essentielle inutilisable pour tout un espace sans contournement, puis les défauts qui en ont un, puis les questions pratiques.
3. Masquez tout secret avant de joindre quoi que ce soit, captures comprises.
4. Si un secret vous a déjà échappé, révoquez et régénérez d’abord la clé. Cela referme l’exposition ; supprimer le message non.
5. Signalez une vulnérabilité présumée avec « security » dans l’objet, sans exploit fonctionnel, et gardez les détails privés jusqu’au correctif.

Comment vérifier le résultat

Rien de ce que vous vous apprêtez à envoyer ne serait dangereux si c’était transféré à la mauvaise adresse, et l’impact est chiffré plutôt que qualifié.

Ce qui coince le plus souvent

• Marquer tout comme urgent, ce qui ne veut alors plus rien dire.
• Un en-tête Authorization visible dans un journal de terminal collé.
• Demander la suppression d’un message au lieu de régénérer la clé exposée.