• Ce module permet de construire les savoirs et savoir-faire liés à l'exploitation des services.
• Un service est entendu ici comme le résultat d’une action qui répond à un besoin.
  • Il est mis en œuvre par des composants logiciels ou matériels.
• L'exploitation des services implique de gérer leur qualité, d'assurer leur continuité et leur sécurité.
  • Elle participe à la détection des problèmes et peut être à l’origine d’une demande de changement.

• Ce module s’inscrit soit dans le processus « Production de services » (P1) soit dans le processus «  fourniture de services  » (P2) en prenant appui sur le processus «  Conception et maintenance des solutions d’infrastructures  ».
• Ce module s’appuie sur les savoirs et savoir-faire vus dans les modules SI1, SI2, SI5, SISR1 et SISR2.
• Même si l'on peut s’en inspirer avec profit, ce module n’est pas une réplique du processus « Exploitation des services » d’ITIL V3.

• L’exploitation des services va au-delà de l’installation et de la configuration de base d’un service. Les notions de base ont été vues en SI5 : il s’agit donc bien ici d’un approfondissement.
• On prend en compte la performance d’un service (qui peut-être mesurée en fonction d’un contrat de service), la continuité et la sécurité du service.

• Le mot service est polysémique. On entend ici le service rendu et perçu par l’utilisateur. Le service ne se réduit donc pas à un simple processus « serveur ».
  • Par exemple la téléphonie sur IP peut-être considérée comme un service ou bien encore la « messagerie » ou le « serveur web » associé à un ou plusieurs sites.
• Par contre le DNS ou le DHCP ne sont pas des services perçus par l’utilisateur. On peut prendre un exemple caractéristique, l’accès internet est aujourd’hui un service perçu par l’utilisateur, quand celui-ci tombe on a immédiatement des appels. C’est donc le service perçu, mais pas le service réel, en effet un accès internet défaillant peut être la conséquence de nombreuses causes de dysfonctionnement.

• La notion de cloud computing peut-être étudiée ici dans la mesure où celle-ci distingue « l’application » en contact avec la client, la « plateforme » sur laquelle elle s’exécute et « l’infrastructure » qui supporte l’ensemble. Dans le module SISR3, le service est proche de la notion d’application.
• Dans tous les cas il faudra choisir un ou plusieurs services comme support d’apprentissage.

On peut avoir différentes stratégies d’apprentissage, soit étudier un service en recherchant presque « l’expertise » soit étudier plusieurs services.

Quel que soit le choix didactique, il faudra essayer de dissocier ce qui est spécifique à un service et ce qui est commun à l’ensemble des services, pour toujours essayer de fournir un savoir qui soit à la fois opérationnel et pérenne. Les normes et standard associés à la gestion des services (quand ils existent) doivent être étudiés. .

• Mettre en production
• Exploiter
• Gérer les incidents et les problèmes

• approfondissement des notions vues en SI1 et SI5.
• Ici on s’intéresse de façon détaillée à l’architecture d’un service dans toutes ses composantes :
  • intégration dans un environnement,
  • installation,
  • configuration,
  • tests,
  • scripts d’installation, etc.

• met en place et utilise tous les éléments permettant
  • de mesurer la qualité de service,
  • d’optimiser le service,
  • de tolérer la panne,
  • et de sécuriser un service.
• C’est ici qu’on met en place les éléments permettant de contrôler l’accès au service.
• On peut ici s’intéresser aussi aux phases préalables d’authentification réseau (SISR5) et système (SISR4) avant même la phase d’authentification par le service qui est pris en charge par les habilitations.
• Les habilitations sont prises en charge par le service ou déléguées à un annuaire, dans ce cas la globalité est vue dans le module. Ici le service ne dysfonctionne pas et on vérifie en permanence son «opérationnalité ».

• on insiste sur toutes les procédures associés à la reprise de service et au fonctionnement dégradé mais étudie aussi les difficultés d’une migration vers une nouvelle version sur un service en exploitation (lien avec SI7).
• Ici le service dysfonctionne et on réagit par rapport à ce dysfonctionnement. On s’appuie bien évidemment sur les éléments vus en SISR1 mais en les ’associant à un service déterminé pour lequel des éléments de configuration de qualité, continuité et sécurité ont été configurés.
• Pour les problèmes de migration, il faudra certainement s’appuyer sur la virtualisation. On s’intéressera aux failles de sécurité connues de certains services.