Vous êtes sur la page 1sur 95

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

Sommaire
1.
2.
3.
4.
5.
6.

Introduction.........................................................................................2
Dmarche de qualit de service du helpdesk.............................................3
Prise en compte de la dmarche qualit...................................................3
Vrification de la classification des natures dincidents................................5
Vrification de la fiche complte............................................................6
Exemple Fiche Intervention....................................................................7

OFPP
T@

Document
319479686

Millsime
janvier 09

Page
1 - 99

Intgration dune dmarche de qualit de service

1.

Introduction

En thorie, toute personne obtenant des services informatiques est un client.


Dans la plupart des cas, lorganisation informatique est le fournisseur.
Lorganisation
informatique
obtient
gnralement
aussi
des
services
informatiques et est donc, en mme temps, cliente des fournisseurs de services
informatiques, ce qui peut crer un ensemble de relations complexes.
Ainsi, un dpartement de dveloppement de logiciels peut demander des services
en ligne fournis par un dpartement central de traitement alors que ce mme
dpartement de dveloppement fournit aussi la maintenance logicielle assurant
la continuit de ces services en ligne. En thorie, la gestion des niveaux de
service est un processus linaire de dfinition des services et de conclusion des
accords, tels que les contrats de sous-traitance avec des fournisseurs Externes,
les accords sur les niveaux oprationnels avec des fournisseurs internes ou les
accords sur les niveaux de service avec les clients. Toutefois, une approche
souple est ncessaire tant donn que les distinctions entre clients et
fournisseurs des services informatiques ne sont pas toujours claires.
Dans le contexte de la gestion des niveaux de service, les dfinitions suivantes
sont utilises pour Le client et le fournisseur :
-- Le client est le reprsentant dune organisation autorise passer des
accords au nom de cette organisation portant sur lobtention de services
informatiques. ne pas confondre avec lutilisateur final des services
informatiques.

-- Le fournisseur est le reprsentant dune organisation autorise passer


des accords au nom de cette organisation portant sur la fourniture de
services informatiques.
Il est trs courant de dcrire la qualit comme la satisfaction du client. La
qualit est donc relative car elle est en fonction des exigences des clients.
La qualit est la conformit dun service rpondre aux exigences dun
client, quil soit externe ou interne. La difficult est de mesurer
prcisment cette qualit de service.
Il faut donc distinguer entre le service attendu (les besoins des utilisateurs), le
service rendu et le service peru. La communication joue donc un rle important.
Les quipes informatiques doivent expliquer ce quelles font, tre transparentes
sur les engagements comme les dlais.

On peut rsumer la qualit en ces 3 points :

Intgration dune dmarche de qualit de service

Donner confiance et satisfaction aux clients

Fidliser les clients actuels et en gagner de nouveau

Diminuer les rclamations

2.Dmarche de qualit de service du


helpdesk
Des moyens sont mis en uvre afin datteindre les objectifs de qualit
fixs :
Reprage, analyse et correction des dysfonctionnements
Rdaction des procdures dexploitation et de support, utilisation de ces
procdures et correction si besoin.
Mise jour rgulire des documents dexploitation et de support
Rdaction de cahier des charges formalisant le besoin de lutilisateur
Utilisation systmatique dun logiciel de gestion des incidents
Utilisation de mthodes (comme en production) : mthodologie
denqute, analyse des risques, cercles de qualit, brainstorming,
mthodologie ITIL, .

En gnral, la dmarche de qualit de service permet dEvaluer les perceptions des


clients, Recueillir leurs attentes.

3. Prise en compte de la dmarche qualit


Le contrat de service permettra de fixer les rgles de la relation clientfournisseur entre les utilisateurs et le site informatique.
Il favorisera la mise en place dune rpartition analytique des dpenses
informatiques vers les clients-utilisateurs, par la cration dunits
duvre.
En
contrepartie,
les
moyens
financiers
(investissements
et
fonctionnement) et humains mettre en place devront tre ngocis,
soit globalement, soit avec chaque entit budgtaire selon
lorganisation de lentreprise.
La personne, qui a en charge un site informatique, se doit de dfinir la
qualit de service quelle sengage fournir lensemble de ses clientsutilisateurs.
La qualit de cette prestation doit tre ngocie avec les reprsentants
des clients-utilisateurs, afin de trouver un compromis entre la teneur de
la prestation et le cot de celle-ci.

Intgration dune dmarche de qualit de service


Ce contrat de service sorientera autour des axes principaux :
-- La confidentialit et la scurit daccs aux ressources
-- La scurit des donnes et la politique de sauvegarde
-- La disponibilit de l nergie informatique
-- Laptitude faire face un sinistre informatique
-- La qualit du support fourni aux utilisateurs
La gestion des niveaux de service surveille les contrats avec le client en ce qui
concerne lassistance fournir. La gestion des incidents doit bien connatre
laccord sur les niveaux de service SLA (Service Level Agreement) pour que cette
information puisse tre utilise lors des communications avec les utilisateurs. Les
enregistrements des incidents peuvent tre utiliss pour la production de
rapports afin de dterminer si le niveau de service convenu est fourni
effectivement au client.
Le contrat dengagement de service ou SLA dfinit le primtre des services
fournir aux utilisateurs. Il prcise de manire claire les objectifs de performance
et de qualit et inclut des indicateurs permettant de mesurer la qualit du
service.

Le fournisseur du service, quil soit interne ou externe, sengage ainsi par


contrat sur une disponibilit de loutil vis--vis des utilisateurs. Par exemple :
moins de 2 heures pour les serveurs, sous 48 heures pour les imprimantes,
15mn maximum pour un incident de niveau 1, etc.

Intgration dune dmarche de qualit de service

4.Vrification de la classification des


natures dincidents
Lorsque lon parle de qualit du service rendu aux utilisateurs de linformatique,
toutes les composantes (ou le maximum dentre elles) doivent tre prises en
compte :
Accs au rseau
Disponibilit des applications
Intgrit des donnes
Fonctionnement du poste de travail
Cette amlioration de la qualit est un processus plus ou moins complexe en
fonction de plusieurs critres : nombre dutilisateurs, nombre de sites, profils
utilisateurs, applications, .
Les outils de bureautique sont plus simples assister que les logiciels mtier, des
utilisateurs rpartis sur des rgions lointains posent plus de problmes que ceux
centraliss en un seul lieu.
Dans ce contexte, la vrification de la classification des incidents conclue avec le
fournisseur est importante puisquelle permet de cerner les problmes relation
client- fournisseur dans sa globalit.
Il convient donc de mettre en place plusieurs indicateurs permettant de mesurer
tous ces lments.
Exemples dindicateurs simples de mesure de la qualit :

Nombre de postes installs, nombre de postes mis jour (dernire version


de lOS)
Nombre dinterventions effectues au total, nombre par technicien,
nombre de problmes rsolus, dure moyenne dune intervention, temps
dintervention
Temps de rponse dune application, ou des applications
Nombre dappels reus, nombre dappels traits par le HD
Nombre dinterruptions et temps dinterruption dun service (messagerie,
accs Internet, )
Nombre de pages imprimes / imprimante

Intgration dune dmarche de qualit de service

5.Vrification de la fiche complte


Lors du Renseignement de la fiche diagnostic ou de la partie diagnostic de la
fiche dintervention, le technicien helpdesk doit vrifier la fiche renseigne.
En effet Le technicien helpdesk doit complter la fiche dintervention en vrifiant
tous les points importants notamment la nature de lincident, son classement, et
de vrifier que ce classement est intgr dans les clauses du contrat du client.
La nature de lincident peut matriel ou logiciel.
La classification des incidents a pour but de dterminer la catgorie de lincident
afin den Faciliter la surveillance et la signalisation. Plus le nombre de catgories
de classification nest lev, Mieux cest mais cela exige une forte participation
du personnel. Il arrive que diffrents aspects de la classification soient combins
dans une liste unique (par exemple type, groupe dassistance et cause), mais
comme cela prte souvent confusion, il est prfrable dutiliser plusieurs listes
Courtes. La prsente section traite des problmes relatifs la classification.
On commence par attribuer aux incidents une catgorie et une sous-catgorie
bases, par Exemple, sur la cause suspecte de lincident ou sur le groupe
dassistance concern :
Traitement central - accs, systme, application.
Rseau - routeur, segment, concentrateur et adresse Internet.
Poste de travail - moniteur, carte de rseau, unit de disque, clavier.
Utilisation et fonctionnalit - service, capacit, disponibilit, sauvegarde,
manuel.
Organisation et procdures - ordre, demande, assistance, communication.
Demande de service - demande adresse par lutilisateur au centre de
services en matire dassistance, de livraison, dinformation, de conseil ou de
documentation. Une telle demande est couverte par une procdure distincte ou
est traite de la mme faon quun incident rel.
Voici ci-dessous, un exemple de fiche dintervention qui spcifie la nature de
lincident, et sa classification.

Intgration dune dmarche de qualit de service

6.Exemple Fiche Intervention

Socit
X

Nom client :

FICHE
DINTERVENTION
CLIENT

Date de lintervention :

Intervenant :

Enonc de la situation :

Nature de lincident

Matriel

Logiciel

Classement de lincident
(Catgories)

Traitement central

Rseau
Poste de travail

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


Descriptif des tches ralises :

Conclusion :

Dure de lintervention :
Visa de lintervenant :

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

Sommaire
1.
2.
3.
4.

Qu'est-ce que la qualit de service informatique ?.....................................2


Contrat d'engagement de service............................................................2
Quels bnfices l'entreprise en retire-t-elle ?.............................................2
Outils disponibles..................................................................................3

OFPP
T@

Document
319479686

Millsime
janvier 09

Page
1 - 99

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

7.Qu'est-ce que la qualit de service


informatique ?
La qualit de service informatique est la conformit dun service rpondre aux
exigences dun client, quil soit externe ou interne. La difficult est de mesurer
prcisment cette qualit de service. Il faut donc distinguer entre le service attendu
(les besoins des utilisateurs), le service rendu et le service peru. La communication
joue donc un rle important : les quipes informatiques doivent expliquer ce qu
elles font, tre transparentes sur les engagements comme les dlais. Les contrats
dengagement de service permettent de "cadrer" le travail des uns et lattente des
autres.

8.Contrat d'engagement de service


Le contrat dengagement de service ou SLA (Service Level Agreement) dfinit le
primtre des services fournir aux utilisateurs. Il prcise de manire claire les
objectifs de performance et de qualit et inclut des indicateurs permettant de
mesurer la qualit du service. Le fournisseur du service, quil soit interne ou
externe, sengage ainsi par contrat sur une disponibilit de loutil vis--vis des
utilisateurs. Cest le seul moyen de garantir la fois un engagement de rsultat
pour le fournisseur et une mesure objective du service rendu pour lutilisateur.
Dans le cas dun prestataire extrieur, le contrat prvoit des pnalits en fonction
du prjudice subi (panne, indisponibilit). Les clauses portent gnralement sur les
dlais dintervention et de rsolution des quipes techniques en fonction de l
importance stratgique des matriels ou des configurations concernes. Par
exemple : moins de deux heures pour les serveurs, sous 48 heures pour les
imprimantes, etc.

9. Quels bnfices l'entreprise en retire-t-elle ?


Les utilisateurs sont mieux servis, ils savent " quoi sattendre" de la part des
quipes de help-desk, mais aussi de la DSI. Le travail des prestataires de
maintenance est mieux valu, lquipe informatique travaille plus sereinement :
elle est moins constamment "dans lurgence" et peut se concentrer sur des
objectifs plus stratgiques que le simple dpannage curatif. De plus, le help-desk
permet damliorer la fiabilit du systme dinformation, la productivit et l
efficacit de lentreprise tout entire.

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

10.

Outils disponibles

Il existe des outils mthodologiques tels que les normes Afnor ISO 8400-2 qui
prconisent un processus itratif damlioration ou les procdures de lassurance
qualit. On trouvera aussi un rfrentiel des meilleures pratiques en matire de
services autour du systme dinformation. Du ct des diteurs de logiciels de
help-desk, tous permettent de grer des contrats dengagement de service, mais l
offre est plthorique sur ce secteur extrmement concurrentiel. On peut citer, sans
tre exhaustif, Peregrine Systems, PS Soft, Remedy (absorb rcemment par
Peregrine), StaffandLine , Magic, Kimoce ou Supporter. Dans tous les cas, le critre
de choix sera ladaptabilit de loutil aux processus de lentreprise. Mais, pour
rsumer grossirement, plus le logiciel est paramtrable, plus il est cher.

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

Sommaire
1.
2.

Introduction.........................................................................................2
Technique danalyse de la demande.........................................................2
2.1. Classification.....................................................................................2
2.2. Test..................................................................................................2
2.3. Transmission.....................................................................................3
2.4. Rapport............................................................................................3

OFPP
T@

Document

Millsime

Page

319479686

novembre
08

1 - 99

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

11. Introduction
Dans le mtier Assistance technique, la communication entre le technicien et la
personne appelante pour un incident sur son poste de travail joue un rle trs
important pour rsoudre rapidement cet incident et aboutir un rsultat positif.

12. Technique danalyse de la demande


12.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.

12.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,
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


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.

12.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.

12.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.

Diagnostic de lincident.

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

Diagnostic de lincident

Sommaire
1.
2.

Introduction.........................................................................................2
Diagnostic de pannes matrielles.............................................................3
2.1. Les pannes Post.................................................................................4
2.2. Les pannes CMOS/BIOS......................................................................4
2.3. Les pannes CARTES MERES.................................................................6
2.4. Les pannes CPU.................................................................................7
2.5. Les pannes RAM.................................................................................8
2.6. Les pannes dalimentation.................................................................10
2.7. Les pannes des disques durs..............................................................11
2.8. Pannes de priphriques....................................................................11
3.
Diagnostic de pannes logicielles.............................................................14
3.1. Panne bureautique............................................................................14
3.2. Panne de base de donnes.................................................................15
3.3. Panne dapplications.........................................................................15
4.
Diagnostic de pannes du SE..................................................................16
4.1. Noyau.............................................................................................16
4.2. Bibliothques...................................................................................17
4.3. Outils systme.................................................................................18
4.4. Programmes applicatifs de base.........................................................18
5.
Renseignement de la fiche diagnostic ou de la partie diagnostic de la fiche
dinterventions.............................................................................................19

OFPP
T@

Document

Millsime

Diagnostic de lincident

janvier 09

Page
1 - 99

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

13. Introduction
Un bon diagnostic utilise des techniques prouves pour rparer les
problmes informatiques. La dcoupe logique du processus de diagnostic en
tapes le rend plus efficace.
Le processus de diagnostic dmarre avec l'identification du problme. Des
informations doivent ensuite tre rassembles pour dfinir les causes.
Ensuite, une solution est dveloppe et mise en place. Enfin, on vrifie que
la solution a fonctionn. Si le problme est rsolu, le processus de
diagnostic se termine avec la documentation de la solution. Si le problme
n'est pas rsolu, le processus redmarre jusqu' ce qu'une solution soit
trouve. Chaque tape est dtaille dans les chapitres suivants.
Dans cette tape, le problme est identifi. Pour cela, il faut analyser les
symptmes, de faon dterminer les causes possibles. Le rsultat est un bilan
dtaill qui dcrit clairement le problme. Sans une bonne comprhension du
problme, le technicien ne peut pas rassembler les bonnes informations pour
dvelopper une solution adquate.
Une fois que le problme a t identifi, la prochaine tape est de collecter
les informations pour qu'une solution puisse tre dveloppe. Un diagnostic
rapide et efficace implique la collecte d'informations fiables afin de trouver
une solution adquate. Les problmes informatiques peuvent varier du
simple au trs complexe. Le problme peut devenir trs compliqu si le
technicien n'a pas la bonne information.

Aujourd'hui, les techniciens ont de nombreux outils disponibles pour les


aider diagnostiquer le problme. Ils peuvent utiliser des multimtres
digitaux (DMM), des outils logiciels de diagnostic, et obtenir des
informations de l'utilisateur final. Les techniciens peuvent aussi inspecter
visuellement les systmes la recherche d'un composant cass et guetter
les symptmes d'un problme.

L'utilisateur final peut fournir des informations sur le fonctionnement


antrieur du systme. Le technicien peut ainsi connatre les changements
effectus par l'utilisateur susceptibles de perturber le systme. L'utilisateur
peut aussi renseigner le technicien sur les modifications du systme, les
erreurs survenues ou la baisse de performance qui a conduit au problme.

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


Le technicien a besoin de savoir comment interroger efficacement
l'utilisateur final. La liste ci-dessous comprend les questions classiques
poser :
L'erreur peut-elle tre dcrite? Ecrire la description du problme.
Y a-t-il un message d'erreur? Les ordinateurs comprennent des outils
d'autodiagnostic. Si l'un des autotests choue, un message d'erreur est
gnr.
Demander l'utilisateur final de se rappeler le message d'erreur ou recrer
le. Dans le cas d'une erreur au POST (Power On Self Test), demander au
client le nombre de bips entendus.
Le problme
historique de
l'vnement.
changements

ou l'erreur se sont-ils dj produits? Essayer d'tablir un


l'vnement. Celui-ci peut permettre d'identifier les causes de
Si le problme s'est produit auparavant, consulter les
survenus prcdemment.

Y a t il eu des changements rcents sur le matriel ou le logiciel? Des


