La tierce maintenance applicative, expliquée à un dirigeant qui n'a pas de DSI

Le moment où on cherche un tiers

Personne ne tape « tierce maintenance applicative » par curiosité. Cette recherche arrive après un déclencheur précis, presque toujours le même : un lien de confiance vient de se rompre entre l'entreprise et la personne ou la structure qui faisait vivre son logiciel jusque là.

Le scénario le plus fréquent ressemble à ceci : un freelance a construit l'application il y a quatre ou cinq ans, il répondait bien les deux premières années, puis les réponses se sont espacées, un devis envoyé en mars n'est toujours pas arrivé en juillet, et l'application continue de faire tourner la facturation chaque jour.

Le deuxième scénario est plus brutal : l'agence qui avait construit l'outil a fermé, ou a changé d'activité, ou a été rachetée et ne répond plus aux demandes des anciens clients. Le contrat initial n'existe plus, le contact non plus, et l'application continue de tourner sans personne pour la surveiller.

Le troisième scénario est interne : la personne qui connaissait le code, salariée ou dirigeante elle-même à ses débuts, est partie ou a changé de poste. Le savoir qui permettait de modifier l'outil sans casser le reste est parti avec elle, et personne dans l'entreprise ne s'en sent capable.

Le point commun à ces trois scénarios : l'application ne s'arrête pas, elle. Elle continue de gérer les stocks, la facturation ou le suivi client, pendant que la confiance dans celui qui devait la maintenir s'est effondrée. Le dirigeant cherche alors quelqu'un qui reprenne la main sans tout recommencer.

C'est là que la recherche devient urgente plutôt que théorique. Un bug qui bloque la facturation un vendredi soir ne laisse pas le temps de comparer dix prestataires : il faut un contrat qui tienne, avec quelqu'un capable de lire du code qu'il n'a pas écrit, vite.

Souvent, l'incident déclencheur a déjà eu lieu quand la recherche commence : une panne de deux jours pendant laquelle personne ne répondait, une facture bloquée un fin de mois, un client final qui s'est plaint publiquement. La recherche d'un contrat de maintenance arrive alors en réaction à une peur précise, celle de revivre la même panne sans personne pour la traiter.

Quand ce n'est pas (encore) une TMA qu'il faut

Toutes les applications en souffrance n'ont pas besoin d'un contrat de maintenance externe, et le dire franchement évite une dépense inutile. Trois situations méritent d'être écartées avant de signer quoi que ce soit.

Première situation : quelqu'un en interne connaît encore le code, même partiellement, et peut répondre aux urgences. Dans ce cas, un accompagnement ponctuel ou une montée en compétence coûte souvent moins cher qu'un contrat mensuel, et laisse le savoir dans l'entreprise plutôt que de le confier à l'extérieur.

Deuxième situation : le volume réel de correctifs et de petites évolutions est trop faible pour justifier un forfait mensuel. Une application stable qui ne réclame qu'une intervention tous les six mois se traite mieux en régie ponctuelle qu'en contrat récurrent, qui facturerait une disponibilité inutilisée.

Troisième situation, la plus délicate à admettre : le code est si dégradé qu'aucune reprise ne tient dans la durée. Certaines applications ont accumulé tant de raccourcis et de bricolages que continuer à les entretenir coûte plus cher, année après année, qu'une reconstruction propre. Le sujet est traité dans le guide sur la refonte logicielle.

Distinguer les trois demande un vrai regard sur le code, pas une estimation à l'aveugle. C'est pour cela qu'un prestataire sérieux propose toujours un audit avant de proposer un contrat, plutôt qu'un forfait signé sur la seule confiance.

Le lecteur qui hésite encore entre du sur-mesure neuf, un logiciel standard ou du no-code pour remplacer entièrement l'existant trouvera ce comparatif dans le guide logiciel sur mesure, avant de revenir ici une fois le choix tranché en faveur d'une reprise.

