d’Analyse des Incidents

MASTER’S THESIS

2004:216 CIV

HÅKAN STRAND

Méthodes et Outils

d’Analyse des Incidents

MASTER OF SCIENCE PROGRAMME Department of Applied Physics and Mechanical Engineering

Division of Physics

Ecole d’Ingénieur ENSMN Axe ISDP

STAGE DE FIN D’ETUDE

Méthode et

Outils d’Analyse des Incidents

Promotion 1999

Responsable : Marie-Claude PORTMANN

S

Par :

Håkan STRAND

Remerciements

Je tiens à remercier mon tuteur industriel Monsieur Hervé VALLET pour son accompagnement et sa disponibilité qu’il m’a accordé durant mon stage de fin d’étude, ainsi que l’accueil de Monsieur Gérard GENDRE, chef du CATV, et son équipe.

Je remercie également Mademoiselle Marie-Claude

PORTMANN qui m’a permis d’effectuer ce projet chez

Renault.

Table des matières

I

... 5

1 PARTIE I - PRESENTATION DU CONTEXTE DU STAGE... 7

1.1 G

R

... 8

1.1.1 Histoire... 8

1.1.2 Gouvernement d’entreprise... 8

1.1.3 Stratégie ... 8

1.1.4 Structure du Groupe Renault ... 9

1.1.5 Les gammes ... 9

Véhicules particuliers ... 9

Véhicules utilitaires ... 10

1.2 C

... 11

1.2.1 Hiérarchie ... 11

1.2.2 DGA de Finance, Crédit, Gestion, Informatique et Audit... 12

1.2.3 Direction des technologies et systèmes d’information - DTSI ... 12

Historique ... 12

Organisation... 13

Mission et management ... 13

Budget de la DTSI ... 14

Projets phares pilotés par la DTSI ... 15

1.2.4 Direction des services et opérations - DSO ... 15

Mission ... 15

Organisation... 15

1.2.5 Centre d’appel, téléphonie et visioconférence (CATV)... 15

Mission ... 15

Organisation... 15

Fonctionnement ... 16

1.2.6 Help-Desk - Unité élémentaire de travail (UET) ... 16

Mission ... 16

Organisation... 17

1.3 A

... 18

1.3.1 Projet en commun... 18

1.4 P

ARS/GII-

2... 19

1.4.1 Origine et actualité du produit... 19

1.4.2 Evolution de l’assistance informatique chez Renault ... 19

1.4.3 Application GII-v2... 20

Interface GII-v2 ... 21

Tableau de bord ... 21

La prise d’appel ... 22

« Advanced search bar »... 23

1.4.4 Eléments d’intérêt particulier concernant le projet... 23

2 PARTIE II – ACTIVITES EN STAGE... 24

2.1 A

’ARS/GII-

2... 25

2.2 A

ARS/GII-

2 ... 26

2.2.1 Périmètres ... 26

2.2.2 Besoins exprimés ... 27

2.2.3 Conclusion... 27

2.3 M

’

... 28

2.3.1 Définitions ... 28

2.3.2 La population statistique ARS/GII-v2 ... 28

2.3.3 Les requêtes ARS/GII-v2 ... 28

2.3.4 Mesure statistique d’incidents ARS/GII-v2 ... 30

2.3.5 Echantillonnage ... 31

2.3.6 Echantillonnage par tirage aléatoire... 31

2.3.7 Ecart type du pourcentage ... 32

2.3.8 Distribution de la population ... 32

2.3.9 Inférence statistique : Estimations du pourcentage ... 33

2.3.10 Intervalle de confiance ... 34

2.3.11 Résultat... 35

2.4 T

’

... 38

2.4.1 Formulation des hypothèses... 38

2.4.2 Prise de décision ... 38

2.4.3 La valeur critique ... 39

2.4.4 Résultat... 40

2.5 E

’

: A

« Q

’

»... 42

2.5.1 Méthode... 42

2.5.2 Requêtes et Contextes... 42

2.5.3 Résultats ... 43

2.5.4 Interprétation ... 43

2.5.5 Conclusion... 45

2.6 E

’

... 46

2.6.1 Anti-requête et anti-population ... 46

2.6.2 Indicateur qualité II ... 46

2.6.3 Réduction de la taille de l’anti-population ... 48

2.7 O

’

... 50

2.8 T

I

R

... 51

2.8.1 Périmètre... 51

2.8.2 Procédure ... 51

2.9 R

ARS... 52

2.9.1 Domaine ... 52

2.9.2 Objet ... 52

2.9.3 Symptôme / Description du problème client ... 52

2.9.4 Fonction ... 53

2.9.5 Système concerné ... 53

2.9.6 Origine du problème ... 53

2.9.7 Type d’appel... 54

2.9.8 Gravité... 54

2.9.9 Type de machine... 54

2.9.10 Conclusion... 54

C

... 55

G

... 56

B

... 57

A

... 58

Organigrammes... 59

L’état actuel de l’utilisation de l’outil de gestion d’incidents informatiques ... 65

Anti-requêtes ... 80

Traitement des Incidents Récurrents... 81

Méthodes et Outils d’Analyse des Incidents

Introduction

Au sein de la direction informatique RENAULT (DTSI), la plupart des chaînes d’assistance pour les utilisateurs des systèmes d’information, sont modélisées à travers un outil de gestion d’incident (ARS/GII-v2). La majorité des ces incidents est créée par le service des Centres d’Appels, Téléphonie et Visioconférence (DTSI/DSO/CATV). Selon leur complexité ou leur caractéristique, les incidents suivent un cycle de vie qui fait intervenir plusieurs équipes des chaînes d’assistance. Tous ces incidents sont suivis dans ARS/GII-v2 : toutes les opérations réalisées par les acteurs doivent donner lieu à des mises à jour des champs de saisie des tickets. Cela permet entre autre de connaître le symptôme précis rencontré par l’utilisateur et le problème précis qui a déclenché la panne.

L’absence de cohérence, entre les différentes équipes de résolution, dans la façon de documenter le ticket, fait que le reporting des tickets d’incident n’est possible que par certains spécialistes qui connaissent très bien les environnements des chaînes d’assistance. Selon les analyses souhaitées, chaque incident doit être examiné séparément : c’est un processus fastidieux qui consomme beaucoup de temps.

Aujourd'hui, on ne sait pas dire le degré de fiabilité des extractions des tickets ni la confiance que l’on peut accorder aux chiffres obtenus.

L’objectif du projet est de compléter à partir des besoins exprimés et des méthodes d’analyse

statistique, les préconisations de documentation des tickets d’incident, les faire valider par

l’ensemble des acteurs des chaînes d’assistance et fournir des outils correspondants. Il s’agit

donc d’harmoniser la documentation des tickets d’incidents par tous les acteurs des chaînes

d’assistance, afin de simplifier et d’améliorer la fiabilité des analyses techniques.

1 Partie I - Présentation du contexte du stage

1.1 Groupe Renault 1.1.1 Histoire

La société Renault Frères sort en 1898 la voiturette Type A. La société créée pour fabriquer des véhicules automobiles et exploiter des brevets relatifs à l’automobile s’installe à Billancourt et construit durant la première guerre mondiale des camions, chars légers et moteurs d’avions.

