LA FOURNITURE DE SERVICES INFORMATIQUES

1. Une démarche qualité dans les unités de recherche

1.1 Description des modèles ITIL et ISO 20000

Les recommandations sur l’organisation des services informatiques qui vont être exposées ci-après sont issues d’une réflexion fortement inspirée de l’approche de l’amélioration de la qualité des services des SI (Systèmes d'Information) décrite par ITIL [7] (Information Technology Infrastructure Library) et plus récemment par la norme ISO 20000 [4].

La norme ISO 20000, prolongement du référentiel ITIL, fournit un modèle pour la gestion de services informatiques. Cette norme formalise l’ensemble des activités d’une production informatique et correspond à une approche « orientée client » qui introduit la notion de « qualité de service » apportée aux utilisateurs. Dans le cadre de l’activité informatique, on peut définir le service comme un échange à valeur ajoutée matérialisée par un flux.

Aujourd’hui, les organisations métiers ont des attentes fortes sur la qualité des services fournis par l’informatique et ces attentes évoluent. Dès lors, le service informatique doit se concentrer sur la qualité de service, en d'autres termes, rendre les services correspondants aux besoins, aux coûts appropriés.

Il nous a semblé opportun de nous référer à ITIL et ISO 20000 qui fournissent un cadre dans lequel positionner les activités et méthodes existantes des services informatiques tout en favorisant leur structuration. Ainsi, parmi les processus métiers présents dans la norme ISO 20000, on distingue ceux relatifs à la fourniture de service et ceux relatifs au support de service.

La « fourniture de services » décrit les processus nécessaires pour fournir le service aux utilisateurs et comporte les processus suivants :

• la gestion des niveaux de service ;
• la gestion de la continuité et de la disponibilité ;
• la gestion de la capacité ;
• la budgétisation ;
• la gestion de la sécurité.

Le « support de service » décrit les processus nécessaires pour mettre en place et assurer un service efficace et fonctionnel. Il est composé des processus suivants :

• la gestion des configurations ;
• la gestion des changements ;
• la gestion de la mise en production ;
• la gestion des incidents ;
• la gestion des problèmes.

A ces processus « métier », s’ajoutent les processus de la boucle PDCA (voir définition paragraphe suivant) destinés à formaliser l’ensemble des activités qui concernent l’amélioration continue avec entre autres :

• les rôles et responsabilités de la direction ;
• la gestion documentaire ;
• la gestion des compétences et de la formation ;
• la surveillance et les mesures.

La méthode PDCA (Plan Do Check Act), encore appelée roue de Deming[8], comporte quatre étapes qui consistent successivement à :

• planifier des actions en réponse à des objectifs (Plan),
• les mettre en œuvre (Do), puis
• contrôler l'efficacité des solutions par rapport aux objectifs au moyen d'indicateurs (Check).
• Avec la quatrième étape (Act), on va chercher à corriger et améliorer le système mis en place ce qui conduit à élaborer un nouveau projet et initier un nouveau cycle.

Entreprendre une démarche de « bonnes pratiques » c’est en effet mettre du bon sens et développer ses capacités d'initiative au service de l’amélioration de la qualité en apprenant à identifier, réaliser, mesurer et analyser de façon progressive afin de travailler plus efficacement et, à terme, gagner du temps, de l’efficacité et augmenter le niveau de qualité des services rendus.

1.2 Transposition au contexte ASR dans une unité de recherche

En replaçant ce modèle d'organisation dans le contexte d’une unité de recherche, les auteurs ont posé comme préalable que les processus décrits devaient être identifiables et mesurables dans l'ensemble des services informatiques de nos unités (CNRS, Universitaires, EPST ou EPIC...) sur la base d’un « plus petit dénominateur commun ». Les bases d'organisation ainsi posées ne doivent pas être restrictives et doivent pouvoir se décliner en fonction du contexte et du périmètre des unités de recherche (taille, mono ou multi-site, diversité des recherches, collaborations internationales…). Ainsi, l’application de cette démarche qualité au métier d’ASR dans un laboratoire de recherche et sa spécificité nous conduisent à proposer un modèle d'organisation décrit plus précisément au cours des chapitres suivants.

1.2.1 Définir le périmètre d'action

Comme préalable à toute organisation, l’ASR doit, dans un premier temps, définir son périmètre d’action en spécifiant ses domaines d’intervention et/ou en excluant les domaines qui ne sont pas de sa responsabilité, ceci pouvant fortement conditionner la nature de ses activités.

1.2.2 Mettre en place une gestion des configurations Ce processus s’intéresse à la gestion de l’infrastructure informatique. Cette étape nécessite d’effectuer un inventaire de l’ensemble des composants aussi bien matériels (ordinateurs, équipements réseau …) qu’immatériels (documentations, licences, contrats…) du service.

1.2.3 Définir les niveaux de service

La définition des niveaux de service doit permettre aux utilisateurs de connaître la nature et l'étendue du support offert par le service informatique. Chaque « niveau de service » sera associé à des objectifs réalistes visant à assurer un niveau de qualité satisfaisant pour les besoins des utilisateurs.

1.2.4 Définir la continuité de service

Associées à chaque niveau de service, l’ASR devra spécifier les exigences des utilisateurs de l'unité en termes de continuité de services. Cet engagement, établi en accord avec la direction (et/ou une commission d'utilisateurs), sera évalué régulièrement.