modifications senses corrig un problme prcdent peuvent tre la cause
du problme actuel. L'ajout d'un matriel ou d'un logiciel peut crer des
problmes imprvus avec les ressources systme.

Le technicien doit aborder le problme de l'utilisateur poliment et


respectueusement. Quelques utilisateurs peuvent refuser d'admettre leurs
erreurs. Un vrai professionnel tablit la confiance afin que l'utilisateur se
confie plus facilement.

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


L'erreur peut-elle tre reproduite? Reproduire le problme aidera l'utilisateur
final dans la description exacte de l'erreur. Le technicien sur site pourra donc
constater de visu le problme.

Aprs avoir rpondu aux questions et vrifi les rponses, le problme devra
tre caractris comme logiciel ou matriel. Le problme pourra tre
circonscrit un lment spcifique ou une partie du systme. Une fois le
problme caractris et circonscrit, le technicien peut ensuite dvelopper
une solution qui se base sur l'exprience, la logique, le raisonnement et le
bon sens du technicien.

14. Diagnostic de pannes matrielles

Le diagnostic d'un systme matriel dsigne toute mthode permettant de


dterminer si une machine est dfaillante ou non et de discriminer l'origine
de la panne partir des informations releves par observation, contrles et
tests.
Cette mthode peut se prsenter sous diverses natures et divers supports.
Il peut s'agir :

d'un algorithme de dtection lectronique ou informatique

d'un arbre de dfaillance

d'un simple test visuel


Une panne matrielle commence par un diagnostic lectronique ou
informatique et peut prendre plusieurs formes.
Les lments matriels qui peuvent tre diagnostiques sur place sont
appels des sous-ensembles. Les sous-ensembles ne ncessitent aucune
soudure et sont faciles enlever et installer. Par exemple, une carte son
PCI est considre comme un sous-ensemble. Une carte son, peut tre
enleve sans outil spcial.

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

Vous trouverez ci-dessous la liste des sous-ensembles classiques :

Moniteurs

Clavier / souris

Carte d'extension modulaire

Microprocesseurs

Alimentation

RAM (tels que les DIMM, SIMM, RIMM, etc.)

Lecteurs de disquettes et disque dur

Carte mre

14.1.

Les pannes Post

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


Chaque fois qu'un ordinateur est allum, il excute un test au dmarrage
(POST). Le POST est une srie de tests d'autodiagnostic que l'ordinateur
excute pour tester les composants principaux. C'est la premire tche
effectue par le BIOS de l'ordinateur. Le POST effectue des tests basiques
sur la carte mre et les principaux composants. Il ne fait pas de tests
approfondis sur le systme de l'ordinateur. Il peut seulement dtecter les
pannes majeures qui bloquent le dmarrage.
Le POST est stock dans le BIOS en ROM de l'ordinateur. Lorsque
l'ordinateur est allum, la fonction POST est charge dans la premire
barrette de RAM. L'ordinateur vrifie le bon fonctionnement du squenceur
systme, du CPU, de la carte vido, de la mmoire et du clavier. Si une
erreur apparat, le BIOS a des codes d'erreur prdfinis qui seront signals
aux utilisateurs. Ces erreurs peuvent tre signales visuellement ou
travers une srie de bips.
Les sries de bips sont une aide utile au dpannage. Ces codes bips
indiquent ou confirment qu'il y a un problme avec le matriel. Les sries de
bips sont composes de bips longs et de bips courts.
Les rapports derreurs gnres par le POST varient lgrement selon le
BIOS install sur l'ordinateur. Pour les informations spcifiques sur les
erreurs POST, veuillez vous rfrer la documentation du BIOS ou le site
web du fabricant.

14.2.

Les pannes CMOS/BIOS

Le composant CMOS ou la mmoire non volatile (NVRAM) stocke les


paramtres et la configuration de dmarrage. Les erreurs classiques
associes au BIOS comprennent les erreurs de CRC du composant CMOS,
les conflits IRQ / DMA, les erreurs concernant les disques durs, les erreurs
de mmoire, et les problmes de CPU.

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


Le BIOS est le premier lment considrer dans le diagnostic des
problmes matriels. Ses caractristiques renseignent le technicien sur les
informations de configuration logicielle et matrielle de bas niveau. La
plupart des utilisateurs finaux ne connaissent pas les informations du BIOS,
ou ne savent pas les interprter. Elles sont donc rarement utilises de faon
efficace dans le dpannage.
Vrifier le BIOS Gnralement :, quand un ordinateur ou un serveur rseau
s'initialise, le numro de version du BIOS s'affiche. Vrifier le site web du
vendeur pour dterminer si la version du BIOS install est la dernire
disponible pour le modle que vous avez. Si une nouvelle version du BIOS
est disponible sur le site web du vendeur, tlcharger la mise jour et
suivre les instructions du constructeur pour la mise jour. La plupart des
ordinateurs et des serveurs rseau ont un BIOS qui est flashable, ce qui
signifie qu'il peut tre facilement effac et mis jour via le logiciel .
Accder au CMOS : Pour accder au programme de configuration du CMOS,
appuyer sur la touche adquate pendant le processus de lancement. La
touche concerne doit tre actionne ds le dbut du processus de
lancement, ou le systme chargera l'OS install. Si l'affichage vido est
oprationnel, un message indiquant l'action effectuer pour accder au
setup est gnralement affich. La touche d'accs au CMOS est
gnralement F1, F2, ou Suppr. Comme il n'y a pas de standard, vrifiez
quelle est la touche actionner dans la documentation adquate.
Identifier le paramtre incorrect : Un moyen de rsoudre les erreurs lies au
CMOS est de rinitialiser les paramtres dans le CMOS leurs valeurs par
dfaut. Rinitialiser le CMOS efface la mmoire et toutes les donnes
dfaillantes potentielles. Effacer la mmoire CMOS peut tre utile quand
l'ordinateur ne redmarre plus du tout. Il y a deux faons de l'effacer Le
moyen le plus facile est d'enlever la batterie CMOS (la petite batterie ronde
sur la carte mre)
La procdure est dcrite ci-dessous :

1. Eteindre l'ordinateur
2. Enlever la batterie du CMOS de la carte mre
3. Court-circuiter les connexions ngatives et positives de l'emplacement de la
batterie sur la carte mre, en utilisant tout matriau conducteur (fil, tte de
tournevis, etc.).
4. Replacer la batterie CMOS dans sa position initiale sur la carte mre
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


5. Allumer le systme pour le dmarrer

Si la procdure ci-dessus n'efface pas le CMOS, dplacer les cavaliers de la


carte mre vers la position clear CMOS pendant quelques secondes.
Pour localiser ces cavaliers, consulter la documentation de la carte mre
fournie par le fabricant.

Mise jour du BIOS : Une mise jour du BIOS peut inclure des correctifs,
des fonctionnalits supplmentaires et le support des derniers
priphriques, afin de rsoudre tous les problmes. Il n'est pas recommand
de mettre jour le BIOS en l'absence de problmes. Si le systme est
oprationnel, la mise jour du BIOS est risque et doit tre vite. Si le
BIOS est mis jour de faon incorrecte, cela peut endommager la carte
mre et les priphriques.
Une attention particulire devra tre porte avant la mise jour du BIOS. La
carte mre doit avoir un BIOS en mmoire flash et supporter la nouvelle
version. Le composant BIOS a aussi besoin de supporter le nouveau numro
de version. Le BIOS ne pourra tre mis jour que si ces critres sont
respects.

14.3.

Les pannes CARTES MERES

La carte mre coordonne le bon fonctionnement des composants du


systme. Elle permet aux priphriques de communiquer et de travailler
ensemble. Si la carte mre est dfaillante, elle doit tre remplace. Les
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


scnarios suivants illustrent les problmes qui peuvent apparatre, et les
procdures suivre pour les rsoudre.
Scnario 1 Si l'ordinateur ne dmarre pas, suivre ces tapes
1. Vrifier l'alimentation lectrique extrieure. Le cble d'alimentation doit
tre correctement connect l'ordinateur et la prise de courant alimente.
2. Vrifier les connexions l'intrieur de l'unit centrale. La carte mre et
les units de masse doivent tre alimentes
3. Regarder le montage de la carte mre. Celle-ci doit tre isole du boitier
par des tampons en caoutchouc chaque point de fixation et ne doit pas
toucher la base en mtal. Si ces tampons ne sont pas correctement
installs, la carte mre peut tre en court-circuit.
4. Enlever chaque carte d'extension et essayer de redmarrer le systme. Si
cela fonctionne, cela prouve la dfaillance de la carte enleve.
5. Vrifier les contrleurs de disque. Enlever les et essayer de dmarrer. Si
cela fonctionne, le problme peut tre circonscrit l'un des disques.
6. Enlever les cartes vido. Si l'ordinateur dmarre, essayer une autre carte.
7. Remplacer la premire barrette de RAM par une dont vous tes sr.
8. Si l'ordinateur, aprs toutes ces manipulations, ne dmarre toujours pas,
la carte mre devra probablement tre remplace.

Scnario 2 Des micros interrupteurs et cavaliers sont prsents la surface


de la carte mre. Leur configuration peut avoir besoin d'tre modifie
pendant le dpannage. Sur certaines cartes mres, par exemple, le
programme de configuration du CMOS est activ par une configuration
particulire des cavaliers. Si ceux-ci ne sont pas remis leur position
initiale, l'ordinateur ne fonctionnera pas correctement. Pour vrifier la
configuration de des cavaliers, consulter soit la documentation, soit le site
web du fabricant.
Scnario 3 Durant la phase de test au dmarrage (POST), la compatibilit
entre la ROM et la carte mre est teste. Si le test choue, l'utilisateur
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


reoit le message : BIOS ROM Checksum Error . Cela signifie que la
compatibilit n'est pas assure. La ROM devra donc tre change par un
modle compatible.

14.4.

Les pannes CPU

Les symptmes d'une panne processeur sont une baisse de performance,


des bips au POST, ou un systme qui ne fonctionne pas correctement. Ces
erreurs indiquent gnralement qu'une erreur interne est survenue. Les
erreurs internes peuvent aussi causer des pannes intermittentes. Si le
systme compte en permanence la RAM ou se fige en comptant la RAM, le
CPU cre des erreurs et a besoin d'tre remplac.
Problmes de refroidissement : La plupart des CPU possdent un ventilateur
destin les refroidir. Si le systme se bloque ou chauffe exagrment, le
ventilateur peut tre mis en cause.
Une bonne maintenance des composants internes prvient les rparations
coteuses du CPU. Il faut garder l'ordinateur dans une zone bien ventile,
nettoyer les ouvertures d'aration rgulirement, remplacer souvent les
filtres et nettoyer l'intrieur de l'ordinateur. Le ventilateur de
refroidissement doit tre spcifique au CPU.
Les CPU peuvent aussi sortir de leur logement, tant donn la dilatation des
mtaux en prsence de chaleur, et leur contraction pendant le
refroidissement. Cette fluctuation risque ventuellement de rendre le CPU
instable, et affectera sa performance. Inspecter visuellement le CPU, et le
remettre en place s'il semble sorti.

14.5.

Les pannes RAM

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


La plupart des RAM sont des RAM dynamiques synchrones (SDRAM) et
DRAM Rambus (RDRAM). SDRAM avec des botiers DIMM 168 pin sont les
modules les plus connus. Avant les SDRAM et RDRAM, il y avait les DRAM.
D'anciens Pentiums utilisaient le mode Fast Page (FPM) et la RAM EDO
(Extended Data-Out). FPM et EDO RAM sont des modules mmoire 72 pin.

RAM Dynamique (DRAM) - DRAM est une forme classique de RAM et


depuis, a t remplace par la SDRAM, plus rapide et moins chre. La DRAM
fonctionne en stockant des donnes de manire lectrique.

RAM EDO - La RAM EDO est plus rapide que la DRAM. EDO RAM a aussi t
remplac par SDRAM. EDO RAM tait une amlioration de la DRAM, parce
qu'elle avait des caractristiques volues de synchronisation. EDO augmente
la dure de stockage des donnes et possde une frquence de
rafrachissement rduite. Ceci soulage le CPU et la RAM en terme de
synchronisation et amliore la performance.

SDRAM - La SDRAM a remplac la DRAM, la FPM et l'EDO. SDRAM est une


amlioration parce les transferts de donnes entre le CPU et la mmoire sont
synchroniss. SDRAM permet au CPU de traiter des donnes tandis qu'un
autre processus est en train d'tre charg.

DDR SDRAM La DDR SDRAM est une nouvelle forme de SDRAM qui peut
thoriquement augmenter la vitesse d'horloge mmoire jusqu' 200
mgahertz (Mhz) ou plus.

Module SIMM - Le botier SIMM est un module mmoire de 72 ou 30


contacts. On considre les SIMM comme des composants anciens, et peuvent
donc se trouver dans des machines d'un certain ge. Les SIMM avec 72
contacts peuvent supporter un transfert sur 32 bits, les SIMM de 32 contacts
peuvent supporter des transferts sur 16 bits.

Module DIMM - le botier DIMM est un module mmoire de 168 contacts.


Les DIMM sont largement utiliss aujourd'hui et supportent un transfert sur
64 bits.

Module Rambus (RIMM) : Le botier RIMM est un module mmoire de 184


contacts qui utilise seulement la RDRAM. De plus petits modules appels SO
RIMM ont un connecteur de 160 contacts. Certains systmes demandent que
les modules RIMM soient ajouts par paires identiques, et d'autres
permettent aux RIMM d'tre installs tout seuls.

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


On peut obtenir plus d'informations sur les types de mmoires spcifiques
partir du site web du fabricant.

Dpanner les problmes de RAM : Les pannes de RAM viennent


soudainement ou de manire intermittente. Une mmoire dfaillante ou sur
utilise peut bloquer le systme tout moment. La performance du systme
est une bonne indication de l'tat de la mmoire. Si le systme fonctionne
sans problme et que les applications bloquent rarement, l'utilisation de la
RAM est adapte la quantit installe.. Si l'ordinateur, effectuant plusieurs
tches la fois, se bloque frquemment, la quantit de RAM est
probablement insuffisante pour la charge de travail.
Dpanner les modules RAM est plutt simple. Aujourd'hui la RAM est bon
march et facile remplacer. Les techniciens peuvent facilement enlever le
module mmoire suspect et le remplacer par un bon Si le problme est
rsolu, le technicien peut conclure que le module RAM est mauvais. Si le
problme de mmoire existe encore, consulter la documentation de la carte
mre. Certaines cartes mres demandent que les modules mmoires soient
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


installs dans un ordre particulier, ou que certains cavaliers soient mis en
place.
Vrifier aussi que le module a t correctement install. Les modules
mmoire sont clipss et s'insrent dans un sens. Si l'utilisateur suspecte
une mauvaise installation, enlever et inspecter le connecteur du module.
Enlever tout dbris ou poussire, et replacer le module mmoire .

Problmes de compatibilit RAM : Les modules mmoire SDRAM supportent


diffrentes vitesses. Les vitesses SDRAM les plus connues sont PC 66, PC
100, et PC 133. La vitesse de la mmoire SDRAM est mesure en mgahertz
(MHz). Le SDRAM avec une valeur en MHz plus leve, indique une mmoire
plus performante. La mmoire SDRAM a des problmes de compatibilit
avec le bus sur la carte mre. La vitesse du module SDRAM doit
correspondre la vitesse du bus. Les vitesses de bus classiques sont PC 100
et PC 133. Quand on cherche acheter des modules RAM, vrifier la vitesse
du bus et acheter un module RAM compatible.

La vitesse des modules EDO et FPM est mesure en nanosecondes (ns). Le


module mmoire avec la valeur en ns la plus basse est le plus rapide. EDO
et FPM ont aussi des problmes de compatibilit avec le bus systme.

Une DRAM plus rapide peut tre installe sur un bus systme plus lent et n'affectera
pas les performances. Le systme agira la vitesse du bus, mme si de la mmoire
plus rapide est installe. Cependant, un module DRAM plus lent ou diffrent, ne
peut pas tre install sur un systme avec des exigences DRAM plus leves ou des
DRAM vitesse d'horloge diffrente.

14.6.

Les pannes dalimentation

L'alimentation joue un rle vital dans le fonctionnement de tout systme


informatique. Si l'alimentation ne fonctionne pas correctement, les
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


composants informatiques seront mal aliments et ne fonctionneront pas
normalement.
L'alimentation convertit le courant alternatif (AC) qui arrive de la prise, en
un courant continu (DC). Le courant alternatif vient du mur, sa valeur
variant de 120 240 volts (tout dpend du pays ou de la rgion). Il est
converti en courant continu +/- 5 et +/- 12 V. Aprs que le courant soit
converti d'alternatif en continu, l'alimentation fournit deux fonctions
importantes l'ordinateur.

Fourniture d'nergie : l'alimentation dlivre la bonne quantit de courant


tous les composants du systme. Par exemple, les micros processeurs, les
cartes modulaires, la RAM et les disques reoivent tous du courant continu de
l'alimentation.

Mcanisme de refroidissement : c'est la fonction la moins vidente de


l'alimentation. Cependant, cette fonctionnalit ne doit pas tre occulte parce
qu'elle joue un rle important dans la performance du systme. Les systmes
informatiques fonctionnent mieux s'ils sont correctement ventils et refroidis.
Un ventilateur intgr la plupart des alimentations refroidit l'alimentation et
les composants internes.

Quand un PC redmarre au hasard ou se bloque aprs avoir fonctionn un


