TAI023 Appliquer une démarche méthodique de résolution de problème

TAI023 Appliquer une démarche méthodique de résolution de problème

TAI023 Appliquer une démarche méthodique de résolution de problème

TABLE DES MATIÈRES

1 Une mauvaise journée qui commence 2

2 à La recherche de l'eldorado 3

3 Les causes possibles d'erreurs 4

3.1 les défauts électriques 4

3.2 les problèmes de connectique 4

3.3 Les défauts des composants 4

3.4 le montage erroné 4

3.5 la mauvaise configuration des extensions 4

3.6 les problèmes de setup 4

3.7 les problèmes d'amorçage 5

3.8 les problèmes des systèmes d'exploitation 5

3.9 les problèmes logiciels 5

4 identifier les symptômes 6

4.1 Quand l'erreur est-elle apparue? 6

4.2 Quand l'erreur se produit-elle ? 6

4.3 L'erreur est-elle reproductible ? 6

4.4 Comment se présente l'erreur ? 6

5 Recherche des causes d'erreurs 7

5.1 la représentation statique 7

5.2 La représentation dynamique 7

5.3 Echanger les éléments 9

5.4 le Strip-tease du micro 9

6 Les bases de données 11

6.1 La base de données inventaires 11

6.2 la base de données interventions 11

6.3 la base de données des incidents 11

7 Les organigrammes de diagnostic 13

7.1 Contexte et principe d’utilisation 13

7.2 Exemple de procédure 13

1 Une mauvaise journée qui commence

Quel utilisateur de micro-ordinateur ne s'est pas retrouvé un jour dans la situation suivante : après avoir travaillé comme un forcené sur son micro depuis le début de la semaine, voilà que brusquement ce dernier fait un caprice et rien ne va plus. 

Impossible d'imprimer un rapport urgent, le carnet de rendez-vous est inaccessible, bref le monde s'écroule.

2 à La recherche de l'eldorado

Le rêve des utilisateurs de micro et des techniciens confrontés à ce genre de problème serait de trouver la solution en consultant une liste des erreurs possibles.

Cet Eldorado existe en théorie, il s'appelle Base de données des incidents, cependant, il ne couvrira pas tous les incidents que vous rencontrerez et ce pour deux raisons : 

1. les incidents sont comme les virus, on en découvre tous les jours.

2. pour une même erreur, les causes peuvent être multiples.

C’est pourquoi, la façon la plus efficace de remédier à une panne est d'appliquer une démarche méthodique qui consiste à identifier les symptômes, à rechercher les causes possibles et enfin d'émettre un diagnostic.

Cette façon de procéder vous permettra de mieux comprendre ce qui se passe et de mettre à jour une base de données des incidents et ainsi de faire un pas vers l'Eldorado.

3 Les causes possibles d'erreurs

3.1 les défauts électriques

Tous les composants d'un micro-ordinateur sont alimentés en électricité. Un défaut électrique peut être à l'origine d'une panne.

Toutefois des défauts de ce genre sont rares et assez difficiles à localiser.

3.2 les problèmes de connectique

A chaque fois que deux éléments sont connectés entre eux par un câble, vous vous exposez à des problèmes de connectiques.

On trouve de la connectique dans le PC, par exemple la connexion des disques à la carte mère. On en trouve aussi à l’extérieur, ce peut être la connexion d’une imprimante à un PC ou encore la connexion d’un PC à une prise réseau.

3.3 Les défauts des composants

Une barrette ou un processeur défectueux et voilà votre machine qui émet des bips sonores ou pire qui ne fait rien du tout. Cela ressemble, dans ce dernier cas, à s'y méprendre, à un défaut électrique.

3.4 le montage erroné

Ce type de problème apparaît généralement tout de suite après le montage d'un élément. Le diagnostic est en général assez simple. Une carte d'extension peut se tordre ou être mal fixée ou incompatible avec un autre composant. C'est le cas, par exemple, d'une carte graphique AGP qui est assez délicate à installer.

