MCO cloud : maintien en conditions opérationnelles

Le maintien en conditions opérationnelles d'une infrastructure cloud n'a presque rien à voir avec celui d'un parc de serveurs en salle machine. Dans le cloud public, une partie du travail est faite par le fournisseur (encore faut-il savoir laquelle) et l'autre partie réclame des outils, des automatismes et une discipline d'exploitation que beaucoup de prestataires héritent à tort du monde « on-premise ». Cette page traduit le MCO en pratique réellement cloud : qui patche quoi sur Azure et AWS, quels outils natifs pilotent la supervision et les correctifs, comment se mesurent la disponibilité et le délai de réparation, ce que coûte un dispositif récurrent, et comment garder la maîtrise de votre infrastructure sans dépendre de votre infogérant.

Qu'est-ce que le MCO (maintien en conditions opérationnelles) ?

Le MCO (maintien en conditions opérationnelles) désigne l'ensemble des activités techniques et organisationnelles qui maintiennent un système d'information disponible, performant et sûr tout au long de son cycle de vie en production. Le terme vient du vocabulaire de la défense et de l'aéronautique, où il qualifie l'effort permanent nécessaire pour qu'un équipement reste apte au service. Appliqué à l'informatique, il recouvre la supervision, la correction des incidents, l'application des correctifs, les sauvegardes, la continuité et l'amélioration continue d'un système une fois qu'il est entré en exploitation.

Le périmètre du MCO commence là où s'arrête le projet. Tant qu'une infrastructure est en construction (conception, migration, déploiement), on parle de projet ou de « build ». Dès qu'elle sert des utilisateurs réels, elle entre dans le « run » : c'est le domaine du MCO. La distinction est essentielle, car les deux mondes n'ont ni la même temporalité, ni les mêmes compétences, ni la même logique économique. Un projet a un début et une fin ; le MCO est récurrent par nature et se mesure dans la durée.

En une phrase : le MCO, c'est tout ce qui maintient votre infrastructure debout, rapide et protégée jour après jour, une fois qu'elle est en production, par opposition au projet qui l'a construite.

Concrètement, un dispositif de MCO répond à des questions très opérationnelles : qui est alerté quand un serveur tombe à 3 h du matin ? Sous combien de temps un correctif de sécurité critique est-il déployé ? Que se passe-t-il quand une base de données sature ? Qui décide d'une fenêtre de maintenance ? Comment restaure-t-on un service après une erreur de manipulation ? Le MCO transforme ces questions en procédures, en automatismes et en engagements mesurables. Sans lui, une infrastructure même parfaitement conçue dérive lentement vers l'instabilité, la dette de sécurité et l'imprévisibilité des coûts, un phénomène que nous traitons en profondeur sur la page infrastructure cloud instable.

Pourquoi le MCO est un sujet à part entière

Trop d'organisations considèrent l'exploitation comme un coût subi plutôt que comme une discipline. Le résultat est connu : un parc dont personne ne connaît plus exactement le contenu, des correctifs en retard de plusieurs mois, des sauvegardes jamais testées, des coûts qui dérivent. Le MCO existe précisément pour éviter cette entropie. Il s'inscrit dans les cadres de référence de la gestion des services informatiques (ITIL et plus largement ITSM) qui formalisent la gestion des incidents, des problèmes, des changements et des niveaux de service. Mais dans le cloud, ces cadres se réinventent autour de pratiques DevOps, SecOps et FinOps qui font de l'exploitation une activité largement automatisée et pilotée par la donnée.

MCO informatique vs MCO cloud : ce qui change vraiment

Le MCO « informatique » classique a été pensé pour des infrastructures que l'on possède : des serveurs physiques, un système de stockage, un réseau, un hyperviseur. Dans ce monde, maintenir en conditions opérationnelles signifie surveiller du matériel, remplacer des disques, appliquer des correctifs sur des systèmes d'exploitation que l'on administre de bout en bout, et gérer un cycle de vie matériel (garantie, fin de support, renouvellement). Les outils historiques de ce monde sont eux-mêmes « on-premise » : supervision réseau type Nagios ou Centreon, GMAO pour le suivi des équipements, ordonnanceurs de tâches.

Le MCO cloud change la nature même du travail sur trois points fondamentaux.

• Le matériel disparaît du périmètre client. Vous ne gérez plus de disques, d'alimentations ni d'hyperviseurs : le fournisseur s'en charge. À la place, vous gérez des services (machines virtuelles, bases managées, fonctions, conteneurs) dont une partie de l'exploitation est déjà assurée. La frontière de ce qui reste à votre charge est définie par le modèle de responsabilité partagée, détaillé plus bas. C'est le concept central du MCO cloud, et celui que la quasi-totalité des contenus en ligne ignore.
• L'exploitation devient logicielle. Dans le cloud, on ne « va pas voir le serveur » : on interroge une API, on lit des métriques, on déclenche un correctif via un service de gestion de parc, on reconstruit un environnement à partir de code. Le MCO cloud est programmable, ce qui le rend automatisable à un degré inaccessible au monde physique.
• Les coûts deviennent variables et pilotables en exploitation. En salle machine, le coût est figé : le serveur est acheté, amorti. Dans le cloud, la facture varie chaque mois selon l'usage. Maintenir un cloud en conditions opérationnelles inclut donc, de façon native, la maîtrise continue des coûts (le FinOps) qui devient un pilier du MCO et non une discipline annexe.

Le piège le plus courant : appliquer au cloud des réflexes d'exploitation hérités du datacenter. Surveiller un cloud comme on surveillait des serveurs physiques, c'est passer à côté de l'automatisation native, sur-payer de la capacité dormante et croire à tort que « le cloud se gère tout seul ». Ni l'un ni l'autre : le cloud ne se gère pas tout seul, mais il se gère autrement.

Cette spécificité cloud est exactement ce qui distingue un infogérant généraliste d'un prestataire spécialisé Azure et AWS. Le socle du MCO cloud relève de notre infogérance cloud entreprise, dont cette page est une déclinaison thématique.