1.2.5 Gérer les interventions

Il convient de prendre en compte de manière efficace toutes les demandes d’intervention qu’il s’agisse de demandes émanant des utilisateurs ou de changements à apporter aux éléments du système.

1.2.6 Gérer les dysfonctionnements

L’objectif consiste, d’une part, à minimiser l’impact des dysfonctionnements du système d’information sur les services et d’autre part, à prévenir leur réapparition.

1.2.7 Assurer les changements et les mises en production

Tout changement apporté au système d’information doit être maîtrisé afin de minimiser le risque d’incident potentiel lors de sa mise en place. La gestion de la sécurité s’appuie sur un référentiel propre, l’ISO 27001 qui sert de base à la mise en place des politiques de sécurité au sein des unités.

A travers ce guide, nous essayerons de préciser d’une part, ce qui nous paraît essentiel à mettre en place au sein d’un système d’information et d’autre part, ce vers quoi il convient de tendre, ces deux niveaux pouvant être considérés comme deux niveaux de maturité de l'organisation du système d'information d'une unité de recherche.

Adaptés à nos structures d'unités CNRS, Universitaires, EPST, EPIC, etc., les concepts ITIL/ISO 20000 peuvent être visualisés au travers de la cartographie de la page suivante.

Les processus de pilotage et de support complètent dans cette cartographie les processus métier représentés par la fourniture de services, la gestion des dysfonctionnements et le contrôle. La norme introduit la notion de « client » : autorités de tutelle, utilisateurs du service (la direction, les chercheurs…) ou partenaires que l’on va chercher à satisfaire. Cette satisfaction va, par exemple, consister à garantir la sécurité des résultats de la recherche, répondre aux besoins des utilisateurs tout en améliorant l’efficacité du service.

Figure 1 : Cartographie des processus dans un laboratoire de recherche

1.3 Définition du périmètre

La fonction première d’un service informatique d’une unité de recherche est de « participer à la réalisation des objectifs métiers de l’unité ». Pour réaliser ces objectifs, le service informatique doit mettre en œuvre un certain nombre de processus au travers des services fournis dans un périmètre donné. L’une des questions les plus délicates qui se pose au préalable est la définition du périmètre sur lequel vont porter les processus énoncés précédemment. Nous avons précisé que l’objectif des recommandations de bonnes pratiques sur le plan organisationnel était de tendre vers un plus petit dénominateur commun aux services informatiques des unités de recherche. Il en va de même pour le périmètre à considérer. Dans le cadre de la mise en place des processus d’organisation, il faut se garder de vouloir envisager « tout » et « tout de suite ». Pour être plus précis, il est nécessaire de respecter des paliers progressifs de maturité dans l’élaboration de ces bonnes pratiques dans la définition du périmètre et de rester pragmatique en fonction des ressources humaines disponibles et de la taille de l’unité. A cet effet, il faut se poser les questions suivantes :

• Quels sont les métiers de l’unité que le service informatique soutient ?
• Quels sont les besoins exprimés par les utilisateurs de l’unité : les « clients » ?
• Quels sont les champs d’activités définis et validés : quel est, par exemple, le périmètre de l’administration réseau au sein du laboratoire ? Le service de noms, le serveur de messagerie, le réseau sans fil, par exemple, sont-ils pris en charge directement par le laboratoire ou par une autre structure de type CRI (Centre de Ressources Informatiques) ?
• Quels sont les éléments matériels et logiciels que le service informatique gère dans le périmètre précédemment défini ?
• Et surtout, quels sont les éléments du périmètre à considérer dans un objectif de disponibilité de l’activité « vitale » du laboratoire ?

Dans sa définition minimale, le périmètre d’activité précédemment défini doit intégrer les éléments nécessaires à la continuité de service de l’unité. Par exemple, les serveurs (supports des données de recherche) font partie de ce périmètre ainsi que tous les éléments nécessaires à la continuité de la recherche. On pourra aussi y inclure le matériel actif, les routeurs et commutateurs (s’ils sont gérés par l’ASR), les sauvegardes, la messagerie... Ce périmètre pourra être élargi dans un deuxième temps, lorsque l’organisation de premier niveau sera fonctionnelle.

Il faut bien comprendre que cette phase de définition du périmètre est essentielle. Elle nécessite sans doute une concertation préalable et une prospection de l’existant avec les instances du laboratoire (direction, commission informatique...). La réponse ne sera pas déclinée à l’identique dans toutes les unités, et chaque unité est un cas particulier avec une taille, des moyens et surtout des objectifs différents. Ceci sous-entend une définition claire des missions du service (si la structure existe) et de celles de l’ASR au sein de l’unité de recherche.

2. La gestion des configurations