moment, il peut indiquer une alimentation dfaillante.
Lalimentation gnre la majorit du flux d'air. Le ventilateur sur l'alimentation
rafrachit l'unit et les autres composants internes du systme. Le ventilateur
aspire l'air des composants internes, la carte mre, la puce et les cartes
modulaires, et vacue l'air chaud en dehors du botier de l'ordinateur. C'est
typiquement le cas avec les nouveaux botiers ATX. Avec les anciens systmes
AT, le ventilateur aspire l'air de l'extrieur et le souffle directement sur les
composants de la carte mre. Aujourd'hui, la plupart des processeurs ont un
ventilateur attach la puce. Le ventilateur intgr refroidit le CPU. Vrifier que
les ventilateurs fonctionnent en coutant le bruit du ventilateur. Ce dernier
devrait fonctionner en ronronnant doucement. Il ne devrait y avoir aucun bruit
excessif.

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

14.7.

Les pannes des disques durs

La reconnaissance par le bios de la machine dun disque dur est la premire


tape vrifier si le poste ne dmarre pas.
Certains ordinateurs sont configurs avec deux disques durs diffrents.
Configurer un ordinateur avec deux disques durs augmente l'espace pour
sauvegarder et stocker des donnes. Si deux disques durs sont configurs
sur le mme cble, ils doivent avoir une relation matre/esclave. En mode
normal, l'ordinateur dmarrera partir de l'OS charg sur le disque dur
paramtr en matre. Le disque matre grera le drive esclave (disque avec
le cavalier mis en place sur esclave) une fois que l'ordinateur dmarrera. Le
disque dur esclave fournit des capacits supplmentaires de stockage.
Quand deux disques sont installs, la majorit des problmes viennent
d'une mauvaise installation des cavaliers, ou d'un paramtrage incorrect du
BIOS. Les fabricants de disque dur dcident des positions de cavaliers, aussi
le technicien aura besoin de consulter le manuel du disque dur ou le site
web du fabricant pour les dtails spcifiques. Cependant, chaque disque doit
tre install soit en Matre, soit en Esclave ou en Cble Select. Le disque qui
contient l'OS. doit tre paramtr en matre. Le second disque doit tre
install en esclave.
La slection par le cble (CSEL) est une option qui dfinit la relation matre /
esclave en fonction de la position du disque sur le cble IDE. Pour que le CSEL
fonctionne correctement, chaque appareil doit avoir ses cavaliers installs sur CSEL,
un cble CSEL doit tre utilis, et le connecteur d'interface d'hte doit supporter le
CSEL.

14.8.

Pannes de priphriques

Les priphriques d'entre tels qu'un clavier, une souris, des scanners, et les
appareils numriques transfrent des donnes dans un ordinateur. La
plupart des priphriques d'entre sont dtects au dmarrage.
Quand on diagnostique des priphriques d'entre, vrifiez que le
priphrique est correctement connect. Vrifier que le cble est dans de
bonnes conditions de fonctionnement et qu'il n'est pas us. Comme avec
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


d'autres problmes matriels, commencer le dpannage en dehors de l'unit
centrale.

Aprs avoir vrifi les connexions du priphrique d'entre, essayer de


relancer l'ordinateur. Quelquefois, un priphrique d'entre peut tre
dconnect pendant son fonctionnement et le redmarrage est efficace.
Faire attention toutes les erreurs qui s'affichent pendant le dmarrage. Les
erreurs seront indiques soit par un message d'erreur sur l'cran vido, soit
un par un code compos de bips.
Par exemple, si un clavier n'est pas correctement connect, l'utilisateur peut
avoir un code sonore ou un message d'erreur 301 .
Deux erreurs connues avec les priphriques d'entre sont l'entre de
caractres incorrects et des priphriques non reconnus. Deux de ces
erreurs peuvent tre la consquence de mauvais pilote ou d'un pilote
dpass. Toujours vrifier le site web du fabricant pour les pilotes mis jour.
Les priphriques d'entre ont besoin du bon pilote pour fonctionner
correctement.
Claviers : Les claviers sont des priphriques d'entre trs utiliss. Etant
donn cette lourde charge de travail et la prsence de nombreux
composants en mouvement, les pannes de clavier sont frquentes. La
meilleure protection contre les erreurs de clavier est la maintenance
proactive.
Souris : La souris est aussi un priphrique d'entre trs utilis. Les souris
sont sujettes la dgradation de leur performance, principalement cause
de la poussire et la salet qui endommagent les composants. Maintenir un
environnement propre et nettoyer la souris frquemment pour avoir une
performance optimale.
Scanners : la plupart des erreurs de scanners sont soit lies une mauvaise
installation du logiciel, soit un priphrique mal connect.
Ports parallles : Les ports parallles sont rarement dfaillants. Cependant,
un problme connu est la faible performance d'un priphrique parallle.

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


Les ports USB : La plupart des nouveaux ordinateurs sont quips avec un
port USB. Aujourd'hui, les ports USB remplacent l'ancien port srie que l'on
trouvait dans la plupart des ordinateurs. Les priphriques USB sont bass
sur la technologie PnP (Plug and Play). Ceci signifie que les priphriques
USB devraient s'installer et fonctionner avec un minimum de configuration.
Cependant, ceci ne signifie pas que les priphriques USB soient sans
problmes. Il y a plusieurs pannes connues qui sont associes aux
priphriques USB.

Un driver manquant ou dpass

Mauvais cblage

Matriel dfectueux

Conflits de ressources

Il existe de nombreux logiciels commerciaux disponibles comme aides aux


pannes matrielles. Ces produits, connus comme logiciels de diagnostic,
aident prvenir les pannes du systme. Quelques-uns des programmes les
plus connus sont inclus dans la liste suivante :

SpinRite http://grc.com/default.htm

Check it http://www.hallogram.com/

PC Technician http://www.windsortech.com/

AMI Diags http://www.ami.com/

SiSoft Sandra (freeware) http://www.3bsoftware.com/

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

SpinRite : SpinRite est un programme de rcupration des donnes partir

d'un disque dur dfaillant. SpinRite est un programme indpendant qui est
capable de se lancer sans le DOS. C'est un logiciel reconnu pour sa capacit
rgler des problmes difficiles. SpinRite peut aussi empcher les pannes
de disque dur. S'il est charg avant une panne, il peut prvenir les
utilisateurs d'un problme potentiel, et peut empcher une dfaillance en
isolant les zones problmes. Les mauvaises zones sont repres comme
dfaillantes. Si une zone est dfaillante, elle ne peut pas tre utilise pour
lire ou crire des donnes.

Checkit : Checkit effectue des analyses du systme et des tests. Il peut

fournir au technicien des rapports sur la performance des composants


matriels. Checkit peut effectuer des tests de bouclage en utilisant des
bouchons. Il peut aussi vrifier le bon fonctionnement du CPU, des slots PCI,
du DMA, du CMOS, du cache, du clavier et les premiers 64 mgaoctets de la
RAM vido.

PC Technician : PC Technicien est un outil de diagnostic indpendant du DOS.


PC Technicien peut effectuer des tests sur les ports parallles, ports srie,
disque dur, le clavier, les cartes vido et la RAM.

AMI Diags : AMI Diags effectue des tests approfondis du systme. AMI Diags
peut fournir des rapports sur la mmoire, les ports srie, les ports
parallles, les modems, les disques durs, le clavier, le BIOS, et les
adaptateurs vido.

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


SiSoft Sandra Sandra (analyseur de systme, assistant de rapport et de diagnostic)

est un programme libre qui fournit un ensemble d'outils diagnostic, qui peut aider
au dpannage et la mesure de performance. Sandra peut tester la performance
des CPU, du modem, de la carte vido, de la mmoire, du BIOS et des disques durs.

15. Diagnostic de pannes logicielles


Une panne logicielle peut tre de 3 types :
Panne bureautique, panne de base de donnes, et panne dapplications.

15.1.

Panne bureautique

Le terme de bureautique dsigne les applications ayant pour objectif la


mcanisation et l'automatisation du travail de bureau soit les processus de
production, d'expdition, de rception et de conservation des documents.
La bureautique se dfinit aussi comme la technique de production et de
communication de documents (textes, audio, images). Les outils
bureautique se classent en trois grandes catgories les outils de production
de document, tel que le traitement de texte, les tableurs et tous les outils
spcialiss de production bass sur un mtier, les outils de communication
principalement les logiciels de courrier et finalement les outils de
conservation tel que les logiciels de gestion documentaire. Ces trois
catgories reprsentent les surfaces traditionnelles du travail de bureau soit
la surface de production, les paniers de rception et d'expdition et
finalement les classeurs.
Dans la ralit des choses, Une panne bureautique peut tre un
disfonctionnement des produits de la suite office Microsoft (WORD, EXCEL,
POWERPOINT) ou du systme open source comme OPENOFFICE.
Une panne bureautique peut tre un problme de mis en page dun
document, un virus qui a infecte un fichier de modle (exemple le modle
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


normal), un message derreur apparat si vous accdez a un menu du
produit, etc. une base de connaissance concernant ce produit devra tre
disponible, consultable par le technicien helpdesk.
Diagnostiquer une panne bureautique veut dire que le technicien helpdesk
doit avoir un minimum de connaissance sur les produits offices pour
rsoudre le problme de lincident. Dans la plupart des cas, le produit de la
suite office sera rinstall si le problme nest pas rsolu.

15.2.

Panne de base de donnes

Une base de donnes, usuellement abrge en BD ou BDD, est un ensemble


structur et organis permettant le stockage de grandes quantits
d'informations afin d'en faciliter l'exploitation (ajout, mise jour, recherche
de donnes).
Une base de donnes se traduit physiquement par un ensemble de fichiers
prsent sur une mmoire de masse (bien souvent un disque). Certaines
peuvent tre accessibles via les rseaux, on parle alors de base de donnes
en ligne.
Les exemples les plus connus l'heure actuelle de base de donnes oriente
objets sont les annuaires, qui sont capables de stocker une multitude
d'informations. Ils la stockent dans des objets, trs souvent une fiche
individuelle, une machine, une ressource... laquelle on associe des
valeurs, ses attributs.
Une panne de base de donnes peut tre un problme daccs la base de
donnes, un service dpendant de la base qui nest pas mont, la base de donnes
est endommage dans ce cas, soit la rparer soit la restaurer a partir dune
sauvegarde, etc. Une base de connaissance concernant la base de donnes devra
tre disponible, consultable pour le technicien helpdesk.

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

15.3.

Panne dapplications

Une application est un outil qui permet de raliser une ou plusieurs tches ou
fonctions. Un amalgame est courant avec le terme logiciel.
Un logiciel est un ensemble de programmes qui permet un ordinateur ou
un systme informatique d'assurer une tche ou une fonction en particulier
(exemple : logiciel de gestion de la relation client, logiciel de production,
logiciel de comptabilit, logiciel de gestion des prts).
On distingue en gnral, dans un systme informatique, la partie matrielle
(l'ordinateur et ses priphriques) et la partie logicielle, immatrielle (les
programmes crits sur le disque dur).
Le logiciel est un bien immatriel, mais surtout c'est un bien non-rival, cest-dire qu'il ne s'use pas ; c'est un bien dont la consommation par un
individu donn n'empche pas d'autres consommateurs d'en jouir
simultanment.

Le terme logiciel est souvent employ pour dsigner un programme


informatique, et inversement, bien qu'un logiciel puisse tre compos d'un
seul ou d'une suite de programmes. Ce dernier cas est d'autant plus
frquent que la capacit rduite de calcul de l'ordinateur oblige une
segmentation des tches en plusieurs modules spars .Il existe un autre
amalgame avec application : l'application est un ensemble de logiciels
ncessaire pour une tche donne (par exemple, un navigateur web est une
application alors que Firefox est un logiciel).
Gnralement, les programmes sont accompagns d'un ensemble de
donnes permettant de les faire fonctionner (par exemple, un jeu viendra
avec de nombreuses images, animations, sons, etc.).
Une panne dapplications peut tre un problme daccs lapplication, un service
dpendant de lapplication qui nest pas mont, lapplication est endommage dans
ce cas, soit la rparer soit linstaller de nouveau, etc. Une base de connaissance
concernant lapplication devra tre disponible, consultable par le technicien
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


helpdesk. Laccs ces bases de connaissance est gnralement un service payant
car lapplication est spcifique son constructeur.

16. Diagnostic de pannes du SE


Le systme dexploitation (SE, en anglais Operating System ou OS) est un
ensemble de programmes responsables de la liaison entre les ressources
matrielles dun ordinateur et les applications informatiques de lutilisateur
(traitement de texte, jeu vido). Il fournit aux programmes applicatifs des
points dentre gnriques pour les priphriques.
Un systme dexploitation est typiquement compos :

dun noyau ;

de bibliothques ;

dun ensemble doutils systme ;

de programmes applicatifs de base.

16.1.

Noyau

Le noyau (ou cur) assure les fonctionnalits suivantes :

gestion des priphriques (au moyen de pilotes) ;

gestion de lexcution des programmes (aussi nomme processus) :

gestion de la mmoire attribue chaque processus ;

ordonnancement des processus (rpartition du temps dexcution sur


le ou les processeurs).

synchronisation et communication entre processus (services de


synchronisation, dchange de messages, mise en commun de
segments de mmoire, etc.)

gestion des fichiers (au moyen de systmes de fichiers) ;


DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail


gestion des protocoles rseau (TCP/IP, IPX, etc.).
Il sagit de la couche primordiale, celle qui est lance lors du dmarrage de
lordinateur que lon appelle couramment le boot. Grce celui-ci, les
premiers services peuvent accder aux applications systme : gestion de la
mmoire, accs aux disques durs et accs aux priphriques, il gre donc
les ressources de lordinateur et permet aux diffrents composants matriels
et logiciels de communiquer entre eux.
Dans ces systmes dexploitation, la mmoire vive est divise en deux
parties indpendantes : le noyau et lespace utilisateur (ce dernier est
lespace de la mmoire ddi aux applications, ce qui permet plus de
scurit : les applications de lespace utilisateur ne peuvent ni
accidentellement ni intentionnellement accder une zone mmoire ne leur
appartenant pas.
Les noyaux ont comme fonctions de base dassurer le chargement et
lexcution des processus, de grer les entres-sorties et proposer une
interface entre lespace noyau et les programmes de lespace utilisateur.
Le systme dexploitation, par cette double structure noyau/utilisateur,
permet le plus souvent aux applications dtre indpendantes de la machine
sur lesquelles elles fonctionnent. Le systme dexploitation masque donc les
particularits de chaque ordinateur, en garantissant les interfaces
ncessaires la compatibilit.

16.2.

Bibliothques

Les bibliothques servent regrouper les oprations les plus utilises dans
les programmes informatiques, afin dviter la redondance de la rcriture
de ces oprations dans tous les programmes.
On distingue gnralement deux types de bibliothques: les bibliothques
systme, et les bibliothques utilitaires. Les bibliothques systme sont
constitues de fonctions permettant lutilisation agrable des fonctionnalits
systmes (gnralement des points dentre vers des fonctions du noyau,
mais pas seulement). Les bibliothques utilitaires contiennent des fonctions
dusage courant et pratique (fonctions mathmatiques, fonctions de tri,
etc.).
Du point de vue du systme, les bibliothques ont diffrentes
caractristiques. Il y a le caractre statique ou dynamique, et le caractre
partag ou non.
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

Une bibliothque statique contient des fonctions qui seront intgres au


code gnr par le compilateur (dition de liens statique). Linconvnient est
quun code ainsi obtenu nest pas mis jour lorsque la bibliothque change.
Lavantage est que le code lui seul est autonome.
Une bibliothque dynamique est une bibliothque qui contient des fonctions
qui seront intgres au code au moment de son excution (dition de liens
dynamique). Lavantage est que le code est jour vis--vis de la mise jour
des bibliothques. Linconvnient est que lexcution dpend de lexistence
de la bibliothque. On raffine aussi laspect dynamique en liaison tardive
(intgration de la fonction lorsquelle est appele) ou au chargement
(intgration des fonctions ds que le programme commence sexcuter).
Une bibliothque partage est une bibliothque dont il est garanti que le
contenu ne sera prsent quen un seul exemplaire dans le systme
dexcution, les fonctions seront partages par toutes les applications les
utilisant un systme de fichier.

16.3.

Outils systme

Les outils systme permettent :


De configurer le systme (grer les comptes des utilisateurs, configuration des
paramtres rseau, dmarrage automatique des services, etc.).
De passer le relais aux applications proposant des services un ou plusieurs
utilisateurs ou dautres ordinateurs, grce au rseau par exemple .

16.4.

Programmes applicatifs de base

Des programmes applicatifs de base offrent des services lutilisateur


(calculatrice, diteur de texte, navigateur web, etc.). Ces programmes
applicatifs sont souvent fournis en paquet promotionnel (bundle]) avec le
systme dexploitation. Certaines personnes estiment quils ne font pas
rellement partie du systme dexploitation. La sparation entre les
programmes applicatifs de base et le systme dexploitation est difficile
dfinir, du fait que lun devient inutile sans lautre, et que bon nombre
dapplications sont programmes en supposant que les programmes
applicatifs de base sont toujours prsents.

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

Une panne dun systme dexploitation peut tre un problme de dmarrage de la


