Un logiciel qui « fonctionne encore » n'est pas un logiciel en bonne santé. La MCO mal planifiée coûte plus cher que la refonte qu'elle était censée éviter. Guide complet, cas réels, méthode.
Donatien Lefranc
Fondateur & Président, Leando
Dans beaucoup de PME, la maintenance du SI suit la même logique que l'entretien d'une vieille voiture : on n'intervient que quand quelque chose casse. Pas de révision préventive, pas de feuille de route, pas de budget alloué. L'outil « tourne encore », donc tout va bien.
C'est une erreur de diagnostic. Un logiciel qui ne plante pas peut très bien être en train de perdre de sa pertinence métier. Les règles de gestion qu'il applique datent de trois ans. Les processus qu'il supporte ont changé mais le code, lui, n'a pas bougé. Les utilisateurs ont compensé en créant des fichiers Excel en parallèle. Le SI « fonctionne » au sens technique, mais il a cessé de servir l'entreprise.
C'est précisément le problème que la MCO est censée prévenir. Et c'est précisément le problème qu'une MCO non planifiée garantit.
Signal d'alerte
Demandez à vos utilisateurs comment ils travaillent vraiment. Si la réponse contient les mots « on exporte dans Excel », « on a un tableau de bord en parallèle » ou « on a trouvé un contournement » : le SI a cessé de répondre aux besoins, et la MCO est en retard.
« Notre cœur métier, c'est de comprendre le contexte d'une entreprise. »
— Donatien Lefranc, fondateur de Leando
Avant de proposer une intervention technique, l'enjeu est de comprendre ce que le SI est censé faire aujourd'hui par rapport à ce qu'il fait effectivement. Cet écart, c'est le vrai périmètre de la MCO.
La MCO (Maintenance en Condition Opérationnelle, ou Maintien en Condition Opérationnelle selon les contextes) désigne l'ensemble des activités qui permettent à un système informatique de rester fonctionnel, sécurisé et aligné avec les besoins métier dans la durée. C'est une définition large, intentionnellement.
La MCO en informatique ne se réduit pas à corriger des bugs. Elle couvre la mise à jour des dépendances logicielles, la conformité aux évolutions réglementaires, l'adaptation aux changements d'infrastructure, et les évolutions fonctionnelles qui accompagnent la croissance de l'entreprise.
Ce qui distingue la MCO d'une simple maintenance corrective, c'est sa dimension stratégique. Maintenir un SI en condition opérationnelle, c'est s'assurer que le système peut encore remplir sa mission dans six mois, dans un an, dans deux ans. Pas seulement demain matin.

