Le MCO informatique emprunte une expression, « maintien en conditions opérationnelles », venue de la défense et de l’industrie, où elle désigne tout ce qui permet à un matériel de rester en état de remplir sa mission. Appliquée à un datacenter, à un réseau ou à une plateforme d’hébergement, elle est devenue une ligne de contrat et un terme vague. Ce texte lui redonne un contenu précis : quatre activités, quatre indicateurs, et les traces qui montrent qu’il est fait.
Une définition qui tient
Dans la définition donnée plus haut, trois mots comptent.
Continue : le MCO commence après la mise en service et ne s’arrête qu’au retrait. Ce n’est pas un projet.
Au niveau attendu : il suppose que le niveau soit défini. Disponibilité, temps de réponse, délai de rétablissement. Sans cible, on ne maintient rien, on répare. Et cette cible n’est jamais 100 %. Le chapitre « Embracing Risk » du livre Site Reliability Engineering de Google le formule ainsi : « 100 % n’est probablement jamais la bonne cible de fiabilité » (traduit de l’anglais).
Dans la durée : il inclut la lutte contre l’usure du logiciel, l’obsolescence des versions, la perte de compétences. Un système qui marche aujourd’hui sur une version qui n’est plus supportée n’est pas maintenu en conditions opérationnelles ; il est en sursis.
Les quatre activités
Les mots « préventif » et « correctif » sont ceux de la norme NF EN 13306, qui fixe le vocabulaire de la maintenance. Le tableau ajoute deux activités propres à l’exploitation d’un logiciel ou d’une infrastructure.
| Activité | Ce qu’elle couvre | Ce qui prouve qu’elle existe |
|---|---|---|
| Préventif | Correctifs, montées de version, remplacement avant fin de support, revue de capacité | Calendrier tenu, part des composants hors support connue et décroissante |
| Correctif | Traitement des incidents, du signalement au rétablissement | Chronologies d’incident horodatées, temps de rétablissement mesuré |
| Évolutif | Changements demandés par les clients ou imposés par l’environnement | Journal des changements, taux de changements sans incident |
| Suivi | Supervision, mesure, revue périodique | Tableau de bord lu, décisions prises à partir de lui |
Une organisation qui fait les quatre sans pouvoir produire la colonne de droite ne sait pas dire si son MCO est tenu. Pour un client hébergé qui demande des comptes après un incident, cela revient à ne pas en faire.
La colonne de droite a une autre vertu. Elle oblige à décider ce que l’on considère comme maintenu. Un composant sans responsable, sans version connue et sans date de fin de support n’est pas maintenu, même s’il fonctionne ce matin. Le MCO commence par cette liste, pas par un contrat.
Les indicateurs qui disent la vérité
Il existe des dizaines d’indicateurs d’exploitation. Quatre suffisent à dire si un MCO est tenu.
Disponibilité des services critiques. Mesurée du point de vue de l’utilisateur, par service et non par serveur. Un serveur disponible qui porte un service en panne ne compte pas.
Temps de rétablissement (MTTR). Mesuré à partir d’horodatages d’outils, pas de souvenirs. Lu en médiane et en 90e centile, pas en moyenne, parce qu’un seul incident de trois jours fausse la moyenne du trimestre. Voir comment le mesurer honnêtement.
Dette d’obsolescence. Part des composants dont la version n’est plus supportée par l’éditeur, ou le sera dans les douze mois. Cet indicateur n’existe que si l’inventaire est à jour, versions comprises.
Taux de changements réussis. Part des changements mis en production sans incident ni retour arrière. Il mesure la maîtrise de l’activité évolutive, celle qui provoque le plus d’incidents.
Ces quatre indicateurs ont une propriété commune : ils ne peuvent pas être produits de mémoire. Ils sortent d’un inventaire, d’une supervision et d’un suivi des incidents qui se parlent.
Chez un opérateur, le préventif se voit chez le client
Chez un hébergeur, un opérateur de datacenters ou un opérateur réseau, une partie du MCO touche des services que d’autres paient. Remplacer un onduleur, monter la version d’un équipement de cœur, intervenir sur une chaîne de froid : c’est du préventif pour l’équipe, c’est une maintenance annoncée pour le client.
Le préventif ne vaut donc que si l’on sait, pour chaque intervention, quels services et quels clients en dépendent. Sans cette réponse, deux dérives apparaissent. Soit on prévient tout le monde, et les avis ne sont plus lus. Soit on prévient au jugé, et un client découvre la coupure en même temps que ses utilisateurs.
La réponse vient encore de l’inventaire, à condition qu’il relie l’équipement, le service et le contrat. Voir comment établir la liste des clients touchés par une maintenance.
Les trois erreurs qui vident le MCO de son sens
Le MCO réduit au contrat. Un prestataire est payé pour « le MCO ». Personne côté client ne lit ses rapports ni ne vérifie ses indicateurs. Le jour de l’incident, on découvre que le périmètre contractuel excluait l’élément tombé.
Pas de responsable par composant. Le MCO est « l’affaire de l’équipe ». Donc de personne. Les correctifs attendent, les fins de support passent inaperçues.
Tout est critique. Si tous les services ont la même priorité, aucun n’en a. Le MCO devient une course sans ordre, et les services vraiment critiques attendent derrière les autres.
Par où commencer
Pas un MCO complet : un MCO dont on peut montrer l’existence, à étendre ensuite.
- L’inventaire. Les services critiques, leurs composants, leurs versions, leur statut de support. Partiel mais exact. Voir la cartographie tenue à jour.
- Les responsables. Un nom par composant. La personne le sait et sait ce qu’on attend d’elle.
- Les indicateurs. Les quatre ci-dessus, calculés à partir des outils existants, même imparfaits. Un premier chiffre vrai vaut mieux qu’un objectif sans mesure.
- La revue. Une heure, les indicateurs sous les yeux, trois décisions prises et notées. Puis la même chose chaque mois.
Une partie de ce travail est mécanique : rapprocher l’inventaire de ce qui tourne, déduire les clients touchés par une intervention. C’est ce que Hopwise Labs inscrit dans vos outils : la liste se déduit des données, vous la validez avant l’envoi.
Questions fréquentes
MCO et MCS, quelle différence ?
Le maintien en conditions opérationnelles (MCO) garantit que le système rend le service attendu : disponibilité, performance, obsolescence maîtrisée. Le maintien en conditions de sécurité (MCS) garantit que son niveau de sécurité ne se dégrade pas : correctifs, durcissement, suivi des vulnérabilités. Les deux se recouvrent largement et reposent sur le même inventaire.
Le MCO, c’est de l’infogérance ?
Non. L’infogérance est un mode de réalisation, par un tiers. Le MCO est l’obligation de résultat elle-même, que l’on exploite en interne ou non. Confier le MCO à un prestataire ne vous dispense pas d’en vérifier les traces.
Quels indicateurs suivre en priorité ?
Quatre suffisent pour commencer : la disponibilité des services critiques, le temps de rétablissement des incidents (MTTR), la part des composants hors support, et le taux de changements réussis sans incident. Ils couvrent les quatre activités du MCO.
Dans un datacenter, le MCO couvre-t-il aussi l’énergie et le froid ?
Souvent, ce sont deux équipes et deux outils : l’une maintient les installations techniques, l’autre les systèmes et les réseaux. Mais une intervention sur une chaîne électrique touche les services hébergés. Les deux calendriers doivent donc s’appuyer sur le même inventaire des dépendances.