Tester l’automatisation en sécurité sur d’anciens tickets

Un test sur d’anciens tickets doit répondre à une question précise : cette automatisation aurait-elle produit une suggestion utile et sûre sans modifier de dossier ni contacter un client ? Ce guide présente un rejeu contrôlé, les points de défaillance à surveiller et une revue sur deux semaines avant d’envisager un pilote réel.

1. Les étapes du travail, de bout en bout

Tester une automatisation sur des tickets historiques consiste à rejouer des demandes passées autorisées dans un flux candidat, puis à comparer ses suggestions aux résultats définis par les personnes qui connaissent le service. C’est une évaluation, pas une autorisation de modifier d’anciens tickets ou d’agir sur le travail client en cours.

1. Définissez une seule question, par exemple : le système peut-il suggérer la bonne file ? Fixez le résultat attendu avant le test.
2. Vérifiez que le responsable des tickets autorise l’évaluation. Examinez les conditions client, les règles de confidentialité et de sécurité, les exigences de conservation et l’environnement de test approuvé.
3. Supprimez les identifiants et les données personnelles ou client inutiles. Limitez les accès, consignez la provenance de l’échantillon et fixez une date de suppression. N’utilisez pas les dossiers sans autorisation de traitement sécurisé.
4. Demandez à des personnes qualifiées d’annoter les résultats attendus selon les règles documentées du service. Résolvez les désaccords avant d’utiliser ces annotations pour la comparaison.
5. Rejouez les dossiers préparés dans un environnement isolé ou en lecture seule. Les suggestions ne doivent ni modifier les tickets, ni contacter les clients, ni accorder des accès, ni exécuter des changements.
6. Comparez les suggestions aux résultats de référence. Consignez les cas risqués ou incertains, puis décidez d’arrêter, de réviser ou de mener une autre évaluation autorisée.

Il s’agit d’une méthode d’évaluation proposée, et non d’une norme sectorielle obligatoire. Adaptez les contrôles au service, à l’accord client et aux données concernées.

Pour comprendre le processus de travail associé à ces dossiers, consultez notre guide sur la gestion des tickets par les entreprises de services informatiques. Pour découvrir d’autres priorités d’automatisation, consultez quoi automatiser en premier.

2. Les points de rupture dans une entreprise de conception informatique et de services IT

Imaginez une entreprise de conception de systèmes qui rejoue d’anciens tickets de support pour tester une suggestion automatique de file. Les dossiers mélangent plusieurs clients, leurs catégories sont incohérentes et ils contiennent quelques signalements inhabituels d’accès ou de sécurité. Le test semble retrouver l’ancienne file dans la plupart des cas, mais les personnes qui l’examinent constatent que l’affectation historique était parfois erronée. Une forte concordance globale peut donc masquer les cas qu’il est le plus important de détecter.

• Les anciennes décisions d’affectation ou de clôture sont considérées comme justes sans vérification.
• L’échantillon omet les demandes ambiguës, inhabituelles ou propres à un client.
• Les dossiers copiés exposent des identifiants, des données personnelles ou des informations appartenant à un autre client.
• Le test est relié aux outils en production et peut modifier des tickets ou envoyer des notifications.
• Les évaluateurs comptent les correspondances faciles, mais négligent les escalades manquées, les suggestions risquées et les cas où le système devrait s’abstenir.
• Aucun responsable désigné ne peut autoriser les données, trancher les désaccords d’annotation ou arrêter l’évaluation.

Gardez visibles les cas limites et les désaccords examinés par une personne. Ne vous fiez à l’évaluation que si le traitement des données et les résultats de référence conviennent à la décision envisagée.

3. Quoi automatiser en premier, et quoi ne jamais automatiser

Pour une première évaluation, privilégiez les suggestions faciles à examiner et à corriger. Gardez le système en mode consultatif afin qu’une personne compare ses résultats avant toute action opérationnelle.

• Les premiers candidats adaptés sont les suggestions de catégorie ou de file, les demandes de champs manquants, les alertes de doublon potentiel et les résumés à faire vérifier par un responsable.
• Gardez sous contrôle humain l’escalade de sécurité, l’évaluation de la gravité et de l’impact client, les changements d’accès, les actions en production, les suppressions, les messages aux clients et la clôture des tickets.
• Ne reliez pas le rejeu à des actions : il ne doit ni écrire dans les systèmes sources ni déclencher de communications réelles.

4. Comment tester en sécurité sur des données passées pendant deux semaines

Utilisez ces deux semaines comme une période d’examen délimitée, et non comme preuve que l’automatisation est prête pour la production. Le calendrier ci-dessous est une proposition pratique d’APLS, pas un référentiel externe.

1. Première semaine , cadrer et préparer : désignez le responsable du processus, choisissez une tâche, autorisez l’usage des données, réduisez les informations sensibles, isolez le test et convenez de la revue des annotations de référence.
2. Deuxième semaine , rejouer et examiner : figez l’échantillon, produisez des suggestions sans effet secondaire, examinez les erreurs et cas limites sensibles, puis discutez des désaccords avec le responsable du service.
3. À la fin , consignez une décision : comparez les résultats aux critères d’acceptation et d’arrêt définis à l’avance. Notez les limites et arrêtez ou révisez le test si les données, contrôles ou résultats ne sont pas fiables.
4. Avant tout pilote en production , obtenez une autorisation distincte et définissez les limites d’accès, la responsabilité humaine, la surveillance, le retour arrière et la gestion des incidents. Un test historique n’autorise pas à lui seul des actions en production.

Pour un éclairage facultatif sur la gestion des risques, consultez le Cadre de gestion des risques liés à l’IA et son guide pratique. Tous deux proposent des recommandations volontaires, pas une certification ni un test de réussite ou d’échec pour ce flux de travail.

5. Liste de contrôle à copier

• Un cas d’usage précis et un responsable désigné sont convenus.
• Les autorisations relatives aux données et au client sont confirmées ; les informations sensibles sont réduites et les accès limités.
• Les résultats de référence suivent des règles documentées ; les annotations contestées sont examinées.
• Le test est isolé ou en lecture seule, sans écriture, notification, changement d’accès ni action en production.
• Les évaluateurs examinent les suggestions erronées, les escalades manquées, les cas incertains et le traitement des données sensibles.
• Les critères d’acceptation et d’arrêt sont consignés avant l’examen des résultats.
• Les limites, décisions et responsables sont documentés ; un pilote en production exige une autorisation distincte.

En bref : les anciens tickets peuvent aider à évaluer une proposition d’automatisation ciblée si l’usage des données est autorisé, les comparaisons pertinentes et le système incapable de produire des effets secondaires. Gardez un test réversible, vérifiable et sous la responsabilité d’une personne.