Le maintien en condition opérationnelle commence lorsqu’un service passe en exploitation. Une équipe doit pouvoir expliquer ce qu’elle surveille, ce qu’elle entretient, qui décide d’un changement et comment elle prouve que le service peut être rétabli. Un périmètre documenté et des résultats vérifiables permettent au client de suivre la qualité du service.
Définir le service réellement couvert
Le périmètre ne se résume pas à une liste de serveurs. Associez applications, équipements, accès, sauvegardes, contrats fournisseurs et heures de service. Pour chaque composant, indiquez qui possède l’accès, qui autorise une intervention et qui reçoit l’information en cas de dégradation. Si une dépendance est exclue du contrat, elle doit être visible : une panne externe peut affecter le service même si tous les équipements suivis fonctionnent.
- Tenir un inventaire utile à l’intervention, avec les versions et les dépendances critiques.
- Décrire les niveaux de priorité, les canaux d’alerte et les personnes habilitées à décider.
- Revoir ce périmètre après un projet, un déménagement ou un changement de fournisseur.
Entretenir sans créer de nouvelles interruptions
Correctifs, capacité, certificats et droits d’accès exigent un calendrier. Chaque changement sensible doit être préparé : raison, impact attendu, fenêtre d’intervention, vérification après modification et solution de retour arrière. Le fait qu’un correctif soit disponible ne dit pas à lui seul quand ni comment le déployer ; l’exposition, la criticité et les dépendances déterminent l’ordre des actions.
Un compte rendu court après chaque intervention permet de savoir ce qui a changé et qui a validé le retour au service. Les changements répétés qui déclenchent des incidents doivent entraîner une révision de la procédure.
Prouver la capacité de reprise
Une sauvegarde déclarée « réussie » n’est pas une preuve que l’application redémarrera avec des données cohérentes. Définissez avec le métier le temps d’indisponibilité admissible (RTO, objectif de temps de reprise) et la perte de données acceptable exprimée en durée (RPO, objectif de point de reprise). Organisez ensuite des essais de restauration représentatifs. Vérifiez l’accès aux sauvegardes, la dépendance aux identités et les étapes de remise en service. Les objectifs doivent être adaptés à chaque service, sans afficher un engagement irréaliste sur toute l’infrastructure.
La documentation de fiabilité du cadre Azure Well-Architected souligne l’importance d’anticiper les défaillances et de valider le retour au fonctionnement attendu ; ce principe s’applique aussi aux environnements hybrides.
Suivre les indicateurs de service
Un rapport utile présente les incidents par impact, les délais de prise en charge et de rétablissement, les opérations planifiées, les restaurations testées, les changements échoués et les risques ouverts. Il sépare les faits observés des recommandations. Lors d’une revue régulière, le client et l’équipe IT peuvent décider de supprimer une cause récurrente, d’améliorer un guide d’intervention (runbook) ou de faire évoluer le niveau de service.
La valeur du MCO tient à cette boucle entre exploitation, preuve et décision. Elle rend les responsabilités claires et aide à investir là où la continuité en a réellement besoin.
À retenir
Le MCO se pilote avec un périmètre explicite, des contrôles tracés et des tests de reprise, pas seulement avec une promesse de disponibilité.
