Comment automatiser le reporting des SLA et de la résolution des tickets pour les clients MSP

Démontrer le respect des SLA (contrats de niveau de service) est essentiel pour les MSP (fournisseurs de services gérés). Il ne s’agit pas d’un simple exercice de reporting : c’est un élément clé pour conserver la confiance des clients et prouver la qualité des performances. De plus, les clients attendent de la transparence, en particulier lorsqu’il s’agit d’obligations contractuelles.

Pour y parvenir, il est judicieux d’automatiser le reporting des SLA et de la résolution des tickets. Le reporting automatisé destiné aux clients supprime les tâches manuelles et instaure un processus cohérent et reproductible. Les MSP peuvent ainsi suivre les tendances de performance, détecter les problèmes au plus tôt et présenter leurs rapports sans la charge de travail habituelle.

Ce guide vous accompagne à travers les outils, scripts et workflows nécessaires pour produire des rapports SLA précis, à grande échelle.

Pour un aperçu visuel rapide, regardez notre guide vidéo Comment automatiser le reporting des SLA et de la résolution des tickets pour les clients MSP.

Automatiser le reporting des SLA et de la résolution des tickets

📌 Prérequis :

• Il vous faut une plateforme PSA active, comme NinjaOne, Autotask ou ConnectWise.
• Les politiques de SLA doivent être attribuées à chaque client afin que les systèmes sachent quels délais s’appliquent.
• Les horodatages et catégories des tickets doivent être correctement enregistrés pour garantir la précision du reporting.
• Des droits d’administrateur sont nécessaires pour PowerShell et les requêtes de données scriptées.
• Vous aurez besoin d’un accès aux journaux d’événements ou aux données système locales pour confirmer la chronologie des incidents.

Définir les métriques SLA et les seuils de résolution

Avant de mettre en place des rapports automatisés qui démontrent aux clients le respect des seuils SLA, vous devez d’abord définir ce que vous mesurez.

📌 Cas d’usage :

• Cela permet d’uniformiser le suivi des SLA pour l’ensemble des clients.
• Cela constitue la référence de configuration pour créer des rapports et tableaux de bord automatisés.
• Cela vous permet de présenter les métriques et objectifs de performance que votre contrat vous impose d’atteindre.

📌 Prérequis :

• Des politiques de SLA attribuées par client via le PSA.
• Un horodatage correct des changements de statut des tickets (créé, pris en compte, résolu).
• Des types ou catégories de tickets définis pour regrouper les données SLA.

Voici les métriques de conformité SLA à inclure dans vos rapports :

• Délai de prise en compte (TTA)
• Délai de résolution (TTR)
• Pourcentage de conformité des délais de réponse SLA
• Taux de résolution par catégorie (matériel, logiciel, réseau)
• Nombre de tickets escaladés par rapport aux tickets résolus
• Nombre de tickets SLA non respectés ou réouverts

Extraire les données SLA et de tickets via PowerShell ou une API

Une fois vos métriques définies, l’étape suivante consiste à extraire les données de tickets depuis votre PSA. La plupart des plateformes prennent en charge les requêtes ou exports API (interface de programmation d’applications), que vous pouvez filtrer et planifier avec PowerShell.

📌 Cas d’usage :

• Cette méthode vous aide à automatiser le suivi des SLA pour plusieurs clients.
• Elle réduit le travail manuel lié aux revues mensuelles de tickets.
• Elle facilite la création de tableaux de bord et de rapports par catégorie de SLA ou par statut de non-respect.

📌 Prérequis :

• Un jeton d’API autorisé à interroger les tickets.
• PowerShell en version 5.1 ou ultérieure.
• Un accès depuis votre RMM ou le Planificateur de tâches pour automatiser l’exécution des scripts.

Voici un exemple de script PowerShell qui récupère les tickets résolus depuis une API PSA et les exporte en CSV :