Ce qu’il faut prendre en compte Une fois le périmètre envisagé et de façon à définir les services à fournir, il faut s’appuyer sur un ensemble d’éléments d’infrastructures sur lesquels l’ASR peut/doit agir. Ces éléments d’infrastructure doivent être identifiés et classés dans une base de connaissances qui sera tenue à jour régulièrement. Dans la terminologie ITIL/ISO 20000, l’ensemble de ces informations constitue la base des configurations connue sous le terme de CMDB (Configuration Management DataBase). Cette base doit être maintenue et mise à jour régulièrement en fonction des modifications intervenues sur les différents éléments d’infrastructure.

La gestion des configurations est une des conditions nécessaires et préalables à la gestion de l’ensemble des autres processus. Elle permet de suivre avec efficacité l’évolution des infrastructures informatiques et d’en assurer la gestion et l’exploitation.

Les éléments de configuration sont les biens matériels ou immatériels qui composent les services offerts dans le périmètre qui a été défini. Par exemple on peut y trouver : les serveurs, postes de travail, imprimantes, autres périphériques, logiciels, licences, équipements réseaux, comptes informatiques, consommables, documentations techniques, contrats...

Pour bien identifier les composants devant figurer dans la base de gestion des configurations, on s’attachera à répondre aux questions suivantes :

• Quels composants matériels utilisons-nous aujourd’hui ?

• Quels équipements doivent être remplacés ?
• Quels contrats de maintenance avons-nous et doivent-ils être revus ?
• Quelles licences avons-nous et sont-elles en règle ?
• A quels réseaux un équipement est-il connecté ?
• Quels sont les composants utilisés et par qui ?
• Quels composants sont impactés par un déploiement, lesquels sont responsables d’une erreur ?
• Comment l’équipe des ASR du laboratoire partage ses connaissances ?
• Quelle documentation est mise à la disposition des utilisateurs et comment ?
• etc.

La gestion des configurations se doit de fournir aux autres processus des informations précises et pertinentes sur les composants du système d’information. Ces informations doivent permettre d’identifier rapidement le composant touché par un incident.

Elles permettent aussi, par exemple, de calculer les coûts de la maintenance et des licences logicielles. Dans sa définition minimale, la base de connaissances des configurations doit comprendre tous les éléments d’infrastructure compris dans le périmètre minimal défini précédemment. Dans une réflexion plus élargie, les objectifs de la gestion des configurations sont les suivants :

• rendre compte de tous les biens et configurations de la production informatique de l’unité ;

• fournir de l’information pertinente sur les configurations pour supporter les autres processus (gestion des niveaux de service : qu’est-ce que l’on doit maintenir, comment ? gestion des changements :
• qu’est-ce qui doit être changé, quelles sont les incidences sur les autres éléments ?...) ;
• fournir des bases solides pour la gestion des dysfonctionnements ;
• comparer l’information stockée à l’infrastructure en place afin de corriger les différences.

Comment organiser la gestion des configurations ?

Il faut se garder de vouloir détailler trop précisément les éléments d’infrastructure afin de conserver la maîtrise de l’ensemble sans perte de temps (ne pas faire « d’usine à gaz »). Il est par ailleurs important d’avoir un contrôle efficace sur les configurations si l’on veut maîtriser correctement ce processus. Ainsi, toute modification apportée par un utilisateur à la configuration de son matériel doit pouvoir être identifiée et répertoriée.

Pour cela il convient de définir le niveau de granularité, c’est-à-dire le niveau de détail des éléments de configuration que l’on veut appliquer (équilibre entre détail et facilité de gestion). Le principe général pour définir le bon niveau est d’avoir le maximum de contrôle sur les éléments avec un minimum de travail d’enregistrement, en intégrant principalement les éléments qui ont un réel impact sur les niveaux de service.

Par exemple, doit-on considérer un ordinateur (poste de travail ou serveur) comme élément de configuration ou doit-on rentrer dans le détail en prenant en compte ses composants (cartes réseau et graphiques, disque dur, graveur...) ?

Le niveau de détail est défini en terme « d’attributs » des éléments de configuration dont voici quelques exemples à considérer (au sein de la CMDB) :

• catégorie (matériel, logiciel, document...) ;

• numéro de série (matériel, logiciel) ;
• numéro de version (logiciel, documentation) ;
• numéro de licence (logiciel) ;
• numéro d’inventaire du matériel ;
• fournisseur ;
• emplacement (site, local) ;
• date achat, date de mise à jour, date de fin de garantie...
• responsable, utilisateur...
• composant principal ou sous-composant de ... (relations entre les composants) ;
• statut ou cycle de vie (opérationnel, en cours de changement,...) ;
• historique des interventions,...

La gestion des configurations peut être opérée de façon simple, à partir d’un outil tableur par exemple ou de manière plus sophistiquée et semi-automatique avec des outils de gestion de parc.

On trouvera dans l’annexe 2 de ce guide un certain nombre de références vers des logiciels ou de la documentation qui peuvent servir et être utilisées par les ASR pour implémenter et mettre en place les différents volets requis dans la qualité de service.

