Ne pas exposer les secrets au support
Une URI peut contenir des noms d’utilisateur, mots de passe, informations d’hôte et noms de base. Traitez sa valeur complète comme un identifiant : ne la collez pas dans un ticket public, une capture, un chat ou un journal non filtré. Si le support doit reconnaître la cible, fournissez une version masquée qui garde le type de base et le contexte non sensible.
Les erreurs peuvent révéler des requêtes, noms de tables ou données client. Relisez-les et remplacez les valeurs privées par des exemples de même structure. Évitez de joindre un fichier d’environnement complet lorsqu’un bref extrait expurgé suffit.
Fournir les détails utiles au diagnostic
Notez l’action en échec, s’il s’agit de la configuration ou d’une requête ultérieure, l’heure approximative et la fréquence du problème. Indiquez le type de base et, si possible, un identifiant non secret de connexion. Ces détails aident à distinguer authentification, autorisations, nommage et réseau.
Signalez les changements récents, comme la rotation d’un secret ou le renommage d’une base, ainsi que les vérifications déjà effectuées. N’envoyez jamais un mot de passe pour prouver son fonctionnement. Si un secret a pu être exposé, remplacez-le selon la procédure habituelle et actualisez la connexion avant de réessayer.