Poser les bonnes questions comme un analyste d’assistance technique

Au service d’assistance à la clientèle d’Esri Canada, nous résolvons les problèmes en posant des questions. Dans ce billet, nous vous présentons les types de questions que nous utilisons pour comprendre un problème, en déterminer les causes possibles et orienter nos enquêtes. Utilisez ces techniques pour résoudre vos propres difficultés et, qui sait, vous deviendrez peut-être la personne vers qui vos collègues se tournent lorsqu’ils ont besoin d’aide.

Avez-vous déjà eu l’impression que votre demande d’assistance technique s’était transformée en un interminable jeu-questionnaire? Si votre réponse est « oui », sachez que chaque question a son utilité. Nos analystes d’assistance à la clientèle apprennent à aborder les problèmes de façon méthodique en recueillant des indices sur les logiciels, les données, l’environnement, les flux de travaux et les utilisateurs en cause. Plus le portrait est complet, plus il devient facile de remonter rapidement à la cause profonde du problème.

Dans ce billet, nous partageons les types de questions que nous posons pour aider nos clients à résoudre leurs demandes d’assistance. Vous pouvez appliquer cette même approche à vos propres enjeux ou encore devenir la vedette du dépannage dans votre organisation en aidant vos collègues à résoudre les leurs.

Si vous cherchez des conseils pour accélérer la résolution de vos demandes d’assistance, nous vous recommandons également de lire le bulletin technique Huit conseils pour résoudre rapidement votre demande d’assistance technique.

Le problème avec « Ça ne fonctionne pas »

Nous avons tous déjà entendu quelqu’un dire quelque chose comme :

• « Je n’arrive pas à faire fonctionner ça »

• « La publication ne fonctionne pas »

• « L’application est lente »

• « J’ai obtenu un message d’erreur »

• « Tout a planté »

Aussi courantes soient-elles, ces affirmations désespérément vagues laissent généralement plus de questions que de réponses. Comme ce genre de commentaires manque cruellement de contexte et de précision, il faut amorcer un véritable travail d’enquête pour en tirer quelque chose d’utile.

1. Commencez par le logiciel

Avant d’examiner un problème en détail, il est important de comprendre les logiciels qui sont en cause.

Voici quelques questions utiles :

• Quel est le produit utilisé?

• Quelle est la version installée?

• Des extensions, modules complémentaires ou outils personnalisés sont-ils utilisés?

• Quel message d’erreur est affiché?

• Les fichiers journaux ont-ils été examinés?

Ces questions permettent d’établir les bases techniques nécessaires à l’enquête. Par exemple, il est possible qu’un problème connu dans une version ait été corrigé dans une autre. De même, des personnalisations introduisent parfois des variables qui ne sont pas immédiatement visibles.

2. Comprenez les données

Les données sont souvent un facteur déterminant, particulièrement lorsqu’un flux de travaux fonctionne avec un ensemble de données, mais échoue avec un autre.

Pensez à poser les questions suivantes :

• D’où proviennent les données?

• Le problème peut-il être reproduit à l’aide de données d’exemple?

• Les noms de champs ou les valeurs contiennent-ils des caractères spéciaux?

• Quel est le degré de complexité de l’ensemble de données?

• Ces données proviennent-elles d’un autre flux de travaux?

Ces questions aident à déterminer si le problème provient réellement du logiciel ou plutôt des données traitées.

3. Examinez l’environnement

Les technologies ne fonctionnent presque jamais de façon isolée.

• Un flux de travaux SIG dépend notamment :

• du système d’exploitation;

• des serveurs;

• des bases de données;

• des ressources infonuagiques;

• des pare-feu;

• des logiciels de sécurité;

• des ressources matérielles disponibles.

Voici quelques questions pertinentes :

Quel est le système d’exploitation utilisé?

• La mémoire et l’espace disque disponibles sont-ils suffisants?

• Le logiciel est-il exécuté localement, dans un environnement virtuel ou dans le nuage?