$headers = @{ "Authorization" = "Bearer $token" }
$response = Invoke-RestMethod -Uri "https://api.ninjaone.com/v2/tickets" -Headers $headers
$response | Where-Object { $_.resolved -eq $true } | Export-Csv "C:\Reports\SLAReport.csv" -NoTypeInformation

Pour filtrer le rapport par client, par plage de dates ou par statut SLA, vous devrez modifier le script. Ajoutez des paramètres de requête à l’URL de l’API ou utilisez des conditions dans PowerShell.

Utiliser le registre pour suivre les événements SLA ou d’agent en local (facultatif)

📌 Cas d’usage :

• Ajoute une piste d’audit locale des réponses scriptées, liées aux identifiants de tickets.
• Vous aide à vérifier le moment où une alerte ou une action corrective a été déclenchée.
• Enrichit les tableaux de bord RMM avec le contexte des tickets par terminal.

📌 Prérequis :

• Cette méthode nécessite des droits d’administrateur pour écrire dans le registre.
• Un RMM ou un script pour mettre à jour les valeurs du registre.
• Un format de nommage standard pour faire correspondre les tickets d’un système à l’autre.

Pour marquer les événements liés aux SLA en local, créez des valeurs de registre personnalisées. Voici comment procéder :

1. Ouvrez l’Éditeur du registre.
2. Accédez à ce chemin : HKEY_LOCAL_MACHINE\SOFTWARE
3. Ensuite, faites un clic droit sur le dossier SOFTWARE, choisissez New > Key et nommez-le Org.
4. Faites un clic droit sur la clé Org et sélectionnez New > Key. Nommez-la : SLAEvents
5. Dans la clé SLAEvents, faites un clic droit dans le volet de droite et choisissez New > String Value.
6. Nommez-la LastAcknowledgedTicket. Double-cliquez dessus et saisissez un identifiant de ticket (par exemple TKT-10129) comme données de la valeur.
7. Créez une autre valeur de chaîne dans SLAEvents. Nommez-la LastActionTime. Double-cliquez dessus et définissez comme données de la valeur l’horodatage de l’événement (par exemple 2025-08-15T14:23Z)

Une fois créées, ces valeurs peuvent être lues ultérieurement par des scripts ou collectées par votre RMM.

💡 Astuce : cette étape est une méthode manuelle de suivi des SLA. Toutefois, le système de gestion des tickets de NinjaOne peut suivre automatiquement la conformité aux SLA.

Exécuter des scripts CMD pour le contexte des terminaux ou la surveillance des services

Vous pouvez utiliser des scripts d’invite de commande pour recueillir des données système de base sur les appareils Windows. Cela vous permet de vérifier ce qui se passait sur un terminal au moment de la création d’un ticket : temps de fonctionnement, services en échec ou événements liés à des problèmes système. Votre processus de reporting sur la résolution des tickets s’en trouve fluidifié.

📌 Cas d’usage :

• Permet de confirmer si un problème était lié à un redémarrage, à un plantage ou à une interruption de service.
• Vous pouvez l’utiliser pour appuyer votre ACR (analyse des causes racines) en corrélant le comportement des terminaux avec les tickets.
• Utile lorsque PowerShell n’est pas disponible.

📌 Prérequis :

• Un accès administrateur pour exécuter l’invite de commande en mode élevé.
• La journalisation et l’historique des événements doivent être activés sur les terminaux.
• Votre processus de reporting doit permettre d’enregistrer ou de téléverser les journaux.

Voici quelques exemples de commandes pour l’invite de commande :

Vérifier le temps de fonctionnement du système

systeminfo | findstr "System Boot Time"

Cette commande renvoie la date du dernier redémarrage du système et vous aide à confirmer si un appareil a été redémarré avant ou après le signalement d’un problème.

Lister les services en échec ou arrêtés

sc query type= service state= all | findstr "STOPPED"