En 1922, Renault devient société anonyme fortement spécialisée dans le domaine des véhicules particuliers et industriels. La société possédait à l’époque de nombreux centres de production.

Nationalisée en janvier 1945, l’entreprise prend le nom de Régie Nationale des Usines Renault et concentre sa production sur la 4CV.

En 1990, Renault redevient une société anonyme gérée par l’Etat français qui procède à une ouverture partielle du capital, étape vers la privatisation, qui est effective en juillet 1996.

L’année 1999 a marqué une nouvelle dimension pour Renault : L’Alliance avec Nissan, signée le 27 mars à Tokyo et l’acquisition d’une nouvelle marque par la prise de participation dans le capital du constructeur automobile roumain Dacia sont décisives. En 2000, Renault augmente sa participation dans le constructeur Dacia à 80% et acquiert une nouvelle marque, Samsung Motors, en Corée du Sud.

En janvier 2001, Renault devient l’actionnaire principal du second groupe mondial de poids lourds quand l’accord signé avec Volvo entre en vigueur.

1.1.2 Gouvernement d’entreprise

La société est administrée par un Conseil d’Administration (CA) composé de seize membres dont douze administrateurs nommés par l’Assemblée Générale des actionnaires, trois sont élus par les salariés et un représente les actionnaires salariés. Le CA désigne parmi ses membres un président. Le mandat des administrateurs dure six ans.

L’équipe de direction, le Comité Exécutif du Groupe (CEG) est composé par les Directeurs Généraux Adjoints (DGA) auxquels sont rattachés les Directions. Le CEG est présidé par le Président Directeur Général (PDG). La Comité de Direction Renault (CDR), également présidé par le PDG, regroupe le CEG et les Directeurs rattachés aux DGA.

L’organisation comporte sept niveaux hiérarchiques commençant par le PDG et allant à l’employé. Pour de plus amples informations voir annexe « Organigrammes ».

1.1.3 Stratégie

La stratégie de Renault s’exprime au travers de trois axes :

• Développer une identité de la marque axée sur l’innovation dans les produits et les

services

• Devenir le constructeur le plus compétitif sur les marchés, en qualité, en coûts et en délais

• S’internationaliser pour devenir un acteur majeur du développement automobile dans le monde

1.1.4 Structure du Groupe Renault

Renault est la société mère du Groupe Renault qui est la structure opérationnelle de l’activité véhicules particuliers et utilitaires. Après l’accord avec Volvo et la constitution du deuxième groupe mondial dans ce secteur, l’activité véhicules industriels disparaît. Renault a échangé 100% des titres de sa filiale Renault V.I./Mack contre 15% des titres de AB Volvo. Après acquisition de 5% supplémentaires sur le marché, Renault détiendra 20% du capital (actionnaire principal) de AB Volvo. Ainsi, Louis Schweitzer, PDG de Renault prend place au CA de Volvo.

Désormais, l’activité du groupe est répartie entre deux branches :

• La Branche Automobile (CA 33,8 milliards d’euros en 2001) a pour activité la conception, la fabrication et la commercialisation de véhicules particuliers et utilitaires.

• La branche financière (CA 1,8 milliards d’euros en 2001) est un outil d’accompagnement financier et commercial qui regroupe les filiales de financement de ventes et de services ainsi que la gestion de trésorerie.

1.1.5 Les gammes

Renault est présent sur la plupart des segments des marchés véhicules particuliers et utilitaires. Huit plate-formes sont utilisées pour la production de l’ensemble de ses véhicules.

La palette des motorisations est couverte par sept familles de moteurs essence et diesel.

Véhicules particuliers

Sur le segment des voitures compactes (A et B ou I1 et I2), Renault offre trois modèles : Twingo, Clio et Kangoo. Ce dernier est un véhicule fonctionnel qui existe également en version 4X4.

Sur le segment de la gamme moyenne (C ou M1) Renault propose Mégane et Scénic. Le segment moyen supérieur (D ou M2) est représenté par Laguna II, dotée d’équipements normalement réservés à des voitures des gammes supérieures.

Renault est essentiellement présent sur le segment supérieur (E ou S) avec l’Espace. Deux

voitures commercialisées récemment, Avantime en 2001 et Vel Satis en 2002, viennent

compléter l’offre sur ce segment.

Véhicules utilitaires

Sur le segment des fourgonnettes (poids inférieur à 2 tonnes), Renault est présent avec Clio

société et Kangoo Express. Le segment des fourgons (entre 2 et 7 tonnes) est représenté par

le Master, Traffic et Mascott.

1.2 Contexte organisationnel et hiérarchique du stage

Le stage est effectué au sein de la Direction des Technologies et Systèmes d’Information (DTSI) au siège à Bologne Billancourt. Cette direction et son arborescence hiérarchique jusqu’au service Centre d’Appel, Téléphonie et Visioconférence (CATV) où le projet se déroule sont présentées ci-dessous. La connaissance du fonctionnement d’un Help-Desk est un plus pour la compréhension du projet.

1.2.1 Hiérarchie

L.SCHWEITZER PDG CEG¹

S.LEVY DGA, DF CEG

J-P.CORNIOU Dir. DTSI CEG - 1

J-F.LOCHE Dir. DSO CEG - 2

G.GENDRE Chef CATV Service

H.VALLET Chef H.D-VPN U.E.T²

1 Comité Exécutif du Groupe 2 Unité Elémentaire de Travail

Fig. : Hiérarchie du stage

M. Louis SCHWEITZER rejoint Renault en 1986. Nommé Directeur Financier et au Plan en 1988, puis DGA en 1989 et Directeur Général (DG) en décembre 1990, il est depuis 1992, PDG du groupe Renault. Il est né en 1943 et diplômé de l’Ecole Nationale d’Administration (ENA).

M. Shemaya LEVY rejoint Renault en 1972. Il occupe le poste de Directeur Commercial et, en 1994, de PDG de Renault Véhicules Industriels (VI). Nommé DGA du Groupe Renault en 1998, il a la responsabilité des Directions Financières, de l’Audit, du Contrôle de Gestion, et des Technologies et des Systèmes d’Information. Il est né en 1947 et diplômé de l’Ecole Nationale de la Statistique et de l’Administration Economique.

M. Jean-Pierre CORNIOU rejoint le groupe Renault en qualité de Directeur de la Direction de l’Organisation et l’ingénierie Informatique (DOII) en 2000, direction qu’il va réorganiser le 2 janvier 2001 en DTSI. Membre du CDR, il est également Président du Club Informatique des Grandes Entreprises Françaises (CIGREF). Il est né en 1950 et diplômé de Institut d’Etudes Politiques de Paris (IEP) et de l’ENA.

M. Jean-François LOCHE est Directeur de la Direction du Service et des Opérations (DSO).

M. Gérard GENDRE est Chef du CATV.

M. Hervé VALLET est Chef du Help-Desk Véhicule et Processus Numériques (HD-VPN) et responsable du performance et de la communication au sein du CATV.

M. Carlos GHOSN rejoint Renault en 1996. En 1999 il quitte ses fonctions pour une mission

de redressement du constructeur japonais Nissan (PDG et membre du CA). Il est membre au

CA de Renault pour renforcer les liens de l’Alliance. Lors de l’Assemble Générale Mixte en