machine, un problme de virus, un problme dinstallation dune application, un
problme avec un correctif de scurit, un problme de bibliothques, etc. Une base
de connaissance concernant le systme dexploitation devra tre disponible,
consultable par le technicien helpdesk. Laccs ces bases de connaissance connues
sous le nom FAQ (foire aux questions) est gnralement gratuit comme le service
Technet de Microsoft mais certains services sont payants. On peut citer des Faq
pour Windows server 2003, des Faq pour Windows XP, etc.

17. Renseignement de la fiche diagnostic ou


de la partie diagnostic de la fiche
dinterventions
Le terme fiche de diagnostic est envisag en tant que mmoire ou
compte-rendu .
Une fiche de diagnostic est un document dcrivant sommairement une
situation, des vnements ou des phnomnes.
Dans notre cas il sagit du technicien helpdesk qui doit renseigner la fiche de
diagnostic pour grer le dossier dincidence du client.que la panne soit
matriel, logiciel, ou panne de systme dapplication, la fiche laisse une
traabilit sur lincident du client soit que cette incident soit rsolu ou non.
Une fiche de diagnostic se prsente sous forme de formulaire qui contient
des champs : on peut y saisir du texte, cocher des cases, effectuer un choix
dans une liste de termes prdfinis.
Voici un exemple de fiche dintervention ou seule la partie diagnostic est
renseigne :
DIRECTION RECHERCHE ET INGENIERIE DE FORMATION
SECTEUR NTIC

ROYAUME DU MAROC

Pour approfondir le sujet.


Office
de la Formation
Professionnelle
et de la
Promotion
Proposition
de rfrences utiles
permettant dapprofondir
le thme
abord du Travail
Le site web : http://www.commentcamarche.net/

Sources de rfrence

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

ROYAUME DU MAROC

Office de la Formation Professionnelle et de la Promotion du Travail

DIRECTION RECHERCHE ET INGENIERIE DE FORMATION


SECTEUR NTIC

Diagnostiquer un problme

Sommaire
1.
2.

Introduction.....................................................................................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
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
3.

5.1.1.
Processus de consignation des problmes..................................10
5.2. Collecte des informations..............................................................13
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

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
1 - 99

Diagnostiquer un problme

18. 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.

19. Diagnostic matriel


19.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.

19.1.1.

La mthode des messages et des codes sonores

Les programmes d'application, le systme d'exploitation et l'ordinateur lui-mme,


sont capables d'identifier les problmes et de les mettre en exergue. Lorsque
cela se produit, un message apparat sur l'cran du moniteur.
Il met donc en relief qu'il y a soit un problme d'exploitation, soit un problme de
conflit entre un logiciel et un quipement donn. Ces messages sont multiples.
Mais les plus courants sont lists dans le tableau de l'annexe 1.
Au niveau des codes sonores, nous avons retenu que lorsque des erreurs ne
pouvant tre indiques sur l'cran surviennent au cours d'une procdure
d'initialisation, le POST (Power On Self Test ) c'est--dire au cours de l'autotest,

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
2 - 99

