
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 l'administrateur systèmes & réseaux de l'équipe, 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.
Défis techniques
- Les tickets arrivent par trois canaux différents (téléphone, e-mail, alertes Datto RMM) avec trois niveaux de détail différents ; le premier travail sur chaque ticket est donc de combler les manques avant tout diagnostic réel.
- Un ticket doit être routé correctement dès la première lecture — les incidents utilisateurs vers le Support Technique, les incidents infrastructure vers l'Exploitation — et un mauvais routage coûte du temps des deux côtés.
- Reproduire le symptôme exact à distance, avant de toucher à une configuration, est le seul moyen d'éviter de modifier le mauvais réglage sur un poste client en production.
- Un outil de sécurité qui signale un site légitime comme malveillant (faux positif Webroot) ressemble en tout point à un blocage réel côté utilisateur — les distinguer nécessite de vérifier la réputation réelle du domaine, pas seulement de faire confiance à l'alerte.
- Chaque correction doit être documentée dans Autotask de façon suffisamment claire pour servir à la fois de pièce de facturation et de référence de dépannage future — une note de ticket vague crée du travail pour le prochain technicien.
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.
Limites connues & décisions
- Ce cas couvre un ticket représentatif de bout en bout plutôt que le volume complet des tickets traités — le déroulé décrit (prise en charge → accès distant → diagnostic → correction → documentation) est celui appliqué à chaque ticket, à des degrés de profondeur variables selon la complexité.
- L'exclusion d'URL dans la console Webroot corrige le symptôme immédiat pour le domaine signalé ; elle ne réentraîne pas le score de réputation sous-jacent de Webroot, donc un faux positif similaire peut réapparaître sur une autre URL — c'est une limite côté éditeur, pas quelque chose de corrigeable depuis la console.
- La résolution à distance via Datto RMM suppose que le poste client est joignable et que l'utilisateur est disponible pour autoriser l'accès ; un ticket où l'une de ces conditions ne serait pas remplie nécessiterait un déplacement sur site, ce qui sort du périmètre du workflow Support Technique décrit ici.
- Le routage entre Support Technique et Exploitation reposait sur la description à la prise en charge, ce qui reste une appréciation ; un ticket qui paraît utilisateur au premier abord (comme celui-ci) peut malgré tout avoir une cause racine infrastructure, et inversement.
Outils utilisés
Captures d'écran