3. La gestion des niveaux de service

3.1 Déterminer les services à considérer

La gestion des niveaux de service doit permettre :

• de déterminer le niveau de service à délivrer aux utilisateurs pour supporter les métiers de l’unité de recherche ;
• de réaliser un suivi pour identifier et constater si les niveaux demandés ont été atteints et sinon pourquoi.

Le but de la gestion des niveaux de service est de définir, de maintenir et d’améliorer progressivement la qualité des services rendus par l’ASR pour assurer les activités de l’unité.

Il convient donc, au cours de ce processus, pour différents services supportés par les ASR dans nos unités (tels que, par exemple, la gestion du parc informatique, la maintenance des serveurs, la surveillance réseau, le déploiement d’application, les sauvegardes, l’archivage, les installations de PC pour le personnel de l’unité, l’assistance de premier niveau aux utilisateurs, etc.) d’associer des « niveaux de services ».

Par exemple :

• Pour un service de « sauvegarde de données », le « niveau de service » pourrait être : « les sauvegardes de données utilisateurs sont effectuées de manière quotidienne et conservées pendant 3 mois de manière glissante. Sur demande des utilisateurs, l’équipe Informatique procédera à des restaurations de données. Les données personnelles figurant dans le répertoire intitulé « personnel » présent dans tous les comptes informatiques ne seront pas sauvegardées ».

• Pour un service « d’installation de PC »... un « niveau de service » pourrait spécifier quelques éléments comme : « Le service d’installation ne concerne que les PC achetés par le service informatique, pour les permanents du laboratoire, les installations se font aux heures ouvrables du lundi au vendredi, le PC est restitué à l’utilisateur sous 48 heures avec sa configuration réseau, un antivirus et les logiciels de bureautique de base sont installés. » Les niveaux de service ainsi définis sont référencés dans un catalogue de services. On pourra les hiérarchiser par type de service :

• services métiers : disponibilité des moyens de calcul, de visualisation graphique, développements informatiques dédiés, support à la gestion financière et RH ;

• services infrastructures : gestion des serveurs, des sauvegardes, des impressions...
• services réseaux : gestion de la disponibilité du réseau, gestion des flux...
• services applicatifs : messagerie, web... ...

La mise en place pratique d’un catalogue de services est présentée au chapitre 8 de cette partie.

L’ASR qui met en place une gestion de niveau de service doit s’assurer au préalable auprès de ses utilisateurs, des services utilisés et de leur usage. Ainsi, le cycle de la qualité de service passe par un engagement entre le service informatique et les utilisateurs de l’unité identifiés dans des structures métier (la direction, les services administratifs, les équipes de recherche). Pour estimer le niveau de service minimal, il faut se rapprocher du périmètre envisagé, des infrastructures gérées et du seuil critique pour la continuité de l’activité.

Dans un deuxième temps, on peut envisager de graduer en trois catégories principales les niveaux de service à apporter :

• vital : un service dont l’interruption bloque complètement le travail dans le laboratoire. Exemple : le service d’annuaire LDAP si l’authentification de connexion sur les machines passe par une authentification LDAP, les routeurs/commutateurs et le contrôleur de domaine si une grande majorité des PC sont sous Windows et nécessitent une authentification ;

• important : un service qui peut être interrompu brièvement. Exemple : messagerie, web, sauvegarde, serveurs de calcul, serveur anti-virus ;
• normal : un service qui peut être interrompu quelques jours. Exemple : un PC, une imprimante, un serveur de licences.

3.2 Quel niveau pour quel service ?

La formulation d’un niveau de service dans le catalogue des services peut comporter :

• la description du service offert ;

• les fonctions métiers couvertes ;
• les périodes de fonctionnement du service ;
• la disponibilité du support ;
• le plan de secours ;
• le plan de reprise...

Deux paramètres sont à considérer pour définir le degré de service à proposer :

• l’existence de besoins différents par groupe d’utilisateur : par exemple le niveau de service pour les secrétariats d’administration et de scolarité ne seront sans doute pas les mêmes que ceux pour un groupe de chercheurs (gérer les sorties d’imprimante pour le service scolarité en période d’inscription semble plus vital que pour un groupe de chercheurs en période moins drastique) ;

• l’existence de contraintes différentes liées aux types d’infrastructures.

Plusieurs questions posées au préalable peuvent aider l’ASR à déterminer les niveaux de service :

• A-t-on mesuré et validé la qualité de service de l’application avant sa mise en production ?

• Nos utilisateurs reçoivent-ils un service conforme à nos engagements ?
• Peut-on mesurer la qualité de service en temps réel ?
• Dispose-t-on d’un système d’alerte efficace pour gérer les incidents d’exploitation en temps réel ?
• Dispose-t-on d’un historique du niveau de service ?
• Peut-on identifier un problème avant qu’il ne réduise la qualité de service ?
• A-t-on une visibilité et un contrôle suffisants du fonctionnement de nos applications métier critiques ? -...

4. La gestion de la continuité de service