3.5 la mauvaise configuration des extensions

Les extensions utilisent généralement des IRQ ou des DMA qui peuvent entrer en conflit avec d'autres éléments qui utiliseraient les mêmes IRQ ou DMA ou encore les mêmes plages d'adresse.

Avec l'apparition de la technologie plug and play, ce type de problème a tendance à disparaître. Cependant, lorsqu'un conflit apparaît il est beaucoup plus délicat à résoudre.

3.6 les problèmes de setup

Sur les machines anciennes, c'est l'une des causes les plus fréquentes de dysfonctionnement lors du processus de démarrage. Parfois, c'est une batterie trop vieille qui provoque la perte des données du SETUP. Dans ce cas, le disque dur et le lecteur de disquette ne sont plus reconnus ce qui rend impossible le démarrage du système.

Une mauvaise déclaration des types de lecteurs disque peut également provoquer une erreur du système.

Les BIOS actuels proposent également un Setup étendu où l'on peut modifier à loisir la fréquence d'horloge du bus ou le rafraîchissement de la RAM. Certains de ces réglages peuvent paralyser entièrement l'ordinateur.

Une bonne nouvelle cependant, sur les PC les plus récents cela va beaucoup mieux si on se contente des options par défaut.

3.7 les problèmes d'amorçage

Lorsque le BIOS a contrôlé les composants déclarés dans la mémoire CMOS, il cherche une mémoire de masse contenant un système d'exploitation. Ainsi, si une disquette est détectée dans le lecteur A:, il tente de donner la main au système d'exploitation sensé s'y trouver. Si la disquette n'est pas bootable, le processus de démarrage est stoppé. Ce type d'erreur fréquent est très facilement repérable.

Après avoir cherché sur le lecteur " A:, le Bios cherche sur le premier disque dur géré par lui-même ou un autre BIOS (celui d'une carte SCSI, par exemple) une partition active. Si la recherche ne donne aucun résultat, le processus de démarrage est de nouveau stoppé.

Lorsqu'une partition active est détectée, le BIOS recherche sur celle-ci un système d'exploitation afin de lui donner la main. S'il n'en trouve aucun, le processus est encore une fois stoppé. 

3.8 les problèmes des systèmes d'exploitation

Les problèmes liés au système d'exploitation son généralement dus à la tentative d'activation d'un programme ou d'un pilote que le système ne parvient pas à localiser. 

L'altération d'un fichier système peut provoquer le blocage complet du système. La corruption, par exemple, de la base de registres de Windows peut être fatale à votre machine.

Ce type de problèmes n'est hélas pas en voie de disparition.

3.9 les problèmes logiciels

Des logiciels mal installés ou défectueux, peuvent conduire à tous les symptômes d'erreur imaginables pendant leur fonctionnement.

Le grand nombre de logiciels sur le marché ainsi que leurs différences de comportement sur les diverses configurations d'ordinateur, rendent impossible l'analyse systématique des problèmes logiciels. Ce dernier point ne sera pas abordé dans ce support.

Vous noterez cependant que ces problèmes connaissent une croissance que nous qualifierons de vertigineuse.

4 identifier les symptômes

La première chose à faire lorsque l'on constate une anomalie de fonctionnement est d'identifier avec un maximum de précision les symptômes. Il ne faut pas vous contenter d'un évasif « Mon ordinateur ne démarre pas ». Pour vous aider dans votre démarche posez-vous les questions suivantes :

 Quand l'erreur est-elle apparue exactement ?

 L'erreur est-elle reproductible ?

 Comment se présente l'erreur ?

Lorsque vous aurez délimité la panne, vous pourrez alors en rechercher les causes.

4.1 Quand l'erreur est-elle apparue?

Il se peut que ce soit après un accès dans le boîtier, une installation de logiciel, un déplacement du matériel, un changement d'utilisateur, etc. 

Cela peut conduire à la solution, par exemple si l'erreur est apparue juste après le changement d'un élément.