2002, Louis SCHWEITZER lui propose la Direction Générale de Renault (2005). Il est né en

Brésil et diplômé de l’Ecole Polytechnique et l’Ecole des Mines de Paris.

1.2.2 DGA de Finance, Crédit, Gestion, Informatique et Audit

L’informatique Renault (DTSI) est rattachée au Directeur Financier qui préside la Direction Générale Adjointe de Renault de Finance, Crédit, Gestion, Informatique et Audit.

1.2.3 Direction des technologies et systèmes d’information - DTSI Historique

En 2000 Monsieur J-P CORNIOU rejoint Renault en qualité de Directeur de la DOII (Direction de l’Organisation et l’Ingénierie Informatique), direction qu’il va transformer en DTSI via un chantier intitulé « la Refondation ». La nouvelle organisation est mise en place le 2 janvier 2001 après avoir été soumise au CEG le 3 juillet 2000. Parmi les principes fondateurs évoqués lors de cette présentation, les constats d’un désordre du parc applicatif et la nécessité d’imposer des contraintes économiques :

• La couverture des besoins opérationnels standards est assurée par un nombre élevé (1279) d’applications informatiques et de SI (Système d’information), qui sont complexes et souvent anciens : nécessité de les rénover ou les réduire.

• Les nouveaux investissements de SI doivent viser l’amélioration visible de la performance et la recherche d’avantages concurrentiels pour un coût maîtrisé. Les résultats doivent être prévisibles, pilotés et mesurés.

C’est une course à l’excellence opérationnelle qui se traduit en la disponibilité quasi totale des SI ainsi que la récupération effective des bénéfices des investissements et la transformation profonde des comportements :

« Le but de la réorganisation est de renforcer la compétitivité de l’entreprise et faire en sorte que Renault et l’Alliance bénéficient pleinement de toutes les potentialités des technologies de l’information, de la connaissance et de la communication »

La nouvelle organisation permet de réduire le budget de 830 à 762 millions d’euros. Cette réduction de budget est réalisée grâce à un processus d’optimisation des ressources, notamment en exploitant mieux le patrimoine existant. C’est aussi une grande réflexion sur le problème de la sous-traitance :

« l’informatique de Renault a été trop pénétrée par les consultants et les sous-traitants. Elle a été pénétrée à perdre son âme, à ne plus savoir ce qu’elle devait faire ».

L’objectif majeur de la réorganisation est de construire une vraie informatique de groupe, un pôle reconnu à l’intérieur et à l’extérieur de l’entreprise :

« déclarer aux analystes financiers que l’informatique est un des actifs de Renault »

Mais comment mesurer la valeur ajoutée du métier, comment savoir ce qu’il fabrique et comment différencier une bonne d’une mauvaise informatique ? La DTSI s’efforce de mettre en place des indicateurs et les rendre visibles à l’ensemble du personnel :

« Favoriser le retour d’expérience et la capitalisation et mettre en place une animation via

des outils et systèmes de reporting ».

Organisation

La DTSI est organisée en trois fonctions qui reposent sur le modèle de fabrication d’un véhicule.

• Concevoir : La Direction de l’Engagement Client (DEC) a pour mission de définir les SI nécessaires à l’atteinte des objectifs de Renault et d’assurer la mise en œuvre opérationnelle. Elle est articulée autour des trois processus majeurs que sont l’ingénierie (Véhicule et Processus Numérique), la « supply chain » (Commerce et Logistique) et les métiers tertiaires (Achats, Qualité et Support).

• Fabriquer : La DTSI construit la réponse informatique aux problèmes fonctionnels de Renault. Elle s’appuie sur des solutions du marché dont elle est garante de l’intégration. La Direction Technique et Solutions (DTS) conçoit et déploie des solutions techniques. L’Office Des Projets (ODP) gère le portefeuille des projets et réunit jusqu’au déploiement toutes les compétences des métiers informatiques internes et externes à la DTSI. La Direction de l’Urbanisme et de l’Architecture Fonctionnelle (DUAF) décline les orientations stratégiques d’urbanisme et d’organisation informatique et garantit la cohérence des données et l’interopérabilité des applications de l’entreprise.

• Livrer : La DSO assure le service et le support applicatif (voir DSO page 14). La Direction de la Transformation des Processus et des Usages (DTPU) veille au bon usage des systèmes et outils existants, en particulier par la formation. Les Entités Opérationnelles Locales (EOL) assurent les services de la DTSI au sein de chaque site Renault dans le monde.

Mission et management

La DTSI assure l’animation de la fonction informatique au niveau du Groupe Renault. La continuité de l’exploitation et la sécurisation des systèmes sont considérées comme un vecteur de compétitivité. L’objectif est de mettre en œuvre une approche industrielle, d’assurer la maintenance de ce qui est techniquement et fonctionnellement indispensable, et renforcer la sûreté des implantations critiques. La DTSI contribue aussi dans tous ces domaines à la construction de l’Alliance.

Le management de la DTSI repose sur trois axes :

• Excellence opérationnelle : une disponibilité des SI qui permet de travailler sans interruption. L’objectif est de passer de ce que l’on appelle les 4 neufs (99,99%) de taux de disponibilité aux 5 neuf (99.999%) ce qui signifie très peu d’arrêt.

• Maîtrise économique : maîtriser le coût de traitement de l’information et mieux exploiter ce patrimoine.

• Alignement business : « l’informatique intégrée chez Renault doit uniquement permettre de bien faire son métier, qui est concevoir, fabriquer et livrer des voitures ».

L’alignement business se fait à travers de choix d’architectures, des projets et de plus

en plus la gestion au quotidien des SI existants.

La volonté de la DTSI de se rapprocher de la réalité industrielle est confirmée par la mise en place d’un langage commun (normalisation) pour ne pas mélanger le fonctionnement courant, le court terme, le moyen terme, les investissements, les projets et les systèmes. La standardisation du modèle d’activité se veut proche du contexte industriel. Elle est décrite en trois couches :

• Tel que construit (TQC) - « faire bien fonctionner ce qui existe au moindre coût » Propriétaire d’un parc applicatif considérable qui représente des investissements de plusieurs dizaines de millions d’euros, il s’agit de continuer à obtenir la rentabilité de ces investissements par la maintenance corrective et réglementaire. Par exemple le support utilisateur, technique et méthode.

• Mieux que construit (MQC) - « Améliorer l’efficacité et l’usage des systèmes existants »

Le parc applicatif n’est pas figé. Il faut améliorer et renforcer le parc informatique à moindre coût. Il s’agit d’adaptations rentables, de standardisations et de simplifications génératrices d’économies à moins de 12 mois

• Autre que construit (AQC) - « Transformer les modèles d’activité et les processus » AQC signifie le vrai changement. Il s’agit de transformer les processus et les modèles d’activité, pour conquérir des parts de marché avec de nouveaux outils mais en respectant des contraintes économiques. Les projets engagés doivent être achevés en limitant le déploiement aux fonctions et / ou aux sites capables d’effectuer les transformations nécessaires pour réaliser les bénéfices opérationnels. AQC comprend la préparation des évolutions majeures postérieures à 2002 créatrices de valeur pour Renault et l’Alliance.

Budget de la DTSI

Le dépenses informatiques (DTSI) sont chiffrés à 762 millions d’euros pour l’année 2002.