Cette méthode identifie les services qui ne sont pas en cours d’exécution. Vous pouvez ensuite comparer ce résultat au problème signalé pour voir si un service critique était hors service au moment de la création du ticket.

Exporter les entrées récentes du journal système

wevtutil qe System /q:"*[System[(EventID=7034)]]" /f:text /c:20

Cette commande extrait les 20 derniers événements du journal système concernant des services arrêtés de façon inattendue. Elle vous aide à déterminer à quel moment un appareil a rencontré une erreur critique.

💡Remarque : vous pouvez utiliser ces commandes pour examiner le comportement d’un terminal autour du moment où un ticket a été ouvert ou résolu.

Créer des modèles de rapports à remettre aux clients

Après avoir collecté les données de conformité SLA et de tickets, l’étape suivante consiste à exporter les tickets et à les présenter à vos clients de façon facilement compréhensible. Vos rapports doivent résumer les métriques clés et les SLA non respectés, et indiquer les axes d’amélioration.

📌 Cas d’usage :

• Vous aide à remettre aux clients des rapports cohérents et à votre image de marque.
• Simplifie le reporting récurrent et les revues de SLA.
• Vous permet de communiquer les tendances, les progrès et les risques en langage clair.

📌 Prérequis :

• Les données SLA et de tickets collectées.
• Un outil permettant de créer des graphiques ou des tableaux (MS Excel, Google Sheets).
• Une structure de rapport définie et normalisée, réutilisable d’un client à l’autre.

Veillez à intégrer ces éléments essentiels dans votre rapport :

• Résumé exécutif – Doit contenir le pourcentage de conformité SLA ainsi que les statistiques clés.
• Tendances des tickets – Volume de tickets, types et schémas de résolution.
• Analyse des SLA non respectés – Identifiants des tickets et raisons de leur signalement.
• Performance des techniciens (facultatif) – Doit indiquer les délais moyens de réponse et de résolution.
• Recommandations – Lacunes de service, causes racines et axes d’amélioration, notamment au regard de l’analyse des SLA non respectés et de la performance des techniciens.

Voici les formats recommandés :

• Microsoft Excel, exporté via PowerShell. Vous pouvez par exemple utiliser cette commande d’exemple sur des données de tickets filtrées :

$response = Invoke-RestMethod -Uri "https://api.psa.com/v2/tickets" -Headers @{ "Authorization" = "Bearer $token" }
$filtered = $response | Where-Object { $_.resolved -eq $true }
$filtered | Export-Excel -Path "C:\Reports\SLA_Report_July.xlsx" -WorksheetName "ResolvedTickets" -AutoSize

Vous pouvez également opter pour une version PDF, mais vous devrez enregistrer le fichier manuellement au format PDF.

• Power BI (Business Intelligence) pour d’autres tableaux de bord avec des métriques en temps réel.
• Un rapport en HTML avec graphiques et tableaux.
• Un rapport planifié nativement dans le PSA.

Veillez à segmenter ces rapports par client et à les aligner sur leurs seuils et objectifs SLA spécifiques.

Automatiser la génération et l’envoi des rapports

La dernière étape de la mise en place de rapports automatisés pour les clients consiste à les leur transmettre. Pour cela, vous pouvez planifier des scripts qui exportent les rapports et envoient des e-mails.

📌 Cas d’usage :

• Vous aide à transmettre les synthèses SLA et les rapports de résolution des tickets sans effort manuel.
• Garantit un reporting ponctuel et jamais en retard pour tous vos clients.

📌 Prérequis :

• Un script de rapport fonctionnel générant des fichiers CSV, XLSX ou PDF.
• Les identifiants du serveur de messagerie ou de la destination de fichiers de vos clients.
• Une plateforme RMM ou PSA prenant en charge les scripts ou rapports planifiés.

Vous pouvez automatiser l’envoi de vos rapports de plusieurs façons :