4.2 Quand l'erreur se produit-elle ?

On peut tirer des conclusions très utiles de cette précision. L'erreur surgit-elle par exemple avant, pendant ou après le processus de démarrage ?

4.3 L'erreur est-elle reproductible ?

Essayez de décrire aussi précisément que possible les conditions dans lesquelles l'erreur surgit. 

Une panne aléatoire qui peut être liée à l'échauffement d'une machine aura certainement une autre origine qu'une erreur qui se produit toujours après l'appel d'une commande déterminée du S.E..

4.4 Comment se présente l'erreur ?

Ne vous contentez pas du : "Mon ordinateur émet un signal sonore au moment où je le mets en marche". Déterminez le nombre et la durée des signaux, car cela peut être un facteur décisif pour la reconnaissance de la panne. Toutes les autres modifications sur l'ordinateur peuvent également jouer un rôle. Est-ce que le ventilateur et le disque dur fonctionnent comme il faut ? Est-ce que les LED s'allument ?

A ce stade, le technicien n'utilise pas que sa vue pour analyser une erreur. L'ouïe est un sens fondamental pour le diagnostic d'erreur. Lorsque vous mettez sous tension une machine, on entend, généralement, le ventilateur. On entend également le ou les disques durs tourner. Au démarrage il faut parfois compter le nombre de bips sonores, etc. Un technicien doit donc savoir écouter une machine.

L’odorat aussi peut se révéler utile, ainsi une odeur de brûlé, peut indiquer qu’une alimentation électrique a subit une surtension fatale lors d’un orage par exemple.

5 Recherche des causes d'erreurs

5.1 la représentation statique

Pour accélérer le processus de recherche d’incident, il est intéressant de modéliser un système complexe en sous-ensembles fonctionnels plus simples.

Commençons par un exemple simple, celui du PC. Ce système peut se représenter sous la forme d’une couche matérielle supportant une couche logicielle.

LOGICIEL 

MATERIEL 

Le raisonnement sera le suivant : un logiciel ne peut fonctionner correctement que si le matériel est lui-même conforme aux spécifications requises par ce logiciel.

En règle générale on partira du principe suivant : une couche N ne peut fonctionner que si la couche N-1 fonctionne et fournit à la couche N les services attendus.

Si l’on modélise un poste de travail, un peu plus finement que précédemment, on arrive à la représentation suivante :

Logiciel d’application 

Pilotes 

S.E. 

BIOS 

MATERIEL 

Ce schéma va vous permettre de localiser plus rapidement l’origine de la panne. Prenons par exemple le disque dur. S’il y a une anomalie, le BIOS ne le détectera pas. La couche S.E. n’est donc pas en cause. Il s’agit soit d’un problème dans la couche matériel, soit un mauvais paramétrage ou une mauvaise version dans la couche BIOS….

5.2 La représentation dynamique

Nous arrivons, ici, au cœur du problème : comment trouver la ou les causes d'un dysfonctionnement ?

Après avoir situé, du moins l’espérons-nous, la couche incriminée, il s’agit, maintenant, de connaître l’enchaînement des événements et leur influence sur l’état du poste de travail.

En fait la problématique est évidente. Il suffit de partir du postulat suivant : avant de ne plus fonctionner, cela fonctionnait. Autrement dit, la machine était dans ce que l'on appellera un état stable et à la suite d'un événement, elle est passée dans un état instable.

Les événements les plus fréquents sont :

 L'ajout d'un composant

 La connexion d'un câble

 L'installation d'un S.E.

 La modification du contenu de la mémoire CMOS

 L'usure du matériel...

Prenons l'exemple d'une machine qui se trouve dans un état que nous appellerons A. Il se produit l'événement suivant : ajout d'une carte son SB16 Value. La machine passe alors dans un état que nous appellerons B[1].

On y ajoute ensuite en lecteur de CD, on passe alors dans un état C.

On ajoute ensuite une carte réseau, cela nous donne donc :