Des mesures de réduction de coûts ont pu réduire les dépenses qui s’élevaient à 830 millions d’euros pour l’année 2001.

Graphique : Dépenses informatiques de la DTSI

Projets phares pilotés par la DTSI

Un aboutissement de 10 ans d’expérience dans le domaine de l’optimisation appliquée à l’aide à la décision a donné naissance à l’OPTIM, un outil commun transversal de planification commerciale et industrielle. Cette application permet de gérer l’adéquation entre les besoins commerciaux et les possibilités industrielles.

Renault a récemment migré d’un ancien système SAP/R2. La mise en place du système SAER (Système d’Achat Etendu Renault) sur les sites automobiles Renault et Nissan réalisera des économies sur les achats hors production.

Ayant utilisé plus de trente applications de messageries, l’utilisation de Webmail par l’ensemble des effectifs Renault permettra de faire dix millions d’euros d’économies. Dans la même optique, le poste de travail normalisé qui sera généralisé entre 2002 et 2004 à l’ensemble des collaborateurs prévoit des gains de l’ordre de 40 millions d’euros.

1.2.4 Direction des services et opérations - DSO Mission

La DSO regroupe des services opérationnels : exploitation, réseaux, télécoms, développement et maintenance corrective sur l’ensemble du parc informatique de Renault. Sa mission est d’assurer le service au quotidien et d’industrialiser les nouveaux systèmes et l’existant.

Organisation

Les services rattachés à la DSO se repartissent en fonctions opérationnels liés à la production, au développement et à la maintenance.

• Production : exploitation informatique et des systèmes d’informations, centres d’appels, téléphonie et visioconférence, intégration et industrialisation technique et applicative

• Développement et maintenance : commerce et logistique, véhicule et processus numériques, achats, qualité et support

1.2.5 Centre d’appel, téléphonie et visioconférence (CATV) Mission

Le service CATV a pour mission de prendre en compte les appels, traiter les incidents, ou assurer leur suivi jusqu’à la résolution. Il construit les chaînes d’assistance et conclut des contrats de service auprès des responsables des systèmes d’information.

Organisation

Hors Téléphonie et Visioconférence, le service compte 121 personnes et gère un budget de 7

millions d’euros.

Le service regroupe un Accueil Utilisateurs et quatre Help-Desk qui assurent l’assistance informatique autour des trois processus majeurs de l’entreprise ainsi que le support relatif au poste de travail. En outre, le service est doté d’un pôle projet et un groupe d’experts de systèmes d’informations Centre d’Appels.

Les chaînes d’assistance sont organisées en trois niveaux commençant par la prise d’appel, passant par les Help-Desks, les supports techniques et locaux, jusqu’aux fournisseurs.

Graphique : Organisation des chaînes d’assistance informatique

L’outil de gestion d’incident ARS/GII-v2 (voir présentation ARS/GII-v2, page 18) permet d’organiser les workflows au sein des chaînes d’assistance regroupant des entités de support (plus de 200 entités de traitement) à l’intérieur et à l’extérieur du CATV.

Fonctionnement

Le CATV prend 1300 appels par jour en provenance de la région parisienne, les vendeurs, les filiales, les fournisseurs, et les importateurs. De plus, le projet Help-Desk Informatique Renault (HDIR) prévoit de rapatrier la fonction prise d’appel des usines en France.

80% des appels sont servis en moins de 15 secondes et 70% sont traités en moins de 30 minutes. Les clients sont satisfaits à 90% (accueil, réponse, délai).

1.2.6 Help-Desk - Unité élémentaire de travail (UET)

Le Help-Desk au sein du CATV correspond à l’UET qui est l’élément le plus petit dans l’organisation Renault. Le Help-Desk assure le premier niveau de support de son domaine dans la chaîne d’assistance d’un incident.

Mission

Le Help-Desk prend en charge les incidents de type fonctionnel et technique. Il s’agit de

comprendre le problème de l’utilisateur, diagnostiquer et résoudre l’incident ou l’escalader

vers les entités supports de niveau 2 ou 3 si nécessaire.

Organisation

Plusieurs techniciens répondent au téléphone et traitent les incidents. Ce travail est confié aux sociétés de prestation. Les techniciens se trouvent dans les locaux de Renault mais managés par un supérieur hiérarchique direct.

Les responsables des Help-Desks (cadres de Renault) gèrent le fonctionnement de l’UET en s’appuyant sur deux postes intermédiaires occupés par des employés de Renault voir des prestataires.

• Le « Problem manager » : -

-

-

- - - - -

-

veille à ce que les incidents soient correctement pris en charge et recherche des solutions pérennes.

suit l’avancement (particulièrement des incidents bloquants et critiques) jusqu’à leur résolution, et s’assure que tous les incidents soient traités dans les délais contractuels ou « raisonnables ».

améliore et clarifie le fonctionnement de la chaîne d’assistance et participe à l’analyse des incidents récurrents.

• Le « Soutien opérationnel » :

analyse et suit la qualité de traitement des incidents pris en charge par les techniciens de résolution du Help-Desk.

élabore et enrichit la documentation technique de résolution (arbres de diagnostic, fiches solutions).

capitalise dans la base de connaissances et la met à jour en permanence dans ARS/GII-v2.

participe à la résolution des incidents niveau 1 bis escaladés par les techniciens de résolution du Help-Desk.

met en place, en collaboration étroite avec le « Problèm Manager », des relations avec les Supports niveau 2 et 3 sur les sujets suivants: organisation des escalades, recherche d’informations fonctionnelles/techniques nouvelles et des schémas d’architecture

analyse des incidents récurrents en vue de leur éradication, définition précise

du "Qui fait Quoi" (périmètre fonctionnel/technique)

1.3 Alliance

L'Alliance Renault-Nissan est fondée sur un accord signé le 27 mars 1999 au terme duquel Renault est entré dans le capital de Nissan à hauteur de 36,8%. Contrairement à une fusion- acquisition, l’Alliance repose sur le respect des cultures différentes et le maintien des identités de chaque marque. Le 1

mars 2002 Renault est monté de 36,8% à 44,4% dans le capital de Nissan. Ce dernier doit entrer dans celui de Renault à hauteur de 15%.

Le partenariat s’appuie sur deux piliers :

• La création d’un groupe de taille mondiale qui permet de répondre aux défies de l’internationalisation.

• Les complémentarités dans le produits (plate-formes), les achats et les marchés (production et commercialisation). Les synergies escomptées pour la période 2000- 2002 représentent une économie de 3,3 milliards de dollars.

1.3.1 Projet en commun

Dès le début de la création de l’Alliance Renault-Nissan, le comité stratégique (Global Alliance Committee ou GAC) a assuré le démarrage et le pilotage des activités. Plusieurs groupes de travail conjoints (Cross Company Teams ou CCT) ont constitué des moteurs du développement.

• En avril 2001, est crée la première société de l'Alliance : RNPO (Renault-Nissan Purchasing Organization), une société d'achats communs détenue à part égale.

• En septembre 2001, RNIO (Renault Nissan IS/IT Office) est crée pour harmoniser les systèmes informatiques des deux groupes.