Un signe simple aide à trancher sans attendre un audit complet : si la dernière modification demandée a coûté plus cher que prévu à cause d'un code impossible à comprendre, plutôt qu'à cause d'un manque de temps chez le prestataire, le problème est probablement plus profond qu'un contrat de maintenance ne le résoudra.

Ce qu'un contrat de TMA couvre concrètement

Le contenu d'un contrat de maintenance applicative varie d'un prestataire à l'autre, mais un socle revient presque toujours, et le connaître évite de découvrir un trou de couverture après la signature.

La correction des bugs en tête de liste : un calcul faux, un écran qui plante, une donnée mal enregistrée. C'est le cœur du contrat, celui que le client remarque en premier quand il fonctionne, et celui dont l'absence se voit immédiatement quand il ne fonctionne pas.

Les mises à jour de sécurité et de dépendances ensuite : les briques logicielles sur lesquelles l'application s'appuie vieillissent même sans y toucher, et un contrat sérieux surveille les alertes de sécurité qui les concernent, plutôt que d'attendre la panne pour les découvrir.

Les petites évolutions enfin, quand le contrat les couvre : un champ ajouté à un formulaire, une règle de calcul qui change parce que la loi ou l'activité a bougé, un export supplémentaire demandé par la comptabilité. Ce sont des demandes de quelques heures, pas des chantiers.

Ce qui n'entre pas dans le contrat, et qu'il vaut mieux clarifier avant de signer : une refonte de l'interface, une nouvelle fonctionnalité majeure qui change l'usage de l'application, ou une migration vers une autre technologie. Ces chantiers se négocient à part, avec leur propre devis.

Le malentendu le plus fréquent du sujet vient de là : un client signe un contrat de maintenance en pensant qu'il couvre aussi les grandes évolutions, et découvre un nouveau devis à la première demande un peu ambitieuse. Un contrat clair nomme cette limite dès le départ, sans la cacher dans une clause en petits caractères.

Un exemple concret de cette frontière : ajouter un champ « numéro de commande » à un formulaire existant relève de la maintenance, presque toujours une affaire de quelques heures. Construire un module entier de suivi de commandes avec ses propres écrans et sa propre logique relève d'un projet à part, avec son propre devis et sa propre planification.

Comment se passe la reprise en main

Aucun prestataire sérieux ne signe un contrat de maintenance sans avoir d'abord lu le code qu'il va entretenir. Cette étape s'appelle la reprise en main, et elle conditionne tout ce qui suit : un devis donné sans elle est un pari, pas une estimation.

Concrètement, la reprise en main commence par la lecture du code existant, section par section, pour comprendre ce qui a été fait et, quand c'est possible, pourquoi. Certaines décisions paraissent absurdes de l'extérieur et se révèlent justifiées une fois le contexte compris, d'autres sont de vrais bricolages qu'il faudra surveiller.

Vient ensuite le test de ce qui existe : faire tourner l'application dans ses cas courants et dans ses cas limites, pour vérifier qu'elle fait bien ce que tout le monde suppose qu'elle fait. Beaucoup de mauvaises surprises se découvrent à ce stade, avant la première modification, pas après.

La reprise en main identifie aussi les zones à risque : le module que personne n'ose toucher, la dépendance trop ancienne pour être mise à jour sans casser autre chose, la partie du code sans aucun test qui vérifierait qu'elle fonctionne encore après un changement.

Elle se termine par une documentation de ce qui ne l'était pas : à minima un état des lieux écrit, pour que le client garde une trace de ce qui a été trouvé, même s'il change de prestataire l'année suivante.

La durée de cette étape dépend directement de la taille de l'application et de l'état de sa documentation existante. Pour une application de taille courante, chez une PME de 30 à 150 personnes, il vaut mieux compter en semaines qu'en jours : une estimation précise se donne au cas par cas, jamais en ordre de grandeur générique.

Pendant cette période, l'application continue de tourner normalement : la reprise en main s'effectue en lisant et en testant, rarement en modifiant quoi que ce soit en production. Un client n'a donc pas à craindre une interruption de service pendant que le nouveau prestataire prend connaissance du système qu'il va entretenir.