Pour paramétrer la carte réseau, on insère dans le lecteur une disquette contenant le logiciel nécessaire à son paramétrage. A ce moment, on constate qu'il est impossible de lire cette dernière. On obtient donc un état E que l'on qualifiera d'instable.

Le dysfonctionnement peut avoir deux origines : Soit c'est le dernier événement ou l'usure du matériel qui est à son origine, soit c'est un événement plus ancien ou une combinaison d'événements qui en est la cause.

A chacune de ces origines correspond une méthode de vérification d'hypothèses. Pour la première, on utilisera une méthode qui consiste à échanger ou à paramétrer à nouveau les éléments qui pourraient être à l'origine du dysfonctionnement. La deuxième méthode consiste à revenir en arrière afin de remonter vers un état de la machine où elle est à nouveau stable. C'est la méthode du "strip-tease" du micro.

Nous allons examiner un peu plus dans le détail ces deux méthodes.

5.3 Echanger les éléments

Cette première méthode est la plus simple. Le risque majeur est d'oublier des hypothèses. Dans notre exemple, on peut émettre quatre hypothèses :

1. La disquette est défectueuse 

2. Le lecteur à une panne physique

3. Le câble est défectueux

4. L'interface disquette est tombée en panne

Ces hypothèses se vérifient simplement, il suffit à chaque fois de remplacer l'élément incriminé et de refaire le test.

Si le dysfonctionnement disparaît, on peut penser que l'élément était effectivement à l'origine du dysfonctionnement. Par mesure de précaution, il est cependant prudent de réessayer l'élément incriminé avant de conclure.

5.4 le Strip-tease du micro

Si aucune de ces hypothèses ne se vérifie, cela signifie que la cause du dysfonctionnement est apparue dans un passé plus lointain. Pour vérifier cette hypothèse, la méthode est simple. On analyse chaque événement qui s'est produit sur la machine et l'on vérifie qu'il n'est pas à l'origine du dysfonctionnement. Cela revient généralement à déshabiller la machine, cette technique s'appelle le "Strip-tease" du micro.

Dans notre exemple, on va donc commencer par retirer la carte réseau et refaire un essai. Si le dysfonctionnement est toujours constaté, on va remonter à l'événement précédant et retirer le lecteur de CD-ROM et ainsi de suite jusqu'à ce que le dysfonctionnement disparaisse.

Lorsque l'événement à l'origine du dysfonctionnement est repéré, l'ajout de la carte son pour notre exemple, on recrée tout d'abord l'événement pour s'assurer de la réapparition du dysfonctionnement. Si ce dernier réapparaît, vous pouvez émettre le diagnostic suivant : le lecteur de disquette a cessé de fonctionner lorsque l'on a rajouté la carte son.

   Ce diagnostic est une réalité, l'anomalie a déjà été constatée à plusieurs reprises. 

A partir de là, il ne vous reste plus qu'à vérifier si c'est la carte son elle-même qui est à l'origine du conflit ou s'il s'agit d'un problème de configuration.

   Lorsque vous vérifiez le paramétrage d'un élément, il est impératif de ne modifier qu'un paramètre à la fois pour pouvoir identifier à coup sûr le paramètre à l'origine du dysfonctionnement. 

Un événement tel que l'ajout d'une carte son, peut être découpé en micro-événements. Cela vous facilitera dans votre diagnostic. Dans notre exemple, nous pourrions avoir :

1. Désactivation du port Midi

2. Modification de l'IRQ

3. Désactivation de l'interface IDE secondaire

4. Mise en place de la carte.

Après ce découpage, il ne vous reste plus qu'à vérifier chaque micro-événement. Pour tester ceux relatifs au paramétrage de la carte, il suffit de les repositionner à leur valeur par défaut.

Pour le dernier micro-événement, il suffit de mettre en place une autre carte, une fois avec les paramétrages par défaut et une fois avec le même paramétrage que la carte incriminée.

6 Les bases de données