Selon le projet de renforcement de l'Alliance, ces entités seront rattachées à la future Renault- Nissan BV (Besloten vennootschap), une société de management de droit néerlandais détenue à parité. Renault-Nissan BV est dotée de réels pouvoirs juridiques et seule habilitée à prendre les décisions stratégiques de l’Alliance.

Le projet prévoit un directoire de 8 membres composé à parité. Louis Schweitzer, PDG de

Renault, en sera le président et Carlos Ghosn, PDG de Nissan, le vice-président.

1.4 Présentation ARS/GII-v2

Depuis juillet 1997, Renault s’appuie sur un outil de gestion d’incidents informatiques nommé ARS: « Action Request System ». L’entreprise ayant de forts besoins en terme d’outil de gestion d’incidents, son choix se porte sur ARS, alors leader mondial des solutions Help- Desk. Il s’agit de la prise en compte des incidents survenus sur les systèmes d’information du parc informatique de Renault.

1.4.1 Origine et actualité du produit

Fondée en 1990 en Californie, Remedy Corporation a démarré ses activités en tant qu’éditeur de solutions de gestion des services informatiques. Dans ce contexte, Remedy commence à développer un moteur de workflow (ARS) qui sert de technologie de base dans ses premiers outils.

ARS est un langage de développement consacré au workflow sur les bases de données standard du marché. Le langage se focalise sur l’écriture des règles de workflow et non sur la structure des données. Cette approche permet à chaque personne de suivre, en temps réel, le traitement d’un incident : groupe de traitement, évolution du diagnostic, relance client, etc…

En août 2001, Peregrine Systems, éditeur de progiciels de gestion d’infrastructure (ressources hors production : équipements, services, connaissance, etc…), acquiert Remedy Corporation (Le Monde Informatique n° 924, 01/02/2002). Peregrine continue à exploiter et développer de nouvelles versions d’ARS. Les partenaires et intégrateurs (revendeurs à valeur ajoutée) poursuivront ses commercialisations d’applications développées sur le noyau ARS.

Ainsi, GII-v2 (l’application utilisée chez Renault) est développé par la société Assistance Informatique Expert sur le noyau ARS. L’outil est un produit interne non commercialisé et il est paramétré afin de fédérer l’ensemble des acteurs des chaînes d’assistance.

1.4.2 Evolution de l’assistance informatique chez Renault

L’assistance informatique Renault à commencé à se développer service par service : les utilisateurs qui ont rencontré des problèmes ont sollicité les développeurs ou les responsables d’un système d’information pour des services de dépannage. Ces derniers ont commencé à exercer un métier qui n’était pas décrit dans leur mission en entreprise. Les premiers outils de gestion d’incidents développés en interne ont ainsi vu le jour.

Parallèlement il existait :

• un Help Desk Corporate, preneur d’appels en provenance du monde entier

• une Cellule d’Assistance Client (CAC) au service du siège et d’autres entités à Boulogne Billancourt

• un service d’Assistance des Usines

Les Help-Desks utilisaient différentes applications de gestion d’incident basées sur le même

noyau de technologie (ARS).

Une première réorganisation sous l’auspice de l’ancienne DOII et la création du Centre d’Assistance Région Parisienne (CARP) font disparaître le CAC. Le CARP assurait le service d’assistance de deux grands domaines : Ingénierie Assistée par Ordinateur (IAO) et Bureautique.

Une deuxième réorganisation (voir la «Refondation ») créée la DTSI. Tous les Help-Desks sauf ceux des usines sont désormais dans le périmètre du CATV (Centre d’Appel, Téléphonie et Visioconférence). HD-Corporate est transformé en HD-Commerce-et-Logistique. La Bureautique est divisée en deux parties : HD-Poste-De-Travail et HD-Achats-Qualité- Sécurité. La partie IAO est rebaptisée HD-Véhicule-Processus-Numérique. ARS/GII-v2, l’actuelle application de gestion d’incidents est mise en place pour réunir ces Help Desk.

L’objectif du dernier projet en cours est de regrouper l’ensemble de l’assistance informatique, y compris les fonctions Accueil et Help-Desk des sites industriels France, en un seul Help- Desk Informatique Renault national (HDIR). L’aboutissement de ce projet permettra d’exploiter un seul outil de gestion d’incidents sur le territoire français et d’industrialiser les chaînes d’assistance. La réalisation imposera quelques légères modifications sur la version actuelle de l’outil d’incidents (voir Référentiel ARS).

En attendant la finalisation du projet HDIR, il existe aujourd’hui une passerelle entre l’ARS Usines et l’ARS Central : un incident créé dans ARS Usines peut ainsi être transmis aux groupes d’escalades centraux par le biais d’une deuxième création de l’incident dans ARS Central. La mise à jour est assurée via un traitement Batch et la consultation des incidents est possible de part et d’autre.

1.4.3 Application GII-v2

Le but n’est pas de décrire le fonctionnement de l’application GII-v2 mais d’expliquer succinctement son périmètre d’utilisation ainsi que ses écrans interactifs nécessaires pour comprendre son intérêt en terme d’exploitation de la base de données.

GII-v2 est une application Client/Serveur. Chaque utilisateur doit impérativement avoir un client ARS sur son poste et posséder un compte ARS. L’environnement peut-être Unix ou Windows 95/98/2000/NT. Plusieurs acteurs sont concernés par l’application GII-v2. Parmi eux nous distinguons les utilisateurs des clients :

Utilisateurs Clients

- Prise d’appel et Help-Desk

- Supports (Industrialisateurs etc…) - Pilotage (Unix, AS 400, MNS) - Usines (Flins, Cléon, etc…)

- Filiales (Allemagne, Espagne etc…) - Partenaires (Help-Desk Grenoble)

- Toute personne travaillant chez Renault - Filiales commerciales (France, UK, etc…) - Importateurs

- Concessionnaires