MCO, TMA et MCS : trois périmètres à ne pas confondre

Trois sigles voisins génèrent une confusion permanente. Les distinguer est indispensable pour cadrer un contrat sans angle mort ni double facturation.

Le MCO (maintien en conditions opérationnelles) porte sur l'infrastructure et la plateforme : serveurs, réseau, stockage, bases de données, conteneurs, services cloud. Son objectif est que le socle technique reste disponible, performant et sûr.

La TMA (tierce maintenance applicative) porte sur le logiciel applicatif : le code des applications métier, leurs évolutions fonctionnelles, la correction de bugs applicatifs, les montées de version du logiciel lui-même. Une TMA maintient l'application ; un MCO maintient le terrain sur lequel elle tourne.

Le MCS (maintien en conditions de sécurité) est le volet sécurité du maintien en condition : application des correctifs de sécurité, gestion des vulnérabilités, durcissement, conformité aux référentiels, surveillance des menaces. Le MCS est souvent décrit comme un sous-ensemble exigeant du MCO, centré sur la posture de sécurité. Dans le cloud, il s'appuie sur des outils dédiés (détection de menaces, gestion de posture) que nous détaillons plus loin et que nous traitons en profondeur sur la page sécurisation infrastructure cloud.

| Critère | MCO | TMA | MCS | |---|---|---|---| | Objet maintenu | Infrastructure et plateforme | Logiciel applicatif (le code métier) | Posture de sécurité du système | | Question centrale | Le socle tient-il et est-il rapide ? | L'application fait-elle ce qu'elle doit ? | Le système est-il à jour et protégé ? | | Activités types | Supervision, patch OS, sauvegarde, continuité | Correction de bugs, évolutions fonctionnelles | Patch sécurité, gestion des CVE, durcissement, conformité | | Compétences | Ops / cloud / réseau | Développement applicatif | SecOps / RSSI | | Relation | Socle du « run » | Au-dessus du MCO | Volet sécurité du MCO |

À retenir : MCO, TMA et MCS se recouvrent partiellement mais ne se substituent pas. Une organisation a généralement besoin des trois. Le danger d'un contrat flou est qu'un correctif de sécurité urgent tombe « entre » le MCO et le MCS, ou qu'une montée de version applicative soit réclamée au titre du MCO alors qu'elle relève de la TMA. Un périmètre écrit noir sur blanc évite ces zones grises coûteuses.

MCO et infogérance : quelle différence ?

On confond souvent MCO et infogérance, car les deux relèvent du « run ». La distinction est de nature, pas de degré. Le MCO est une activité : l'ensemble des tâches de maintien en condition. L'infogérance est un mode de réalisation : confier tout ou partie de l'exploitation (dont le MCO) à un prestataire externe. On peut donc faire du MCO en interne sans aucune infogérance, ou externaliser son MCO via un contrat d'infogérance. L'infogérance englobe généralement plus large que le seul MCO : gestion du parc, support utilisateurs, gouvernance, pilotage. Dit autrement, le MCO est l'une des prestations cœur d'un contrat d'infogérance, mais l'infogérance ne se réduit pas au MCO.

Les types de maintenance : préventive, corrective, adaptative, évolutive, prédictive

Le MCO ne se réduit pas à « réparer quand ça casse ». Cinq familles de maintenance, héritées des normes de maintenance industrielle et transposées à l'informatique, structurent l'activité. Les distinguer permet de calibrer un contrat et de comprendre ce que l'on paie.

• Maintenance corrective : intervenir après la panne pour rétablir le service. C'est la maintenance réactive, déclenchée par un incident. Indispensable mais coûteuse si elle devient le mode dominant : une infrastructure qui ne vit qu'en corrective est une infrastructure mal maintenue.
• Maintenance préventive : agir avant la panne, à intervalle planifié ou selon un état observé, pour réduire la probabilité de défaillance. Appliquer les correctifs avant qu'une faille ne soit exploitée, renouveler les certificats avant expiration, vérifier les sauvegardes : autant d'actes préventifs.
• Maintenance adaptative : ajuster le système aux changements de son environnement sans modifier sa fonction. Dans le cloud, c'est par exemple suivre la dépréciation d'une version de service managé, migrer vers un type d'instance dont l'ancien est retiré, s'adapter à une évolution d'API du fournisseur.
• Maintenance évolutive : faire évoluer le système pour répondre à de nouveaux besoins (nouvelle fonctionnalité d'infrastructure, montée en charge, nouvelle région). Elle ajoute de la valeur plutôt que de la maintenir, et chevauche le territoire du projet.
• Maintenance prédictive : anticiper la défaillance en analysant les données de fonctionnement (tendances, anomalies) pour intervenir au bon moment, ni trop tôt ni trop tard. Dans le cloud, elle s'appuie sur les métriques de supervision et, de plus en plus, sur l'AIOps : l'application de l'analyse de données et de l'apprentissage automatique à l'exploitation pour détecter des signaux faibles avant l'incident.

| Type | Déclencheur | Objectif | Exemple cloud | |---|---|---|---| | Corrective | Après l'incident | Rétablir le service | Redémarrer un service tombé, restaurer une base corrompue | | Préventive | Planifié / état observé | Réduire le risque de panne | Appliquer les correctifs mensuels, renouveler un certificat TLS | | Adaptative | Changement d'environnement | Rester compatible | Migrer une instance dont le type est déprécié | | Évolutive | Nouveau besoin | Ajouter de la capacité/fonction | Étendre une architecture à une nouvelle région | | Prédictive | Signal faible dans la donnée | Anticiper la défaillance | Détecter une saturation disque par tendance avant l'alerte |

Le bon équilibre : une exploitation mature bascule progressivement de la corrective vers la préventive et la prédictive. Plus la part de corrective est élevée, plus l'infrastructure subit ; plus la part de préventive et prédictive monte, plus elle est maîtrisée. Mesurer cette répartition est l'un des indicateurs de maturité d'un dispositif de MCO.

Les piliers du MCO cloud

Un dispositif de MCO cloud crédible repose sur six piliers. Les cinq premiers sont communs à tout MCO ; le sixième (le FinOps) est spécifique au cloud et largement absent des approches traditionnelles.

1. Supervision : le système nerveux du Run

On ne maintient que ce que l'on voit. La supervision est le système nerveux du « run » : elle capte en continu l'état des composants et déclenche les alertes qui mettent la maintenance en mouvement. Pour le MCO, son rôle est précis : c'est elle qui fait basculer une infrastructure de la maintenance corrective (réagir après la panne) vers la préventive et la prédictive (agir sur le signal faible avant l'incident). La taxonomie complète (supervision vs monitoring vs observabilité, métriques/logs/traces, NOC et astreinte humaine, outils de détection) fait l'objet de notre page dédiée : supervision cloud 24/7 : monitoring vs observabilité.

