Rédiger un ticket de support efficace

Un ticket bien rédigé fournit à l’équipe les détails nécessaires pour enquêter sans devoir deviner. Il ne garantit ni délai de réponse ni résultat, mais clarifie l’étape suivante. Ce guide explique quoi inclure et propose des modèles pour les catégories courantes.

Pour savoir comment déposer un ticket, notamment où cliquer et quels champs remplir, consultez Utiliser le centre de support. Cet article porte sur le contenu.

Structure essentielle d’un bon ticket

Tout ticket utile répond à quatre questions :

1. Ce que je tentais de faire : indiquez votre objectif, pas seulement le problème.
2. Ce qui s’est réellement passé : fournissez l’erreur, l’état ou le comportement exact.
3. Ce que j’ai déjà essayé : cela évite de répéter une vérification élémentaire.
4. Informations d’identification : domaine, boîte mail, numéro de facture ou horodatages permettant d’identifier le cas.

Plus vous fournissez de contexte, plus il est facile de vérifier la bonne partie du produit. N’incluez jamais de mot de passe, de code 2FA ni de jeton d’API.

Informations à fournir selon la catégorie

Tickets de facturation

• Numéro de facture ou référence de paiement affiché dans Billing ou sur le reçu.
• Montant attendu et montant facturé s’ils diffèrent.
• Précisez s’il s’agit d’un renouvellement, d’une activation d’option, d’une demande de remboursement, etc.
• 4 derniers chiffres de la carte pour un problème lié à une carte, mais jamais le PAN complet ni le CVV.
• Devise et montant contesté.

Exemple :

J’ai été débité de $52 hier, alors que j’attendais $39. Le numéro de facture figurant sur ma page Billing est indiqué ci-dessous. 4 derniers chiffres : 4242. Merci d’indiquer si la différence correspond à un autre élément ou à une taxe. J’ai joint une capture du tableau de bord affichant le débit.

Tickets techniques ou d’envoi

• Adresse de la boîte mail expéditrice.
• Adresse du destinataire ou modèle, par exemple « tous les destinataires @gmail.com ».
• Message d’erreur exact, avec le texte complet et les codes comme 550 ou 421.
• Date de début : date, heure et fuseau horaire si possible.
• Possibilité d’envoyer vers d’autres adresses depuis la même boîte : cela indique si le problème concerne un destinataire ou fournisseur précis.
• Possibilité d’envoyer le même e-mail depuis le webmail : cela distingue un problème de configuration de l’application d’un problème de compte ou de livraison.

Exemple :

Depuis ce matin, la boîte alice@mycompany.com ne peut envoyer vers aucune adresse gmail.com. Les autres destinataires (yahoo.com, outlook.com) fonctionnent. Le message de rejet est "550 5.7.1 [2026-05-15.05] Our system has detected an unusual rate of sending. Please try again later." Le webmail affiche la même erreur. Le problème a commencé vers 09:00 UTC le 2026-05-15. Les autres boîtes du domaine ne peuvent pas non plus joindre gmail.com.

Tickets DNS

• Nom de domaine.
• État affiché par TrekMail et enregistrement exact non vérifié.
• Résultat d’une recherche DNS, si disponible, par exemple la sortie de dig pour un enregistrement MX ou TXT SPF.
• Votre fournisseur DNS (Cloudflare, GoDaddy, etc.).
• Enregistrement précis qui ne se vérifie pas.
• Indiquez toute modification DNS récente et son heure approximative.

Exemple :

Domaine : mycompany.com. L’enregistrement DKIM reste rouge sur la page Domains. Je l’ai ajouté hier dans Cloudflare et réglé sur DNS uniquement, sans proxy. dig +short TXT dkim._domainkey.mycompany.com renvoie la valeur attendue v=DKIM1; k=rsa; p=.... TrekMail le signale toujours comme absent. J’ai aussi vérifié la propagation avec un autre service DNS.

Tickets de délivrabilité ou spam

• Domaine et boîte mail d’envoi.
• Taux de rebond dans le panneau Domain Email Stats.
• Exemples de destinataires concernés par un rebond ou un classement en spam, sans fournir toute la liste.
• Origine de la liste : formulaire d’inscription, ancien fournisseur ou autre source.
• Habitudes d’envoi récentes : changement de volume ou d’audience.

Exemple :

Le taux de rebond de mycompany.com est passé de 0.5% à 8% au cours des sept derniers jours. J’ai joint une capture Email Stats. J’envoie une newsletter avec consentement à environ 2,000 abonnés. Les rebonds incluent "user unknown" et "mailbox over quota". J’ai supprimé environ 200 abonnés inactifs il y a deux semaines, seul changement récent. Dois-je vérifier le reste de la liste avant un nouvel envoi ?

Tickets d’API

• Nom du jeton d’API, sans coller le jeton lui-même.
• Endpoint appelé.
• Corps de la requête, avec les données sensibles masquées.
• Réponse, avec code d’état et corps.
• Comportement attendu et comportement observé.

