Académique Documents
Professionnel Documents
Culture Documents
HJGHJ PDF
HJGHJ PDF
Diagnostiquer le problme
www.ofppt.info
SECTEUR NTIC
Diagnostiquer un problme
Sommaire
1. Introduction ..................................................................................... 2
2. Diagnostic matriel............................................................................ 2
2.1. Diffrentes Mthodes de Recherche des Pannes sur Micro-Ordinateurs .. 2
2.1.1. La mthode des messages et des codes sonores .......................... 2
2.1.2. La mthode des diagnostics intgrs .......................................... 3
2.1.3. La mthode des mesures et les tests manuels des composants ...... 4
3. Mthodologie de rsolution des problmes ........................................... 6
3.1. Classification ................................................................................. 6
3.2. Test.............................................................................................. 7
3.3. Transmission ................................................................................. 7
3.4. Rapport ........................................................................................ 8
4. Utilisateurs d'une mthodologie de rsolution des problmes .................. 8
4.1. Utilisateurs finaux .......................................................................... 8
4.2. Spcialistes du support technique .................................................... 9
4.3. Ingnieurs du support technique ...................................................... 9
4.4. Responsables et planificateurs ....................................................... 10
5. tapes types d'une mthodologie de rsolution des problmes .............. 10
5.1. Consignation du problme ............................................................. 10
5.1.1. Processus de consignation des problmes ................................. 10
5.2. Collecte des informations .............................................................. 14
5.2.1. Processus de collecte initiale des donnes ................................. 14
5.3. Dveloppement d'un plan d'action .................................................. 15
5.3.1. Mthodes conseilles de dveloppement d'un plan d'action.......... 16
5.4. Implmentation du plan d'action .................................................... 17
5.4.1. Processus d'implmentation d'un plan d'action ........................... 18
5.5. Documentation de la rsolution ...................................................... 20
5.5.1. Processus de consignation de la rsolution ................................ 20
1. Introduction
En tant que technicien du support technique pour la rsolution des problmes lis
au poste de travail (ou technicien DST), une partie de votre travail consiste
prendre en charge les utilisateurs finaux et rsoudre divers types de tches.
Toutefois, les responsabilits dun technicien DST impliquent beaucoup plus que
la simple rsolution dun problme. Un technicien DST doit tre capable dcouter
un utilisateur, de recueillir des informations auprs de celui-ci, de diagnostiquer
et de rsoudre le problme (ou de remonter le problme un technicien senior
ou un administrateur systme) et de documenter correctement la rsolution du
problme de la faon indique par la stratgie de lentreprise.
2. Diagnostic matriel
2.1. Diffrentes Mthodes de Recherche des Pannes
sur Micro-Ordinateurs
Il existe des procdures de diagnostics pour dtecter les causes probables voir
mme les causes relles des pannes sur un micro-ordinateur. Car, en cas de
blocage de la machine, tant que la panne n'est pas dcele, on ne saurait rien
entreprendre quant la rparation de celle-ci.
Nous allons donc voir quelques grandes techniques de recherche et
d'identification de pannes. Avant d'entreprendre quoi que se soit, il faut observer
certains pralables savoir l'interrogation de l'utilisateur comme suit :
Par quoi la panne se traduit-elle ? Quelles sont les manifestations ?
Quand la panne est-elle survenue ?
Si la machine a t dplace ou l'un de ses priphriques.
S'il y a eu connexion ou dconnexion.
Si un nouveau logiciel a t install voir un nouveau priphrique ou une
nouvelle carte.
Quelles furent les commandes lances immdiatement avant la panne ?
Si quelque chose d'inhabituel a t constat, une anomalie ou un message
d'erreur.
3.1. Classification
Lorsqu'un utilisateur final rencontre un problme informatique et vous le signale,
cela dclenche une srie de processus de classification. Au cours de ceux-ci, vous
collectez des informations auprs de l'utilisateur pour tenter d'tablir la nature et
l'tendue du problme. La discussion initiale peut rvler des informations
permettant une rsolution immdiate. Cependant, dans le cas de problmes plus
graves ou plus complexes, vous devez faire appel aux autres processus de
rsolution pour parvenir les rsoudre.
Les problmes qui affectent de nombreux utilisateurs finaux ont un impact plus
sensible sur la productivit de l'organisation et doivent tre rsolus plus
rapidement.
La classification vous permet de dterminer l'tendue et l'impact des problmes
en vue d'tablir leur priorit.
Mme si vous tes en mesure de rsoudre le problme tout de suite, vous devez
le consigner en vous conformant la mthodologie en vigueur. Des procdures
de consignation appropries garantissent qu'aucun rapport d'incident ne se
perde. En ayant la possibilit d'accder aux rapports d'incident dtaills, une
organisation peut surveiller ses systmes informatiques de manire plus efficace
et prendre des dcisions informes.
3.2. Test
Une fois que vous avez tabli la priorit d'un problme et consign l'incident, la
phase de test dbute. Au cours de celle-ci, vous faites appel plusieurs
processus pour dterminer la cause probable du problme. Vous pouvez
commencer par dresser la liste des causes possibles, gnralement, en les
divisant et en les isolants. Dans le domaine des systmes informatiques, cela
peut vouloir dire tablir une distinction entre les problmes de serveur et de
station de travail, de matriel et de logiciel, et de systme d'exploitation et
d'applications. De cette manire, vous pouvez liminer les causes possibles pour
dterminer les causes probables.
Lorsque vous avez rduit la liste des causes possibles un nombre grable, vous
pouvez dmarrer le processus de test. Ce processus vise dterminer la cause
probable parmi les causes possibles restantes. Vous pouvez essayer de
reproduire le problme dans un environnement de test. Si vous pouvez le
reproduire facilement, cela signifie que vous avez dtermin la cause probable.
En revanche, si vous prouvez des difficults le reproduire, vous devez
analyser vos rsultats et revenir sur votre cheminement initial.
3.3. Transmission
Si vous ne pouvez pas trouver de rsolution pendant la phase de test initiale,
vous devez consulter la documentation supplmentaire ou transmettre le
problme, soit au fabricant du composant suspect, soit au sein de votre
organisation si vous disposez de ressources internes. Un processus de
transmission d'incident au personnel de support technique de deuxime niveau
devrait tre en place au sein de votre organisation. Un membre de ce service
vous posera des questions pour essayer de classifier l'tendue du problme et de
dfinir un niveau priorit.
3.4. Rapport
Lorsque l'incident a t rsolu, vous devez documenter sa rsolution. Il est
important d'enregistrer les modifications apportes la configuration de votre
systme informatique.
En outre, les problmes ont tendance se produire plusieurs fois. S'ils ont t
documents correctement, vous gagnerez du temps la prochaine fois que vous
serez amen rsoudre des occurrences similaires du problme.
Problme dtect
Auto-assistance
Chaque fois que cela est possible, incitez les utilisateurs trouver eux-mmes
des solutions. Certains problmes peuvent tre rsolus trs rapidement si
l'utilisateur prend le temps de rflchir ce qui vient d'arriver.
Proposez toujours une formation adquate aux utilisateurs finaux. Non
seulement ils tireront mieux parti de leurs applications, mais ils seront moins
susceptibles de rencontrer des problmes et seront mieux mmes de rsoudre
nombre de problmes eux-mmes, sans contacter le support technique.
Quelles que soient les formations que les utilisateurs finaux auront reues et
quelles que soient vos incitations, ils ne pourront pas rsoudre tous les
problmes. Il est important de mettre en place une procdure adquate pour
contacter le support technique afin que les utilisateurs la comprennent bien.
Pendant cette phase, consignez les dtails du problme.
Pour cela, vous pouvez utiliser une base de donnes. Vous pouvez ensuite mettre
jour l'enregistrement de base de donnes mesure que vous travaillez sur une
rsolution.
Si vous n'avez pas les comptences ncessaires pour rsoudre le problme
signal, assignez le problme d'autres personnes de votre organisation. Pour
les problmes complexes, vous pouvez runir une quipe spcialise. Mettez
jour l'enregistrement dans la base de donnes de support pour suivre les
informations relatives l'activit que vous, ou d'autres, avez effectue par
rapport au problme signal.
Transmission
Rsolution
Une fois que vous avez dtermin la cause probable d'un problme et avez
dvelopp un plan d'action, vous devez valuer ce plan. Cette valuation doit
inclure les tapes suivantes :
faire la liaison avec les spcialistes du support technique impliqus dans
l'implmentation du plan ;
mener bien toutes les demandes dcoulant des procdures de gestion
des modifications ;
analyser l'impact possible des modifications l'infrastructure informatique
proposes ;
dtailler les tapes de test du plan propos ;
dtailler le plan de restauration des modifications au cas o celles-ci ne
produisent pas le rsultat escompt.
Aprs avoir valu le plan d'action propos, vous pouvez le mettre en oeuvre. Au
cas o le plan d'action ne rsout pas le problme, envisagez de restaurer les
modifications apportes suite l'valuation du plan d'action. Vous devez
galement repenser la phase de classification, car il est possible que le diagnostic
et la classification initiaux taient errons.
Problme clos
Aprs avoir rsolu le problme, vous devez le fermer. Pour cela, mettez jour
l'enregistrement de base de donnes en rapport avec le problme pour indiquer
que vous avez rsolu le problme de manire permanente, puis fermez
l'enregistrement.
Questionner
couter
Consulter
Lorsque vous avez enregistr toutes les informations pertinentes fournies par
Rechercher
Dvelopper
Une fois que vous avez dtermin une cause probable du problme, vous devez
dvelopper un plan d'action.
Consulter la documentation
Vous devez vous assurer que toutes les modifications que vous envisagez
d'implmenter ne nuiront pas au reste de l'infrastructure informatique. Par
exemple, il est possible que sur un ordinateur spcifique, un nouveau pilote de
priphrique pour un composant matriel suspect soit l'origine de conflits entre
priphriques qui provoquent des problmes de dmarrage de l'ordinateur. Au
niveau de l'organisation, l'installation d'un Service Pack sur un serveur de
messagerie peut changer la faon dont les serveurs grent certains types de
messages et provoquer la non-remise des messages.
Ces problmes potentiels seront visibles lorsque vous implmenterez votre plan
d'action dans l'environnement de test. Vous pourrez alors corriger votre plan
d'action afin d'viter que ces problmes ne se produisent dans l'environnement
de production.
Rsoudre le problme
Surveiller et valuer
Qu'un problme soit compltement rsolu ou non, vous devez documenter toutes
les tapes que vous avez effectues pour le rsoudre ou tenter de le rsoudre. Si
vous avez consign l'incident dans une base de donnes pour suivre son tat,
vous devez mettre jour l'enregistrement pour indiquer que le problme a t
rsolu ou non et si l'incident est clos ou non. La rubrique suivante traite plus
particulirement du processus de consignation d'une rsolution d'un problme.
Consigner la rsolution
Vous devez mettre jour tous les enregistrements de base de donnes associs
un incident. La mise jour doit inclure la rsolution et toute autre information
pertinente relative au correctif ou la solution de contournement utilis pour
rsoudre le problme.
Vous ne devez pas considrer un problme comme rsolu tant que la rsolution
n'a pas t documente de faon tre utile pour la rsolution d'incidents
ultrieurs. Enfin, vous devez clore l'enregistrement d'incident.
Vous devez permettre l'utilisateur final qui a signal le problme de savoir que
vous avez rsolu le problme. Si l'utilisateur doit prendre des mesures spciales
ou doit contourner le problme, vous devez l'en informer. Si vous avez apport
des modifications significatives l'infrastructure, les utilisateurs peuvent avoir
besoin de recevoir une formation.
Sources de rfrence
Citer les auteurs et les sources de rfrence utilises pour llaboration du
support