Qu'est-ce que le Maintien en Condition Opérationnelle (MCO) ?

Après la mise en ligne d’une application particulièrement lorsqu’elle est critique (génératrice de revenus, utilisée par de nombreux utilisateurs par exemple), il est essentiel de s’assure qu’elle répond à votre standard de qualité, quelle que soit la quantité de code qui la compose. C’est précisément le rôle du MCO, le Maintien en Condition Opérationnelle : garder un produit disponible, fiable et sûr, jour après jour.

Chez Dernier Cri, le MCO est la brique de base que nous posons quand nous démarrons une TMA (Tierce Maintenance Applicative).

Le MCO, c’est quoi exactement ?

Le MCO désigne l’ensemble des activités qui garantissent qu’une plateforme reste disponible, performante et sécurisée dans la durée.

Pour bien situer le MCO, il faut le replacer dans la maintenance globale d’une application (TMA pour Tierce Maintenance Applicative), à savoir de l’infogérance (la gestion de l’infrastructure et des déploiements), de la maintenance corrective et préventive (corriger les incidents, anticiper les pannes) et de la maintenance évolutive (faire vivre et grandir le produit).

L’infogérance et la maintenance corrective/préventive sont les éléments indispensables pour garantir une maintenance de qualité, c’est précisément l’objet du MCO. La maintenance évolutive permettra de faire vivre son produit dans le temps. Sans MCO solide, la maintenance évolutive conduira inexorablement à des déconvenues.

De manière opérationnelle, le MCO repose sur quelques capacités fondamentales :

• Déployer en confiance : être capable de mettre en production sur les serveurs de façon fiable et répétable.
• Observer l’infrastructure : suivre les métriques clés des serveurs (taux de charge, ressources) avec un KPI central et en particulier la disponibilité.
• Observer l’applicatif : piloter le produit sur quatre dimensions fiabilité, performance, sécurité, robustesse.
• Donner de la visibilité aux utilisateurs sur l’état de la plateforme, en toute transparence.

Le fil rouge : on ne peut agir que sur ce qu’on mesure. Sans démarche d’observabilité, le MCO se résume à réagir une fois que les utilisateurs ont déjà constaté le problème. Avec, on anticipe.

Toutefois, il est recommandé de l’étendre avec des interventions ponctuelles mais critiques :

• Test de PRA (Plan de Reprise d’Activité) : vérifier qu’on sait réellement reconstruire et redémarrer la plateforme en cas de sinistre.
• Réalisation de pentests : éprouver la sécurité de la plateforme à partir de tout ce qu’on connaît du système.

En résumé, le MCO se joue sur deux rythmes :

Ces opérations, longtemps coûteuses et réservées à des moments rares, sont en train de changer de devenir des commodités, plus que jamais il devient pertinent de les inclure dans une routine de maintenance.

‍

Nos convictions sur la manière d’opérer un MCO

• On ne peut agir que sur ce qu’on mesure. L’observabilité dont a parlé plus haut est au cœur de notre démarche. Sans ces chiffres on ne voit rien et surtout on ne progresse jamais
• Votre interlocuteur ne devrait pas être un simple passe-plats. Un Application Manager dédié, profil développeur et technico-fonctionnel, est un point de contact unique. La plus value d’un chef de projet n’est perceptible qu’à parti du moment où plusieurs personnes interviennent sur le projet.
• Reprendre un projet, c’est endosser sa responsabilité. Nous traitons le code repris comme le nôtre. Cela implique qu’il faut du temps pour l’apprivoiser, comprendre ses aspérit

A l’instar du développement, l’IA ne remplace pas la compétence de maintenance, mais l’accentue. En particulier, reconstruire un environnement technique devient facile. Là où recréer une infrastructure complète était un chantier, l’IA accélère la génération et la mise en cohérence des configurations. Le PRA cesse d’être théorique, tout comme l’automatisation des pentests. La sécurité n’est plus la roue du carrosse qu’on a laissé au garage : elle devient un contrôle continu, partiellement automatisé, qui colle au rythme réel des évolutions du produit — une logique security by design.

En clair, en abaissant le coût des opérations qui rendent un MCO vraiment robuste, l’IA permet de rendre l’exceptionnel standard.

Enfin, le Run (la TMA, maintenance 360° : assistance, correction, prévention) et le Build (l’évolution produit) sont deux mouvements distincts mais continus. Une équipe Build pluridisciplinaire doit être mobilisable, à la demande, le Run, est disponible en permanence, pour assiter chaque livraison, pour ne jamais faire face à une éventuelle rupture de service, quelque soit ce qu’on attend, instantannéité ou profondeur de réflexion à grande échelle.

Nous utilisons l’IA pour renforcer notre MCO :

• intervenir virtuellement 24/7, en s’appuyant sur l’observabilité et l’automatisation — comme sur la plateforme April ;
• réduire la dette technique de façon continue ;
• diagnostiquer les causes racines de certains bugs plus vite.

Mais nous savons aussi ce que l’IA ne fait pas chez nous. C’est notre garde-fou :

• Elle ne pousse jamais de code sans relecture humaine.
• Elle n’accède pas à la base de données ni au système de fichiers de production.

L’IA accélère le diagnostic et l’opération ; l’humain garde la responsabilité de ce qui touche au produit en production. C’est cette ligne, claire et assumée, qui fait la différence entre un MCO qui rassure et un MCO qui dérape.

Vous pensez que votre plateforme mérite mieux que de simplement « tenir » ? Parlons-en.