FIELD PRACTICE

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

Lors d'un stage chez MIDRANGE GROUP (équipe Support Technique), j'ai été placée sous la tutelle de Théo KACEL, Administrateur Systèmes et Réseaux. L'équipe traite les demandes de support des clients gérés via trois canaux d'entrée : 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). Théo m'a confié un ticket client en production à traiter sous sa supervision.

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 Autotask
Un client signalait ne pas pouvoir accéder à un site internet spécifique. Webroot affichait un message « site bloqué » sur son poste. Le ticket a été assigné à Théo et délégué pour une résolution en conditions réelles.
2
Étape 2 — Prise en main à distance via Datto RMM
Nous 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 Webroot
Aprè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 Webroot

Chiffres clés

Canaux d'entrée de tickets

Téléphone · E-mail · Agent Datto RMM

Aucune

Intervention sur site

Résolution 100% à distance via Datto RMM

Non

Réinstallation Webroot

Exclusion d'URL depuis la console — poste non modifié

Oui

Résolution documentée

Saisie Autotask avec cause racine et étapes

Apprentissages clés

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