2. Gestion des correctifs (patch management)

Maintenir à jour les systèmes d'exploitation, les middlewares et les composants est l'acte de maintenance le plus structurant, et le plus négligé. Un parc en retard de correctifs accumule des vulnérabilités (CVE) exploitables. Le patch management organise l'inventaire des composants, l'évaluation des correctifs disponibles, leur test, puis leur déploiement maîtrisé. Dans le cloud, ce travail s'appuie sur des services dédiés que nous nommons plus bas, et il se complique de la question : quels correctifs sont à ma charge, et lesquels le fournisseur applique-t-il pour moi ?

3. Sécurité et conformité (MCS)

Le volet sécurité du MCO surveille la posture du système : configurations à risque, vulnérabilités, écarts par rapport aux référentiels (CIS Benchmarks), conformité réglementaire (RGPD, sectorielle). Il s'appuie sur des outils de gestion de posture (CSPM) et de détection des menaces. Ce pilier rejoint les recommandations de l'ANSSI et structure le quotidien d'un RSSI.

4. Sauvegarde et restauration

Sauvegarder ne suffit pas : il faut pouvoir restaurer, et l'avoir prouvé. Le MCO inclut la politique de sauvegarde (fréquence, rétention, isolement), la protection contre l'altération (sauvegardes immuables contre les rançongiciels) et, surtout, le test régulier de restauration. Une sauvegarde jamais restaurée n'est pas une protection, c'est une hypothèse.

5. Continuité d'activité (PRA / PCA)

Le MCO entretient les dispositifs de continuité : le PRA (plan de reprise d'activité) et le PCA (plan de continuité d'activité), avec leurs objectifs chiffrés de temps de reprise (RTO) et de perte de données tolérée (RPO). Maintenir en condition, c'est aussi garder ces plans à jour et les tester régulièrement, faute de quoi ils deviennent des fictions. Nous traitons ce sujet en profondeur sur PRA cloud et PCA cloud.

6. FinOps : la maîtrise des coûts en exploitation

C'est le pilier que personne n'associe au MCO, et c'est une erreur dans le cloud. Une infrastructure cloud dont les coûts dérivent n'est pas en conditions opérationnelles : elle gaspille. Le FinOps intégré au MCO surveille la facture en continu, redimensionne les ressources sur-provisionnées (rightsizing), éteint les environnements hors usage, applique une politique d'étiquetage (tagging) pour imputer les coûts, et exploite les engagements (Savings Plans, Reserved Instances) pour réduire le coût des charges stables. Membre de la FinOps Foundation, notre réseau de prestataires traite ce pilier nativement : voir optimisation coûts cloud et notre audit FinOps.

Six piliers, un seul objectif : que votre infrastructure reste disponible, rapide, sûre, restaurable, continue et économiquement maîtrisée. Un MCO qui assure les cinq premiers piliers mais laisse filer les coûts n'est pas complet dans le cloud. C'est la différence entre un infogérant qui « fait tourner » et un prestataire qui pilote.

Le cœur du sujet : le MCO en environnement cloud public

C'est ici que le MCO cloud se sépare radicalement du MCO classique. Trois notions structurent tout : le modèle de responsabilité partagée, les outils cloud-natifs, et la gestion du parc en code. Les ignorer revient à exploiter un cloud comme un datacenter, l'erreur la plus répandue.

Le modèle de responsabilité partagée : qui patche quoi ?

Dans le cloud public, le fournisseur et le client se partagent la responsabilité de la sécurité et de l'exploitation. La règle générale, formulée par AWS comme par Microsoft, distingue la sécurité du cloud (assurée par le fournisseur) de la sécurité dans le cloud (à la charge du client). Mais la frontière exacte dépend du type de service consommé. C'est la subtilité que la plupart des contenus omettent.

• Pour une machine virtuelle (IaaS) : le fournisseur gère le matériel, la couche de virtualisation et le réseau physique. Le client reste responsable du système d'exploitation invité (et donc de ses correctifs), des middlewares, des applications, des données et de la configuration réseau logique. Autrement dit, patcher l'OS d'une VM Azure ou EC2 reste votre responsabilité : le fournisseur ne le fait pas pour vous.
• Pour un service managé (PaaS), comme une base de données managée ou une fonction : le fournisseur prend en charge le système d'exploitation sous-jacent et le moteur, y compris une grande partie des correctifs. Le client se concentre sur la configuration, les accès et les données. Le périmètre de patch management du client se réduit nettement.
• Pour un service entièrement managé (SaaS / serverless) : l'essentiel de l'exploitation est assuré par le fournisseur ; le client gère surtout ses données, ses accès et sa configuration.

| Couche | IaaS (VM / EC2) | PaaS (base managée, fonction) | SaaS / serverless | |---|---|---|---| | Matériel, datacenter | Fournisseur | Fournisseur | Fournisseur | | Virtualisation, réseau physique | Fournisseur | Fournisseur | Fournisseur | | OS invité + correctifs OS | Client | Fournisseur | Fournisseur | | Runtime / moteur (BDD, langage) | Client | Fournisseur | Fournisseur | | Application | Client | Client | Partiel | | Configuration, accès (IAM) | Client | Client | Client | | Données | Client | Client | Client |