L’objectif de la gestion de la « continuité de service » (en corollaire à la gestion des niveaux de service) est de diminuer durablement la fréquence et la durée des incidents en s’assurant que l’infrastructure informatique et la fourniture de service qui lui est associée peuvent être remises en route dans les temps requis et convenus.

Depuis plusieurs années, l’interdépendance entre activités métiers et soutien informatique est parvenue à un point tel que si les services informatiques offerts s’arrêtent, une grande part des activités de recherche peut être fortement impactée. L’activité de recherche nécessite de plus en plus un fonctionnement 7/7j et 24/24h du système d’information et des services informatiques.

La gestion de la continuité de service consiste à :

• identifier, par une méthode d’analyse de risques, les menaces et les vulnérabilités sur les actifs de l’infrastructure ;

• appliquer dans un deuxième temps des mesures (préventives et de reprises) qui permettent de conserver un niveau de continuité de service.

La gestion de la continuité de service doit donc s’accompagner d’un plan de continuité de service (actions d’urgences, sauvegardes des enregistrements vitaux, évaluation des dommages, plan de reprise...).

Le contenu de ce plan pourra prendre en compte :

• la/les procédures de déclenchement de ce plan ;

• les équipements couverts par le plan ;
• la description des procédures de continuité définies ;
• les responsabilités et impacts sur les ressources humaines ;
• les impacts sur la sécurité (en mode dégradé) ;
• les procédures de retour à la normale ;
• les procédures de retour à la normale ;
• les procédures de test du plan de continuité ;
• ...

5. La gestion des interventions

5.1 Ce qu’il faut prendre en compte

L’objectif principal de la gestion des interventions est de simplifier et formaliser la chaîne de demande d’assistance en provenance de l’utilisateur tout en augmentant la réactivité du service. Cette fonction nécessite de prendre en compte l’ensemble de l’intervention, de l’appel de l’utilisateur, jusqu’au retour de sa demande après résolution du problème.

Il s’avère également essentiel pour un ASR de mémoriser les demandes de façon à pouvoir recenser l’ensemble des interventions effectuées au niveau du SI. Les informations ainsi recueillies permettront, d’une part, d’assurer un meilleur suivi des interventions et, d’autre part, de disposer d’un historique des demandes et de statistiques.

Tout utilisateur étant amené à effectuer une demande d’intervention, l’objectif de la gestion des interventions va consister à fluidifier leur traitement. A cet effet, il est recommandé de mettre en place un circuit de décision : filtrer les demandes, en déterminer la priorité et les catégoriser, le choix de la priorité devant intégrer une analyse de risque et s’effectuer en concertation avec l’utilisateur.

A ce stade, l’ASR doit se demander quel niveau d’intervention il doit prendre en charge et quel type d’intervention va nécessiter un suivi précis.

5.2 Comment organiser la gestion des interventions

Ce premier niveau de la gestion des interventions qui s’avère essentiel pourra être réalisé différemment selon les méthodes de travail des ASR (cahier de laboratoire, fichier numérique, outils logiciels de type helpdesk...).

A un deuxième niveau de maturité du système, la gestion des interventions pourra se complexifier. Deux points seront alors à prendre en considération.

Optimiser les ressources pour accélérer le traitement des interventions

Dans le cas d’un nombre important d’interventions ponctuelles, la saisie d’un appel doit être rapide et sûre de façon à récupérer l’ensemble des données de l’utilisateur et les motifs de son appel, ces informations pouvant faire l’objet d’une fiche d’appel très structurée (coordonnées, descriptif, date, intervenant...). Au retour d’intervention, la fiche permettra son suivi : temps passé, solution adoptée, fourniture ... L’affectation des ressources, qu’elles soient matérielles ou humaines, s’effectuera à partir de cette fiche et une planification de l’intervention sera mise en place.

Analyser les interventions

Des tableaux d’analyses découleront des interventions effectuées. Cette synthèse pourra prendre plusieurs formes :

• tableaux de bord ;

• recherches multicritères sur les interventions ;
• base de connaissances ;
• rapports statistiques à personnaliser (ex : nombre d’interventions par mois,...).

Cette analyse des interventions pourra constituer, par ailleurs, un paramètre de mesure de l’activité du service. Son évaluation régulière permettra de suivre l’amélioration de son fonctionnement dans le cadre du modèle PDCA inhérent à la norme ISO 20000.

6. La gestion des dysfonctionnements

L’objectif essentiel de ce processus est de chercher à résoudre les dysfonctionnements susceptibles de se produire au sein d’un SI.

Il s’agit de minimiser leurs répercussions sur les niveaux de service mais également de prévenir leur réapparition.

La norme ISO 20000 distingue la notion d’incident de celle de problème.

Un incident se décrit comme « tout événement qui ne fait pas partie des opérations standards d’un service, et qui provoque ou peut provoquer une interruption de service ou altérer sa qualité » alors qu’un problème est considéré comme la « cause inconnue et sous-sous-jacente d’un ou de plusieurs incidents ».

Les référentiels ITIL et ISO 20000 décrivent la gestion de dysfonctionnements en deux processus distincts, la gestion des incidents et la gestion des problèmes.

