Un bon ticket, c'est un ticket qui se résout sans aller-retour. Pour nous aider à vous aider, suivez cette structure. Ça paraît évident — en pratique, 60 % des tickets qui traînent, traînent parce que l'info manque.
Où ouvrir un ticket
Toutes les demandes de support passent par notre ServiceDesk :
https://servicedesk.datacampus.fr
Les demandes envoyées par email direct ou via LinkedIn ne sont pas tracées et passent souvent à la trappe. Le ServiceDesk garantit que votre demande est affectée au bon technicien et que l'historique est conservé.
Ce qu'un bon ticket contient
1. L'URL ou le service exact
Pas « mon site » ni « le serveur mail ». L'URL complète : https://monclient.fr/espace-pro/facture/42. Si le problème est sur plusieurs URLs, citez-en deux ou trois représentatives.
2. L'heure précise
Heure et minute (fuseau Europe/Paris). Un « ça bug depuis ce matin » oblige le support à parcourir 8 heures de logs. Un « erreur 500 à 14 h 23 » se localise en 30 secondes.
3. Le message d'erreur complet
Le texte brut, pas une reformulation. Copier-coller du message + capture d'écran si c'est du front. Pour une erreur PHP ou serveur, les logs sont précieux : voir les ~/logs/error_log côté Plesk.
4. Ce qui a déjà été tenté
« J'ai vidé le cache, essayé en navigation privée, sur un autre navigateur, testé avec un autre compte. » Ça évite qu'on vous demande de faire ce que vous avez déjà fait.
5. La reproductibilité
- Systématique : chaque fois que je fais X, ça plante.
- Intermittent : ça plante 1 fois sur 5 environ.
- Ponctuel : c'est arrivé une seule fois.
Indiquer les étapes pour reproduire quand c'est possible (« 1. se connecter avec X, 2. cliquer sur Y, 3. bug »).
Modèle de ticket prêt à l'emploi
URL concernée : https://monclient.fr/checkout
Heure du problème : 2026-04-22 14:23 CEST
Navigateur / OS : Firefox 124 sur macOS 14
Message d'erreur :
"Erreur 500 - Internal Server Error"
(copie d'écran jointe + extrait error_log ci-dessous)
Extrait logs :
[22/Apr/2026:14:23:17] PHP Fatal error: Allowed memory size of
134217728 bytes exhausted in /httpdocs/wp-includes/class.php:812
Reproductibilité : systématique dès qu'on ajoute > 3 produits au panier.
Déjà tenté : vidage cache (WP Rocket + navigateur), désactivation
du plugin WooCommerce Subscriptions (même erreur), test sur staging
(même comportement).
Impact : checkout HS en production, perte de chiffre d'affaires.Ce qui ralentit un ticket
- « Ça marche pas » — on ne sait ni quoi, ni où, ni quand.
- « C'est urgent » sans détail — tout le monde est urgent, ça ne nous aide pas à prioriser.
- « Comme la semaine dernière » — les tickets se résolvent sur leurs propres éléments, pas sur le souvenir.
- Plusieurs sujets dans un seul ticket — un sujet = un ticket. Sinon, on perd en lisibilité et en suivi.
- Captures d'écran floues ou sans contexte — l'URL doit être visible, l'erreur lisible.
Niveaux de priorité
Trois niveaux, à choisir dans le formulaire. À utiliser avec mesure — l'abus de priorité haute dilue le signal.
| Priorité | Pour quoi | Exemples |
|---|---|---|
| Normale | Demande courante, pas bloquante | Ajout d'un domaine, question de configuration, demande d'évolution. |
| Urgente | Impact fort sur un service, contournement possible | Bug sur un formulaire de contact, lenteur marquée, erreur PHP sur une section du site. |
| Critique | Production à l'arrêt, pertes financières, données en jeu | Site totalement inaccessible, boutique HS, fuite ou compromission suspectée, perte de données. |
Temps de réponse
Les délais d'intervention dépendent de votre SLA contractuel. Par défaut :
- SLA N0 Standard — prise en charge en heures ouvrées (lun-ven, 9 h-18 h).
- SLA N1 Heures ouvrées — engagement de temps de réponse en heures ouvrées.
- SLA N2 24/7 — astreinte 24 h/24, 7 j/7, y compris week-ends et jours fériés.
Les incidents critiques passent devant la file, quel que soit le SLA. Pour un incident critique en dehors de nos heures ouvrées, si vous n'êtes pas en SLA 24/7, appelez le +33 5 16 64 00 75 : une procédure d'urgence est en place.