- Nissan, RVI (Renault Véhicule Industriel), RCI (Renault Crédit International, etc…

Tableau : utilisateurs et clients ARS/GII-v2

L’application GII-v2 contient de multiples informations matérialisées par de tables et des champs qui facilitent la gestion d’incidents. Distinguons par exemple :

• La recherche d’un client, effectuée via une base de contacts contenant des informations de base : téléphone, localisation, etc…

• L’affectation d’une ressource informatique à un contact, effectuée via une base machines : descriptions matériel, paramétrage, etc…

• La résolution (incidents standards), trouvée dans une base de connaissance : symptômes, solutions, procédures attachées en pièce jointe, etc...

• Le diagnostic d’un incident, décrit dans plusieurs tables de qualification.

N.B. : Dans le cadre du stage « Méthode et outils d’analyse des Incidents » on s’intéresse tout particulièrement aux tables et aux champs de qualification de l’incident.

Interface GII-v2

Principalement, il existe deux écrans GII-v2 : Tableau de bord et Prise d’appel. Le dernier fonctionne en trois modes : requête, création et modification.

Tableau de bord

Le tableau de bord permet d’afficher des statistiques de l’activité d’un groupe d’escalade ainsi que l’état et le nombre d’incidents en cours chez ce dernier. Il comporte une fonction de recherche multicritères et il sert de passerelle à l’interface de prise d’appel dans l’un de trois modes de fonctionnement. De plus, il est possible d’y consulter des informations générales (mises à jour par des personnes habilitées) sur l’assistance informatique.

Fig. : tableau de bord GII-v2

La prise d’appel

La prise d’appel est la vue principale de l’application GII-v2. Elle permet de saisir et modifier la fiche d’un ticket ainsi que d’aiguiller l’incident au bon groupe d’escalade. L’écran prise d’appel se décompose en plusieurs parties :

• En tête du ticket : un numéro d’incident automatique et unique.

• Identité et localisation du client : Identité d’un client et/ou entité ou site auquel le client est rattaché.

• Historique des incidents : incidents « non archivés » liés au client ou à l’entité.

• Boutons d’action sur le ticket : transmettre, accepter, suspendre, etc…

• Onglet « Machines » : paramétrage, fournisseur, etc…

• Onglet « Historique du ticket » : actions effectuées sur le ticket.

• Onglet « Indicateurs » : analyse succincte sur le cycle de vie de l’incident.

• Qualification du ticket : trois champs (Domaine, Objet et Fonction) en mode de cascade.

• Nature d’incidents et diagnostic :type d’appel, gravité, symptôme, solution, etc…

La vue principal en mode création (Dans le cadre de ce projet la qualification et la nature de l’incident présentent tout particulièrement un grand intérêt lors des requêtes) est présentée ci- dessous. Les deux autres modes « requête » et « modification » ont l’apparence similaire.

Fig. : Prise d’appel

« Advanced search bar »

GII/v2 possède un champ optionnel de la vue Prise d’appel qui permet de composer des requêtes plus élaborées que celles du tableau de bord. Le langage est basé sur SQL (Standard Query Language) et l’élaboration des requêtes est facilitée par des boutons prédéfinis d’opérateurs et de syntaxe.

Fig. : Advanced search bar

1.4.4 Eléments d’intérêt particulier concernant le projet

Le projet « Méthode et Outils d’analyse des Incidents » s’intéresse comme le titre l’indique à l’analyse d’incidents. Dans cette optique trois parties de l’application GII-v2 ont d’intérêt particulier :

• Ergonomie et fonctionnalité

La partie qualification et diagnostic est l’élément fondamental pour l’analyse à posteriori d’incidents. La partie basse de la vue prise d’appel comporte plusieurs champs pour qualifier et diagnostiquer un incident. Pour de plus amples informations voir « Référentiel ARS » au chapitre 2.9.

• Cycle de vie et escalade

Pendant son cycle de vie, l’incident traverse différents états (transmis, suspendu, etc…). Il suffit d’appuyer sur l’un des boutons d’action dans la partie droite de la vue prise d’appel pour que l’incident passe d’un état à un autre.

La transformation d’état est liée à l’aiguillage d’un incident vers un groupe capable de faire un diagnostic et résoudre le problème. La vue prise d’appel propose des groupes d’escalade via trois boutons (GP : Groupe Proposé, G/O : Groupe / Objet, Tous). Principalement, le premier bouton propose un ou plusieurs groupes en fonction de l’objet de l’incident, la machine, le groupe actuel et l’emplacement du client.

• Extractions d’incidents

GII-v2 permet d’extraire des incidents à travers des requêtes. Le résultat est affiché dans une liste déroulante et mise en forme grâce à une fonctionnalité de reporting. Cette fonctionnalité permet d’imprimer, sauvegarder ou exporter vers une application (Excel, Access, etc …) pour exploiter les résultats de la sortie.

L’émergence et les enjeux de l’outil seront illustrés à travers deux audits auprès des acteurs

des chaînes d’assistance et des responsables des SI dans les chapitres suivants.

2 Partie II – Activités en stage

2.1 Audit utilisation d’ARS/GII-v2

Un audit au sein de la DTSI a été effectué dans le cadre du stage intitulé « Méthodes et Outils d’Analyses des Incidents ». Durant la période du 11/04/02 au 26/04/02, des acteurs des chaînes d’assistance ont répondu aux questions destinées à mettre en évidence leur façon de travailler et de documenter les tickets d’incidents dans ARS/GII-V2 (voir annexe : STRAND,

« L’état actuel de l’utilisation de l’outil de gestion d’incidents informatiques : ARS/GII-v2 »).

Ce recueil d’information a permis de synthétiser de manière succincte, la disparité de l’interprétation des différents champs de saisie dans l’outil ainsi que de comprendre l’intérêt et la volonté des groupes de résolution à s’impliquer et animer le fonctionnement de l’utilisation d’ARS/GII-V2.

Ainsi, l’objectif de l’audit a été de trouver un consensus dans la globalité de l’utilisation de l’outil au niveau de la documentation des tickets d’incidents, visant à définir la méthode d’extraction d’échantillons la plus fiable et précise. Or, aujourd’hui on se demande d’emblée si cette méthode unique et fédératrice existe : il est donc d’autant plus intéressant de posséder l’empreinte du fonctionnement actuel pour se réunir autour d’une façon de documenter cohérente (voir chapitre 2.9, « Référentiel ARS ») et convenable par tous les acteurs des chaînes d’assistance à l’instar de ses spécificités opérationnelles. Le but visé étant de simplifier et d’accélérer les interrogations d’ARS pour comprendre les problèmes rencontrés par les utilisateurs des systèmes d’informations Renault.

Outre ces résultats, vous trouverez dans ce document une brève description de la méthode des

interviews, ainsi que ses limites et ses précisions quant aux acteurs interrogés.

2.2 Audit statistique indicateurs ARS/GII-v2

Dans la continuité de l’étude de l’utilisation d’ARS/GII-v2, j’ai poursuivi par un audit sur les attentes des responsables décideurs des SI câblés sur ce dernier. Cette « Méthodes et Outils d’Analyses des Incidents » s’est déroulée pendant la période du 16/05/2002 au 31/05/2002.

Ces responsables des SI ont été sollicité afin de connaître leurs besoins en terme de statistiques et d’indicateurs.

« Quels sont les indicateurs que vous sortez et aimeriez sortir d’une base d’incidents pour comprendre les problèmes rencontrés par les utilisateurs de vos systèmes d’information ? » Par la même, dans un souci d’avoir une image globale, la plupart des directions au sein de la DTSI ont été auditées :

Interlocuteurs Indicateurs

DEC : VPN

DTPU : Métrique des usages

DTS : Solutions pour le Calcul DTS :

ICS/Solutions DOI

DEOL : EOL Projets DCF

DSO : Gestion des Données Techniques

DSO : Systèmes d'Achats Etendus Renault (SAER)

Fig. : Directions auditées

2.2.1 Périmètres

Plusieurs systèmes informatiques sont concernés, on trouve entre autres :

• SITA : Projet e-commerce concernant 80 pays qui s’appuie sur le réseaux SITA. Ce projet est prévu á être déployé à partir de 2003 dans des pays où il n’y a pas de filiales ou encore l’infrastructure est faible.

• SIGNE : Application de gestion de données techniques via une base de données qui permet une portabilité de données entre plusieurs applications IAO et CAO

• SAER : Systèmes d’Achats Etendus Renault permet au utilisateurs d’exprimer leur besoins d’achats hors production dans le périmètre demandeur, acheteur, logisticien et prototype.

• SAGESSE : Système d’Aide à la GEStion des Supports d’Essai permettant de simuler

l’assemblage de pièces (véhicule, caisse, moteur, boîte de vitesse, etc…) pour

effectuer des essais.

2.2.2 Besoins exprimés

En appliquant le règle 85/15, un tronc commun peut être proposé pour tous ceux qui ont une assistance utilisateur modélisé dans ARS/GII-v2. Il devra contenir les indicateurs suivants :

• Un délai de résolution d’un incident.

• Un suivi dans le temps qui montre l’impact des événements ponctuels.

• Matrice en trois dimensions comportant : - Système de technologie.

- Regard fonctionnel.

- Espace (Site géographique tenant compte de l’architecture informatique).

Autres besoins exprimés concernent les aspects exploitation et disponibilité des systèmes informatiques :

• Identification des incidents récurrents.

• Capitalisation : Typologie des problèmes et leur solution.

• Taux de disponibilité d’une ressource informatique et durée cumulée d’indisponibilité.

• Comptabilisation au niveau de la gravité d’un incident.

2.2.3 Conclusion

Les demandes des décideurs seront prises en compte lors de la définition d’un référentiel ARS (voir chapitre 2.9, « Référentiel ARS) pour être capable de fournir les indicateurs souhaités. La collaboration entre les services centre d’appel et les entités qui gèrent les systèmes d’information n’est pas suffisamment mature. Il faudra communiquer davantage est établir des contrats de services où figure éventuellement une spécification sur les indicateurs qui peuvent être fournis.

Quand le référentiel sera partagé par l’ensemble des acteurs dans les chaînes d’assistance, le

CATV publiera un guide des indicateurs consolidés. Les décideurs exprimeront ainsi leurs

besoins plus facilement.

2.3 Mesure et décision statistique sur une population d’incidents 2.3.1 Définitions

Les mesures statistiques portent soit sur l’ensemble d’une population, soit sur un échantillon tiré d’une sur cette dernière. L’échantillon ne représente une population que s’il a été constitué selon les règles d’échantillonnage statistiques, dont le principe de base est que chaque élément de la population ciblée doit avoir une probabilité connue, supérieure à zéro pour faire partie de l’échantillon.

Les observations sont des éléments dans une population ou dans un échantillon sur lesquelles les mesures portent. Les mesures qui changent d’une observation à une autre sont appelées variables. Les variables binaires sont un cas particulier de variable à échelle à intervalle.

Dans une population, la moyenne des variables binaires constitue la probabilité d’une observation d’avoir la valeur 1.

ig. : Tirage aléatoire d’une population

.3.2 La population statistique ARS/GII-v2

our le cas d’ARS/GII-v2 nous partons de l’hypothèse que tous les incidents ont une raison

our des raisons de clarté nous appelons ces sous-populations créées par des requêtes des

.3.3 Les requêtes ARS/GII-v2

a correspondance éventuelle d’une population avec par exemple un certain système

L'ensemble des éléments (e) : Population

Partie tirée de la population:

Echantillon P(e) > 0

F

2 P

d’être. C’est après avoir classé les incidents à travers une requête où leur appartenance à une population que l’on peut déterminer sa remise en cause. Effectivement, les requêtes servent à extraire les incidents selon des critères de recherche définis par l’utilisateur.

P

populations. Une population peut correspondre à un système d’information, à une application, à un emplacement géographique, à une gravité, etc…Autrement dit, chaque population est un sous-ensemble de l’ensemble des incidents ARS/GII-v2.

2 L

d’information est entièrement déterminée par sa requête qui là créée. Les requêtes permettent

d’emblée d’isoler différentes populations en ciblant un ou plusieurs champs de saisie qui sont

plus ou moins exploitables selon leur pertinence. L’intérêt d’une requête est d’extraire une

volumétrie de certaines familles d’incident. Ces incidents repérés par la requête doivent

correspondre au contexte que nous donnons à la requête.

Ci-dessous nous vous proposons une requête portant sur un contexte déterminé :

Fig. : Illustration d’une requête qui va isoler une population d’incidents créée à partir du 1^er janvier 2002 qui correspond au système ISIS

Ex : Nous pouvons facilement isoler les incidents qui ont été crées le 1

avril 2002 en interrogeant la base de données contenant l’ensemble des incidents ARS/GII-v2 sur le champ

« Date de création ». La population émergeante contiendra les incidents saisis à cette date précise. Le seul critère déterminant, et distinguant la population de l’ensemble des incidents est donc le champ « Date de création ».

La justesse de la correspondance de cette population et le contexte de cette requête vont être difficile à contester car le champ « Date de création » est rempli automatiquement lorsqu’un utilisateur ouvre un incident. Autrement dit : l’ordinateur ne se trompe pas sur la date.

Fig. : Isolation d’une population d’incidents créée à partir du 1^er avril 2002

L’information de cet exemple n’est pas sensationnelle. Elle nous donne simplement le nombre d’incidents créé le 1

avril 2002. En conséquence, nous croyons sans faille à la justesse de ce volume.

Ex : Imaginons maintenant que nous voulons isoler une population contenant tous les incidents « GDG » qui ont été occasionnés à cause de profils utilisateurs non déclarés sur le serveur « méthaphase » par exemple. Pour ce, nous sommes obligés d’écrire une requête plus élaborée (il faut avoir recours à la fouille textuelle, moins exacte que des requêtes par mot indexés) qu’interroge plusieurs champs.

Le résultat de cette requête donne également une volumétrie. Certes, une information plus parlante mais aussi moins fiable puisque nous avons interrogé des champs renseignés par différentes personnes, chacune susceptible de se tromper dans son diagnostic.

Nous sommes donc amenés à statuer l’appartenance d’un incident à une population définie

par les critères de recherche d’une requête déterminant son contexte. Plus précisément : Une

population doit uniquement contenir les incidents qui correspondent réellement à son

contexte déterminé par sa requête.

2.3.4 Mesure statistique d’incidents ARS/GII-v2

La mesure sur un incident se traduit par une question : « L’incident appartient-il au contexte de la population ? »

La réponse est dans le cas d’une variable binaire : « oui » ou « non ». Nous considérons la réponse « je ne sais pas » étant équivalente à la réponse « non ». Notre population contient ainsi uniquement des observations exactes sur lesquelles les mesures donneront des variables binaires. La distribution de la population est dit binômiale.

Ex : Dans le cas des incidents « GDG » où la cause a été la non déclaration d’un profil utilisateur sur le serveur « Métaphase » nous devons répondre à la question affirmativement quand bien même les incidents de la population ont une raison d’y être. Si oui, un incident vaut 1, si non un incident vaut 0. La moyenne représente le pourcentage des incidents qui correspondent au contexte de la population.

En survolant les incidents dans une population, il est évident qu’ils correspondent bien aux critères de la requête proprement dit, sinon ils n’étaient pas repérés. C’est à dire que les champs de saisie sont remplis selon les critères de recherche. L’analyse approfondie du champ « intervention courante » (i.e. le tableau de bord qui permet de détailler plus les analyses et tests effectués pour diagnostiquer et traiter le devenir d’un incident) nous dira si un incident appartient ou non à la population malgré les qualifications qui ont permis de le repérer lors de la requête.

En l’occurrence, nous sommes en mesure de répondre à une question bien précise en analysant un échantillon d’une population : « Quelle probabilité pouvons-nous accorder à la volumétrie d’une population ? » Cette probabilité correspond au pourcentage des incidents qui appartiennent au contexte de la requête.

Récapitulatif des définitions :

Ci-dessous un résumé des concepts mise en place pour l’analyse d’incidents.

Ensemble d’incidents ARS/GII-v2

Population Observations Variables

Tous les incidents dans la base oracle

Sous-ensemble d’incidents, isolé via une requête dont le contexte est déterminé par ses critères de recherche

Sont amenés à être analysés les incidents d’une population où un échantillon

Mesures

portants sur des observations.

(*)

Binaires

Vrai Faux

Tableau : Récapitulatif des concepts d’analyse d’incidents

2.3.5 Echantillonnage

Pour ne pas avoir à analyser tous les incidents dans une population qui peut atteindre des volumes importants, nous avons recours à la technique d’échantillonnage.

population Echantillon

L’ensemble complet des unités que nous souhaitons étudier

Tous sous-ensembles de la population

Tableau : Population versus échantillon

Il y a plusieurs raisons pour lesquelles l’échantillonnage est utilisé. Ci-dessous les principaux avantages de l’échantillonnage (spécifique au cas ARS/GII-v2) :

Temps d’analyse Précision des résultats d’échantillon Population fluctuante L’analyse approfondie d’un

incident immobilisera le lecteur un certain temps (gain de temps)

Un échantillon fournit une moyenne d’une variable binaire qui donne une estimation désirée du paramètre

La façon de documenter et le nombre d’incidents peut changer dans le temps du déroulement de l’analyse

Tableau : Principaux avantages d’échantillonnage

2.3.6 Echantillonnage par tirage aléatoire

L’importance de respecter les règles d’échantillonnage est primordiale pour un résultat correct. Dans le cas d’un tirage aléatoire, chaque observation de l’échantillon faisant partie de la population doit avoir la même probabilité, supérieure à 0 d’être choisie.

Dans une population de 100 incidents nous décidons d’en prélever 20. Le nombre d’échantillons possibles (nombre de permutations) sont de l’ordre :

100 20 80

!

! × !

La probabilité d’un incident d’être choisie dans cet exemple est de :

100

Lorsque la taille de l'échantillon est suffisamment grande : règle empirique : n>30, la

distribution d'échantillonnage des pourcentages est approximativement une distribution

normale, que la distribution de la population soit normale ou non. De plus, lorsque la

distribution de la population est normale, la distribution d'échantillonnage des pourcentages

est une distribution normale.

2.3.7 Ecart type du pourcentage

La «règle empirique» affirme qu'il y à 95% de chances que la moyenne des pourcentages se situe à moins de deux écarts types de la moyenne. Par conséquent, il est important de savoir le taux de dispersion des moyennes échantillonnales, i.e. de pouvoir calculer l’écart type du pourcentage.

Pourcentage échantillonnal défini comme étant :

( )

p x

= n 100%

x : Le nombre de succès (voir définition page suivante) n : La taille de la population

Définition: on appelle l'écart type de la distribution d'échantillonnage des pourcentages, l’erreur type du pourcentage

Ecart type de la distribution d’échantillonnage des pourcentages défini comme étant :

( )

σ π π

p n

N n

= − N

−

−

− 100%

1 1

π : Pourcentage de la population

Le pourcentage de la population est le paramètre que nous souhaitons estimer. Nous sommes obligés d’utiliser l’écart type de la distribution des pourcentages calculé à partir du pourcentage de l’échantillon.

Ecart type de la distribution d’échantillonnage des pourcentages estimés défini comme étant :

( )

σ$p

p p

n

N n N 100%

1 1

−

−

−

− p : Pourcentage de l’échantillon

2.3.8 Distribution de la population

la distribution binômiale décrit la distribution de probabilité lorsqu'il n'y a que deux résultats possibles à chaque essai et que le résultat d'un essai est indépendant du résultat de tout autre essai.

Une population ARS/GII contient des incidents qui correspondent ou ne correspondent pas à

son contexte. Les deux résultats possibles à chaque essai sont donc une affirmation ou une

infirmation : réponse « oui » ou « non » à propos de l’appartenance d’un incident.

Les deux résultats possibles sont appelés « succès » ou « échec ». Le succès est le résultat pour lequel nous souhaitons déterminer la probabilité.

Succès Echec

notation p q

p q + = 1

Tableau : Succès et échec

2.3.9 Inférence statistique : Estimations du pourcentage

Le but de l’inférence statistique est de généraliser les résultats obtenus auprès d’un échantillon pour décrire la population.

Population Echantillon Dénotation Paramètre Indice Statistique

Symbole π p

Tableau : Inférence statistique

Le but est de construire autour de l’indice statistique p un intervalle de confiance pour le paramètre π avec un niveau de confiance déterminé et une marge d’erreur tolérée.

Nous souhaitons mettre en place des intervalles de confiance autour des estimations pour une volumétrie d’une typologie des incidents. Cela nous permettra de dire avec un niveau de confiance que le paramètre π (pourcentage des incidents correspondants au contexte de la population) se trouve à l’intérieur de cette intervalle. De plus nous sommes capables de conditionner la marge d’erreur c’est à dire l’étendue de cette intervalle.

Ex : Nous désirons obtenir une estimation d'une précision donnée a priori. Il est alors possible, moyennant certaines hypothèses, de calculer la taille échantillonnale requise pour atteindre ce degré de précision.

Supposons que la taille de la population est infinie ou très grande. La taille de l’échantillon (n) est déterminée en fonction de trois paramètres :

1. La marge d’erreur (δ) tolérée

2. Le niveau de confiance (Z) désiré sur l’estimation

3. Le pourcentage (π) de la population (le paramètre à estimer)

Un estimé conservateur de π de 50% correspond au pire des cas, i.e. il donne la taille la plus grande de l’échantillon (n) en tenant les deux autres paramètres fixes.

( )

( )

n Z

=

−

2

π 100% π δ

Taille de l’échantillon

0 20 40 60 80 100 120

Pourcentage (%)

0 0,05 0,1 0,15 0,2 0,25 0,3

Majorant

Pourcentage (%) Majorant dans le dividende

Graphique : Variation du majorant dans le dividende en fonction de la valeur estimée du pourcentage de la population

En tenant compte des tailles échantillonnales requises pour atteindre une certaine marge d’erreur tolérée et un niveau de confiance désiré, nous sommes obligés de nous situer dans le carré bas à droite pour restreindre l’analyse des incidents à un nombre raisonnable. Les conséquences d’un échantillon de taille inférieur à 30 nous oblige de considérer une distribution t au lieu de travailler avec la distribution normale.

Tableau : Taille de l’échantillon en fonction du niveau de confiance et la marge d’erreur désirée dans le pire de cas (π=50%)

N’excédant pas un échantillon de 100 incidents et travaillant avec la distribution normale, le niveau de confiance s’étale entre 80 et 95 de signification pour une marge d’erreur tolérée de plus ou moins 10 % (voir partie grisée du tableau).

2.3.10 Intervalle de confiance

Après avoir échantillonné nous procédons à l’étape analytique : chaque incident dans

l’échantillon est attribué à un succès ou un échec. Le pourcentage des succès est l’indice

statistique (p) de l’échantillon c’est-à-dire l’estimateur du paramètre (π) de la population.