6.1 La gestion des incidents

La gestion des incidents va consister à rétablir les services le plus rapidement possible. Tout incident devra être enregistré et documenté de façon à tracer les opérations qui ont été nécessaires à sa résolution. Outre la description originelle de l’incident, l’enregistrement devra être mis à jour tout au long du cycle de vie de l’incident, de façon à pouvoir par la suite communiquer sur celui-ci. L’enregistrement pourra ainsi comporter les informations suivantes :

• la catégorie (réseau, station, service, organisation...) ;

• la date ;
• la priorité ;
• les services impactés ;
• le statut (nouveau, en cours, résolu...).
• etc.

6.2 La gestion des problèmes

La gestion des problèmes vise à rechercher la cause première des incidents récurrents et nécessite de mettre en place un suivi d’actions pour améliorer ou corriger la situation. C’est pourquoi, de façon à traiter correctement et rapidement un incident récurrent qui se présente, il est indispensable que les informations sur les incidents soient disponibles.

La gestion des problèmes va comprendre deux types d’actions :

• les actions correctives : il s’agit, dans un premier temps, d’identifier les causes des incidents passés et résoudre les problèmes en réponse à ces incidents et, dans un deuxième temps, de formuler des propositions d’amélioration et de correction ;
• les actions préventives : il s’agit de l’identification et de la résolution des problèmes connus avant que les incidents ne surviennent. On cherche donc à prévenir l’apparition des problèmes en identifiant les faiblesses du SI et en proposant des solutions pour les éliminer. Cela va consister à définir des axes d’amélioration qu’il conviendrait d’apporter au système. En alimentant ainsi le système d’amélioration continue, cette gestion pourra servir à la justification de demandes de nouvelles acquisitions ou remplacement de matériels nécessaires au bon fonctionnement du service (virtualisation des services,...).

Par la suite, l’ASR pourra affiner la gestion des dysfonctionnements à partir des questions suivantes :

• Comment différencier les responsabilités entre la gestion des incidents et la gestion des problèmes ?
• Comment communiquer auprès des utilisateurs sur les incidents ?
• Comment gérer dans certaines situations le « conflit d’intérêt » qui peut exister entre la résolution d’un incident et la résolution du problème associé (le redémarrage immédiat d’un serveur peut conduire à l’effacement de certains fichiers logs qui auraient pu être utiles à la résolution du problème) ?
• Comment formaliser les solutions mises en place ? Là encore, le service informatique devra définir les méthodes et outils qu’il convient d’utiliser pour mettre en place cette gestion des dysfonctionnements.

7. La gestion des changements et de la mise en production

Les changements au sein d’un service SI peuvent être multiples et concerner par exemple l’ajout ou la suppression d’un élément de configuration, l’évolution de la version d’un composant voire un changement organisationnel. L’objectif de la gestion des changements et de la mise en production est de réduire au minimum les conséquences des incidents éventuels liés à ces changements sur le système. A cet effet, toute modification, qu’il s’agisse de modifications matérielles (changement de disque, ajout de mémoire...) ou logicielles (mises à jour des systèmes, installation de logiciels...) devra être notifiée de façon à en garder une trace et éventuellement à pouvoir revenir en arrière.

Lorsqu’un changement est nécessaire, il faut évaluer les risques de sa mise en œuvre et son impact sur la continuité de l’activité métier pendant et après cette mise en œuvre. Lors de la mise en production, il va s’agir de protéger l’environnement de production et les services associés par l’utilisation de procédures formelles et par des vérifications lors de l’implémentation des changements.

La gestion des changements et de la mise en production consiste à faire évoluer un SI de façon structurée sans commettre d’erreurs. On va ainsi chercher à réduire l’impact négatif des changements, améliorer la gestion des dysfonctionnements par une connaissance précise des modifications apportées et donc, à terme, améliorer l’efficacité des services rendus.

Tout changement sera accompagné de tests permettant de valider les modifications apportées. Une solution de repli de type « retour arrière » sera également étudiée. Il est préférable, d’une manière générale, de planifier les changements en fonction de la disponibilité des ressources tout en cherchant à éviter les changements faits dans l’urgence suite à un dysfonctionnement du système. L’ASR devra donc se poser la question des méthodes et des démarches qu’il convient de mettre en place pour traiter efficacement et rapidement ces changements tels que :

• mettre en place un dispositif adapté à la taille du service ;
• mettre en place un planning prévisionnel des changements, par exemple, la mise à jour système des serveurs du laboratoire ;
• avertir et informer les utilisateurs suffisamment tôt de l’interruption de service inhérente au changement de configuration ;
• accompagner les utilisateurs en cas de changement organisationnel qui pourrait impacter leur manière de travailler.

Avec un niveau de maturité supplémentaire dans l’organisation, l’ASR cherchera à apporter une vue la plus complète possible du processus et à s’assurer que tous les aspects de ces changements ont bien été pris en compte (tests complets, solution de retour arrière...). A ce niveau, il conviendra de se poser les questions suivantes :

