1. Décrire l’action qui prend du temps
Indiquez ce que vous étiez en train de faire : démarrer le poste, ouvrir une session, lancer une application, enregistrer un fichier ou envoyer un document. Notez l’heure, la fréquence et le message affiché s’il y en a un. Une capture d’écran peut être utile, après avoir masqué les informations confidentielles.
Décrivez aussi le résultat : l’action finit-elle par aboutir, reste-t-elle bloquée ou faut-il recommencer ? Un temps approximatif et un exemple reproductible sont plus exploitables qu’une impression générale. Si l’incident apparaît depuis un changement connu, signalez-le sans conclure que ce changement en est nécessairement la cause.
2. Préciser les personnes et les équipements touchés
Le problème concerne-t-il un seul ordinateur, plusieurs personnes ou tout un service ? Se produit-il sur place et à distance ? Une autre application fonctionne-t-elle normalement ? Ces comparaisons donnent un périmètre au diagnostic, sans demander à l’utilisateur de modifier des paramètres techniques.
Sur une session distante, distinguez le comportement du poste local et celui de l’environnement du serveur. Pour une messagerie, indiquez si le webmail présente le même symptôme que l’application ou le téléphone. Pour un fichier partagé, précisez si d’autres documents ou d’autres utilisateurs sont également concernés.
3. Identifier l’endroit où se trouvent les ressources
Un document peut être local, sur un serveur ou dans un espace en ligne. L’application peut s’exécuter sur l’ordinateur ou dans une session à distance. Cette information aide à identifier les vérifications nécessaires et les intervenants concernés.
Une difficulté réseau peut influer sur un service distant, mais toutes les lenteurs ne proviennent pas du Wi-Fi. Le stockage, la charge d’une application, les droits ou le fonctionnement d’un service peuvent demander un examen séparé. Le rôle du diagnostic est de rapprocher les observations et les traces pour situer le problème.
4. Éviter de changer plusieurs choses en même temps
Avant une intervention, conservez les éléments utiles et transmettez-les à l’équipe qui suit votre parc. Des modifications successives et non documentées rendent la comparaison plus difficile. Un redémarrage peut parfois faire disparaître temporairement un symptôme ; son heure et son effet restent alors des informations à signaler.
L’intervenant peut définir un test, effectuer une action ciblée puis observer le résultat. Le compte rendu distingue la correction appliquée du contrôle obtenu. Un test réussi sur un document constitue une étape ; le retour de l’utilisateur permet de vérifier le comportement dans son travail réel.
5. Choisir la suite à partir du diagnostic
Selon les résultats, la réponse peut relever d’un réglage de poste, d’une évolution matérielle, du système serveur, de l’application ou de l’installation réseau. La décision de remplacer un ordinateur ou d’ajouter des ressources gagne à reposer sur cette analyse plutôt que sur le seul âge du matériel.
Agedis coordonne les vérifications du poste et des systèmes. Alltech peut compléter un besoin de liaison ou de couverture sur site. L’éditeur intervient sur son application ; Dtouch peut étudier une adaptation logicielle spécifique. Pour un environnement hébergé, le volet datacenter est examiné avec Cloudlab lorsque les observations le justifient.
À préparer pour votre prochain échange
- Action précise et heure de l’incident
- Message, capture expurgée et résultat observé
- Utilisateurs et appareils concernés
- Situation locale, réseau ou session distante
- Changement récent et tests déjà effectués