En pratique, la MCO informatique se confond souvent avec la TMA (Tierce Maintenance Applicative) dans le discours des prestataires. Ce sont deux choses différentes : la TMA est un mode d'organisation contractuel, la MCO est un périmètre fonctionnel. On peut faire de la MCO en interne, en TMA, ou dans un modèle hybride. Ce qui compte, c'est que le périmètre soit défini et le budget alloué.
La plupart des DSI et des dirigeants de PME parlent de « maintenance » comme d'un bloc homogène. C'est une simplification qui coûte cher. Il y a en réalité trois types de maintenance, avec des logiques de déclenchement, des budgets et des horizons de planification différents.
La MCO corrective couvre les bugs, les pannes, les dysfonctionnements en production. Elle est non-négociable et non-planifiable dans le détail : un bug critique en production ne demande pas la permission. Ce qui se planifie, c'est la capacité de réponse : qui est d'astreinte, quel est le SLA, quel est le processus d'escalade. Budget indicatif : 5 à 8 % du coût du projet par an, selon la criticité.
La MCO évolutive couvre les nouvelles fonctionnalités, les améliorations d'ergonomie, les extensions de périmètre. Elle suit la feuille de route métier. C'est la plus stratégique des trois : elle décide si le logiciel accompagne la croissance ou freine l'entreprise. C'est aussi la première à être sacrifiée en cas de contrainte budgétaire, ce qui est précisément l'inverse de ce qu'il faudrait faire. Budget indicatif : 8 à 12 % du coût du projet par an.
La MCO adaptative couvre les mises à jour imposées par l'environnement : nouvelles versions de navigateurs, changements d'OS, mises à jour de librairies, évolutions réglementaires (RGPD, accessibilité, normes sectorielles). Elle est souvent invisible jusqu'au jour où elle ne l'est plus. Un logiciel qui n'a pas été mis à jour depuis deux ans accumule une dette adaptative qui peut bloquer toute évolution future. Budget indicatif : 3 à 5 % du coût du projet par an.
Ces trois types de maintenance s'additionnent. Un SI actif avec des utilisateurs réels nécessite entre 15 et 20 % de son coût de développement initial par an pour rester en bonne santé. En dessous de 10 %, l'accumulation de dette est garantie. Ce n'est pas un avis : c'est ce que l'on observe systématiquement lors des audits.
La maintenance réactive a une logique simple : on répond aux urgences. C'est humain, c'est souvent inévitable. Le problème, c'est qu'elle se transforme progressivement en mode de fonctionnement par défaut. Et ce mode coûte cher.
Quand la MCO n'est pas planifiée, chaque intervention est une urgence. Chaque urgence est facturée à prix fort. Chaque correction rapide crée de nouvelles incohérences. Les développeurs passent davantage de temps à comprendre le code existant qu'à livrer de la valeur. La vélocité baisse, les coûts montent.
A un certain point, le coût annuel de la MCO réactive dépasse le coût d'une refonte. Mais la refonte est devenue risquée : le code est si peu documenté, si peu testé, si peu compris, qu'on ne sait plus exactement ce que le système fait vraiment. On maintient par peur de tout casser.
Cas bureau d'études énergie offshore, 45 personnes, Bretagne
Une PME de 45 personnes avec un ERP interne vieillissant et des dizaines de fichiers Excel qui s'étaient accumulés en parallèle. L'intuition initiale des dirigeants était claire : « il nous faut tel outil. » Leando a posé une vision SI cible sur 12 mois avant toute décision d'achat ou de développement.
Les dirigeants ont voulu reprendre l'exécution en autonomie. Rattrapés par l'urgence du quotidien, ils n'ont pas donné suite dans l'immédiat. Mais la valeur de cet exercice persiste : la vision construite les protège des mauvais achats d'outils. Ils savent désormais quelles décisions valent leur coût et lesquelles peuvent attendre. Ils souhaitent aujourd'hui reprendre la collaboration.
C'est précisément l'utilité d'une feuille de route MCO : même sans l'exécuter immédiatement, elle protège contre les décisions prises dans l'urgence.
La feuille de route n'a pas besoin d'être un document de 50 pages. Elle doit répondre à trois questions : quelles évolutions sont prévues sur 12 mois, quel est l'ordre de priorité, et qui valide les arbitrages. Sans ça, chaque urgence du quotidien écrase les priorités stratégiques. Et on se retrouve, deux ans plus tard, à expliquer pourquoi il faut tout refaire.
Une MCO planifiée repose sur quatre piliers. Ils ne sont pas complexes. Ils sont juste rarement mis en place ensemble.
Avant de planifier des interventions techniques, répondez à la question métier : où doit être le SI dans 18 mois pour servir les ambitions de l'entreprise ? Quels processus doivent être couverts ? Quelles intégrations sont nécessaires ? Ce travail prend deux à cinq jours. Il économise des mois de développement dans le mauvais sens.
La MCO n'est pas du développement. C'est de l'entretien. Les confondre dans le même budget conduit à arbitrer contre la maintenance à chaque sprint. Allouez un budget MCO annuel explicite : 15 à 20 % du coût de développement initial pour un SI actif. Révisez-le chaque année selon l'évolution du périmètre.
Tous les trimestres, 90 minutes avec les métiers et le référent technique. On passe en revue : les correctifs en attente, les évolutions en backlog, les contraintes adaptatives identifiées. On priorise, on arbitre, on aligne les ressources. Sans ce rituel, le backlog grossit jusqu'à l'infarctus.
Pas un wiki exhaustif que personne ne lit. Une documentation ciblée sur les décisions critiques : pourquoi ce choix d'architecture, pourquoi cette structure de données, comment ce module interagit avec les autres. Sans ça, chaque rotation d'équipe repart de zéro. Chaque urgence est traitée sans contexte. Et la MCO coûte toujours plus cher qu'elle ne devrait.
« Construire petit pour faire évoluer et accompagner le besoin et accompagner la croissance. »
— Donatien Lefranc, fondateur de Leando
Cette approche progressive n'est pas de la timidité. C'est la seule façon de maintenir un SI en production sans interruption de continuité. La brique embryonnaire d'aujourd'hui est le module central de demain. Ce qui change, c'est la maturité de l'organisation pour l'absorber.
L'IA a transformé la production de code. Ce qui prenait une semaine prend maintenant une journée. C'est une accélération réelle, et elle change le périmètre de la MCO d'une façon que peu d'équipes ont encore intégrée.
L'IA génère du code fonctionnel. Elle ne génère pas de la cohérence architecturale. Quand plusieurs développeurs utilisent des outils de génération de code en parallèle sur le même SI, les décisions implicites s'accumulent. Chaque prompt bien formulé produit du code cohérent localement. Le problème émerge à l'échelle du système, quand on découvre que deux modules partent de suppositions contradictoires sur le même concept métier.
« Les décisions sont implicites avec l'IA — notamment avec le vibe coding. Les développeurs juniors peuvent prendre des décisions sans même s'en rendre compte. »
— Donatien Lefranc, fondateur de Leando
Cette observation change la nature de la MCO sur les projets qui utilisent l'IA intensivement. La revue de code ne suffit plus : il faut une revue des décisions d'architecture. Pas seulement vérifier que le code fonctionne, mais vérifier que les décisions prises par l'IA (implicitement, à travers les prompts) sont cohérentes avec la vision SI cible.
C'est particulièrement critique pour les équipes avec des développeurs juniors. Un junior qui utilise l'IA peut produire du code qui a l'air propre en surface et qui cache des choix structurants jamais validés par personne. La MCO doit intégrer ce risque.
Ce que l'IA accélère
Ce que l'IA ne remplace pas
La bonne nouvelle : l'IA peut aussi aider la MCO de façon positive. Analyse automatique de la dette technique, génération de tests de régression, détection de dépendances obsolètes. Les outils existent. Ils nécessitent un cadre de gouvernance pour ne pas produire eux-mêmes de nouvelles décisions implicites.
Ces deux projets illustrent ce que la MCO planifiée (ou non planifiée) produit concrètement.
Docent · Startup IA
Docent, une startup dans le domaine de l'IA, avait vu ses coûts AWS grimper à 8 000 $ par mois. Pas à cause d'une croissance explosive du nombre d'utilisateurs. À cause d'une infrastructure qui n'avait jamais été auditée depuis la phase de prototypage.
L'intervention de Leando n'a pas été une refonte. C'est une rationalisation progressive : identification des ressources surdimensionnées, mise en place d'une gouvernance d'infrastructure, montée en version de services cloud sous-utilisés. Aucun « big bang », aucune interruption de service.
Résultat : les coûts AWS sont passés de 8 000 $/mois à 1 800 $/mois, soit une réduction de 80 %. Ce n'est pas de l'optimisation magique. C'est ce que produit une MCO adaptative et infrastructure appliquée à un système qui n'avait jamais été entretenu.
Ce que ça enseigne
Le coût de l'absence de MCO adaptative sur un an peut dépasser le budget d'une MCO complète sur trois ans. Dans ce cas : 74 000 $ de surcoût annuel évitables par un audit de quelques jours.
BKW · ETI Énergie
BKW est une ETI dans le secteur de l'énergie avec un système legacy PHP en production et un datalake à intégrer. La tentation du « big bang » était forte : remplacer l'ancien système d'un coup. C'est le choix que Leando a déconseillé.
L'approche retenue : maintenir le système existant en production pendant toute la phase de construction du nouveau, en parallèle. Le nouveau système est construit en brique embryonnaire, testé avec les vrais utilisateurs, progressivement étendu. Aucune interruption de continuité opérationnelle.
Cette approche n'est pas de la frilosité. C'est la reconnaissance qu'un système legacy en production porte une connaissance métier implicite qu'aucun cahier des charges ne capture entièrement. La MCO du système existant est la condition qui permet de construire le nouveau sans pression.
Ce que ça enseigne
Maintenir et migrer ne s'opposent pas. La MCO du système existant finance, dans le temps, le financement implicite de la transition. C'est plus lent, mais c'est le seul chemin qui ne met pas l'activité en risque.

TMA : ce que le contrat de maintenance couvre vraiment
TMA vs MCO : les différences concrètes et ce que signer un contrat TMA implique.
Moderniser le SI d'une PME : méthode et guide complet
Quand la MCO ne suffit plus et qu'il faut passer à la modernisation.
Vibe coding et dette technique : le danger invisible
Comment l'IA accélère l'accumulation de dette et ce que ça change pour la MCO.
7 raisons pour lesquelles votre transformation digitale s'enlise
Les signaux d'une MCO défaillante dans une transformation plus large.
Les questions qu'on nous pose systématiquement
La TMA (Tierce Maintenance Applicative) est un contrat : vous externalisez la maintenance à un prestataire tiers. La MCO est un périmètre : l'ensemble des activités qui maintiennent le logiciel opérationnel. On peut faire de la MCO en interne ou en TMA. La TMA est un mode d'organisation, la MCO est ce qu'on fait. Confondre les deux, c'est souvent signer un contrat TMA en pensant avoir une stratégie MCO.
Passez à l'action
Leando audite votre SI, évalue votre dette technique et vous donne un plan MCO sur 12 mois. Diagnostic clair. Priorités actionnables. Sans jargon.
Demander un diagnostic gratuit