Combien coûte une tierce maintenance applicative

Le sujet appelle un chiffre, et le donner honnêtement vaut mieux que de le noyer dans du vocabulaire. Chez Techmind, un suivi se situe entre 3 000 et 5 000 euros par mois, selon la criticité du système entretenu et le volume de demandes à traiter.

Ce qui fait varier le montant à l'intérieur de cette fourchette : le nombre d'utilisateurs qui dépendent de l'application, la fréquence des demandes d'évolution, la présence ou non de tests automatisés qui accélèrent chaque modification, et le délai de réponse attendu en cas d'incident bloquant.

Deux formats de facturation coexistent sur ce marché. Le forfait mensuel couvre un volume d'heures défini à l'avance, prévisible pour le client comme pour le prestataire, adapté à une application qui réclame un entretien régulier. La régie facture le temps réellement passé, plus adaptée à une application stable qui ne réclame qu'une intervention occasionnelle.

Pour situer ce montant face à un projet neuf : un premier outil construit sur mesure se chiffre entre 15 000 et 50 000 euros selon son ampleur, et un audit préalable pour préparer un projet neuf entre 5 000 et 15 000 euros. La comparaison complète des coûts vit dans le guide logiciel sur mesure, section prix.

Un dirigeant qui compare un devis de maintenance à un devis de reconstruction complète compare rarement deux choses de même nature : l'un entretient un actif existant, l'autre en construit un nouveau. Le bon calcul rapporte le coût mensuel de la maintenance au coût que produirait une panne prolongée de l'application, pas au prix d'un projet neuf.

Le prix annoncé avant la reprise en main reste une estimation, jamais un engagement définitif. Un système documenté et testé coûte moins cher à entretenir qu'un système opaque, et cet écart ne se mesure qu'après avoir lu le code, pas avant.

Un ordre de grandeur utile pour situer la dépense : une application qui gère la facturation ou le suivi client d'une entreprise de taille moyenne représente rarement plus d'une heure de travail par jour ouvré pour rester en bon état, correctifs et petites évolutions compris. Au-delà, soit l'application grossit vite, soit elle portait déjà une dette qu'il faudra traiter à part.

Un dernier repère avant de négocier un devis : le montant mensuel d'une maintenance se compare rarement à un salaire chargé de développeur à temps plein, il correspond plutôt à une fraction de ce temps, réservée en priorité à l'application qui en a besoin. Un prestataire qui facture l'équivalent d'un poste complet pour une seule application moyenne mérite qu'on lui demande pourquoi.

Le rythme d'un contrat au quotidien

Un contrat de maintenance se juge à son rythme, pas seulement à son contenu. Avant de signer, un dirigeant a intérêt à demander comment se déroule une semaine ordinaire, et ce que devient une demande urgente un vendredi après-midi.

Chez Techmind, une demande signalée comme bloquante reçoit une première réponse en moins d'un jour ouvré, pas en heures comptées au sigle. Un dirigeant qui entend « engagement de service » ou des sigles à trois lettres a le droit de demander la traduction en jours ou en heures, sans détour.

Les demandes non bloquantes s'organisent en liste priorisée plutôt qu'au fil de l'eau : un correctif mineur ou une petite évolution rejoint un lot traité chaque mois, ce qui évite de facturer chaque micro-demande comme un projet à part et de saturer le temps disponible sur des urgences qui n'en sont pas.

Un point mensuel fait le tour de ce qui a été corrigé, de ce qui reste ouvert, et de ce qui commence à ressembler à un chantier plus large. C'est aussi le moment où une petite dette qui s'accumule doit être nommée avant de devenir un problème, plutôt que découverte d'un coup, des mois plus tard.

Ce rythme protège les deux parties : le client sait ce qui se passe sur son application sans avoir à demander, et le prestataire garde une vision d'ensemble qui évite de traiter chaque ticket isolément, sans lien avec les précédents.

