
Gestion d'incidents IT — Autotask, Webroot & Datto RMM
Triage d'incidents en production chez MIDRANGE GROUP : ticketing Autotask, accès distant Datto RMM et résolution d'un faux positif Webroot.
Contexte
Chez MIDRANGE GROUP, au sein de l'équipe Support Technique aux côtés de Théo KACEL (Administrateur Systèmes & Réseaux), je traitais les demandes de support des clients gérés, réceptionnées via trois canaux : appels téléphoniques directs vers la ligne support, e-mails à l'adresse support, et alertes automatiques levées par l'agent Datto RMM installé sur les postes clients.
Une fois un ticket ouvert dans Autotask, il est routé soit vers l'équipe Support Technique (incidents utilisateurs), soit vers l'équipe Exploitation (infrastructure et supervision). Voici le traitement d'un ticket client en production, de la prise en charge à la résolution.
Les trois canaux d'ouverture de tickets
- Téléphone : le client appelle directement la ligne support. Le technicien crée le ticket manuellement dans Autotask et commence le triage immédiatement.
- E-mail : le client envoie un message à l'adresse support. Autotask l'ingère automatiquement et crée le ticket, qui est ensuite assigné à la file appropriée.
- Agent Datto RMM : l'agent installé sur les postes gérés supervise l'appareil en temps réel et peut lever des alertes automatiquement (pic CPU, disque plein, événement de sécurité). Ces alertes génèrent des tickets dans Autotask sans aucune action du client.
Résolution de l'incident — étape par étape
- 1Étape 1 — Ticket reçu dans AutotaskUn client signalait ne pas pouvoir accéder à un site internet spécifique. Webroot affichait un message « site bloqué » sur son poste. Le ticket m'a été assigné, avec Théo en soutien pour la résolution.
- 2Étape 2 — Prise en main à distance via Datto RMMNous avons contacté le client et demandé son autorisation pour prendre le contrôle à distance de son poste via Datto RMM. Cela nous a permis de reproduire le problème en temps réel, de voir exactement le message d'avertissement Webroot, et de confirmer quelle URL était bloquée.
- 3Étape 3 — Diagnostic : faux positif WebrootAprès examen de l'URL bloquée, nous avons déterminé qu'il s'agissait d'un site professionnel légitime, incorrectement signalé par l'intelligence de menaces de Webroot. Le site n'était pas malveillant — Webroot l'avait classé comme suspect sur la base de son score de réputation de domaine.
- 4Étape 4 — Exclusion d'URL dans la console de gestion WebrootNous nous sommes connectés à la console de gestion Webroot (CE 23.2) et avons navigué vers la liste de suppression d'URL dans la politique du client. Nous avons ajouté le domaine bloqué à la liste de suppression (liste blanche). Le changement s'est propagé sur le poste du client en quelques minutes, et le site est devenu accessible sans aucune intervention supplémentaire sur la machine.
- 5Étape 5 — Résolution consignée dans AutotaskUne saisie de temps a été créée dans Autotask avec un résumé du problème, la cause racine (faux positif) et les étapes de résolution effectuées. Le ticket a été clôturé comme « Terminé ». Le temps de travail a été enregistré pour la facturation client et intégré à la traçabilité des interventions.
Impact
Incident résolu en une seule session, entièrement à distance, sans déplacement ni réinstallation logicielle sur le poste du client.
Chiffres clés
Bonnes pratiques
- Les faux positifs Webroot sur des sites professionnels légitimes sont un scénario de support récurrent : le premier réflexe doit toujours être de vérifier la liste de suppression d'URL avant d'escalader ou de reconfigurer le poste.
- L'accès distant Datto RMM élimine le besoin de déplacements sur site pour la majorité des incidents utilisateurs, réduisant significativement le temps de résolution.
- Les saisies de temps Autotask ne sont pas optionnelles : elles servent à la fois de pièce de facturation pour le client et de base de connaissances consultable pour les incidents récurrents.
- Le routage des tickets est essentiel : distinguer dès le premier signalement un ticket Support Technique (utilisateur) d'un ticket Exploitation (infrastructure) évite les mauvaises attributions et les pertes de temps.
- Toujours reproduire le problème à distance avant de modifier une configuration — confirmer le symptôme exact prévient les changements prématurés ou incorrects.
Outils utilisés
Captures d'écran