La conséquence opérationnelle : sur une architecture IaaS, votre MCO doit organiser le patch management de chaque OS invité : Azure et AWS ne le font pas à votre place. En migrant vers du PaaS et du managé, vous transférez une partie de cette charge au fournisseur. Choisir le bon niveau de service est donc, aussi, une décision de MCO : plus c'est managé, moins vous exploitez, mais moins vous maîtrisez finement. Cet arbitrage fait partie de notre travail de conseil architecture.

Comprendre cette frontière dissipe deux mythes opposés et également faux : « le cloud est sécurisé par défaut, je n'ai rien à faire » et « le cloud m'oblige à tout gérer moi-même ». La vérité est contractuelle et dépend du service.

Les outils cloud-natifs du MCO (Azure et AWS)

Le MCO cloud s'opère avec des services intégrés aux plateformes, pas avec des outils on-premise transposés. En nommer précisément quelques-uns donne la mesure de ce qu'un dispositif moderne mobilise, et de ce qui distingue un prestataire réellement cloud.

Sur Microsoft Azure :

• Azure Monitor : la plateforme d'observabilité (métriques, logs via Log Analytics, alertes, tableaux de bord). Le poste de pilotage de la supervision.
• Azure Update Manager : la gestion centralisée des correctifs des machines virtuelles (Windows et Linux), avec évaluation, planification et déploiement par fenêtres de maintenance.
• Microsoft Defender for Cloud : la gestion de posture de sécurité (CSPM) et la protection des charges (CWPP) : recommandations, score de sécurité, détection des menaces. Cœur du MCS sur Azure.
• Azure Policy : l'application automatique de règles de gouvernance et de conformité (chiffrement obligatoire, régions autorisées, étiquetage imposé). Empêche la dérive de configuration à la source.
• Azure Automation : l'automatisation des tâches récurrentes d'exploitation (runbooks, configuration, extinction planifiée).

Sur Amazon Web Services :

• Amazon CloudWatch : les métriques, logs et alarmes, l'équivalent fonctionnel d'Azure Monitor.
• AWS Systems Manager Patch Manager : la gestion des correctifs des instances (EC2 et serveurs hybrides), avec lignes de base de correctifs et déploiement orchestré.
• AWS Security Hub : l'agrégation et la priorisation des constats de sécurité, avec contrôles alignés sur des référentiels (dont CIS).
• AWS Config : l'inventaire et l'évaluation continue de la conformité des configurations, avec historique et règles.

Pourquoi nommer ces outils compte : un prestataire qui parle encore de Nagios et de GMAO pour superviser un cloud public n'a pas opéré le virage. Le MCO cloud se pilote depuis la console et les API du fournisseur, avec les services ci-dessus, souvent complétés d'outils d'observabilité tiers. Notre exploitation s'appuie nativement sur ces briques : voir nos approches architecte Azure et infrastructure DevOps.

Le cycle de vie d'un correctif en environnement cloud 24/7

Appliquer un correctif sur une infrastructure qui sert des utilisateurs en permanence ne s'improvise pas. Un cycle maîtrisé suit des étapes claires :

1. Inventaire et veille CVE : connaître précisément les composants en production et suivre les vulnérabilités publiées qui les concernent.
2. Évaluation et priorisation : tous les correctifs ne se valent pas. Une CVE critique activement exploitée justifie un déploiement en urgence ; un correctif mineur attend la fenêtre planifiée.
3. Test sur un environnement de pré-production : valider que le correctif ne casse rien avant de le pousser en production.
4. Déploiement échelonné (canary / par vagues) : appliquer d'abord à un sous-ensemble, observer, puis généraliser. On ne patche jamais tout le parc d'un coup.
5. Fenêtres de maintenance : planifier les opérations à impact dans des créneaux convenus, communiqués à l'avance.
6. Capacité de retour arrière (rollback) : pouvoir revenir à l'état antérieur si le correctif provoque une régression. Dans le cloud, l'Infrastructure as Code et les instantanés rendent ce retour rapide et fiable.

L'arbitrage du jour J : entre laisser une faille critique ouverte et risquer une régression en patchant en urgence, le bon dispositif de MCO a déjà prévu les deux : une procédure d'urgence pour les CVE critiques et un rollback testé. La maturité ne se mesure pas à l'absence d'incident, mais à la vitesse et à la propreté de la réaction.

MCO Kubernetes (AKS / EKS)

Les clusters Kubernetes managés (AKS sur Azure, EKS sur AWS) ajoutent une dimension propre au MCO. Maintenir un cluster en conditions opérationnelles, c'est notamment :

