Une application que plus personne ne maintient ne coûte rien sur la facture et beaucoup dans l'activité. Le prix se paie en heures perdues par les équipes, en failles laissées ouvertes, en projets bloqués parce qu'un outil central ne peut plus évoluer, et en dette technique qui rend chaque intervention plus chère que la précédente. Ces postes se chiffrent avec vos propres données, et une grille en cinq questions en fin d'article permet de le faire.
Le faux confort d'une application qui tourne encore
Dans beaucoup de PME et d'ETI, la situation ressemble à ceci. Un outil interne a été développé il y a quatre ou cinq ans par un prestataire, un freelance ou un salarié depuis parti. Il gère les devis, les plannings, les commandes ou les relances clients. Il fonctionne, alors personne n'y touche, jusqu'au jour où il faut confier sa reprise en maintenance applicative à quelqu'un dans l'urgence.
Une application qui tourne sans mainteneur n'est pas stable, elle est immobile. Autour d'elle, tout bouge : le système d'exploitation du serveur, les navigateurs, les services tiers qu'elle appelle, les habitudes des utilisateurs, les obligations réglementaires. Chaque mois qui passe creuse l'écart entre ce que l'application sait faire et ce que l'entreprise a besoin qu'elle fasse.
Le dirigeant, lui, voit une ligne de dépense qui a disparu. Le budget informatique paraît maîtrisé. En réalité, le coût s'est déplacé vers des postes que la comptabilité ne mesure pas : le temps des équipes, le risque, et la valeur de l'entreprise le jour où un acquéreur ou un auditeur demandera qui sait comment ce logiciel fonctionne.
Sécurité : dépendances jamais mises à jour, secrets en clair, failles connues non corrigées
Une application métier s'appuie sur des dizaines, souvent des centaines, de bibliothèques tierces. Chacune publie régulièrement des correctifs de sécurité. Sans mainteneur, ces correctifs ne sont jamais appliqués. Les failles concernées sont publiques, documentées, et outillées par des attaquants qui parcourent le web à la recherche de ces versions précises.
Le cas typique : un site de commande en ligne pour des clients professionnels, développé sur un cadre applicatif dont la version n'a plus reçu de mise à jour depuis trois ans. Personne ne l'a piraté par génie, un robot a simplement testé une faille connue et a réussi. Résultat : base clients exfiltrée, déclaration à la CNIL, courriers aux clients, et une semaine de production perdue le temps de comprendre ce qui s'était passé.
Le second problème vient des secrets. Dans une application sans suivi, on trouve fréquemment des mots de passe de base de données ou des clés d'accès à des services externes écrits directement dans le code, parfois versionnés dans un dépôt accessible à d'anciens collaborateurs. Personne ne les a jamais renouvelés parce que personne ne savait où ils étaient.
Enfin, les accès. Le prestataire d'origine a peut-être encore un compte administrateur sur l'hébergement. Un ancien salarié a peut-être encore une clé SSH valide. Sans revue régulière, ces portes restent ouvertes indéfiniment. Traiter les dépendances obsolètes et les mises à jour de sécurité sans casser l'existant demande une méthode, par petites étapes testées.
Obsolescence : quand l'environnement change sans prévenir
L'obsolescence est plus sournoise que la faille de sécurité, parce qu'elle arrive sans attaquant. Elle se manifeste un lundi matin par une fonctionnalité qui ne marche plus, sans que rien n'ait changé dans l'application.
Premier vecteur : les services externes. Une application qui envoie des SMS, récupère des taux de change, interroge un service de cartographie ou se connecte à un logiciel comptable dépend de l'interface de ces services. Ces interfaces évoluent, les anciennes versions sont désactivées avec un préavis de quelques mois envoyé à une adresse e-mail que plus personne ne lit. Le jour de la coupure, la synchronisation comptable s'arrête, et le service financier le découvre à la clôture.
Deuxième vecteur : le langage et son environnement. Chaque version d'un langage ou d'un cadre applicatif a une date de fin de support. Passée cette date, plus aucun correctif, et surtout, une incompatibilité croissante avec les outils modernes. Une situation fréquente en milieu industriel : un outil de gestion de production impossible à réinstaller sur un serveur neuf, parce que la version du langage nécessaire n'existait plus dans les distributions récentes. Le seul serveur qui le faisait tourner devenait un objet précieux et fragile.
Troisième vecteur : l'hébergeur, qui migre ses infrastructures et retire d'anciennes offres. Une application sans mainteneur n'a personne pour lire ces annonces. Elle subit la migration au lieu de la piloter.
Le coût d'une équipe bloquée : comment le calculer avec vos propres chiffres
C'est le poste le plus concret et le plus souvent ignoré, parce qu'il n'apparaît sur aucune facture. Quand un outil central tombe ou se dégrade, ceux qui attendent sont des commerciaux, des gestionnaires et des opérateurs de production.
Le calcul se fait en trois lignes. Prenez le nombre de personnes qui dépendent de l'application pour travailler. Multipliez par leur coût horaire chargé. Multipliez par le nombre d'heures perdues par mois, en additionnant les pannes franches, les contournements manuels et les ressaisies dans un tableur parce que la fonction d'export ne fonctionne plus.
Un exemple réaliste. Une PME de services de quarante personnes utilise un outil interne de planification des interventions. Douze techniciens et trois planificateurs en dépendent. L'outil tombe en panne deux ou trois fois par mois, et chaque incident coûte environ une demi-journée de désorganisation à l'équipe de planification, plus une heure par technicien qui appelle pour savoir où aller. Sur un mois, on dépasse rapidement une cinquantaine d'heures perdues, sans compter les interventions ratées et les clients mécontents. Sur un an, cela représente plusieurs semaines de travail d'un salarié à temps plein, passées à contourner un logiciel.
Ajoutez le coût du blocage stratégique. Vous voulez ouvrir une nouvelle agence, changer de logiciel comptable, mettre en place un portail client ? Si l'application centrale ne peut pas être modifiée sans risque, chacun de ces projets est retardé ou abandonné. Ce coût d'opportunité est rarement chiffré, mais il est souvent le plus élevé de tous.
La dette qui s'accumule et rend la reprise plus chère chaque trimestre
La dette technique fonctionne comme une dette financière : elle porte intérêt. Chaque trimestre sans maintenance ajoute des versions à rattraper, des incompatibilités à résoudre, des correctifs de contournement empilés par un salarié débrouillard qui a modifié le code sans documentation.
Concrètement, remettre à niveau une application maintenue régulièrement se fait par petites étapes, chacune testée et réversible. Remettre à niveau une application abandonnée depuis quatre ans revient à sauter plusieurs versions majeures d'un coup, avec des changements de comportement en cascade et des tests à réécrire. Ce qui aurait coûté quelques jours par an répartis dans le temps coûte plusieurs semaines en une fois, avec un risque de régression bien plus élevé.
Il y a aussi un effet de seuil. Passé un certain retard, la reprise devient si coûteuse que la seule option raisonnable est de tout refaire. L'entreprise paie alors un nouveau développement complet, plus la migration des données, plus la conduite du changement, pour retrouver ce qu'elle avait déjà. Un audit de dette technique permet de savoir de quel côté du seuil on se trouve avant d'engager quoi que ce soit.
Le risque de dépendance : le savoir dans une seule tête
Dans les entreprises que nous rencontrons, la connaissance d'une application non maintenue tient souvent en une seule personne. Parfois c'est le prestataire d'origine, qui répond de moins en moins vite et facture de plus en plus cher chaque intervention parce qu'il est le seul à pouvoir la faire. Parfois c'est un salarié, qui n'est pas développeur mais qui a appris à redémarrer le service et à corriger les données à la main dans la base.
Le jour où cette personne quitte l'entreprise, part en arrêt long, ou simplement cesse de répondre, l'application devient une boîte noire. Il n'y a pas de documentation, pas de procédure de déploiement, parfois même pas de copie du code source à jour. Il arrive qu'une entreprise découvre que le code de son outil de gestion d'entrepôt n'existe que sur le serveur de production, sans dépôt, sans sauvegarde du code, et que le prestataire a cessé son activité.
Cette dépendance est aussi un risque de négociation. Un prestataire qui se sait irremplaçable n'a aucune raison de tenir ses délais ni ses prix. Si votre interlocuteur actuel ne répond plus demain et qu'il faut plus de quelques jours pour qu'une autre équipe intervienne, l'entreprise dépend d'une seule personne pour un outil critique.
Grille d'estimation : cinq questions pour mesurer votre exposition
Cette grille donne un niveau d'exposition et la liste des chiffres à collecter pour le convertir en coût. Répondez pour chaque application critique de l'entreprise.
1. Combien de personnes s'arrêtent de travailler si cette application tombe une journée ? Comptez les utilisateurs directs et ceux qui dépendent de leurs résultats. Multipliez par le coût journalier chargé. C'est votre coût de panne unitaire.
2. À quand remonte la dernière mise à jour de sécurité appliquée ? Moins de six mois, l'exposition est faible. Entre six mois et deux ans, elle est réelle. Plus de deux ans ou inconnu, considérez que des failles connues sont exploitables aujourd'hui.
3. Combien de personnes peuvent intervenir sur le code dès demain ? Deux ou plus, avec accès au dépôt et à la documentation, la situation est saine. Une seule, la dépendance est forte. Zéro, ou vous ne savez pas, vous avez une boîte noire.
4. Quels services externes l'application appelle-t-elle, et qui reçoit leurs annonces de changement ? Listez-les. Chaque service dont personne ne suit les évolutions est une coupure programmée à une date inconnue.
5. Quel projet de l'entreprise est retardé ou impossible à cause de cette application ? Nouvelle activité, nouvel outil, conformité réglementaire, intégration d'un partenaire. Chiffrez le retard en chiffre d'affaires différé ou en surcoût de contournement.
Une application qui cumule un coût de panne élevé, plus de deux ans sans correctif, une seule personne capable d'intervenir et au moins un projet bloqué n'est pas un sujet informatique. C'est un risque d'entreprise, à traiter au même niveau qu'un litige client ou qu'un fournisseur unique.
Ce qu'un contrat de maintenance change dans cette équation
Un contrat de maintenance ne supprime pas ces risques, il change leur nature. Ils sont mesurés, et un tiers s'engage par écrit à les suivre.
La première chose qui change, c'est la visibilité. L'application est supervisée en continu, les erreurs sont détectées avant que les utilisateurs ne les signalent, et un rapport d'activité régulier dit ce qui a été fait, ce qui a été observé, et ce qui reste à traiter. Le dirigeant sait ce qu'il paie et pourquoi. Les sept clauses qui manquent aux contrats de maintenance classiques détaillent ce que ce rapport doit contenir.
La deuxième, c'est la remise à niveau planifiée. Les dépendances sont mises à jour par petites étapes, avec des tests automatisés qui vérifient que rien ne casse. Les fins de support sont anticipées, les migrations d'hébergeur ou d'interface tierce sont préparées avant la date de coupure. La dette cesse de s'accumuler.
La troisième, c'est la fin de la dépendance. Le code, la documentation et les accès restent chez le client, dans un dépôt qu'il contrôle. Les procédures de déploiement sont écrites. Si le prestataire change demain, l'équipe suivante peut reprendre le travail. C'est exactement l'objectif d'une tierce maintenance applicative bien conçue, et c'est par là que nous commençons quand une entreprise nous demande de reprendre la main sur une application sans mainteneur : un audit du code et de l'infrastructure, une reprise sous contrôle de version, puis des engagements écrits, définis au contrat après l'audit.
Pour les applications qui embarquent des composants d'intelligence artificielle, le sujet s'élargit : les modèles dérivent, les coûts de maintenance d'un RAG évoluent, les fournisseurs déprécient leurs versions. Le maintien de ces briques relève de la même logique, avec des compétences spécifiques. Nous avons détaillé ce qu'il faut surveiller après la mise en production d'une IA, et la façon dont ces sujets s'articulent avec la maintenance classique.
Une application non maintenue coûte déjà quelque chose chaque mois, en temps d'équipe, en risque et en projets différés. La grille ci-dessus permet d'en faire un chiffre, et de le comparer à un budget de maintenance connu à l'avance.