Un canal simple suffit à faire vivre ce rythme : un email ou un outil de tickets partagé, où chaque demande garde une trace écrite. Le dirigeant qui appelait auparavant un numéro personnel, en espérant que la personne réponde, gagne un fonctionnement plus fiable, même si moins direct en apparence.

Ce que Techmind ne fera pas

La peur la plus fréquente face à un contrat de maintenance est de perdre la main sur son propre outil : que le prestataire devienne impossible à remplacer, garde le code pour lui, et impose ses conditions dès que le client veut partir. Cette peur mérite une réponse claire, pas une formule rassurante.

Nous ne signons aucun contrat qui empêche d'y mettre fin : un client qui veut arrêter le prévient dans les délais convenus, récupère le code, la documentation produite pendant la reprise en main et l'historique des modifications, sans négociation supplémentaire.

Nous ne retenons ni le code ni la documentation en cas de désaccord ou de fin de contrat. Ce que nous avons produit pendant la maintenance appartient à l'entreprise qui l'a payé, et cela se dit avant la signature, jamais après une dispute.

Nous ne facturons pas de reprise en main cachée dans un forfait annoncé bas pour signer vite. Si l'audit initial révèle un travail plus important que prévu, le client le sait avant que le devis change, jamais après avoir découvert la facture.

Cette posture protège autant le client que le prestataire : un contrat que personne ne veut quitter parce qu'il fonctionne vaut mieux qu'un contrat que personne ne peut quitter parce qu'il enferme.

Ces engagements se vérifient d'ailleurs facilement avant de signer : il suffit de demander par écrit ce qui se passe en cas de départ, et de comparer la réponse à ce que le contrat dit réellement. Un prestataire qui répond sans détour sur ce point mérite déjà davantage de confiance que celui qui élude la question.

Les risques d'une mauvaise reprise et comment les éviter

Une reprise en main mal préparée révèle parfois plus de problèmes que prévu, et il vaut mieux le savoir avant de signer un contrat de maintenance qu'après. Trois risques reviennent le plus souvent.

Le code sans documentation d'abord : quand personne n'a écrit pourquoi telle règle existe, le prestataire qui reprend la main doit reconstituer l'intention à partir du seul comportement observé, ce qui prend du temps et laisse toujours une part d'incertitude sur les cas les plus rares.

Les dépendances obsolètes ensuite : une application construite sur des briques logicielles qui ne reçoivent plus de correctifs de sécurité expose l'entreprise à un risque qui grandit avec le temps, indépendamment de toute nouvelle demande. Mettre ces briques à jour peut lui-même casser des parties du code qui en dépendaient silencieusement.

La dette accumulée enfin, celle qu'on découvre seulement une fois la reprise en main terminée : des raccourcis pris il y a des années, jamais nettoyés, qui rendent chaque modification suivante plus lente que la précédente. Le sujet mérite d'être compris en détail dans le guide sur la dette technique.

Une reprise ne doit jamais être vendue comme une garantie sans surprise : dire l'inverse rassure trop vite et prépare une déception plus tard. Un audit honnête liste ce qui inquiète, même quand ce n'est pas ce que le client espérait entendre au départ.

La bonne réaction face à une dette découverte n'est ni de tout réécrire dans la panique, ni de l'ignorer en espérant qu'elle attende sagement. Elle se rembourse par étapes, en commençant par les zones les plus risquées, sans arrêter l'activité de l'entreprise pendant les travaux.

Un moyen simple de vérifier l'état des dépendances avant de signer : demander au prestataire une liste des briques logicielles utilisées et de leur ancienneté. Une application qui n'a reçu aucune mise à jour depuis plusieurs années porte presque toujours ce risque, même quand elle fonctionne encore sans incident visible.

Des exemples concrets de ce qu'une TMA corrige au quotidien

Les incidents qu'une maintenance applicative traite ressemblent rarement à un scénario catastrophe. Ce sont des accrocs ordinaires, répétés, qui finissent par coûter cher parce que personne n'a le temps de les traiter sans contrat en place.