• Comment intégrer de façon optimale les processus de gestion des changements et de la mise en production avec la gestion des configurations ?
• Comment communiquer sur les changements apportés à l’infrastructure ?

Par ailleurs, un bilan sera mis en place à partir des points suivants :

• L’implémentation s’est-elle bien passée ?
• Dans le cas d’une réponse négative, la solution de retour arrière a-t-elle pu être réalisée ?
• La planification en termes de ressources était-elle suffisante ?
• L’utilisateur est-il satisfait ?
• Y a-t’il eu un effet de bord non prévu ?

8. Le catalogue de services

Comme nous l’avons vu précédemment, les référentiels ITIL/ISO 20000 préconisent l’établissement d’un catalogue de services sans fournir concrètement de méthodologie de mise en application. L’objet de ce chapitre est donc de donner quelques pistes pour construire un catalogue de services qui ne soit pas un outil de plus à maintenir, mais un véritable moyen de gérer des services avec succès.

8.1 Utilité du catalogue de services

La gestion et l’organisation d’un service SI ne relèvent plus seulement de la gestion « de technologies ». Aujourd’hui, on demande de plus en plus au service informatique de l’unité d’assurer une meilleure visibilité de ses activités, de gérer les risques, d’argumenter ses dépenses et de savoir accompagner les évolutions en concertation avec les « métiers » de l’unité. Un des moyens pour l’ASR d’atteindre ces objectifs est de disposer d’un catalogue de services qui peut devenir la base de la communication avec les métiers présents dans l’unité de recherche suivant les principes énoncés ci-dessous.

Le catalogue de services doit :

• être un moyen essentiel de communication et de coordination avec les métiers de l’unité. A ce titre, il permet de définir clairement et exhaustivement les services proposés, pour quelle population d’utilisateurs et les conditions de leur mise en œuvre. Dès lors, il convient de s’assurer que les services proposés sont bien en phase avec les besoins des utilisateurs ;

• ne pas être mis en place sans avoir fait un état des lieux des services existants ;
• être un outil accessible et de compréhension simple non seulement pour les utilisateurs, mais aussi pour les membres du SI. Il ne doit pas être ressenti comme un inventaire technique et incompréhensible ;
• permettre de disposer d’un langage commun avec les utilisateurs et la direction ;
• être tenu à jour et pouvoir évoluer, les besoins des utilisateurs n’étant pas figés dans le temps ;
• respecter au mieux les bonnes pratiques ITIL/ISO 20000, à savoir être documenté et évalué.

En préambule il est recommandé de prendre en compte les éléments suivants :

• Un utilisateur peut être vu comme un « client » à qui l’on propose un -service dont il a besoin.

• Il faut commencer la démarche avec pragmatisme : recenser les services existants et démarrer sans vouloir être totalement exhaustif avec, par exemple, les services les plus utilisés, les plus demandés ou bien les plus critiques...
• Le catalogue de service doit permettre d’aboutir à de vrais engagements écrits avec ses utilisateurs au travers d’un contrat de service (Service Level Agreement ou SLA).
• Définir des niveaux de mesure (indicateurs, rapports réguliers...).

8.2 La démarche

Les cinq étapes suivantes sont fondamentales et nécessaires au bon fonctionnement de l’unité pour ne pas perdre de vue l’objectif principal qui est de se mettre en phase avec les besoins des utilisateurs :

• constituer un inventaire de l’existant : rassembler dans un premier temps les informations sur les services existants, en relation avec les utilisateurs, dans une phase d’identification des services (les éléments renseignés peuvent prendre comme support la CMDB, si elle a été créée) ;
• compléter ces éléments par la mise en place d’interviews auprès des métiers de manière à identifier des besoins qui n’ont pas encore été traduits en services ;
• définir des critères qui permettront de prioriser les services afin de prendre les décisions de maintenir,
• remplacer, renouveler ou retirer ces services. Cela conduira à établir la liste des services à fournir ;
• fournir une vision synthétique des services pour lesquels le service SI s’engage vis à vis de ses clients dans le cadre de la formalisation d’un contrat de service ;
• communiquer les actions à entreprendre pour mettre en place les services à destination de l’ensemble des utilisateurs et proposer une vision « utilisateur » claire et ergonomique des services fournis (voir figure 3).

Ces différentes étapes devront être validées en relation avec la direction de l’unité, dans le cadre d’une commission informatique d’unité par exemple.

8.3 Identification des services

Cette étape essentielle va consister à réaliser un inventaire et une priorisation des services fournis ou à fournir par le service des systèmes d’information. Compte tenu des liens de dépendances entre services, il est indispensable de référencer les services métiers mais également les services supports ou techniques dont ils dépendent. En effet, on distingue, d’une part, les services directement perceptibles par les utilisateurs dans la pratique de leur métier (services métiers), et d’autre part les services proprement techniques, non directement perceptibles par les utilisateurs mais qui participent à leur soutien.

Exemple : l’installation d’une imprimante réseau est un service métier qui nécessite un service support qui est la gestion d’un serveur d’impression (non visible par le client).