Afin d'être le plus efficace possible, un technicien de maintenance a besoin de trois types d'information : 

 De quoi est composée la machine sur laquelle il doit intervenir.

 Quelles ont été les dernières interventions effectuées sur cette machine.

 Quels sont les dysfonctionnements les plus couramment rencontrés et les solutions que l'on peut y apporter.

Pour cela, on utilise un logiciel de gestion de parc. Celui-ci permet de gérer et d’exploiter différentes bases de données qui vont stocker ces différentes informations.

6.1 La base de données inventaires

Cette base de données va vous permettre de savoir où vous mettez les pieds. C'est la première information que vous devez consulter avant une intervention.

Elle contient des informations relatives à la composition physique de la machine ainsi que des informations sur les logiciels installés, sur le propriétaire de la machine et sur ses utilisateurs.

On y trouve également des informations concernant le contrat de maintenance associé aux composants du parc ainsi que des informations concernant les garanties qui s'appliquent à ces derniers.

6.2 la base de données interventions

Cette base va vous permettre de visualiser toutes les informations en ce qui concerne les événements et les interventions liés à la machine sur laquelle vous devez intervenir.

Vous devez consulter cette base d'informations avant votre intervention et la mettre à jour après votre intervention

6.3 la base de données des incidents

Cette base de données va vous permettre de capitaliser votre expérience en matière de diagnostic de dysfonctionnement. Chaque dysfonctionnement devra y être référencé ainsi que les causes de son apparition. C'est ainsi que vous apprenez, par exemple, que le lecteur de disquette ne fonctionne plus si vous avez dans votre machine une carte SB Value édition et que vous avez désactivé l'interface E-IDE sur cette dernière.

Cette base doit donc être consultée avant une intervention et mise à jour à chaque fois que cela est nécessaire.

   Si vous vous déplacez en clientèle, il n'est pas interdit d'imprimer le contenu de la base de données. 

 Toutefois, avec un logiciel de gestion de parc apparaît le problème de la mise à jour des informations enregistrées dans ses bases de données

 On doit procéder régulièrement à l'inventaire du parc. Cet inventaire doit être également mis à jour à chaque modification du parc. Le responsable de cet inventaire est la personne qui occupe les fonctions de gestionnaire de parc.

   Si personne n'occupe cette fonction, il s'agit d'un problème d'organisation qu'il est nécessaire de résoudre. Quelqu'un doit absolument faire vivre cette base de données  

 Chaque intervention sur un composant du parc doit être impérativement référencée de façon précise et immédiatement après l'intervention.

La personne qui doit mettre à jour ou fournir les informations nécessaires à    celle-ci est le technicien. 

 Chaque dysfonctionnement doit également faire l'objet d'une mise à jour de la base de données des incidents. C'est toujours le technicien qui doit être à l'origine de la mise à jour de cette information et les remarques sont les mêmes que pour la mise à jour de la base de données interventions.

7 Les organigrammes de diagnostic

7.1 Contexte et principe d’utilisation

Pour faciliter la démarche de diagnostic, il existe parfois des organigrammes qui guident le technicien dans son investigation.

Ce type d’organigramme est souvent utilisé dans les structures Help Desk pour optimiser et uniformiser le diagnostic des techniciens.

Pour utiliser ce type d’organigramme, il suffit de poser la première question, puis, de la réponse, on se dirige vers une autre question ou une action et ainsi de suite.

Ce type d’organigramme va permettre, même à un débutant, de faire des diagnostics rapides et efficaces. Si un technicien ne parvient pas à résoudre le problème avec ce type d’algorithme, il va passer la main à un expert (support technique) et ce dernier aura la certitude que les tests élémentaires auront été faits.

7.2 Exemples de procédure

Le technicien Help Desk doit suivre à la lettre ce type de procédure. A titre d’exemple, vous trouverez ci-après une procédure qui pourrait être utilisée par la hot line d’un fournisseur d’accès Internet pour dépanner un particulier qui ne parvient pas à se connecter.