Diagnostiquer un problme
l'ordinateur met une srie de signaux sonores (bips ) identifiant le problme. Ce
code sonore est le profil des signaux.
Ainsi, un bip suivi d'un second et d'une rafale de trois bips (code 1-1-3) signifie
que l'ordinateur n'a pas pu lire les donnes dans la mmoire non volatile (NVRAM
). Les codes sonores tant varis, nous allons lister dans un tableau ceux qui
sont les plus souvent rencontrs sur les micro-ordinateurs (voir le tableau de
l'annexe 2).

19.1.2.

La mthode des diagnostics intgrs

Les diagnostics intgrs sont des programmes de dtection de pannes, intgrs


l'ordinateur par le constructeur. Ces programmes se trouvent dans la mmoire
flash et utiliss en premier lieu pour isoler les problmes de composants centraux
du systme, de la carte mre, du sous-systme de la mmoire et le soussystme de la mmoire cache.
Ces diagnostics intgrs sont utiliss mme si des composants du systme tels
que la mmoire, le clavier, les units et le BIOS ne fonctionnent pas. Tout comme
les diagnostics sur disquette, les diagnostics intgrs vrifient l'ordinateur sans
aucun composant supplmentaire et sans dtruire aucunes donnes. Ils gnrent
aussi des messages afin de mettre en relief les pannes dtectes dans
l'ordinateur.
Quand utiliser les diagnostics intgrs ?
Ils seront utiliss chaque fois qu'un problme survient dans le micro-ordinateur.
Au cas o les causes de la panne ne sont pas retrouves, alors on utilisera les
diagnostics sur disquette.
Dispositions prendre avant le lancement
Les diagnostics intgrs utilisent le sous-systme, vido intgr l'ordinateur
pour afficher les messages des diagnostics sur l'cran du moniteur. Il faut alors
dconnecter le moniteur de la carte d'extension vido et le connecter au soussystme vido intgr de faon pouvoir utiliser les diagnostics intgrs. Il faut
galement insrer une disquette formate dans l'unit de la disquette
dinitialisation avant d'excuter les diagnostics intgrs de sorte que le chemin
d'accs d'initialisation puisse tre test correctement.
Lancement des diagnostics intgrs
Au niveau de certains ordinateurs possdant un bouton spcial de diagnostic, le
lancement se fait tout simplement en appuyant sur celui-ci. Dans le cas
contraire, on appuiera sur le bouton de rinitialisation pendant une seconde
n'importe quel moment, aprs avoir allumer l'ordinateur. Ce dernier accde alors
aux diagnostics intgrs au lieu d'effectuer la procdure de dmarrage. Lorsque
les diagnostics commencent s'excuter, l'ordinateur lance trois codes sonores
en consquence rapide. Aprs quelques secondes, pendant lesquelles les
diagnostics intgrs testent le sous-systme vido intgr, un cran de
bienvenue apparat sur le moniteur. Celui-ci reste affich jusqu'au moment o on
presse le bouton de rinitialisation pour commencer l'excution des tests des
diagnostics intgrs. Si on ne veut pas excuter ces diagnostics, alors on teint
l'ordinateur et on le rallume.

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
3 - 99

Diagnostiquer un problme
Si un problme est dtect avant l'initialisation du sous-systme vido,
l'ordinateur peut mettre une srie de codes sonores identifiant le problme. Ces
codes tant varis nous allons lister les plus courants dans un tableau (annexe3)
Test des diagnostics intgrs
Dans les diagnostics intgrs, les tests sont organiss en groupe de tests et en
sous-groupes de tests l'intrieur de chaque groupe. Les tests effectus sur
chaque systme varient en fonction de l'quipement existant dans le systme.
Les tests de diagnostics sont conus pour dtecter avec prcision un composant
du systme en dfaillance.

19.1.3.
La mthode des mesures et les tests manuels des
composants
C'est la mthode au cours de laquelle on recherche les pannes d'une manire
manuelle. Ici, la recherche des pannes se fait par approche descendante, en
allant du gnral au particulier, du plus simple vers le plus compliqu. Tout
d'abord, on songera aux erreurs logicielles, aux mauvaises dclarations du setup,
aux connexions, aux cbles d'alimentation, aux interrupteurs. En suite on
songera aux priphriques, puis l'unit centrale.
Enfin, on procdera certains tests et mesures pour mieux cerner l'origine des
problmes.
Les tests comparatifs
Dans cette mthode aussi appele de substitution, un appareil ou une carte est
compare un appareil ou une carte identique et fonctionnant normalement. Il
s'agit d'une mthode matrielle et l'avantage de cette mthode vient du fait
qu'elle permet d'isoler rapidement le groupe en panne et de pouvoir le tester.
Mais la prsence d'un systme similaire est indispensable.
Cas des mesures
Dans cette mthode on aura besoins d'un ensemble d'outils (appareils) qui
permettra de faire les mesures, d'interprter et de vrifier les observations.
Comme appareils on aura besoin d'un multimtre, d'un oscilloscope, d'une sonde
logique, d'un analyseur logique et d'un testeur de composants.
Le multimtre
Les courts-circuits ou les circuits ouverts, les tensions errones sont les
problmes les plus connus. N'importe quel ohm-mtre peut tester les conditions
d'ouverture ou de court-circuit. Un multimtre digital ou un volt-ohm- milli
ampremtre suffisent pour tester les tensions et les courants.
Si les composants et le schma sont connus, il s'agit d'une opration simple mais
longue qui permet de s'assurer que chaque connexion est sa place et que les
bons courants sont obtenus avec des tensions correctes. Dans notre cas de
dpannage des micro-ordinateurs, il est mieux d'utiliser un multimtre digital
pour des raisons de confort de lecture.
Avec cet appareil, on pourra alors contrler les rsistances, les condensateurs,
les diodes et les transistors pour dterminer s'ils sont fonctionnels ou non. Voir
schmas ci-dessous.
La sonde logique
Elle permet de vrifier rapidement les niveaux logiques, de faon isoler toute
anomalie. La sonde logique nous est utile dans le diagnostic des problmes poss
par les circuits logiques. Un signal tant reprsent par : soit un niveau haut (+

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
4 - 99

Diagnostiquer un problme
5 volts ) et un niveau bas (0 volt ), seule la sonde logique grce son indicateur
diode lectroluminescente ou d'une ampoule lectrique, le testeur indiquera
que le signal est 0 ou 1 ou indtermin. C'est l'instrument de mesure
qui permet de dterminer ou non et confirmer le bon fonctionnement d'un signal
sur un point de mesure (voir schmas ci-dessous )
L'oscilloscope.
Instrument de valeur, il trouve sa place dans un atelier de dpannage. A la
diffrence du multimtre, l'oscilloscope permet de mesurer l'amplitude et la
dure des signaux. on peut suivre alors les diffrents cycles d'une opration.
Avec les nouveaux microprocesseurs dont la vitesse varie entre 33 Mhz et 266
Mhz, pour visualiser les vnements, il faudra avoir un oscilloscope d'au moins
50 Mhz. Il existe deux grandes familles d'oscilloscopes dont :
- Les oscilloscopes analogiques qui sont plus adapts aux dpannages
des crans.
- Les oscilloscopes digitaux appropris aux dpannages des cartes
logiques (voir schmas ci-dessous.
- L'analyseur logique
C'est un appareil complexe qui permet d'afficher sur son cran simultanment
plusieurs signaux un instant prcis. L'analyseur logique se classe en deux
grandes catgories :
- Ceux qui mettent l'accent sur les informations de type timing qui sont
en fait des oscilloscopes multicanaux et qu'on utilise pour dtecter des
erreurs logiques, du bruit ou des problmes de niveaux logiques.
- Ceux qui donnent des informations d'tat et nous permettent de
visualiser le flux des informations dans le systme en examinant tous les
points importants du circuit sous forme binaire.
Ces analyseurs permettent de dtecter les erreurs de logiciels ou les erreurs
dues une interaction logiciel-matriel (voir schmas ci-dessous).

20. Mthodologie de rsolution des


problmes
Les spcificits des diverses mthodologies de rsolution des problmes
informatiques peuvent varier et les processus impliqus ne sont pas prcis.
Toutefois, la plupart des mthodologies partagent des processus et des
procdures communs qui font l'objet de cette rubrique. En fait, on peut affirmer
que toute mthodologie de rsolution des problmes fait appel des processus
et procdures communs, quel que soit le domaine : informatique, plomberie ou
mcanique automobile. Tout incident parcourt une srie de processus conus
pour rsoudre les problmes aussi rapidement et efficacement que possible.
Parmi ces processus, la classification, le test, la transmission et la cration de
rapports sont l'pine dorsale de toute mthodologie de rsolution des problmes.
Celle-ci voluera dans le temps en fonction des changements technologiques et
de l'mergence de nouveaux outils.

20.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

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
5 - 99

Diagnostiquer un problme
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.

20.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.

20.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.

20.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.

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
6 - 99

Diagnostiquer un problme
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.

21. Utilisateurs d'une mthodologie de


rsolution des problmes
Les services de support fonctionnent au sein d'une structure hirarchique
prcise. Lorsque des utilisateurs finaux signalent des incidents aux techniciens du
support technique, savoir le premier niveau du support technique, et que ceuxci ne peuvent pas les rsoudre, ils les transmettent au support technique de
deuxime niveau. Les ingnieurs de ce service ont des connaissances et des
comptences plus spcialises pour rsoudre les problmes. Lorsque cela est
ncessaire, les ingnieurs du support technique peuvent remonter leur tour le
problme au support de troisime niveau. Le problme est alors pris en charge
par des ingnieurs systme experts dots de comptences trs cibles.
Les architectes systme, les concepteurs et les planificateurs occupent le
quatrime niveau de la structure. Les ingnieurs systme peuvent faire appel aux
architectes systme et planificateurs de niveau 4 pour concevoir et planifier des
modifications importantes apporter une infrastructure dues la rsolution
d'un problme.
Une mthodologie de rsolution des problmes bien conue peut bnficier
nombre de personnes au sein de votre organisation, et pas seulement aux
techniciens d'un service de support technique.

21.1.

Utilisateurs finaux

Les utilisateurs finaux travaillent dans le cadre de la mthodologie dfinie. Ils


reoivent une formation sur le matriel et les logiciels qu'ils utilisent. De plus, le
personnel du support technique leur fournit des documents d'auto-assistance qui
leur permettront de rechercher des solutions tout seuls. Ces documents peuvent
prendre la forme de documentation imprime, de didacticiels en ligne ou de
guides rpertoriant les questions frquemment poses.
La mise disposition de documents d'auto-assistance aux utilisateurs finaux
constitue une partie importante de la mthodologie de rsolution des problmes.
L'utilisateur a les moyens de rsoudre des problmes sans contacter le support
technique.
La mthodologie de rsolution des problmes dfinit le processus de rsolution
des problmes, les procdures de transmission et le type de communication
qu'un utilisateur final peut attendre du support technique. Elle profite
l'utilisateur final, car celui-ci ne passe que par un point de contact pour rsoudre
les problmes et le service de support technique doit tenir l'utilisateur inform de
la progression de la rsolution. Lorsqu'un problme ne peut pas tre rgl par
auto-assistance, l'utilisateur final contacte le support technique.

21.2.

Spcialistes du support technique

Les spcialistes du support technique fournissent le premier niveau d'assistance


aux utilisateurs finaux. En tant que premier point de contact des utilisateurs
Document
Millsime
Page
OFPPT
janvier 09
319479686
7 - 99
@

Diagnostiquer un problme
finaux, ils travaillent dans le cadre de la mthodologie de rsolution des
problmes pour dfinir la nature du problme qui leur est signal. Les
spcialistes du service de support technique ont en gnral plus de comptences
en matire de support technique que les ingnieurs du support technique.
Lorsque les spcialistes de service de support technique ne peuvent pas rsoudre
un problme dans le laps de temps dfini par l'utilisateur, c'est eux qu'il
incombe de transmettre le problme au support technique de deuxime niveau
ou aux fournisseurs externes. La mthodologie de rsolution des problmes
profite aux spcialistes du support technique dans la mesure o elle dfinit
clairement les processus qu'ils doivent utiliser pour dfinir les problmes, tablir
leur priorit, les transmettre et les rsoudre.

21.3.

Ingnieurs du support technique

Les ingnieurs du support technique assurent le support de deuxime niveau au


sein d'une organisation. En gnral, ils travaillent sur les problmes que les
spcialistes du support technique leur ont transmis. La mthodologie de
rsolution des problmes bnficie aux ingnieurs du support technique dans la
mesure o ils peuvent se concentrer sur les causes probables que les spcialistes
auront dfinies, sans perdre de temps sur la collecte des informations de base.
Les ingnieurs du support technique sont essentiellement chargs de rsoudre
des problmes que les utilisateurs finaux ont signals. Ils travaillent dans le
cadre de la mthodologie de rsolution des problmes et contribuent galement
son dveloppement.
Certains ingnieurs du support technique se spcialisent dans un domaine de
l'infrastructure informatique de l'organisation, alors que d'autres fournissent une
assistance gnrale plus dtaille que ne proposent pas les spcialistes du
support technique. Par exemple, un ingnieur du support technique peut se
spcialiser dans les problmes de rseau ou d'infrastructure de messagerie.

21.4.

Responsables et planificateurs

Les gestionnaires et les planificateurs travaillent en dehors de la mthodologie de


rsolution des problmes, mais en tirent galement parti.
Comme le personnel de support technique des premier et deuxime niveaux
intgre ce qu'il a appris des problmes passs dans les mthodes conseilles
actuelles et documente les modifications qu'il a apportes aux systmes
informatiques, cela garantit que l'infrastructure informatique est efficace et
productive. Une documentation jour et exacte fournit aux planificateurs et aux
responsables une base solide sur laquelle prendre leurs dcisions relatives
l'infrastructure informatique.

22. tapes types d'une mthodologie de


rsolution des problmes
Lorsque vous commencez rsoudre un problme, il est important de savoir
clairement quelles tapes vous allez excuter.

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
8 - 99

Diagnostiquer un problme

22.1.

Consignation du problme

Le processus de consignation du problme dans un rapport commence lorsqu'un


utilisateur final appelle le support technique pour la premire fois. ce stade,
vous devez enregistrer les dtails du problme et poser des questions
pertinentes l'utilisateur en vue de dterminer l'tendue du problme. Les
rponses ces questions peuvent vous aider dterminer la priorit du
problme.
Il est important de tenir l'utilisateur final inform de la progression tout au long
du processus de rsolution des problmes. En outre, pendant l'tape de cration
de rapport, vous pouvez indiquer l'utilisateur ce qui va se passer.

22.1.1.

Processus de consignation des problmes

Il est important de veiller ce qu'un processus bien matris existe au sein de


votre organisation pour que les problmes soient consigns comme il faut.
Problme dtect
Le processus de signalement d'un problme dbute lorsque l'utilisateur final
dtecte un problme de matriel informatique, de systme d'exploitation ou
d'application.
L'utilisateur peut essayer de rsoudre le problme lui-mme ou contacter le
support technique. Si le problme est intermittent, l'utilisateur peut ne pas
prendre de mesure immdiate. Si le problme se reproduit, il est possible que
l'utilisateur prenne des mesures supplmentaires.
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.
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

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
9 - 99

Diagnostiquer un problme
informations relatives l'activit que vous, ou d'autres, avez effectue par
rapport au problme signal.
Classification et support initial
Aprs que l'utilisateur a contact le support technique, essayez de classifier le
problme et d'en dterminer l'importance et l'urgence. Pour ce faire, vous pouvez
poser des questions trs spcifiques l'utilisateur. Il peut s'agir de questions
comme celles-ci :
Qui d'autre a le mme problme ? Si le problme est rpandu, cela indique
un problme plus gnral moins susceptible d'tre propre l'ordinateur de
l'utilisateur. En outre, les problmes qui affectent beaucoup d'utilisateurs
sont plus urgents que ce touchant un seul utilisateur.
Quand avez-vous remarqu le problme pour la premire fois ? Il se peut
que l'ordinateur n'ait jamais fonctionn correctement. Il est trs utile de
savoir si l'ordinateur n'a jamais fonctionn correctement, car cela peut
indiquer un problme li au dploiement plutt qu' l'utilisation.
Est-ce que quelque chose a chang peu prs au mme moment o vous
avez remarqu le problme ? Si l'utilisateur a rcemment install de
nouvelles applications ou mis jour des pilotes et si le problme est
survenu aprs ces modifications, il est possible que les modifications aient
contribu au problme que l'utilisateur signale.
Au cours de cette phase, vous pouvez dterminer une cause probable du
problme signal, mais ne tirez pas de conclusions trop htives. Vous risquez
autrement de gaspiller beaucoup de temps et de ressources. Votre objectif
pendant cette phase est de dfinir le problme correctement.
Transmission
Lorsqu'un problme doit tre transmis un service de support technique de
niveau suprieur ou des fournisseurs externes, veillez consigner
suffisamment de dtails en vue de les transmettre. Il est trs utile qu'une
procdure de transmission soit clairement dfinie pour un maximum d'efficacit.
La procdure peut stipuler d'inclure les informations suivantes :
une description prcise du problme signal ;
un enregistrement de tous les messages d'erreur associs au problme ;
un enregistrement des tentatives de rsolution faites par les membres du
support technique ainsi que le rsultat de chaque tentative ;
un enregistrement concernant tous les outils de diagnostic utiliss par les
membres du support technique ;
la dure pouvant s'couler avant qu'il y ait obligation de transmettre un
problme.
Vous pouvez considrer de transmettre le problme aux fournisseurs externes
dans les cas suivants :
vous ne pouvez rsoudre le problme ;
vous ne disposez pas de suffisamment de ressources internes pour rsoudre le
problme ;
votre organisation n'a pas les comptences requises pour rsoudre le problme
;
vous avez identifi la cause probable du problme et elle provient d'un
composant tiers spcifique.
Document
Millsime
Page
OFPPT
janvier 09
319479686
10 - 99
@

Diagnostiquer un problme
Chaque fois que vous remontez un problme, restez-en toujours le propritaire
et utilisez l'enregistrement de base de donnes pour suivre la progression vers
une rsolution.
Assurez-vous galement que vous fournissez toute l'assistance ncessaire aux
autres niveaux d'assistance et aux fournisseurs externes.
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.

22.2.

Collecte des informations

Il est possible que vous puissiez rsoudre le problme signal pendant l'tape
initiale de cration de rapport. Ceci est particulirement vrai dans le cas de
problmes relativement simples. Si vous ne parvenez pas rsoudre
immdiatement le problme, vous devez rassembler le plus d'informations
possible propos du problme dans le but d'identifier les causes possibles. Vous
pouvez utiliser des outils d'analyse, consulter des journaux des vnements ou
simplement poser des questions supplmentaires l'utilisateur pour recueillir
davantage d'informations.

22.2.1.

Processus de collecte initiale des donnes

La phase de collecte des informations relatives un problme signal est trs


importante.
En suivant une srie d'tapes prcise et logique, vous pouvez dfinir clairement
la nature du problme et parvenir dterminer une cause prcise.
Questionner

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
11 - 99

Diagnostiquer un problme

Le processus dmarre lorsqu'un utilisateur contacte le support technique en


suivant une procdure dfinie. Il peut tablir ce contact initial par le biais de la
messagerie lectronique, du tlphone ou de tout autre moyen. En tant que
membre du service du support technique, vous devez poser des questions claires
et prcises l'utilisateur sur les symptmes du problme afin de pouvoir
commencer en dfinir la cause. Il est galement important de consigner le
problme dans une base de donnes. Vous utiliserez cet enregistrement tout au
long du cycle de vie du problme pour suivre sa progression jusqu' sa
rsolution.
couter
Lorsqu'un utilisateur final vous signale un problme, coutez-le attentivement. Il
arrive souvent que lorsquun utilisateur rpond vos questions et relate
l'historique d'un problme, celui-ci en rvle involontairement la cause. En
demandant l'utilisateur de commencer depuis le dbut et d'expliquer
exactement ce qu'il faisait immdiatement avant de remarquer le problme et
pendant qu'il l'a remarqu, vous pouvez parfois dterminer la cause du
problme.
Consulter
Lorsque vous avez enregistr toutes les informations pertinentes fournies par
l'utilisateur, la tche suivante consiste dterminer la cause du problme
signal. Commencez par consulter la documentation concernant les problmes
connus que vous avez disposition.
Il est possible que le problme se soit dj produit. Si tel est le cas, vous pouvez
parvenir une rsolution et une clture rapides de l'incident.
Rechercher
Si la documentation existante ne vous permet pas d'tablir de causes probables,
vous devez mener quelques recherches dans diverses sources. Par exemple, vous
pouvez effectuer des recherches dans la Base de connaissances de support
Microsoft ou dans des forums en ligne.
Dvelopper
Une fois que vous avez dtermin une cause probable du problme, vous devez
dvelopper un plan d'action.

22.3.

Dveloppement d'un plan d'action

Lorsque vous avez suffisamment d'informations, vous tentez de dterminer la


cause du problme. Il existe deux approches possibles :
L'approche linaire est une mthodologie qui rvle rapidement la cause
principale d'un problme, car elle implique de suivre une srie logique
d'tapes. Prenez pour point de dpart ce que l'utilisateur final a dit et

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
12 - 99

Diagnostiquer un problme
continuez de faon mthodique jusqu' ce que vous dcouvriez la source
du problme.
L'approche soustractive est une mthodologie dans laquelle vous vous
reprsentez mentalement les composants systme de l'ordinateur.
Sparez les composants en deux le long d'une ligne que vous pouvez
tester. Par exemple, le problme est-il d un composant matriel ou un
composant rseau ?
Effectuez ensuite un test pour voir de quel ct de la ligne le problme se situe,
puis continuez de la mme manire jusqu' ce que vous ayez isol le composant
qui pose problme.
Quelle que soit l'approche pour laquelle vous optez, l'objectif de cette tape est
d'isoler la cause du problme. Lorsque vous pensez l'avoir dtermine, vous
devez tester vos hypothses. Si les tests s'avrent concluants, continuez jusqu'
ce que vous ayez dtermin la cause relle.
Une fois que vos tests ont rvl la cause d'un problme, vous devez planifier les
actions suivantes. Par exemple, si le problme implique le remplacement d'un
disque du serveur, vous devez commander le nouveau disque, dterminer une
heure approprie pour effectuer le remplacement, sauvegarder les donnes
prsentes sur le disque remplacer, arrter le serveur, installer physiquement le
nouveau disque et excuter une restauration des donnes sur celui-ci.

22.3.1.
Mthodes conseilles de dveloppement d'un plan
d'action
Les problmes simples sont faciles rsoudre rapidement et leur plan d'action
peut ne pas demander beaucoup de rflexion. Par exemple, si un utilisateur final
signale qu'il a oubli son mot de passe, votre plan d'action consiste ouvrir
Utilisateurs et ordinateurs Active
Directory et rinitialiser le mot de passe. Toutefois, les problmes plus graves
ou plus complexes exigent une certaine rflexion.
Analyser les donnes disponibles
Avant de commencer modifier la configuration, analysez les donnes
disponibles pour vous assurer que vous avez dtermin la cause probable du
problme signal.
Consulter la documentation
Consultez toute la documentation relative au correctif que vous envisagez de
mettre en uvre. Par exemple, si celui-ci requiert l'installation d'un Service Pack,
examinez la documentation relative au Service Pack.
Crer un environnement de test
Si le correctif envisag ou la solution de contournement implique une
reconfiguration significative ou si des problmes surviennent pendant la mise en
uvre du correctif, la productivit des utilisateurs pourrait s'en trouver affecte.
Il est important que vous criez un environnement de test qui ressemble
troitement au systme de production et l'utilisiez pour tester votre plan
d'action. Les technologies de virtualisation (telle que Microsoft Virtual PC) offrent

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
13 - 99

Diagnostiquer un problme
un moyen pratique de crer des environnements de test sans requrir
d'investissements majeurs dans du matriel ou des logiciels supplmentaires.
Considrer l'impact des modifications
Vous pouvez tre amen effectuer un important travail de reconfiguration pour
rsoudre des problmes complexes. Les modifications que vous envisagez
peuvent avoir une incidence sur de nombreux lments de votre organisation.
Par exemple, si le correctif que vous projetez d'implmenter ncessite le
redmarrage d'un serveur auquel les utilisateurs sont connects, tel qu'un
serveur de messagerie ou un serveur de base de donnes, vous devez prvoir
l'implmentation du correctif en dehors des heures ouvres.
En outre, vous devez vrifier que les modifications proposes ne nuiront pas aux
autres applications ou services.
Prvoir une restauration
Si vous implmentez un correctif ou solution de contournement qui ne rsout pas
le problme, vous pouvez envisager de revenir en arrire. L'excution d'une
restauration n'est pas ncessaire, mais peut tre souhaitable dans des
circonstances particulires.
Par exemple, si le correctif implique l'application d'une mise jour, la
suppression de la mise jour peut tre acceptable. Toutefois, si le correctif
implique la mise niveau d'applications pour inclure de nouvelles fonctionnalits
qui peuvent tre utiles aux utilisateurs finaux, il peut tre souhaitable de laisser
les nouvelles applications installes plutt que de rtablir l'application plus
ancienne. Vous pouvez utiliser l'environnement de test pour vous entraner
annuler un correctif ou une solution de contournement propos.

22.4.

Implmentation du plan d'action

Aprs avoir mis au point un plan d'action, vous devez l'implmenter. Lorsque
vous implmentez un plan d'action en vue de rsoudre des problmes graves,
vous devez considrer l'impact des modifications que vous prvoyez d'apporter
sur la disponibilit des services. Les grandes organisations ont des procdures de
gestion des modifications auxquelles vous devez vous conformer.
Avant de modifier la configuration, valuez quels aspects de la reconfiguration
vous pouvez raliser distance avec des outils d'administration et des utilitaires.
Vous pouvez rsoudre beaucoup de problmes avec des techniques de gestion
distance pour viter de vous rendre sur l'ordinateur de l'utilisateur. Toutefois,
certains problmes ne peuvent pas tre rsolus l'aide de tels outils, et vous
devrez vous rendre sur l'ordinateur de l'utilisateur final.

22.4.1.

Processus d'implmentation d'un plan d'action

En gnral, votre plan d'action se composera des tapes suivantes. Toutefois,


n'oubliez pas que les tapes spcifiques de votre plan d'action peuvent varier en
raison de la complexit ou des circonstances d'un problme donn.
Implmenter dans un environnement de test

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
14 - 99

Diagnostiquer un problme
Avant de tenter de mettre en uvre un correctif sur le systme de production,
implmentez votre plan d'action dans un environnement de test. Gardez l'esprit
que le processus de modification de quelques aspects de la configuration d'un
ordinateur peut rsoudre un problme spcifique, mais peut introduire d'autres
problmes. Ainsi, si vous appliquez une mise jour de scurit au systme
d'exploitation pour rsoudre un problme de scurit, celle-ci peut modifier le
comportement de certaines applications.
Lorsque vous tes satisfait que le correctif ou la solution de contournement
puisse tre implment sans provoquer de problmes supplmentaires et qu'il
rsout le problme signal, passez l'tape suivante. Les problmes simples
peuvent ne pas requrir cette tape de test.
Analyser l'impact possible
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.
Se reporter la gestion des modifications
Les grandes organisations implmentent des procdures de gestion des
modifications pour garantir que le personnel de support technique apporte des
modifications l'infrastructure informatique conformment aux instructions et
qu'il les documente suffisamment une fois effectues. Si votre organisation utilise
une telle procdure, vous devez dterminer ce qui est requis de vous lors de
l'implmentation du correctif ou de la solution de contournement. Consultez la
documentation adquate, et lorsque cela est ncessaire, discutez des
modifications proposes avec les personnes appropries.
Rsoudre le problme
Les spcialistes du support technique peuvent souvent rsoudre rapidement les
problmes les plus courants, sans faire appel aux spcialistes des produits. Les
problmes moins courants ou plus complexes requirent souvent l'intervention
de spcialistes de support technique ou de fournisseurs externes, et parfois la
cration d'une quipe spcialise regroupant les comptences ncessaires la
rsolution d'un problme particulier. Lorsque cela est possible, considrez
l'utilisation des outils et des utilitaires d'administration distance, car ceux-ci
permettent souvent de trouver des solutions plus rapidement.
Surveiller et valuer

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
15 - 99

Diagnostiquer un problme
Si un correctif ou une solution de contournement est susceptible de prendre
plusieurs heures et d'impliquer plusieurs tapes, vous devez surveiller la
progression du processus de rsolution du problme. Il est important que vous
valuiez les donnes collectes lors de ce processus pour dterminer si vous tes
sur le point de trouver une solution. Si les donnes ne vous permettent pas de
l'affirmer, envisagez de revoir votre plan d'action.
Rendre compte et documenter
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.

22.5.

Documentation de la rsolution

Lorsque vous avez rsolu le problme, vous devez documenter sa rsolution.


Cette tche implique un de nombre processus qui varie en fonction de
l'infrastructure du support technique. Au minimum, vous devez informer
l'utilisateur final que vous avez rsolu le problme. Si un systme de
consignation est en place, vous devez clore l'incident.
Beaucoup d'organisations s'appuient sur la documentation pour fournir des
informations relatives la configuration de leurs systmes informatiques. Si vous
avez procd une reconfiguration pour rsoudre un problme, vous devez
mettre jour la documentation de support pour reflter les modifications
apportes.
En outre, lors de la phase de collecte des informations, il est souvent utile de
consulter les journaux d'incident, qu'un problme similaire ait t signal ou non
par quelqu'un d'autre.
Savoir si un autre technicien a document des problmes similaires n'est possible
que si, la clture de l'incident, vous documentez ce que vous avez fait pour
rsoudre le problme.

22.5.1.

Processus de consignation de la rsolution

Dans la plupart des organisations de support, un processus existe pour


enregistrer et documenter un problme signal par un utilisateur. En gnral, le
personnel du support technique consigne l'incident signal dans une base de
donnes. Lorsqu'un problme est rsolu, vous devez clore l'incident et en
informer l'utilisateur qu'il l'a signal.
Mettre jour la documentation actuelle
Si le problme a rvl des failles dans l'infrastructure informatique actuelle,
dans les mthodes de travail ou dans d'autres domaines, vous devez mettre
jour la documentation actuelle pour faire tat de ces failles et des correctifs ou
solutions de contournement appropris. Par exemple, si vous installez un Service
Pack pour un systme d'exploitation dans toute l'organisation pour rsoudre un
problme d'incompatibilit entre applications, vous devez enregistrer les

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
16 - 99

Diagnostiquer un problme
informations se rapportant ce problme ainsi que la procdure d'installation du
Service Pack dans la documentation relative l'infrastructure.
Crer une nouvelle documentation
Les problmes graves et complexes entranent souvent des modifications
d'infrastructure majeures. Vous devez crer la documentation ncessaire pour
prendre en charge ces modifications. Par exemple, si vous installez une nouvelle
version d'une application pour rsoudre un problme, mettre jour la
documentation existante ne suffit pas. La nouvelle version de l'application peut
comporter de nouvelles fonctionnalits et peut fonctionner diffremment de
l'ancienne version. Vous devez communiquer aux utilisateurs et aux
administrateurs qu'ils doivent dsormais travailler sur la nouvelle version.
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.
Communiquer avec l'utilisateur final
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.
Consigner des mesures prventives
Un problme ayant tendance se rpter, il est essentiel que vous le
documentiez ainsi que sa cause et les tapes qui ont permis de le rsoudre. Une
documentation adquate garantit que les ingnieurs de support technique qui
seront confronts au mme problme puissent dcouvrir une cause probable et
une solution recommande tt dans le processus de rsolution.
Mettre laccent sur un point particulier
Note dattention particulire.

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
17 - 99

Diagnostiquer un problme

Pour approfondir le sujet.


Proposition de rfrences utiles permettant dapprofondir le thme abord

Sources de rfrence
Citer les auteurs et les sources de rfrence utilises pour llaboration du support

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
18 - 99

Diagnostiquer un problme

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
19 - 99

Sommaire
1.
2.

Introduction.....................................................................................2
Mthodologie de rsolution des problmes............................................2
2.1. Classification.................................................................................2
2.2. Test.............................................................................................2
2.3. Transmission.................................................................................3
2.4. Rapport........................................................................................3
3.
Utilisateurs d'une mthodologie de rsolution des problmes..................3
3.1. Utilisateurs finaux..........................................................................4
3.2. Spcialistes du support technique....................................................4
3.3. Ingnieurs du support technique......................................................4
3.4. Responsables et planificateurs.........................................................5
4.
tapes types d'une mthodologie de rsolution des problmes................5
4.1. Consignation du problme...............................................................5
4.1.1.
Processus de consignation des problmes....................................5
4.2. Collecte des informations................................................................8
4.2.1.
Processus de collecte initiale des donnes...................................8
4.3. Dveloppement d'un plan d'action....................................................9
4.3.1.
Mthodes conseilles de dveloppement d'un plan d'action............9
4.4. Implmentation du plan d'action....................................................11
4.4.1.
Processus d'implmentation d'un plan d'action...........................11
4.5. Documentation de la rsolution......................................................12
4.5.1.

Processus de consignation de la rsolution.................................13

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
1 - 99

Assurer la rsolution du problme

23.

Introduction

Le dveloppement et l'utilisation d'une mthodologie de rsolution des problmes


vous aideront diagnostiquer et rsoudre plus rapidement et plus facilement
les problmes lis au fonctionnement des ordinateurs. Dans ce module, vous
allez dcrire, dvelopper et appliquer une mthodologie de rsolution des
problmes. Vous allez galement expliquer quoi sert une telle mthodologie et
les avantages qu'elle prsente pour votre organisation.

24. Mthodologie de rsolution des


problmes
Les spcificits des diverses mthodologies de rsolution des problmes
informatiques peuvent varier et les processus impliqus ne sont pas prcis.
Toutefois, la plupart des mthodologies partagent des processus et des
procdures communs qui font l'objet de cette rubrique. En fait, on peut affirmer
que toute mthodologie de rsolution des problmes fait appel des processus
et procdures communs, quel que soit le domaine : informatique, plomberie ou
mcanique automobile. Tout incident parcourt une srie de processus conus
pour rsoudre les problmes aussi rapidement et efficacement que possible.
Parmi ces processus, la classification, le test, la transmission et la cration de
rapports sont l'pine dorsale de toute mthodologie de rsolution des problmes.
Celle-ci voluera dans le temps en fonction des changements technologiques et
de l'mergence de nouveaux outils.

24.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.

24.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
Document
Millsime
Page
OFPPT
janvier 09
319479686
2 - 99
@

Assurer la rsolution du problme


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.

24.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.

24.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.

25. Utilisateurs d'une mthodologie de


rsolution des problmes
Les services de support fonctionnent au sein d'une structure hirarchique
prcise. Lorsque des utilisateurs finaux signalent des incidents aux techniciens du
support technique, savoir le premier niveau du support technique, et que ceuxci ne peuvent pas les rsoudre, ils les transmettent au support technique de
deuxime niveau. Les ingnieurs de ce service ont des connaissances et des
comptences plus spcialises pour rsoudre les problmes. Lorsque cela est
ncessaire, les ingnieurs du support technique peuvent remonter leur tour le
problme au support de troisime niveau. Le problme est alors pris en charge
par des ingnieurs systme experts dots de comptences trs cibles.
Les architectes systme, les concepteurs et les planificateurs occupent le
quatrime niveau de la structure. Les ingnieurs systme peuvent faire appel aux
architectes systme et planificateurs de niveau 4 pour concevoir et planifier des

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
3 - 99

Assurer la rsolution du problme


modifications importantes apporter une infrastructure dues la rsolution
d'un problme.
Une mthodologie de rsolution des problmes bien conue peut bnficier
nombre de personnes au sein de votre organisation, et pas seulement aux
techniciens d'un service de support technique.

25.1.

Utilisateurs finaux

Les utilisateurs finaux travaillent dans le cadre de la mthodologie dfinie. Ils


reoivent une formation sur le matriel et les logiciels qu'ils utilisent. De plus, le
personnel du support technique leur fournit des documents d'auto-assistance qui
leur permettront de rechercher des solutions tout seuls. Ces documents peuvent
prendre la forme de documentation imprime, de didacticiels en ligne ou de
guides rpertoriant les questions frquemment poses.
La mise disposition de documents d'auto-assistance aux utilisateurs finaux
constitue une partie importante de la mthodologie de rsolution des problmes.
L'utilisateur a les moyens de rsoudre des problmes sans contacter le support
technique.
La mthodologie de rsolution des problmes dfinit le processus de rsolution
des problmes, les procdures de transmission et le type de communication
qu'un utilisateur final peut attendre du support technique. Elle profite
l'utilisateur final, car celui-ci ne passe que par un point de contact pour rsoudre
les problmes et le service de support technique doit tenir l'utilisateur inform de
la progression de la rsolution. Lorsqu'un problme ne peut pas tre rgl par
auto-assistance, l'utilisateur final contacte le support technique.

25.2.

Spcialistes du support technique

Les spcialistes du support technique fournissent le premier niveau d'assistance


aux utilisateurs finaux. En tant que premier point de contact des utilisateurs
finaux, ils travaillent dans le cadre de la mthodologie de rsolution des
problmes pour dfinir la nature du problme qui leur est signal. Les
spcialistes du service de support technique ont en gnral plus de comptences
en matire de support technique que les ingnieurs du support technique.
Lorsque les spcialistes de service de support technique ne peuvent pas rsoudre
un problme dans le laps de temps dfini par l'utilisateur, c'est eux qu'il
incombe de transmettre le problme au support technique de deuxime niveau
ou aux fournisseurs externes. La mthodologie de rsolution des problmes
profite aux spcialistes du support technique dans la mesure o elle dfinit
clairement les processus qu'ils doivent utiliser pour dfinir les problmes, tablir
leur priorit, les transmettre et les rsoudre.

25.3.

Ingnieurs du support technique

Les ingnieurs du support technique assurent le support de deuxime niveau au


sein d'une organisation. En gnral, ils travaillent sur les problmes que les
spcialistes du support technique leur ont transmis. La mthodologie de
rsolution des problmes bnficie aux ingnieurs du support technique dans la
mesure o ils peuvent se concentrer sur les causes probables que les spcialistes
auront dfinies, sans perdre de temps sur la collecte des informations de base.

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
4 - 99

Assurer la rsolution du problme


Les ingnieurs du support technique sont essentiellement chargs de rsoudre
des problmes que les utilisateurs finaux ont signals. Ils travaillent dans le
cadre de la mthodologie de rsolution des problmes et contribuent galement
son dveloppement.
Certains ingnieurs du support technique se spcialisent dans un domaine de
l'infrastructure informatique de l'organisation, alors que d'autres fournissent une
assistance gnrale plus dtaille que ne proposent pas les spcialistes du
support technique. Par exemple, un ingnieur du support technique peut se
spcialiser dans les problmes de rseau ou d'infrastructure de messagerie.

25.4.

Responsables et planificateurs

Les gestionnaires et les planificateurs travaillent en dehors de la mthodologie de


rsolution des problmes, mais en tirent galement parti.
Comme le personnel de support technique des premier et deuxime niveaux
intgre ce qu'il a appris des problmes passs dans les mthodes conseilles
actuelles et documente les modifications qu'il a apportes aux systmes
informatiques, cela garantit que l'infrastructure informatique est efficace et
productive. Une documentation jour et exacte fournit aux planificateurs et aux
responsables une base solide sur laquelle prendre leurs dcisions relatives
l'infrastructure informatique.

26. tapes types d'une mthodologie de


rsolution des problmes
Lorsque vous commencez rsoudre un problme, il est important de savoir
clairement quelles tapes vous allez excuter.

26.1.

Consignation du problme

Le processus de consignation du problme dans un rapport commence lorsqu'un


utilisateur final appelle le support technique pour la premire fois. ce stade,
vous devez enregistrer les dtails du problme et poser des questions
pertinentes l'utilisateur en vue de dterminer l'tendue du problme. Les
rponses ces questions peuvent vous aider dterminer la priorit du
problme.
Il est important de tenir l'utilisateur final inform de la progression tout au long
du processus de rsolution des problmes. En outre, pendant l'tape de cration
de rapport, vous pouvez indiquer l'utilisateur ce qui va se passer.

26.1.1.

Processus de consignation des problmes

Il est important de veiller ce qu'un processus bien matris existe au sein de


votre organisation pour que les problmes soient consigns comme il faut.
Problme dtect

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
5 - 99

Assurer la rsolution du problme


Le processus de signalement d'un problme dbute lorsque l'utilisateur final
dtecte un problme de matriel informatique, de systme d'exploitation ou
d'application.
L'utilisateur peut essayer de rsoudre le problme lui-mme ou contacter le
support technique. Si le problme est intermittent, l'utilisateur peut ne pas
prendre de mesure immdiate. Si le problme se reproduit, il est possible que
l'utilisateur prenne des mesures supplmentaires.
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.
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.
Classification et support initial
Aprs que l'utilisateur a contact le support technique, essayez de classifier le
problme et d'en dterminer l'importance et l'urgence. Pour ce faire, vous pouvez
poser des questions trs spcifiques l'utilisateur. Il peut s'agir de questions
comme celles-ci :
Qui d'autre a le mme problme ? Si le problme est rpandu, cela indique
un problme plus gnral moins susceptible d'tre propre l'ordinateur de
l'utilisateur. En outre, les problmes qui affectent beaucoup d'utilisateurs
sont plus urgents que ce touchant un seul utilisateur.
Quand avez-vous remarqu le problme pour la premire fois ? Il se peut
que l'ordinateur n'ait jamais fonctionn correctement. Il est trs utile de
savoir si l'ordinateur n'a jamais fonctionn correctement, car cela peut
indiquer un problme li au dploiement plutt qu' l'utilisation.
Est-ce que quelque chose a chang peu prs au mme moment o vous
avez remarqu le problme ? Si l'utilisateur a rcemment install de
Document
Millsime
Page
OFPPT
janvier 09
319479686
6 - 99
@

Assurer la rsolution du problme


nouvelles applications ou mis jour des pilotes et si le problme est
survenu aprs ces modifications, il est possible que les modifications aient
contribu au problme que l'utilisateur signale.
Au cours de cette phase, vous pouvez dterminer une cause probable du
problme signal, mais ne tirez pas de conclusions trop htives. Vous risquez
autrement de gaspiller beaucoup de temps et de ressources. Votre objectif
pendant cette phase est de dfinir le problme correctement.
Transmission
Lorsqu'un problme doit tre transmis un service de support technique de
niveau suprieur ou des fournisseurs externes, veillez consigner
suffisamment de dtails en vue de les transmettre. Il est trs utile qu'une
procdure de transmission soit clairement dfinie pour un maximum d'efficacit.
La procdure peut stipuler d'inclure les informations suivantes :
une description prcise du problme signal ;
un enregistrement de tous les messages d'erreur associs au problme ;
un enregistrement des tentatives de rsolution faites par les membres du
support technique ainsi que le rsultat de chaque tentative ;
un enregistrement concernant tous les outils de diagnostic utiliss par les
membres du support technique ;
la dure pouvant s'couler avant qu'il y ait obligation de transmettre un
problme.
Vous pouvez considrer de transmettre le problme aux fournisseurs externes
dans les cas suivants :
vous ne pouvez rsoudre le problme ;
vous ne disposez pas de suffisamment de ressources internes pour rsoudre le
problme ;
votre organisation n'a pas les comptences requises pour rsoudre le problme
;
vous avez identifi la cause probable du problme et elle provient d'un
composant tiers spcifique.
Chaque fois que vous remontez un problme, restez-en toujours le propritaire
et utilisez l'enregistrement de base de donnes pour suivre la progression vers
une rsolution.
Assurez-vous galement que vous fournissez toute l'assistance ncessaire aux
autres niveaux d'assistance et aux fournisseurs externes.
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 ;

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
7 - 99

Assurer la rsolution du problme

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.

26.2.

Collecte des informations

Il est possible que vous puissiez rsoudre le problme signal pendant l'tape
initiale de cration de rapport. Ceci est particulirement vrai dans le cas de
problmes relativement simples. Si vous ne parvenez pas rsoudre
immdiatement le problme, vous devez rassembler le plus d'informations
possible propos du problme dans le but d'identifier les causes possibles. Vous
pouvez utiliser des outils d'analyse, consulter des journaux des vnements ou
simplement poser des questions supplmentaires l'utilisateur pour recueillir
davantage d'informations.

26.2.1.

Processus de collecte initiale des donnes

La phase de collecte des informations relatives un problme signal est trs


importante.
En suivant une srie d'tapes prcise et logique, vous pouvez dfinir clairement
la nature du problme et parvenir dterminer une cause prcise.
Questionner
Le processus dmarre lorsqu'un utilisateur contacte le support technique en
suivant une procdure dfinie. Il peut tablir ce contact initial par le biais de la
messagerie lectronique, du tlphone ou de tout autre moyen. En tant que
membre du service du support technique, vous devez poser des questions claires
et prcises l'utilisateur sur les symptmes du problme afin de pouvoir
commencer en dfinir la cause. Il est galement important de consigner le
problme dans une base de donnes. Vous utiliserez cet enregistrement tout au
long du cycle de vie du problme pour suivre sa progression jusqu' sa
rsolution.
couter
Lorsqu'un utilisateur final vous signale un problme, coutez-le attentivement. Il
arrive souvent que lorsquun utilisateur rpond vos questions et relate
l'historique d'un problme, celui-ci en rvle involontairement la cause. En
demandant l'utilisateur de commencer depuis le dbut et d'expliquer
exactement ce qu'il faisait immdiatement avant de remarquer le problme et

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
8 - 99

Assurer la rsolution du problme


pendant qu'il l'a remarqu, vous pouvez parfois dterminer la cause du
problme.
Consulter
Lorsque vous avez enregistr toutes les informations pertinentes fournies par
l'utilisateur, la tche suivante consiste dterminer la cause du problme
signal. Commencez par consulter la documentation concernant les problmes
connus que vous avez disposition.
Il est possible que le problme se soit dj produit. Si tel est le cas, vous pouvez
parvenir une rsolution et une clture rapides de l'incident.
Rechercher
Si la documentation existante ne vous permet pas d'tablir de causes probables,
vous devez mener quelques recherches dans diverses sources. Par exemple, vous
pouvez effectuer des recherches dans la Base de connaissances de support
Microsoft ou dans des forums en ligne.
Dvelopper
Une fois que vous avez dtermin une cause probable du problme, vous devez
dvelopper un plan d'action.

26.3.

Dveloppement d'un plan d'action

Lorsque vous avez suffisamment d'informations, vous tentez de dterminer la


cause du problme. Il existe deux approches possibles :
L'approche linaire est une mthodologie qui rvle rapidement la cause
principale d'un problme, car elle implique de suivre une srie logique
d'tapes. Prenez pour point de dpart ce que l'utilisateur final a dit et
continuez de faon mthodique jusqu' ce que vous dcouvriez la source
du problme.
L'approche soustractive est une mthodologie dans laquelle vous vous
reprsentez mentalement les composants systme de l'ordinateur.
Sparez les composants en deux le long d'une ligne que vous pouvez
tester. Par exemple, le problme est-il d un composant matriel ou un
composant rseau ?
Effectuez ensuite un test pour voir de quel ct de la ligne le problme se situe,
puis continuez de la mme manire jusqu' ce que vous ayez isol le composant
qui pose problme.
Quelle que soit l'approche pour laquelle vous optez, l'objectif de cette tape est
d'isoler la cause du problme. Lorsque vous pensez l'avoir dtermine, vous
devez tester vos hypothses. Si les tests s'avrent concluants, continuez jusqu'
ce que vous ayez dtermin la cause relle.
Une fois que vos tests ont rvl la cause d'un problme, vous devez planifier les
actions suivantes. Par exemple, si le problme implique le remplacement d'un
disque du serveur, vous devez commander le nouveau disque, dterminer une
heure approprie pour effectuer le remplacement, sauvegarder les donnes

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
9 - 99

Assurer la rsolution du problme


prsentes sur le disque remplacer, arrter le serveur, installer physiquement le
nouveau disque et excuter une restauration des donnes sur celui-ci.

26.3.1.
Mthodes conseilles de dveloppement d'un plan
d'action
Les problmes simples sont faciles rsoudre rapidement et leur plan d'action
peut ne pas demander beaucoup de rflexion. Par exemple, si un utilisateur final
signale qu'il a oubli son mot de passe, votre plan d'action consiste ouvrir
Utilisateurs et ordinateurs Active
Directory et rinitialiser le mot de passe. Toutefois, les problmes plus graves
ou plus complexes exigent une certaine rflexion.
Analyser les donnes disponibles
Avant de commencer modifier la configuration, analysez les donnes
disponibles pour vous assurer que vous avez dtermin la cause probable du
problme signal.
Consulter la documentation
Consultez toute la documentation relative au correctif que vous envisagez de
mettre en uvre. Par exemple, si celui-ci requiert l'installation d'un Service Pack,
examinez la documentation relative au Service Pack.
Crer un environnement de test
Si le correctif envisag ou la solution de contournement implique une
reconfiguration significative ou si des problmes surviennent pendant la mise en
uvre du correctif, la productivit des utilisateurs pourrait s'en trouver affecte.
Il est important que vous criez un environnement de test qui ressemble
troitement au systme de production et l'utilisiez pour tester votre plan
d'action. Les technologies de virtualisation (telle que Microsoft Virtual PC) offrent
un moyen pratique de crer des environnements de test sans requrir
d'investissements majeurs dans du matriel ou des logiciels supplmentaires.
Considrer l'impact des modifications
Vous pouvez tre amen effectuer un important travail de reconfiguration pour
rsoudre des problmes complexes. Les modifications que vous envisagez
peuvent avoir une incidence sur de nombreux lments de votre organisation.
Par exemple, si le correctif que vous projetez d'implmenter ncessite le
redmarrage d'un serveur auquel les utilisateurs sont connects, tel qu'un
serveur de messagerie ou un serveur de base de donnes, vous devez prvoir
l'implmentation du correctif en dehors des heures ouvres.
En outre, vous devez vrifier que les modifications proposes ne nuiront pas aux
autres applications ou services.
Prvoir une restauration

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
10 - 99

Assurer la rsolution du problme


Si vous implmentez un correctif ou solution de contournement qui ne rsout pas
le problme, vous pouvez envisager de revenir en arrire. L'excution d'une
restauration n'est pas ncessaire, mais peut tre souhaitable dans des
circonstances particulires.
Par exemple, si le correctif implique l'application d'une mise jour, la
suppression de la mise jour peut tre acceptable. Toutefois, si le correctif
implique la mise niveau d'applications pour inclure de nouvelles fonctionnalits
qui peuvent tre utiles aux utilisateurs finaux, il peut tre souhaitable de laisser
les nouvelles applications installes plutt que de rtablir l'application plus
ancienne. Vous pouvez utiliser l'environnement de test pour vous entraner
annuler un correctif ou une solution de contournement propos.

26.4.

Implmentation du plan d'action

Aprs avoir mis au point un plan d'action, vous devez l'implmenter. Lorsque
vous implmentez un plan d'action en vue de rsoudre des problmes graves,
vous devez considrer l'impact des modifications que vous prvoyez d'apporter
sur la disponibilit des services. Les grandes organisations ont des procdures de
gestion des modifications auxquelles vous devez vous conformer.
Avant de modifier la configuration, valuez quels aspects de la reconfiguration
vous pouvez raliser distance avec des outils d'administration et des utilitaires.
Vous pouvez rsoudre beaucoup de problmes avec des techniques de gestion
distance pour viter de vous rendre sur l'ordinateur de l'utilisateur. Toutefois,
certains problmes ne peuvent pas tre rsolus l'aide de tels outils, et vous
devrez vous rendre sur l'ordinateur de l'utilisateur final.

26.4.1.

Processus d'implmentation d'un plan d'action

En gnral, votre plan d'action se composera des tapes suivantes. Toutefois,


n'oubliez pas que les tapes spcifiques de votre plan d'action peuvent varier en
raison de la complexit ou des circonstances d'un problme donn.
Implmenter dans un environnement de test
Avant de tenter de mettre en uvre un correctif sur le systme de production,
implmentez votre plan d'action dans un environnement de test. Gardez l'esprit
que le processus de modification de quelques aspects de la configuration d'un
ordinateur peut rsoudre un problme spcifique, mais peut introduire d'autres
problmes. Ainsi, si vous appliquez une mise jour de scurit au systme
d'exploitation pour rsoudre un problme de scurit, celle-ci peut modifier le
comportement de certaines applications.
Lorsque vous tes satisfait que le correctif ou la solution de contournement
puisse tre implment sans provoquer de problmes supplmentaires et qu'il
rsout le problme signal, passez l'tape suivante. Les problmes simples
peuvent ne pas requrir cette tape de test.
Analyser l'impact possible
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

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
11 - 99

Assurer la rsolution du problme


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.
Se reporter la gestion des modifications
Les grandes organisations implmentent des procdures de gestion des
modifications pour garantir que le personnel de support technique apporte des
modifications l'infrastructure informatique conformment aux instructions et
qu'il les documente suffisamment une fois effectues. Si votre organisation utilise
une telle procdure, vous devez dterminer ce qui est requis de vous lors de
l'implmentation du correctif ou de la solution de contournement. Consultez la
documentation adquate, et lorsque cela est ncessaire, discutez des
modifications proposes avec les personnes appropries.
Rsoudre le problme
Les spcialistes du support technique peuvent souvent rsoudre rapidement les
problmes les plus courants, sans faire appel aux spcialistes des produits. Les
problmes moins courants ou plus complexes requirent souvent l'intervention
de spcialistes de support technique ou de fournisseurs externes, et parfois la
cration d'une quipe spcialise regroupant les comptences ncessaires la
rsolution d'un problme particulier. Lorsque cela est possible, considrez
l'utilisation des outils et des utilitaires d'administration distance, car ceux-ci
permettent souvent de trouver des solutions plus rapidement.
Surveiller et valuer
Si un correctif ou une solution de contournement est susceptible de prendre
plusieurs heures et d'impliquer plusieurs tapes, vous devez surveiller la
progression du processus de rsolution du problme. Il est important que vous
valuiez les donnes collectes lors de ce processus pour dterminer si vous tes
sur le point de trouver une solution. Si les donnes ne vous permettent pas de
l'affirmer, envisagez de revoir votre plan d'action.
Rendre compte et documenter
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.

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
12 - 99

Assurer la rsolution du problme

26.5.

Documentation de la rsolution

Lorsque vous avez rsolu le problme, vous devez documenter sa rsolution.


Cette tche implique un de nombre processus qui varie en fonction de
l'infrastructure du support technique. Au minimum, vous devez informer
l'utilisateur final que vous avez rsolu le problme. Si un systme de
consignation est en place, vous devez clore l'incident.
Beaucoup d'organisations s'appuient sur la documentation pour fournir des
informations relatives la configuration de leurs systmes informatiques. Si vous
avez procd une reconfiguration pour rsoudre un problme, vous devez
mettre jour la documentation de support pour reflter les modifications
apportes.
En outre, lors de la phase de collecte des informations, il est souvent utile de
consulter les journaux d'incident, qu'un problme similaire ait t signal ou non
par quelqu'un d'autre.
Savoir si un autre technicien a document des problmes similaires n'est possible
que si, la clture de l'incident, vous documentez ce que vous avez fait pour
rsoudre le problme.

26.5.1.

Processus de consignation de la rsolution

Dans la plupart des organisations de support, un processus existe pour


enregistrer et documenter un problme signal par un utilisateur. En gnral, le
personnel du support technique consigne l'incident signal dans une base de
donnes. Lorsqu'un problme est rsolu, vous devez clore l'incident et en
informer l'utilisateur qu'il l'a signal.
Mettre jour la documentation actuelle
Si le problme a rvl des failles dans l'infrastructure informatique actuelle,
dans les mthodes de travail ou dans d'autres domaines, vous devez mettre
jour la documentation actuelle pour faire tat de ces failles et des correctifs ou
solutions de contournement appropris. Par exemple, si vous installez un Service
Pack pour un systme d'exploitation dans toute l'organisation pour rsoudre un
problme d'incompatibilit entre applications, vous devez enregistrer les
informations se rapportant ce problme ainsi que la procdure d'installation du
Service Pack dans la documentation relative l'infrastructure.
Crer une nouvelle documentation
Les problmes graves et complexes entranent souvent des modifications
d'infrastructure majeures. Vous devez crer la documentation ncessaire pour
prendre en charge ces modifications. Par exemple, si vous installez une nouvelle
version d'une application pour rsoudre un problme, mettre jour la
documentation existante ne suffit pas. La nouvelle version de l'application peut
comporter de nouvelles fonctionnalits et peut fonctionner diffremment de
l'ancienne version. Vous devez communiquer aux utilisateurs et aux
administrateurs qu'ils doivent dsormais travailler sur la nouvelle version.
Consigner la rsolution

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
13 - 99

Assurer la rsolution du problme


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.
Communiquer avec l'utilisateur final
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.
Consigner des mesures prventives
Un problme ayant tendance se rpter, il est essentiel que vous le
documentiez ainsi que sa cause et les tapes qui ont permis de le rsoudre. Une
documentation adquate garantit que les ingnieurs de support technique qui
seront confronts au mme problme puissent dcouvrir une cause probable et
une solution recommande tt dans le processus de rsolution.

Mettre laccent sur un point particulier


Note dattention particulire.

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
14 - 99

Assurer la rsolution du problme

Pour approfondir le sujet.


Proposition de rfrences utiles permettant dapprofondir le thme abord

Sources de rfrence
Citer les auteurs et les sources de rfrence utilises pour llaboration du support

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
15 - 99

Assurer la rsolution du problme

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
16 - 99

Sommaire
1.
2.

Introduction.....................................................................................2
Mthodologie de rsolution des problmes............................................2
2.1. Classification.................................................................................2
2.2. Test.............................................................................................2
2.3. Transmission.................................................................................3
2.4. Rapport........................................................................................3
3.
Utilisateurs d'une mthodologie de rsolution des problmes..................3
3.1. Utilisateurs finaux..........................................................................4
3.2. Spcialistes du support technique....................................................4
3.3. Ingnieurs du support technique......................................................4
3.4. Responsables et planificateurs.........................................................5
4.
tapes types d'une mthodologie de rsolution des problmes................5
4.1. Consignation du problme...............................................................5
4.1.1.
Processus de consignation des problmes....................................5
4.2. Collecte des informations................................................................8
4.2.1.
Processus de collecte initiale des donnes...................................8
4.3. Dveloppement d'un plan d'action....................................................9
4.3.1.
Mthodes conseilles de dveloppement d'un plan d'action............9
4.4. Implmentation du plan d'action....................................................11
4.4.1.
Processus d'implmentation d'un plan d'action...........................11
4.5. Documentation de la rsolution......................................................12
4.5.1.

Processus de consignation de la rsolution.................................13

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
1 - 99

Assurer la rsolution du problme

27.

Introduction

Le dveloppement et l'utilisation d'une mthodologie de rsolution des problmes


vous aideront diagnostiquer et rsoudre plus rapidement et plus facilement
les problmes lis au fonctionnement des ordinateurs. Dans ce module, vous
allez dcrire, dvelopper et appliquer une mthodologie de rsolution des
problmes. Vous allez galement expliquer quoi sert une telle mthodologie et
les avantages qu'elle prsente pour votre organisation.

28. Mthodologie de rsolution des


problmes
Les spcificits des diverses mthodologies de rsolution des problmes
informatiques peuvent varier et les processus impliqus ne sont pas prcis.
Toutefois, la plupart des mthodologies partagent des processus et des
procdures communs qui font l'objet de cette rubrique. En fait, on peut affirmer
que toute mthodologie de rsolution des problmes fait appel des processus
et procdures communs, quel que soit le domaine : informatique, plomberie ou
mcanique automobile. Tout incident parcourt une srie de processus conus
pour rsoudre les problmes aussi rapidement et efficacement que possible.
Parmi ces processus, la classification, le test, la transmission et la cration de
rapports sont l'pine dorsale de toute mthodologie de rsolution des problmes.
Celle-ci voluera dans le temps en fonction des changements technologiques et
de l'mergence de nouveaux outils.

28.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.

28.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
Document
Millsime
Page
OFPPT
janvier 09
319479686
2 - 99
@

Assurer la rsolution du problme


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.

28.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.

28.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.

29. Utilisateurs d'une mthodologie de


rsolution des problmes
Les services de support fonctionnent au sein d'une structure hirarchique
prcise. Lorsque des utilisateurs finaux signalent des incidents aux techniciens du
support technique, savoir le premier niveau du support technique, et que ceuxci ne peuvent pas les rsoudre, ils les transmettent au support technique de
deuxime niveau. Les ingnieurs de ce service ont des connaissances et des
comptences plus spcialises pour rsoudre les problmes. Lorsque cela est
ncessaire, les ingnieurs du support technique peuvent remonter leur tour le
problme au support de troisime niveau. Le problme est alors pris en charge
par des ingnieurs systme experts dots de comptences trs cibles.
Les architectes systme, les concepteurs et les planificateurs occupent le
quatrime niveau de la structure. Les ingnieurs systme peuvent faire appel aux
architectes systme et planificateurs de niveau 4 pour concevoir et planifier des

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
3 - 99

Assurer la rsolution du problme


modifications importantes apporter une infrastructure dues la rsolution
d'un problme.
Une mthodologie de rsolution des problmes bien conue peut bnficier
nombre de personnes au sein de votre organisation, et pas seulement aux
techniciens d'un service de support technique.

29.1.

Utilisateurs finaux

Les utilisateurs finaux travaillent dans le cadre de la mthodologie dfinie. Ils


reoivent une formation sur le matriel et les logiciels qu'ils utilisent. De plus, le
personnel du support technique leur fournit des documents d'auto-assistance qui
leur permettront de rechercher des solutions tout seuls. Ces documents peuvent
prendre la forme de documentation imprime, de didacticiels en ligne ou de
guides rpertoriant les questions frquemment poses.
La mise disposition de documents d'auto-assistance aux utilisateurs finaux
constitue une partie importante de la mthodologie de rsolution des problmes.
L'utilisateur a les moyens de rsoudre des problmes sans contacter le support
technique.
La mthodologie de rsolution des problmes dfinit le processus de rsolution
des problmes, les procdures de transmission et le type de communication
qu'un utilisateur final peut attendre du support technique. Elle profite
l'utilisateur final, car celui-ci ne passe que par un point de contact pour rsoudre
les problmes et le service de support technique doit tenir l'utilisateur inform de
la progression de la rsolution. Lorsqu'un problme ne peut pas tre rgl par
auto-assistance, l'utilisateur final contacte le support technique.

29.2.

Spcialistes du support technique

Les spcialistes du support technique fournissent le premier niveau d'assistance


aux utilisateurs finaux. En tant que premier point de contact des utilisateurs
finaux, ils travaillent dans le cadre de la mthodologie de rsolution des
problmes pour dfinir la nature du problme qui leur est signal. Les
spcialistes du service de support technique ont en gnral plus de comptences
en matire de support technique que les ingnieurs du support technique.
Lorsque les spcialistes de service de support technique ne peuvent pas rsoudre
un problme dans le laps de temps dfini par l'utilisateur, c'est eux qu'il
incombe de transmettre le problme au support technique de deuxime niveau
ou aux fournisseurs externes. La mthodologie de rsolution des problmes
profite aux spcialistes du support technique dans la mesure o elle dfinit
clairement les processus qu'ils doivent utiliser pour dfinir les problmes, tablir
leur priorit, les transmettre et les rsoudre.

29.3.

Ingnieurs du support technique

Les ingnieurs du support technique assurent le support de deuxime niveau au


sein d'une organisation. En gnral, ils travaillent sur les problmes que les
spcialistes du support technique leur ont transmis. La mthodologie de
rsolution des problmes bnficie aux ingnieurs du support technique dans la
mesure o ils peuvent se concentrer sur les causes probables que les spcialistes
auront dfinies, sans perdre de temps sur la collecte des informations de base.

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
4 - 99

Assurer la rsolution du problme


Les ingnieurs du support technique sont essentiellement chargs de rsoudre
des problmes que les utilisateurs finaux ont signals. Ils travaillent dans le
cadre de la mthodologie de rsolution des problmes et contribuent galement
son dveloppement.
Certains ingnieurs du support technique se spcialisent dans un domaine de
l'infrastructure informatique de l'organisation, alors que d'autres fournissent une
assistance gnrale plus dtaille que ne proposent pas les spcialistes du
support technique. Par exemple, un ingnieur du support technique peut se
spcialiser dans les problmes de rseau ou d'infrastructure de messagerie.

29.4.

Responsables et planificateurs

Les gestionnaires et les planificateurs travaillent en dehors de la mthodologie de


rsolution des problmes, mais en tirent galement parti.
Comme le personnel de support technique des premier et deuxime niveaux
intgre ce qu'il a appris des problmes passs dans les mthodes conseilles
actuelles et documente les modifications qu'il a apportes aux systmes
informatiques, cela garantit que l'infrastructure informatique est efficace et
productive. Une documentation jour et exacte fournit aux planificateurs et aux
responsables une base solide sur laquelle prendre leurs dcisions relatives
l'infrastructure informatique.

30. tapes types d'une mthodologie de


rsolution des problmes
Lorsque vous commencez rsoudre un problme, il est important de savoir
clairement quelles tapes vous allez excuter.

30.1.

Consignation du problme

Le processus de consignation du problme dans un rapport commence lorsqu'un


utilisateur final appelle le support technique pour la premire fois. ce stade,
vous devez enregistrer les dtails du problme et poser des questions
pertinentes l'utilisateur en vue de dterminer l'tendue du problme. Les
rponses ces questions peuvent vous aider dterminer la priorit du
problme.
Il est important de tenir l'utilisateur final inform de la progression tout au long
du processus de rsolution des problmes. En outre, pendant l'tape de cration
de rapport, vous pouvez indiquer l'utilisateur ce qui va se passer.

30.1.1.

Processus de consignation des problmes

Il est important de veiller ce qu'un processus bien matris existe au sein de


votre organisation pour que les problmes soient consigns comme il faut.
Problme dtect

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
5 - 99

Assurer la rsolution du problme


Le processus de signalement d'un problme dbute lorsque l'utilisateur final
dtecte un problme de matriel informatique, de systme d'exploitation ou
d'application.
L'utilisateur peut essayer de rsoudre le problme lui-mme ou contacter le
support technique. Si le problme est intermittent, l'utilisateur peut ne pas
prendre de mesure immdiate. Si le problme se reproduit, il est possible que
l'utilisateur prenne des mesures supplmentaires.
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.
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.
Classification et support initial
Aprs que l'utilisateur a contact le support technique, essayez de classifier le
problme et d'en dterminer l'importance et l'urgence. Pour ce faire, vous pouvez
poser des questions trs spcifiques l'utilisateur. Il peut s'agir de questions
comme celles-ci :
Qui d'autre a le mme problme ? Si le problme est rpandu, cela indique
un problme plus gnral moins susceptible d'tre propre l'ordinateur de
l'utilisateur. En outre, les problmes qui affectent beaucoup d'utilisateurs
sont plus urgents que ce touchant un seul utilisateur.
Quand avez-vous remarqu le problme pour la premire fois ? Il se peut
que l'ordinateur n'ait jamais fonctionn correctement. Il est trs utile de
savoir si l'ordinateur n'a jamais fonctionn correctement, car cela peut
indiquer un problme li au dploiement plutt qu' l'utilisation.
Est-ce que quelque chose a chang peu prs au mme moment o vous
avez remarqu le problme ? Si l'utilisateur a rcemment install de
Document
Millsime
Page
OFPPT
janvier 09
319479686
6 - 99
@

Assurer la rsolution du problme


nouvelles applications ou mis jour des pilotes et si le problme est
survenu aprs ces modifications, il est possible que les modifications aient
contribu au problme que l'utilisateur signale.
Au cours de cette phase, vous pouvez dterminer une cause probable du
problme signal, mais ne tirez pas de conclusions trop htives. Vous risquez
autrement de gaspiller beaucoup de temps et de ressources. Votre objectif
pendant cette phase est de dfinir le problme correctement.
Transmission
Lorsqu'un problme doit tre transmis un service de support technique de
niveau suprieur ou des fournisseurs externes, veillez consigner
suffisamment de dtails en vue de les transmettre. Il est trs utile qu'une
procdure de transmission soit clairement dfinie pour un maximum d'efficacit.
La procdure peut stipuler d'inclure les informations suivantes :
une description prcise du problme signal ;
un enregistrement de tous les messages d'erreur associs au problme ;
un enregistrement des tentatives de rsolution faites par les membres du
support technique ainsi que le rsultat de chaque tentative ;
un enregistrement concernant tous les outils de diagnostic utiliss par les
membres du support technique ;
la dure pouvant s'couler avant qu'il y ait obligation de transmettre un
problme.
Vous pouvez considrer de transmettre le problme aux fournisseurs externes
dans les cas suivants :
vous ne pouvez rsoudre le problme ;
vous ne disposez pas de suffisamment de ressources internes pour rsoudre le
problme ;
votre organisation n'a pas les comptences requises pour rsoudre le problme
;
vous avez identifi la cause probable du problme et elle provient d'un
composant tiers spcifique.
Chaque fois que vous remontez un problme, restez-en toujours le propritaire
et utilisez l'enregistrement de base de donnes pour suivre la progression vers
une rsolution.
Assurez-vous galement que vous fournissez toute l'assistance ncessaire aux
autres niveaux d'assistance et aux fournisseurs externes.
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 ;

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
7 - 99

Assurer la rsolution du problme

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.

30.2.

Collecte des informations

Il est possible que vous puissiez rsoudre le problme signal pendant l'tape
initiale de cration de rapport. Ceci est particulirement vrai dans le cas de
problmes relativement simples. Si vous ne parvenez pas rsoudre
immdiatement le problme, vous devez rassembler le plus d'informations
possible propos du problme dans le but d'identifier les causes possibles. Vous
pouvez utiliser des outils d'analyse, consulter des journaux des vnements ou
simplement poser des questions supplmentaires l'utilisateur pour recueillir
davantage d'informations.

30.2.1.

Processus de collecte initiale des donnes

La phase de collecte des informations relatives un problme signal est trs


importante.
En suivant une srie d'tapes prcise et logique, vous pouvez dfinir clairement
la nature du problme et parvenir dterminer une cause prcise.
Questionner
Le processus dmarre lorsqu'un utilisateur contacte le support technique en
suivant une procdure dfinie. Il peut tablir ce contact initial par le biais de la
messagerie lectronique, du tlphone ou de tout autre moyen. En tant que
membre du service du support technique, vous devez poser des questions claires
et prcises l'utilisateur sur les symptmes du problme afin de pouvoir
commencer en dfinir la cause. Il est galement important de consigner le
problme dans une base de donnes. Vous utiliserez cet enregistrement tout au
long du cycle de vie du problme pour suivre sa progression jusqu' sa
rsolution.
couter
Lorsqu'un utilisateur final vous signale un problme, coutez-le attentivement. Il
arrive souvent que lorsquun utilisateur rpond vos questions et relate
l'historique d'un problme, celui-ci en rvle involontairement la cause. En
demandant l'utilisateur de commencer depuis le dbut et d'expliquer
exactement ce qu'il faisait immdiatement avant de remarquer le problme et

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
8 - 99

Assurer la rsolution du problme


pendant qu'il l'a remarqu, vous pouvez parfois dterminer la cause du
problme.
Consulter
Lorsque vous avez enregistr toutes les informations pertinentes fournies par
l'utilisateur, la tche suivante consiste dterminer la cause du problme
signal. Commencez par consulter la documentation concernant les problmes
connus que vous avez disposition.
Il est possible que le problme se soit dj produit. Si tel est le cas, vous pouvez
parvenir une rsolution et une clture rapides de l'incident.
Rechercher
Si la documentation existante ne vous permet pas d'tablir de causes probables,
vous devez mener quelques recherches dans diverses sources. Par exemple, vous
pouvez effectuer des recherches dans la Base de connaissances de support
Microsoft ou dans des forums en ligne.
Dvelopper
Une fois que vous avez dtermin une cause probable du problme, vous devez
dvelopper un plan d'action.

30.3.

Dveloppement d'un plan d'action

Lorsque vous avez suffisamment d'informations, vous tentez de dterminer la


cause du problme. Il existe deux approches possibles :
L'approche linaire est une mthodologie qui rvle rapidement la cause
principale d'un problme, car elle implique de suivre une srie logique
d'tapes. Prenez pour point de dpart ce que l'utilisateur final a dit et
continuez de faon mthodique jusqu' ce que vous dcouvriez la source
du problme.
L'approche soustractive est une mthodologie dans laquelle vous vous
reprsentez mentalement les composants systme de l'ordinateur.
Sparez les composants en deux le long d'une ligne que vous pouvez
tester. Par exemple, le problme est-il d un composant matriel ou un
composant rseau ?
Effectuez ensuite un test pour voir de quel ct de la ligne le problme se situe,
puis continuez de la mme manire jusqu' ce que vous ayez isol le composant
qui pose problme.
Quelle que soit l'approche pour laquelle vous optez, l'objectif de cette tape est
d'isoler la cause du problme. Lorsque vous pensez l'avoir dtermine, vous
devez tester vos hypothses. Si les tests s'avrent concluants, continuez jusqu'
ce que vous ayez dtermin la cause relle.
Une fois que vos tests ont rvl la cause d'un problme, vous devez planifier les
actions suivantes. Par exemple, si le problme implique le remplacement d'un
disque du serveur, vous devez commander le nouveau disque, dterminer une
heure approprie pour effectuer le remplacement, sauvegarder les donnes

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
9 - 99

Assurer la rsolution du problme


prsentes sur le disque remplacer, arrter le serveur, installer physiquement le
nouveau disque et excuter une restauration des donnes sur celui-ci.

30.3.1.
Mthodes conseilles de dveloppement d'un plan
d'action
Les problmes simples sont faciles rsoudre rapidement et leur plan d'action
peut ne pas demander beaucoup de rflexion. Par exemple, si un utilisateur final
signale qu'il a oubli son mot de passe, votre plan d'action consiste ouvrir
Utilisateurs et ordinateurs Active
Directory et rinitialiser le mot de passe. Toutefois, les problmes plus graves
ou plus complexes exigent une certaine rflexion.
Analyser les donnes disponibles
Avant de commencer modifier la configuration, analysez les donnes
disponibles pour vous assurer que vous avez dtermin la cause probable du
problme signal.
Consulter la documentation
Consultez toute la documentation relative au correctif que vous envisagez de
mettre en uvre. Par exemple, si celui-ci requiert l'installation d'un Service Pack,
examinez la documentation relative au Service Pack.
Crer un environnement de test
Si le correctif envisag ou la solution de contournement implique une
reconfiguration significative ou si des problmes surviennent pendant la mise en
uvre du correctif, la productivit des utilisateurs pourrait s'en trouver affecte.
Il est important que vous criez un environnement de test qui ressemble
troitement au systme de production et l'utilisiez pour tester votre plan
d'action. Les technologies de virtualisation (telle que Microsoft Virtual PC) offrent
un moyen pratique de crer des environnements de test sans requrir
d'investissements majeurs dans du matriel ou des logiciels supplmentaires.
Considrer l'impact des modifications
Vous pouvez tre amen effectuer un important travail de reconfiguration pour
rsoudre des problmes complexes. Les modifications que vous envisagez
peuvent avoir une incidence sur de nombreux lments de votre organisation.
Par exemple, si le correctif que vous projetez d'implmenter ncessite le
redmarrage d'un serveur auquel les utilisateurs sont connects, tel qu'un
serveur de messagerie ou un serveur de base de donnes, vous devez prvoir
l'implmentation du correctif en dehors des heures ouvres.
En outre, vous devez vrifier que les modifications proposes ne nuiront pas aux
autres applications ou services.
Prvoir une restauration

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
10 - 99

Assurer la rsolution du problme


Si vous implmentez un correctif ou solution de contournement qui ne rsout pas
le problme, vous pouvez envisager de revenir en arrire. L'excution d'une
restauration n'est pas ncessaire, mais peut tre souhaitable dans des
circonstances particulires.
Par exemple, si le correctif implique l'application d'une mise jour, la
suppression de la mise jour peut tre acceptable. Toutefois, si le correctif
implique la mise niveau d'applications pour inclure de nouvelles fonctionnalits
qui peuvent tre utiles aux utilisateurs finaux, il peut tre souhaitable de laisser
les nouvelles applications installes plutt que de rtablir l'application plus
ancienne. Vous pouvez utiliser l'environnement de test pour vous entraner
annuler un correctif ou une solution de contournement propos.

30.4.

Implmentation du plan d'action

Aprs avoir mis au point un plan d'action, vous devez l'implmenter. Lorsque
vous implmentez un plan d'action en vue de rsoudre des problmes graves,
vous devez considrer l'impact des modifications que vous prvoyez d'apporter
sur la disponibilit des services. Les grandes organisations ont des procdures de
gestion des modifications auxquelles vous devez vous conformer.
Avant de modifier la configuration, valuez quels aspects de la reconfiguration
vous pouvez raliser distance avec des outils d'administration et des utilitaires.
Vous pouvez rsoudre beaucoup de problmes avec des techniques de gestion
distance pour viter de vous rendre sur l'ordinateur de l'utilisateur. Toutefois,
certains problmes ne peuvent pas tre rsolus l'aide de tels outils, et vous
devrez vous rendre sur l'ordinateur de l'utilisateur final.

30.4.1.

Processus d'implmentation d'un plan d'action

En gnral, votre plan d'action se composera des tapes suivantes. Toutefois,


n'oubliez pas que les tapes spcifiques de votre plan d'action peuvent varier en
raison de la complexit ou des circonstances d'un problme donn.
Implmenter dans un environnement de test
Avant de tenter de mettre en uvre un correctif sur le systme de production,
implmentez votre plan d'action dans un environnement de test. Gardez l'esprit
que le processus de modification de quelques aspects de la configuration d'un
ordinateur peut rsoudre un problme spcifique, mais peut introduire d'autres
problmes. Ainsi, si vous appliquez une mise jour de scurit au systme
d'exploitation pour rsoudre un problme de scurit, celle-ci peut modifier le
comportement de certaines applications.
Lorsque vous tes satisfait que le correctif ou la solution de contournement
puisse tre implment sans provoquer de problmes supplmentaires et qu'il
rsout le problme signal, passez l'tape suivante. Les problmes simples
peuvent ne pas requrir cette tape de test.
Analyser l'impact possible
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

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
11 - 99

Assurer la rsolution du problme


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.
Se reporter la gestion des modifications
Les grandes organisations implmentent des procdures de gestion des
modifications pour garantir que le personnel de support technique apporte des
modifications l'infrastructure informatique conformment aux instructions et
qu'il les documente suffisamment une fois effectues. Si votre organisation utilise
une telle procdure, vous devez dterminer ce qui est requis de vous lors de
l'implmentation du correctif ou de la solution de contournement. Consultez la
documentation adquate, et lorsque cela est ncessaire, discutez des
modifications proposes avec les personnes appropries.
Rsoudre le problme
Les spcialistes du support technique peuvent souvent rsoudre rapidement les
problmes les plus courants, sans faire appel aux spcialistes des produits. Les
problmes moins courants ou plus complexes requirent souvent l'intervention
de spcialistes de support technique ou de fournisseurs externes, et parfois la
cration d'une quipe spcialise regroupant les comptences ncessaires la
rsolution d'un problme particulier. Lorsque cela est possible, considrez
l'utilisation des outils et des utilitaires d'administration distance, car ceux-ci
permettent souvent de trouver des solutions plus rapidement.
Surveiller et valuer
Si un correctif ou une solution de contournement est susceptible de prendre
plusieurs heures et d'impliquer plusieurs tapes, vous devez surveiller la
progression du processus de rsolution du problme. Il est important que vous
valuiez les donnes collectes lors de ce processus pour dterminer si vous tes
sur le point de trouver une solution. Si les donnes ne vous permettent pas de
l'affirmer, envisagez de revoir votre plan d'action.
Rendre compte et documenter
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.

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
12 - 99

Assurer la rsolution du problme

30.5.

Documentation de la rsolution

Lorsque vous avez rsolu le problme, vous devez documenter sa rsolution.


Cette tche implique un de nombre processus qui varie en fonction de
l'infrastructure du support technique. Au minimum, vous devez informer
l'utilisateur final que vous avez rsolu le problme. Si un systme de
consignation est en place, vous devez clore l'incident.
Beaucoup d'organisations s'appuient sur la documentation pour fournir des
informations relatives la configuration de leurs systmes informatiques. Si vous
avez procd une reconfiguration pour rsoudre un problme, vous devez
mettre jour la documentation de support pour reflter les modifications
apportes.
En outre, lors de la phase de collecte des informations, il est souvent utile de
consulter les journaux d'incident, qu'un problme similaire ait t signal ou non
par quelqu'un d'autre.
Savoir si un autre technicien a document des problmes similaires n'est possible
que si, la clture de l'incident, vous documentez ce que vous avez fait pour
rsoudre le problme.

30.5.1.

Processus de consignation de la rsolution

Dans la plupart des organisations de support, un processus existe pour


enregistrer et documenter un problme signal par un utilisateur. En gnral, le
personnel du support technique consigne l'incident signal dans une base de
donnes. Lorsqu'un problme est rsolu, vous devez clore l'incident et en
informer l'utilisateur qu'il l'a signal.
Mettre jour la documentation actuelle
Si le problme a rvl des failles dans l'infrastructure informatique actuelle,
dans les mthodes de travail ou dans d'autres domaines, vous devez mettre
jour la documentation actuelle pour faire tat de ces failles et des correctifs ou
solutions de contournement appropris. Par exemple, si vous installez un Service
Pack pour un systme d'exploitation dans toute l'organisation pour rsoudre un
problme d'incompatibilit entre applications, vous devez enregistrer les
informations se rapportant ce problme ainsi que la procdure d'installation du
Service Pack dans la documentation relative l'infrastructure.
Crer une nouvelle documentation
Les problmes graves et complexes entranent souvent des modifications
d'infrastructure majeures. Vous devez crer la documentation ncessaire pour
prendre en charge ces modifications. Par exemple, si vous installez une nouvelle
version d'une application pour rsoudre un problme, mettre jour la
documentation existante ne suffit pas. La nouvelle version de l'application peut
comporter de nouvelles fonctionnalits et peut fonctionner diffremment de
l'ancienne version. Vous devez communiquer aux utilisateurs et aux
administrateurs qu'ils doivent dsormais travailler sur la nouvelle version.
Consigner la rsolution

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
13 - 99

Assurer la rsolution du problme


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.
Communiquer avec l'utilisateur final
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.
Consigner des mesures prventives
Un problme ayant tendance se rpter, il est essentiel que vous le
documentiez ainsi que sa cause et les tapes qui ont permis de le rsoudre. Une
documentation adquate garantit que les ingnieurs de support technique qui
seront confronts au mme problme puissent dcouvrir une cause probable et
une solution recommande tt dans le processus de rsolution.

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
14 - 99

Assurer la rsolution du problme

Pour approfondir le sujet.


Proposition de rfrences utiles permettant dapprofondir le thme abord

Sources de rfrence
Citer les auteurs et les sources de rfrence utilises pour llaboration du support

OFPPT
@

Document
319479686

Millsime
janvier 09

Page
15 - 99