La figure suivante permet de comprendre les relations qu’il faut établir entre services métiers et services supports.

Figure 2 : Corrélation processus métier/support

Pour ce faire, il est intéressant de décrire les services à travers une matrice d’identification des services qui prendra en compte leur état, leur importance ainsi que leur composition (plusieurs niveaux ou imbrications de services).

Nous proposons un modèle d’identification des services à travers une feuille de tableur (tableau ci-après) qui comprend quatre parties distinctes, une partie inventaire, une partie processus et métier, une partie dépendances des services et une partie évaluation des niveaux de service

Tableau 1 : Matrice d’identification de services

Voici brièvement, la description de cette matrice et des sections associées :

• la partie inventaire (colonne 1 à 6) permet de recenser les services et leurs caractéristiques de base, la visibilité éventuelle (dans le catalogue) du service et son état actuel (utilisation, type de gestion et état) ;
• la partie processus (colonne 7) permet d’associer les services décrits aux processus métier correspondants et de fournir un premier élément d’évaluation en fonction de leur criticité (importance pour le métier). Cette colonne, simplifiée pour l’exemple, peut être affinée et faire apparaître un découpage en processus de réalisation, de pilotage et de soutien de l’unité ;
• la partie dépendance (colonne 8) permet de décrire les interactions entre les services métiers et les services supports associés (services techniques qui viennent composer le service principal). Cette description prendra toute son importance lorsqu’il conviendra d’établir la fiche de description d’un service ;
• la partie niveau de service (colonne 9 à 12) permet d’évaluer les services décrits à partir des interviews conduits auprès de l’ensemble des parties prenantes (utilisateurs et service SI).

A partir de cette matrice, le service informatique en concertation avec la direction de l’unité et/ou une commission d’utilisateurs identifiera et validera les services retenus dont l’offre apparaîtra dans le catalogue de services.

8.4 Communiquer l’offre de services

L’étape suivante consiste à communiquer l’offre de service retenue auprès des utilisateurs. Cela peut être envisagé à deux niveaux, d’une part des fiches de description de chaque service et d’autre part une interface proposant une vue client du catalogue de services.

Fiche de description d’un service

Ce niveau de description décrit plus finement les services au travers de fiches unitaires de service qui visent à donner une vision synthétique de chaque service selon un modèle unique (tableau 2).

Il est possible d’élaborer la fiche à partir de la méthode QQOQCCP (Qui, Quoi, Où, Quand, Combien, Comment, Pourquoi) qui est une méthode de travail basée sur un questionnement systématique :

- Qui (quel collaborateur peut bénéficier de ce service) ;
- Quoi (qu’est-ce qu’est le service) ;
- Où (où s’adresser pour du support) ;
- Quand (délai de mise en œuvre et garantie de service) ;
- Combien (estimation du coût du service) ;
- Comment (moyen de demander ce service, et à qui) ;
- Pourquoi (liens utiles dans l’organisation).

La fiche d’identification de service fournit une série d’attributs descriptifs, parmi lesquels par exemple :

- l’objet de la prestation ;
- les moyens d’y accéder ;
- les garanties de la prestation (disponibilité du service, temps d’intervention...) ;
- les responsabilités ;
- le périmètre couvert ;
- l’appellation : le nom du service ;
- les objectifs du service, son utilité, les bénéfices apportés ;
- la disponibilité et la continuité de service ;
- les exceptions et les exclusions ;
- le public concerné ;
- les points de contact ;
- la durée, la pérennité, les plages de fonctionnement du service ;
- les dispositions éventuelles en matière de sécurité ;
- la mesure de la qualité fournie ;
- ...

En ce qui concerne les garanties de la prestation, on peut être amené, selon le cas, à choisir entre une garantie en terme de disponibilité (en spécifiant une durée d’indisponibilité maximale), de temps d’intervention (durée maximale avant intervention après un incident), ou encore une garantie de temps de réponse.

Le Service Level Agreement (SLA) représente ainsi l’engagement que le fournisseur de service prend vis à vis de l’utilisateur.

Tableau 2 : Fiche d’identification de service

Pour améliorer la communication sur l’offre de services, le catalogue de services peut être mis à disposition de l’ensemble des utilisateurs à travers une interface web ergonomique donnant accès aux fiches de description des services décrites précédemment.

Voici ci-dessous un exemple avec le catalogue proposé par l’Université de Genève à travers le site web de la division informatique :

Figure 3 : Exemple de catalogue (https://catalogue-si.unige.ch/)

On pourra également s’inspirer du catalogue de l’Université de Strasbourg.

En conclusion, la mise en place d’un catalogue de service ne se résume pas à développer un outil. Il ne faut pas perdre de vue que l’outil n’est qu’un moyen et non une fin.

Le catalogue de services conduit à structurer et organiser les services offerts. Vis-à-vis des utilisateurs et des partenaires, il devient une interface essentielle car il formalise et rend compte de l’activité du service. A ce double titre, il est réellement intégré dans une démarche qualité. Il doit être ainsi réévalué périodiquement dans le cadre du processus d’amélioration continue (modèle PDCA).