Maintenance externalisée ou développeur interne : qui doit faire vivre votre logiciel ?

TMA ou développeur interne : le tableau comparatif

La TMA (tierce maintenance applicative) confie à un prestataire la correction, l'adaptation et l'évolution d'un logiciel en production, selon un contrat. Le développeur interne est un salarié de l'entreprise, présent au quotidien, qui connaît les équipes et leurs demandes. Les deux peuvent bien fonctionner ; ils ne protègent pas des mêmes risques.

Ce que coûte vraiment chaque option

Comparer un salaire et un abonnement de maintenance fausse la décision : les deux chiffres ne couvrent pas le même périmètre. Pour être juste, additionnez de chaque côté tous les postes.

• Développeur interne : salaire et charges, poste de travail et licences, temps de recrutement, formation continue, temps d'encadrement, et coût du poste vacant entre deux recrutements, quand plus personne ne peut corriger le logiciel.
• Maintenance externalisée : abonnement ou forfait de maintenance, évolutions chiffrées à part, temps de prise en main initial du code, et temps que vous passez à rédiger les demandes et à valider les livraisons.

Pour un logiciel qui demande quelques jours de travail par mois, un poste à temps plein reste souvent sous-employé, ou absorbé par d'autres tâches informatiques. Les facteurs de coût sont détaillés dans les pages combien coûte la maintenance d'un logiciel et recruter un développeur ou passer par une agence.

Le risque du développeur unique

Le risque principal d'un développeur unique n'est pas sa compétence, mais son absence. Le scénario est classique : le développeur qui a écrit l'outil part, les mots de passe du serveur sont dans son gestionnaire personnel, le déploiement se faisait « à la main » selon une procédure jamais écrite, et la première panne révèle que personne ne sait redémarrer l'application.

Cette fragilité a aussi une dimension réglementaire. L'article 32 du RGPD demande, pour tout traitement de données personnelles, la capacité de rétablir la disponibilité des données et l'accès à celles-ci dans des délais appropriés en cas d'incident, ainsi qu'une procédure pour tester régulièrement l'efficacité des mesures de sécurité. Une organisation où une seule personne détient les clés tient difficilement cet engagement. La page le développeur qui connaissait le logiciel est parti décrit comment reprendre la main dans ce cas.

Les compétences qu'un logiciel en production réclame

Un logiciel métier en production demande plus de compétences qu'un seul profil n'en réunit d'ordinaire :

• le code de l'application, côté serveur et côté écrans ;
• l'application mobile, quand elle existe, avec les règles des stores à suivre à chaque mise à jour ;
• la base de données : sauvegardes, performances, migrations ;
• le serveur : mises à jour du système, certificats, supervision ;
• la sécurité : correctifs, comptes, journaux.

Sur ces deux derniers points, les références publiques sont claires. Les dix règles d'or de l'ANSSI demandent d'appliquer les mises à jour dès qu'elles sont proposées et de réaliser régulièrement des sauvegardes non connectées. Les règles essentielles de la CNIL, mises à jour en juin 2026, recommandent la règle du 3-2-1 (trois copies, deux supports, une copie déconnectée) et des tests de restauration réguliers. Ces tâches discrètes sont les premières sacrifiées quand une seule personne gère aussi les demandes des utilisateurs.

Documentation et accès : la condition de toute organisation

Interne ou externe, la maintenance repose sur une base commune, qui permet de changer d'organisation sans tout perdre. La CNIL, dans son guide RGPD pour l'équipe de développement, consacre des fiches à la gestion du code source et à la qualité du code et de sa documentation ; ce sont les fondations d'une maintenance transmissible.

1. Un dépôt de code au nom de l'entreprise, avec l'historique des modifications.
2. Les accès (hébergement, base, stores, services tiers) dans un coffre partagé dont l'entreprise est propriétaire.
3. Une procédure de déploiement écrite, qu'une autre personne peut suivre.
4. Une procédure de restauration testée, pas seulement une sauvegarde programmée.
5. La liste des services tiers utilisés, avec leurs échéances de renouvellement.

Les clauses à faire figurer dans les contrats sont présentées dans le guide propriété du code source et réversibilité.

Le modèle mixte : un développeur interne épaulé par un prestataire

Le modèle mixte répartit le travail selon ce que chacun fait le mieux. Le développeur salarié prend les petites évolutions demandées par les équipes, qu'il comprend sans long cahier des charges. Le prestataire assure ce qui demande de la continuité ou des compétences rares : mises à jour de sécurité, exploitation des serveurs, application mobile, relecture du code, renfort lors des gros chantiers et remplacement pendant les absences.

Pour que l'attelage fonctionne, trois règles s'écrivent dès le départ : un seul dépôt de code partagé, des conventions de développement communes et une frontière claire entre ce que chacun livre en production. Sans elles, deux personnes modifient le même logiciel sans se coordonner, et le risque grandit au lieu de baisser.

Notre verdict selon la taille de l'entreprise

Quand aucune des deux options ne convient

• Le logiciel est un SaaS du marché : sa maintenance revient à l'éditeur ; votre sujet est le paramétrage et les connexions avec vos autres outils.
• Le logiciel est trop fragile pour être maintenu : ni un salarié ni un prestataire ne stabiliseront un code qui casse à chaque correction. La question devient celle de la reprise ou de la refonte, traitée dans le comparatif refaire son logiciel ou reprendre l'existant.
• Vous avez besoin d'une surveillance jour et nuit : une astreinte permanente relève d'un contrat d'infogérance dédié, pas d'une maintenance applicative classique ni d'un salarié seul.

L'accompagnement proposé par YMHB Web

Après la mise en service, YMHB Web propose un accompagnement qui couvre la maintenance et l'évolution des logiciels construits ou repris par l'agence. Son contenu, les délais d'intervention et ce qui relève d'une évolution chiffrée à part sont écrits avant le démarrage. Un modèle mixte avec un développeur salarié se cadre de la même façon, en écrivant qui livre quoi en production. Pour un logiciel écrit par un autre prestataire, tout commence par un état des lieux du code, des accès et de la documentation. Le guide TMA : définition de la maintenance applicative détaille les engagements à faire écrire dans un contrat.