• Des règles d’antivirus ou de pare-feu pourraient-elles interférer?

• Existe-t-il des schémas d’architecture pertinents?

Il arrive qu’un problème qui semble lié à un logiciel soit en réalité causé par l’environnement, par exemple un manque de ressources ou un problème de communication réseau.

4. Concentrez-vous sur le flux de travaux

L’une des questions les plus puissantes en dépannage est la suivante :

Comprendre ce que la personne essaie réellement d’accomplir est parfois aussi important que comprendre le problème lui-même.

Voici d’autres questions possibles :

• Quelles étapes sont effectuées?

• À quel moment le problème survient-il?

• Ce processus a-t-il déjà fonctionné correctement?

• D’où provient ce processus?

• Existe-t-il une autre façon d’obtenir le même résultat?

Parfois, la solution n’est pas de corriger le flux de travaux existant. Dans certains cas, il s’agit plutôt de trouver un meilleur processus qui permet d’atteindre le même objectif organisationnel.

5. N’oubliez pas les utilisateurs

Les problèmes techniques ne touchent pas toujours tout le monde de la même manière.

Les questions liées aux utilisateurs révèlent souvent des indices précieux :

• Le problème touche-t-il une seule personne ou plusieurs utilisateurs?

• Quels droits d’accès ont été attribués?

• Les utilisateurs s’authentifient-ils différemment?

• Le problème se produit-il sur un autre poste de travail ou un autre réseau?

• Certaines politiques organisationnelles influencent-elles l’accès?

Si une seule personne est touchée, l’enquête s’orientera probablement vers les droits d’accès, les profils ou la configuration de son poste de travail. Si tout le monde est touché, le problème est davantage susceptible d’être lié à la configuration ou à l’infrastructure.

Les indices se trouvent souvent dans les fichiers journaux

Un bon dépannage ne consiste pas uniquement à poser des questions. Il consiste également à recueillir des preuves. Les journaux fournissent souvent le contexte nécessaire pour comprendre pourquoi un problème survient.

Voici quelques sources d’information utiles :

• Journaux d’application

• Journaux d’événements du système d’exploitation

• Messages d’erreur

• Captures d’écran

• Rapports de diagnostic

Fournir cette information dès le départ réduit considérablement le temps consacré à la collecte de renseignements et permet de concentrer les efforts sur la recherche d’une solution.

La question la plus importante

Bien souvent, la réponse se cache derrière une seule question :

Les changements comprennent notamment :

• une mise à niveau logicielle;

• une mise à jour de sécurité;

• l’ajout de nouveau matériel;

• une modification de configuration;

• une mise à jour des données;

• un changement de droits d’accès.

Comprendre ce qui a changé fournit un contexte précieux et permet souvent d’orienter directement l’enquête vers la cause du problème.

En conclusion

La prochaine fois que vous serez confronté à un problème technique, résistez à la tentation de chercher immédiatement une solution rapide et évidente. Les problèmes complexes exigent souvent une analyse approfondie avant que la bonne solution ne se dessine. Prenez plutôt du recul et concentrez-vous d’abord sur la compréhension du problème. En posant des questions réfléchies sur les logiciels, les données, l’environnement, les flux de travaux et les utilisateurs concernés, vous disposerez du contexte nécessaire pour effectuer un dépannage efficace. Les meilleurs spécialistes du dépannage ne sont pas ceux qui ont toutes les réponses. Ce sont ceux qui savent quelles questions poser.

Si vous êtes toujours dans une impasse, notre équipe d’assistance à la clientèle est toujours là pour vous aider. N’hésitez pas à communiquer ce que vous avez appris, ce que vous avez déjà essayé et les indices que vous avez recueillis. Un regard neuf permet souvent de repérer un élément passé inaperçu ou d’établir un lien qui n’avait pas été fait.

Ce billet a été écrit en anglais par Amanda De Medeiros et peut être consulté ici.