Une mise à jour d'une bibliothèque logicielle qui casse une fonction au déploiement suivant : l'application fonctionnait la veille, elle plante le lendemain matin, sans qu'aucune donnée n'ait changé du côté du client. Sans surveillance, ce type d'incident se découvre au pire moment, quand un utilisateur appelle en urgence.

Un certificat de sécurité qui expire sans que personne ne l'ait noté dans un calendrier : le site ou l'application affiche soudain une alerte de sécurité aux visiteurs, pour une raison purement administrative, invisible tant que personne n'y pense à l'avance.

Un bug remonté par un client final qui bloque une facturation : une ligne de commande qui ne s'enregistre pas dans certains cas précis, découverte parce qu'un client s'est plaint plutôt que par un contrôle interne. Le correctif prend parfois une heure, une fois la cause trouvée.

Une règle de calcul qui doit changer parce que la loi a bougé : un taux de TVA, un barème, une obligation nouvelle qui touche directement ce que l'application produit. Ces changements sont prévisibles dans leur nature, imprévisibles dans leur date, et un contrat de maintenance absorbe cette imprévisibilité.

Aucun de ces exemples n'est un cas client réel, faute de référence validée pour ce sujet à ce jour : ce sont des scénarios génériques, du type de ceux que toute application en usage courant rencontre tôt ou tard, quelle que soit l'entreprise qui l'utilise.

Ce qui distingue une bonne maintenance d'une mauvaise ne se voit pas dans les incidents eux-mêmes, inévitables quelle que soit la qualité du code, mais dans le délai entre l'apparition du problème et sa correction. Un contrat qui fonctionne fait disparaître un bug en quelques heures. Un contrat qui ne fonctionne pas laisse le même bug traîner des semaines, jusqu'à ce qu'un client s'en plaigne une deuxième fois.

Comment choisir son prestataire de TMA

Le choix d'un prestataire de maintenance se joue avant la signature, sur des critères vérifiables, pas sur une impression de confiance générale.

Premier critère : accepte-t-il de lire du code qu'il n'a pas écrit, sans exiger de tout réécrire pour s'y retrouver ? Un prestataire qui propose systématiquement une reconstruction, quel que soit l'état réel de l'application, cherche peut-être un projet plus gros que ce dont l'entreprise a besoin.

Deuxième critère : propose-t-il un audit avant de chiffrer un forfait, plutôt qu'un devis donné à l'aveugle sur la seule base d'une conversation ? Un contrat signé sans avoir ouvert le code une seule fois reste un pari, quel que soit le sérieux affiché par celui qui le propose.

Troisième critère : explique-t-il noir sur blanc ce qui se passe si le contrat s'arrête ? Qui garde le code, la documentation, l'historique des modifications ? Un prestataire qui esquive cette question au moment de signer se comportera rarement mieux le jour où elle deviendra concrète.

Quatrième critère : donne-t-il un délai de réponse en jours ou en heures, plutôt qu'une formule vague du type « au plus vite » ? Un engagement chiffré, même modeste, vaut mieux qu'une promesse qui ne coûte rien à faire et rien à tenir.

Un dirigeant qui, en posant ces questions, réalise qu'il n'a pas besoin d'une reprise mais d'un projet neuf, bien préparé depuis le départ, trouvera dans le guide sur le cahier des charges de quoi structurer cette demande avant de la confier à qui que ce soit.

Ces critères ne garantissent pas un contrat parfait, aucun ne le peut vraiment. Ils réduisent le risque de découvrir, six mois plus tard, qu'on a signé avec quelqu'un qui promettait plus qu'il ne pouvait tenir.

Rien n'empêche non plus de démarrer petit : un premier mois d'observation, avant de signer un contrat sur douze mois, laisse le temps de juger la réactivité réelle du prestataire. Une entreprise déjà échaudée par un premier prestataire a le droit de tester avant de s'engager plus longtemps.