• Gérer les versions : Kubernetes suit un rythme de versions soutenu et chaque version a une fenêtre de support limitée. Le MCO planifie les mises à jour de cluster (plan de contrôle et nœuds) avant la fin de support, sans interrompre les charges.
• Maîtriser les accès : le RBAC (contrôle d'accès par rôles) définit qui peut faire quoi dans le cluster, un point de sécurité majeur en exploitation.
• Sécuriser les charges : application des politiques de sécurité des pods, des network policies et du contrôle d'admission pour empêcher les déploiements non conformes.
• Patcher les images : les conteneurs embarquent leurs propres dépendances ; maintenir leurs images à jour relève du MCO autant que l'OS des nœuds.

Ce volet exige une expertise spécifique, que nous portons via nos pratiques consultant Kubernetes et l'audit Kubernetes.

Infrastructure as Code et gestion du drift

Dans un MCO cloud mature, l'infrastructure n'est pas administrée à la main : elle est décrite en Infrastructure as Code (Terraform, Bicep), versionnée dans des dépôts. Cela change l'exploitation en profondeur. Toute modification passe par un cycle plan / apply revu et traçable, plutôt que par des clics manuels non documentés. Surtout, le MCO surveille le drift : l'écart entre l'état décrit dans le code (le state) et l'état réel de l'infrastructure. Un changement appliqué directement en console, hors code, crée une dérive qui rend l'environnement non reproductible et fragilise la prochaine restauration. Détecter et résorber ce drift est une activité de MCO à part entière.

L'avantage décisif de l'IaC en exploitation : une infrastructure décrite en code se reconstruit à l'identique, s'audite et se restaure rapidement. Et comme ce code vit dans vos dépôts, votre exploitation ne dépend plus du savoir d'une personne ou de la mémoire d'un prestataire. C'est le socle de votre autonomie, et l'inverse de l'enfermement.

Multi-cloud et hybride : gouverner un parc réparti

Beaucoup d'organisations exploitent un parc réparti : des charges sur Azure, d'autres sur AWS, et parfois des serveurs encore on-premise. Le MCO d'un tel ensemble exige une gouvernance unifiée : une vision consolidée de la supervision, des correctifs et de la conformité à travers des environnements hétérogènes. C'est précisément là qu'un intermédiaire indépendant, capable de comparer et de coordonner les deux hyperscalers, apporte une valeur qu'un prestataire mono-cloud ne peut offrir. La cohérence du pilotage prime sur la multiplication des consoles, sujet que nous abordons aussi sous l'angle gouvernance cloud.

Supervision, incidents et niveaux de support N1 / N2 / N3

Quand un incident survient, l'efficacité tient à l'organisation du support. Trois niveaux structurent classiquement la réponse :

• N1 (premier niveau) : réception et qualification de l'alerte ou de la demande, traitement des incidents courants selon des procédures établies, escalade si nécessaire. Souvent opéré par un NOC (Network Operations Center) pour l'exploitation, ou un SOC (Security Operations Center) pour la sécurité.
• N2 (deuxième niveau) : diagnostic technique approfondi, résolution des incidents qui dépassent les procédures de N1. Compétences cloud confirmées.
• N3 (troisième niveau) : expertise pointue : architecture, ingénierie, correction de fond, intervention sur le code ou la configuration profonde. C'est le niveau qui traite les incidents complexes et alimente l'amélioration continue.

Un cycle de gestion d'incident bien rodé suit la logique ITIL : détection → qualification → priorisation → résolution → clôture → revue. Les incidents récurrents font l'objet d'une gestion des problèmes distincte, qui cherche la cause racine pour qu'ils ne se reproduisent plus : la différence entre éteindre l'incendie et supprimer ce qui l'allume.

Les métriques qui pilotent un MCO (et la part contractuelle du SLA)

Un MCO se pilote par des indicateurs chiffrés de maintenance. C'est là que la plupart des contenus restent vagues ; nous chiffrons, et nous distinguons ce qui relève de la maintenance (notre angle propre) de ce qui relève du contrat de service.

SLA, GTI, GTR : la part contractuelle

Un MCO s'exécute sous un SLA (Service Level Agreement) : disponibilité visée, délai de prise en compte (GTI) et délai de résolution (GTR) par niveau de gravité, plages de couverture. Mais la grille chiffrée de ces engagements, leurs définitions contractuelles et les pénalités associées relèvent du contrat-cadre d'exploitation : retrouvez la grille SLA, GTI et GTR contractuelle de l'infogérance. Côté MCO, ce qui nous appartient en propre, ce sont les métriques de maintenance qui prouvent, mois après mois, que ces engagements sont tenus dans la durée.

Les indicateurs propres au maintien en condition

| Indicateur | Définition | Ce qu'il mesure | |---|---|---| | Disponibilité | % de temps où le service est opérationnel | La continuité réelle du service | | MTTR (Mean Time To Repair) | Temps moyen de réparation après un incident | La rapidité de remise en service | | MTBF (Mean Time Between Failures) | Temps moyen entre deux pannes | La fiabilité du système | | Délai de réaction | Temps entre l'alerte et la prise en charge | La réactivité du dispositif | | Taux de correctifs à jour | % de composants au niveau de patch attendu | La dette de sécurité |

La disponibilité s'exprime en « neuf » : 99,9 % autorise environ 8 h 45 d'indisponibilité par an ; 99,95 % environ 4 h 23 ; 99,98 % environ 1 h 45 ; 99,99 % environ 52 minutes. Chaque neuf supplémentaire coûte significativement plus cher en architecture (redondance, multi-région) et en exploitation. Le bon niveau se choisit par criticité, pas par principe.

Sur les chiffres : les niveaux de disponibilité que nous citons (99,9 %, 99,98 %) et les délais de réaction sont des cibles constatées sur des dispositifs comparables et visées contractuellement, jamais des résultats garantis dans l'absolu. Aucune architecture ne garantit zéro incident ; un MCO sérieux garantit en revanche une méthode de réaction et de mesure. Méfiez-vous de tout prestataire qui promet « 100 % de disponibilité » ou « zéro panne » : c'est commercialement séduisant et techniquement faux.

Internaliser ou externaliser le MCO : le réflexe « maintenance »

Faut-il opérer son MCO en interne ou le confier à un prestataire ? Du point de vue de la maintenance, la question se ramène à une seule : pouvez-vous tenir une astreinte de patch et de réponse à incident 24/7, avec des compétences cloud rares, sans faire reposer tout le maintien en condition sur une poignée de sachants ? Quand le parc grossit et que la criticité impose une couverture permanente, internaliser une maintenance qui reste surtout corrective devient coûteux et fragile.

Une approche hybride est souvent la plus saine : l'équipe interne (ou la DSI) garde la gouvernance, le pilotage stratégique et la connaissance métier ; le prestataire opère le « run » et la maintenance préventive 24/7, et apporte l'expertise cloud pointue. L'analyse économique complète (TCO interne vs externalisé, modèles de tarification, seuils de bascule) est développée dans le TCO et le choix interne vs externalisé en infogérance.

Le vrai risque de l'externalisation n'est pas le coût, c'est l'enfermement. Un infogérant qui détient seul votre code IaC, vos comptes et votre documentation vous rend captif : changer de prestataire devient un projet à part entière. C'est exactement ce que nous refusons par construction (voir plus bas, la réversibilité).

Qui gère le MCO ? DSI, ESN, infogérant, équipe interne

Plusieurs acteurs peuvent porter le MCO. La DSI en assure généralement la gouvernance et l'arbitrage. Une équipe interne d'exploitation peut l'opérer directement quand la taille et les compétences le permettent. Une ESN (entreprise de services du numérique) ou un infogérant prennent en charge tout ou partie de l'exploitation par contrat. Sur les aspects sécurité, le RSSI pilote le MCS, souvent appuyé par un SOC. Dans le cloud, la frontière des responsabilités intègre aussi le fournisseur (Azure, AWS) au titre du modèle de responsabilité partagée. Un MCO cloud bien gouverné explicite qui fait quoi entre ces acteurs, par écrit.

Mettre en place le dispositif de maintenance

La méthodologie générique de reprise d'une infrastructure existante (audit initial, transition, transfert de connaissance, plan de bascule) est décrite dans la reprise d'infrastructure et l'onboarding d'infogérance. Deux étapes, en revanche, sont propres au MCO et conditionnent toute la maintenance qui suivra :

1. L'inventaire du parc à maintenir : ressources, versions, dépendances, niveau de correctifs et configuration. Sans cet état des lieux, on patche à l'aveugle et la maintenance préventive est impossible. C'est l'objet d'un audit d'infrastructure cloud.
2. La définition des fenêtres et procédures de maintenance : runbooks de patch, cycle de validation et de rollback des correctifs, calendrier des mises à jour de cluster, seuils de supervision et règles d'escalade N1/N2/N3. C'est ce qui transforme la maintenance en mécanique répétable plutôt qu'en réaction d'urgence.

Une fois ces fondations posées, le « run » démarre avec mesure des métriques (MTTR, MTBF, taux de conformité de patch) dès le premier jour, puis amélioration continue : réduction progressive de la part de corrective au profit de la préventive et de la prédictive.

Les bénéfices du MCO pour l'entreprise

Un MCO bien mené produit des effets mesurables et stratégiques :

• Disponibilité : moins d'interruptions, des reprises plus rapides, une continuité de service qui protège le chiffre d'affaires et l'image.
• Performance : des systèmes surveillés et ajustés restent rapides ; la dérive de latence est détectée tôt. Sujet voisin des applications lentes dans le cloud.
• Sécurité : un parc à jour réduit la surface d'attaque ; la dette de vulnérabilités ne s'accumule pas.
• Productivité : les équipes internes se concentrent sur la valeur métier plutôt que sur l'extinction d'incendies.
• Prévisibilité des coûts : avec le pilier FinOps, la facture cesse de surprendre et devient un levier piloté.
• Sérénité de la direction : un dispositif mesuré et reporté transforme l'incertitude opérationnelle en risque maîtrisé.

Conformité dans le MCO : l'apport propre du maintien en condition

Le « run » est le moment où la conformité se vit, pas seulement où elle se déclare, et l'apport propre du MCO est concret : c'est le patch management et le maintien en conditions de sécurité (MCS) qui tiennent, jour après jour, les exigences de disponibilité, d'intégrité et de résilience. Un parc à jour de ses correctifs, des sauvegardes testées, une posture durcie selon les CIS Benchmarks et mesurée en continu (via Defender for Cloud, Security Hub, AWS Config) : voilà ce que la maintenance apporte directement à un dossier de conformité.

Les définitions des cadres réglementaires transverses, RGPD (responsable de traitement / sous-traitant), ISO 27001, HDS, NIS2, DORA, et la grille de conformité consolidée relèvent du contrat-cadre d'exploitation : voir la conformité RGPD, HDS, NIS2 et DORA en infogérance. Deux rappels propres au MCO : pour les données de santé, l'hébergement se fait chez un partenaire certifié HDS (la certification vise l'hébergeur, jamais Architecte Cloud ni votre configuration, voir secteur santé) ; et les livrables d'exploitation s'inscrivent dans une démarche ISO 27001. Ce volet rejoint notre travail de cybersécurité cloud.

Combien coûte un MCO cloud ? Durée, livrables et budget

Les facteurs de coût

Le budget d'un MCO cloud dépend de plusieurs paramètres :

• L'étendue du parc : nombre de ressources, de comptes/abonnements, d'environnements à maintenir.
• Le niveau de service : une couverture 24/7 avec astreinte coûte plus qu'une couverture en heures ouvrées ; chaque « neuf » de disponibilité supplémentaire renchérit le dispositif.
• Le périmètre : socle infrastructure seul, ou avec MCS, FinOps, gestion Kubernetes, multi-cloud.
• La conformité : un cadre HDS ou DORA ajoute des exigences et donc du coût.
• La maturité de départ : une infrastructure déjà décrite en IaC, documentée et supervisée s'exploite à moindre effort.

Durée et modèle de facturation

Le MCO est par nature récurrent : il se facture le plus souvent au forfait mensuel (un montant convenu pour un périmètre et des SLA définis), parfois à l'usage ou en unités d'œuvre pour les interventions hors forfait. La consommation cloud elle-même (votre facture Azure/AWS) reste distincte et à votre nom : nous n'y prenons aucune marge cachée.

À titre indicatif et sur devis selon le périmètre, un dispositif de MCO cloud récurrent se situe couramment dans une fourchette de l'ordre de 3 000 à 12 000 € par mois. Le bas de la fourchette correspond à un socle d'infrastructure de taille modérée en supervision et patch management ; le haut, à un parc étendu, en 24/7, avec MCS avancé, FinOps actif, exploitation Kubernetes et exigences de conformité.

Un dispositif de MCO comprend généralement :

• La supervision continue et la gestion des alertes (observabilité, tableaux de bord).
• Le patch management des composants à votre charge, selon le modèle de responsabilité partagée.
• La gestion des incidents avec niveaux de support et SLA, et le reporting associé.
• La gestion de posture de sécurité (MCS) et le suivi de conformité.
• La sauvegarde et les tests de restauration, l'entretien des plans de continuité (PRA/PCA).
• Le pilotage FinOps : suivi de la facture, rightsizing, extinction hors usage, recommandations d'engagements.
• Un reporting périodique à la DSI et à la direction (indicateurs, incidents, coûts, sécurité), en langage clair.

Sur le budget : cette fourchette de 3 000 à 12 000 € par mois est un repère indicatif pour cadrer une discussion, jamais un prix ferme. Le devis précis dépend de votre parc réel, établi après un échange. Coûts clairs, aucun engagement caché : c'est notre règle. La consommation cloud sous-jacente reste sur vos comptes, à votre nom.

Internaliser, externaliser : et garder la maîtrise : notre approche

Beaucoup d'acteurs proposent du MCO et de l'infogérance. Trois principes nous distinguent, et ils répondent au risque numéro un de l'externalisation : l'enfermement.

• Indépendance : intermédiaire indépendant sur Azure et AWS. Les prestataires de notre réseau opèrent votre exploitation sans parti pris hyperscaler ni revente d'outils, et nous recommandons toujours ce qui sert votre intérêt, y compris vous orienter vers du managé pour réduire votre charge de MCO.
• Autonomie : tout ce qui est construit et exploité vous appartient. Le code Infrastructure as Code (Terraform, Bicep), les runbooks et la documentation vivent dans vos dépôts, sur vos comptes cloud, à votre nom. Votre exploitation n'est captive de personne.
• Réversibilité : vous pouvez reprendre la main ou changer de prestataire sans rupture, parce que rien n'est verrouillé chez nous. C'est une exigence de bon sens, et une obligation pour les acteurs soumis à DORA. La réversibilité est une condition d'entrée de nos contrats, pas une option.

Nos atouts : un réseau de prestataires expérimentés, partenaires Microsoft Azure (Solutions Partner for Infrastructure) et AWS (Advanced Tier Services), disposant des certifications requises (Azure Solutions Architect Expert, AWS DevOps Engineer Pro, CISSP, Azure Security Engineer, FinOps Certified Practitioner), en démarche ISO 27001, membre de la FinOps Foundation. Découvrez notre approche et l'ensemble de nos services.

Choisir un prestataire de MCO : les critères propres à la maintenance

La grille complète de sélection d'un prestataire (références, gouvernance, modèle contractuel, réversibilité, conformité) est détaillée dans comment choisir son prestataire d'infogérance cloud. Trois critères, en revanche, sont spécifiques au MCO et révèlent immédiatement la maturité de maintenance d'un candidat :

• Le modèle de responsabilité partagée est-il explicité, service par service ? Un prestataire incapable de vous dire « qui patche quoi » sur vos VM, vos bases managées et vos clusters n'a pas cadré son périmètre de maintenance.
• Les outils sont-ils cloud-natifs ou transposés du datacenter ? Superviser et patcher un cloud avec des réflexes on-premise, c'est passer à côté de l'automatisation et sur-payer la maintenance corrective.
• Les métriques de maintenance sont-elles mesurées et reportées ? MTTR, MTBF, taux de conformité de patch : sans ces chiffres, l'engagement de maintien en condition n'est pas pilotable.

Le piège du périmètre flou : un contrat de MCO vague se paie en « hors forfait » répétés et en zones grises où chaque incident devient une négociation. La clarté du périmètre, dès le devis, est le meilleur prédicteur d'une exploitation sereine. Exigez-la.

Cas représentatif : faire reculer la maintenance corrective

Cas anonymisé et représentatif, choisi pour illustrer le cœur du MCO : transformer une maintenance subie en maintenance maîtrisée.

ETI industrielle (multi-cloud)

Une ETI industrielle exploitait un parc réparti entre Azure et des serveurs résiduels on-premise, sans supervision consolidée ni politique de correctifs claire, donc une maintenance entièrement subie, déclenchée par les pannes. La mise en place d'un MCO unifié (Azure Monitor et Update Manager pour le patch management, gouvernance par Azure Policy contre le drift de configuration, FinOps actif) a fait basculer la part de maintenance vers la préventive et stabilisé la facture. Le retard de correctifs, qui se comptait en mois, est repassé sous contrôle avec un cycle de patch planifié. Voir secteur industrie.

Les autres profils (éditeur SaaS en 24/7 sur clusters EKS, acteur de santé en périmètre partenaire certifié HDS, services financiers soumis à DORA) relèvent des mêmes principes de maintenance déclinés par contrainte sectorielle, détaillés dans les cas sectoriels de l'infogérance cloud.

Mettre en place votre MCO cloud avec Architecte Cloud

Un MCO réussi commence par une question simple : que faut-il maintenir, à quel niveau de service, et qui en est responsable : vous, nous, ou le fournisseur ? À partir de là, l'exploitation devient une mécanique mesurée plutôt qu'une suite d'imprévus. Les prestataires de notre réseau opèrent votre cloud du socle d'infrastructure jusqu'au FinOps, sur Azure comme sur AWS, en vous laissant la pleine propriété de tout ce qui est construit.

Pour faire le point sur l'état de votre exploitation, commencez par un diagnostic en ligne ; pour un devis adapté à votre périmètre, contactez-nous : réponse sous 48 h ouvrées. Ce dispositif s'inscrit dans notre infogérance cloud entreprise, aux côtés de la supervision cloud 24/7 et du traitement d'une infrastructure cloud instable.

FAQ

Qu'est-ce que le MCO en informatique ?

Le MCO (maintien en conditions opérationnelles) désigne l'ensemble des activités qui maintiennent un système d'information disponible, performant et sûr en production tout au long de son cycle de vie : supervision, correction des incidents, application des correctifs, sauvegarde, continuité et amélioration continue. Il couvre la phase de « run » (exploitation), par opposition au projet (« build ») qui a construit l'infrastructure. Le MCO est récurrent par nature.

Quelle est la différence entre MCO et MCS ?

Le MCO maintient l'infrastructure disponible et performante au sens large. Le MCS (maintien en conditions de sécurité) est le volet sécurité de ce maintien : application des correctifs de sécurité, gestion des vulnérabilités (CVE), durcissement, conformité aux référentiels (CIS) et surveillance des menaces. Le MCS est généralement décrit comme un sous-ensemble exigeant du MCO, centré sur la posture de sécurité. Une organisation a besoin des deux, avec un périmètre clairement réparti.

Quelle est la différence entre MCO et TMA ?

Le MCO porte sur l'infrastructure et la plateforme (serveurs, réseau, bases, conteneurs, services cloud). La TMA (tierce maintenance applicative) porte sur le logiciel applicatif : correction de bugs applicatifs, évolutions fonctionnelles, montées de version du logiciel. En résumé, le MCO maintient le terrain sur lequel l'application tourne ; la TMA maintient l'application elle-même. Les deux sont complémentaires et ne se substituent pas.

Quelle différence entre MCO et infogérance ?

Le MCO est une activité (l'ensemble des tâches de maintien en condition). L'infogérance est un mode de réalisation : confier tout ou partie de l'exploitation, dont le MCO, à un prestataire externe. On peut faire du MCO en interne sans infogérance, ou externaliser son MCO via un contrat d'infogérance. L'infogérance englobe souvent plus large que le seul MCO (gestion de parc, support, gouvernance, pilotage).

Comment fonctionne le MCO dans le cloud (Azure, AWS) ?

Dans le cloud public, le MCO repose sur le modèle de responsabilité partagée : le fournisseur gère le matériel et une partie de l'exploitation, le client gère ce qui reste à sa charge selon le type de service (sur une VM, l'OS et ses correctifs restent au client ; sur du managé, le fournisseur en prend davantage). Il s'opère avec des outils cloud-natifs : Azure Monitor, Azure Update Manager, Defender for Cloud, Azure Policy côté Azure ; CloudWatch, Systems Manager Patch Manager, Security Hub, AWS Config côté AWS.

Qui gère le maintien en conditions opérationnelles ?

Plusieurs acteurs : la DSI en assure la gouvernance, une équipe interne peut l'opérer, une ESN ou un infogérant peuvent en prendre tout ou partie en charge par contrat. Le RSSI pilote le volet sécurité (MCS). Dans le cloud, le fournisseur (Azure, AWS) porte aussi une part des responsabilités au titre du modèle de responsabilité partagée. Un MCO bien gouverné explicite par écrit qui fait quoi entre ces acteurs.

Quels outils sont utilisés pour le MCO cloud ?

Sur Azure : Azure Monitor (observabilité), Azure Update Manager (correctifs), Microsoft Defender for Cloud (posture de sécurité), Azure Policy (gouvernance), Azure Automation. Sur AWS : Amazon CloudWatch (métriques et logs), AWS Systems Manager Patch Manager (correctifs), AWS Security Hub (sécurité), AWS Config (conformité des configurations). Un prestataire encore centré sur des outils on-premise (Nagios, GMAO) pour un cloud public n'a pas opéré le virage cloud.

Quels sont les composants d'un MCO cloud ?

Six piliers : la supervision et l'observabilité (métriques, logs, alertes), la gestion des correctifs (patch management), la sécurité et la conformité (MCS), la sauvegarde et la restauration, la continuité d'activité (PRA/PCA avec RTO/RPO), et (spécifique au cloud) le FinOps, la maîtrise continue des coûts en exploitation. Un MCO cloud complet couvre les six ; oublier le FinOps laisse la facture dériver.

Qu'est-ce qu'un SLA dans le cadre du MCO ?

Un SLA (Service Level Agreement) est un accord qui définit le niveau de service attendu : disponibilité visée, délais de prise en compte et de résolution par niveau de gravité, plages de couverture (heures ouvrées ou 24/7) et conséquences en cas de manquement. Il se pilote avec des métriques chiffrées : taux de disponibilité (99,9 %, 99,98 %…), MTTR (temps moyen de réparation), MTBF (temps entre pannes) et délai de réaction.

Faut-il internaliser ou externaliser le MCO ?

Cela dépend de la taille du parc, de la criticité (un service 24/7 impose une astreinte coûteuse à internaliser), de la disponibilité des compétences cloud et du modèle économique souhaité. Une approche hybride est souvent la plus saine : l'équipe interne garde la gouvernance et la connaissance métier, le prestataire opère le « run » 24/7. Le vrai risque de l'externalisation n'est pas le coût mais l'enfermement : exigez la propriété de votre code IaC et de vos comptes cloud.

Combien coûte un MCO cloud ?

À titre indicatif et sur devis selon le périmètre, un dispositif de MCO cloud récurrent se situe couramment dans une fourchette de l'ordre de 3 000 à 12 000 € par mois. Le bas correspond à un socle d'infrastructure modérée en supervision et patch management ; le haut, à un parc étendu en 24/7 avec MCS avancé, FinOps, Kubernetes et conformité. La consommation cloud (facture Azure/AWS) reste distincte et à votre nom, sans marge cachée.

Quelle est la différence entre maintenance préventive et corrective ?

La maintenance corrective intervient après la panne pour rétablir le service : elle est réactive et coûteuse si elle devient dominante. La maintenance préventive agit avant la panne, de façon planifiée ou selon un état observé, pour réduire la probabilité de défaillance (appliquer les correctifs à temps, renouveler les certificats, vérifier les sauvegardes). Une exploitation mature réduit la part de corrective au profit de la préventive et de la prédictive.

Quels sont les avantages du MCO pour une entreprise ?

Une meilleure disponibilité (moins d'interruptions, reprises plus rapides), une performance maintenue, une sécurité renforcée (parc à jour, dette de vulnérabilités contenue), une productivité accrue des équipes internes recentrées sur la valeur métier, une prévisibilité des coûts grâce au pilier FinOps, et une sérénité de la direction qui transforme l'incertitude opérationnelle en risque mesuré et reporté.

Quelles sont les étapes de mise en place du MCO ?

Six temps : état des lieux et inventaire du parc, définition du périmètre et des niveaux de service (SLA), outillage (supervision, patch management, gestion de posture, automatisation), formalisation des procédures et runbooks, mise en exploitation avec mesure des indicateurs, puis amélioration continue. L'inventaire initial est décisif : sans connaître précisément ce que l'on maintient, on maintient à l'aveugle.