• Planifier des scripts qui exportent les données SLA et les envoient par e-mail au client.
• Envoi via API vers SharePoint, S3 ou un dossier FTP sécurisé.
• Utiliser les outils de planification natifs du PSA. Les rapports exportés de NinjaOne en sont un bon exemple.
• Vous pouvez aussi déclencher l’automatisation depuis votre RMM.

Voici un exemple d’envoi d’e-mail en PowerShell :

Send-MailMessage -From "[email protected]" -To "[email protected]" `
-Subject "Monthly SLA Performance - July" `
-Attachments "C:\Reports\SLAReport_July2025.pdf" `
-SmtpServer "smtp.msp.com"

⚠️ Points de vigilance

Autres points à prendre en compte pour automatiser le reporting des SLA et de la résolution des tickets

Associer les SLA à chaque client

Les clients n’ont pas les mêmes exigences en matière de délais de réponse et de résolution. Assurez-vous que chaque ticket est relié à la politique de SLA appropriée dans votre système PSA.

Uniformiser les données de tickets entre les environnements

Utilisez les mêmes catégories de tickets, noms de statuts et workflows pour tous vos clients. Les données seront ainsi plus faciles à filtrer, à représenter graphiquement et à comparer pour suivre la performance SLA dans le temps.

Conserver les données brutes pour les audits

Mieux vaut conserver les journaux de tickets exportés et les horodatages de résolution pendant au moins 12 à 24 mois. Cela vous sera utile lors des revues de contrat, des litiges de facturation et des audits externes.

Séparer les données par client

C’est absolument essentiel dans les environnements multi-tenant. Filtrez et exportez toujours les tickets par identifiant client : vous éviterez les fuites de données et vos rapports resteront clairs et exacts.

Résoudre les problèmes de reporting des SLA et de la résolution des tickets

Horodatages manquants

Assurez-vous que votre système de gestion des tickets enregistre tous les changements de statut requis, à savoir :

• Créé
• Pris en compte
• Escaladé
• Résolu

Sans ces informations, les métriques SLA de votre rapport seront incomplètes.

Mauvaise correspondance des SLA

Vérifiez que vos règles d’automatisation PSA et vos files d’attente de tickets appliquent les bonnes politiques de SLA pour chaque client. Un ticket mal orienté peut affecter les statistiques et fausser vos chiffres.

Échecs des scripts PowerShell

Si vos scripts n’exportent pas ou n’envoient pas les rapports, vérifiez les problèmes d’autorisations d’API, les jetons expirés ou les erreurs dans le script.

Affichage incohérent des fuseaux horaires

Si les horodatages du rapport ne concordent pas avec l’historique des tickets, ramenez tout à l’UTC ou, mieux encore, convertissez les données à l’heure locale du client.

Les services NinjaOne

Avec NinjaOne, les MSP peuvent automatiser le reporting des SLA et fluidifier le suivi de la résolution des tickets pour l’ensemble de leurs clients. Ses fonctions sont présentées dans le tableau ci-dessous :

Automatiser les rapports SLA et de tickets garde les MSP et leurs clients informés

Automatiser le reporting des SLA et de la résolution des tickets aide les MSP à rester responsables, transparents et efficaces. Cela réduit le temps consacré aux exports manuels, améliore la précision du reporting et garantit que les engagements de service sont tenus et visibles.

Nous avons vu comment définir les bonnes métriques SLA, extraire les données de tickets avec PowerShell ou une API, valider les événements de résolution à l’aide du registre et des outils CMD, et mettre en forme les rapports destinés aux clients. Avec ces méthodes en place, les MSP peuvent proposer un reporting SLA fiable et aligné sur leurs politiques, à grande échelle.

Sujets connexes :

• Les automatisations de gestion des tickets NinjaOne indispensables pour bien démarrer
• Qu’est-ce qu’un contrat de niveau de service (SLA) MSP ?
• 6 conseils de reporting pour le service d’assistance dans la gestion informatique moderne
• Au-delà du dépannage : les bonnes pratiques des rapports informatiques