Exemple :

J’appelle POST /api/v1/verify/bulk avec un tableau emails masqué et mode: quick. Je reçois HTTP 422 ; le corps de la réponse est joint ci-dessous sans les adresses e-mail. Je m’attendais à la création d’une tâche de vérification. Nom du jeton : "production-verify-token". Cela a commencé vers 13:00 UTC aujourd’hui, et la même requête fonctionnait hier.

Tickets de compte ou connexion

• Adresse e-mail du compte, utilisée pour vous connecter.
• Problème constaté, comme l’impossibilité de se connecter, l’absence de l’e-mail de réinitialisation ou un échec de 2FA.
• Navigateur et système d’exploitation.
• Indiquez si vous utilisez un fournisseur de connexion sociale (Google, Microsoft ou service similaire).
• Date approximative de la dernière connexion réussie.

Pour une récupération 2FA, décrivez le problème d’accès et fournissez uniquement les informations demandées par la procédure officielle. N’envoyez jamais votre mot de passe actuel, un code 2FA, un code de récupération ou une pièce d’identité dans un ticket ordinaire, sauf demande explicite d’une procédure TrekMail vérifiée.

Informations à NE PAS inclure

Ne partagez pas :

• Mots de passe en clair. Jamais, qu’il s’agisse du tableau de bord, des boîtes mail ou de services tiers.
• Numéros de carte complets, CVV ou coordonnées bancaires complètes. Les 4 derniers chiffres suffisent pour l’identification.
• Jetons d’API en clair ; leur nom permet de les identifier.
• Adresses ou données d’autres clients dans les pièces jointes. Anonymisez-les ou masquez-les.
• Données personnelles sensibles des destinataires, sauf nécessité absolue pour l’enquête.

Si vous partagez un secret par erreur, révoquez-le ou remplacez-le si possible, puis informez rapidement le support afin d’obtenir la marche à suivre.

Conseils pour les pièces jointes

• Captures d’écran : images uniquement (JPEG, PNG, GIF, WebP), 5 MB maximum. Montrez la page et l’erreur utiles, mais recadrez ou masquez les URL contenant un jeton, une adresse de boîte mail ou d’autres informations privées.
• Résultat d’une requête DNS : collez-le comme texte, formaté avec des accents graves, pas comme capture.
• Journaux d’erreurs : collez les lignes pertinentes, pas le journal entier.
• Texte de rebond : incluez le rapport complet, surtout la ligne Diagnostic-Code:.
• Captures du navigateur : évitez d’afficher d’autres onglets, notifications, mots de passe enregistrés ou données client sans rapport.

La suppression des images jointes au ticket est programmée 30 jours après sa clôture. Conservez localement tout élément important.

Un problème par ticket

Pour deux problèmes distincts, déposez deux tickets. Chaque échange reste ainsi ciblé et son historique est plus facile à suivre.

Si les problèmes sont liés, par exemple « échec de facturation ET arrêt des envois », un seul ticket convient si le lien est clairement expliqué.

Mettre à jour un ticket

Si le problème se résout avant la réponse du support, par exemple après la propagation DNS ou le rétablissement d’un service tiers, ajoutez une brève mise à jour telle que "Resolved: DNS finished propagating. Please close this ticket." Vous pouvez aussi fermer vous-même un ticket actif depuis sa page.

Si une solution provisoire convient sans être la solution souhaitée, précisez-le : "I worked around it by doing X, but I would still like to understand why the original way did not work."

Modèles à copier

Pour un ticket générique « quelque chose ne fonctionne pas » :

Subject: <one-line summary of the issue>

What I was trying to do:
  <your goal>

What happened:
  <exact error or behaviour, including error messages>

Started:
  <timestamp or "always", "since yesterday", etc.>

What I tried:
  - <attempt 1>
  - <attempt 2>

Identifying info:
  - Domain: <domain.com>
  - Mailbox: <user@domain.com>
  - <Invoice number if billing, API token name if API, and similar identifiers>

Pour une demande de fonctionnalité :

Subject: Feature request: <one-line description>

What I'd like to do:
  <user story: "as a <type of user>, I'd like to <action> so that <benefit>">

Current workaround:
  <if any>

Why this would help:
  <use case, frequency, scale>

Similar in other tools:
  <if any reference example>

Pour contester une facturation :

Subject: Billing dispute: <one-line summary>

Invoice number or payment reference: <from Billing or the payment receipt>
Charge amount: $X.XX
Expected amount: $Y.YY
Account email: alice@mycompany.com

What I was expecting:
  <explanation of what your subscription should have charged>

What was actually charged:
  <explanation of the actual invoice / charge>

Resolution requested:
  <refund / credit / explanation / something else>

Articles associés

• Utiliser le centre de support et les tickets
• Erreurs d’envoi courantes et solutions
• Problèmes de paiement (carte ou cryptomonnaie)
• Résoudre les échecs de paiement
• Taux de rebond trop élevé
• E-mails classés comme spam
• Impossible de connecter le client de messagerie