Prestataire de maintenance applicative : TMA, support et reprise de vos applications

Quel prestataire choisir pour la maintenance d’une application existante ?

Un prestataire de maintenance applicative doit pouvoir reprendre une application qu’il n’a pas développée sans imposer immédiatement une refonte. La première étape consiste à comprendre le code, l’architecture, les données, les environnements, les dépendances et les processus de déploiement afin d’identifier ce qui peut être maintenu tel quel et ce qui fragilise réellement le RUN.

La compétence nécessaire dépend donc du produit. Une application métier peut demander simultanément du développement frontend/backend, de la base de données, des API, du cloud et du DevOps. Nous constituons le périmètre de maintenance selon ces besoins plutôt que d’affecter systématiquement une équipe complète à une application qui ne nécessite que quelques interventions par mois.

Le bon prestataire doit enfin rendre son intervention mesurable : périmètre couvert, criticité des incidents, délais de prise en charge, responsabilités, consommation mensuelle, backlog et réversibilité doivent être définis dès le démarrage.

Que couvre un contrat de maintenance applicative ou de TMA ?

La TMA, tierce maintenance applicative, consiste à confier tout ou partie de la maintenance d’un logiciel à un prestataire externe. Elle ne se limite pas à corriger les bugs : le périmètre est défini selon ce qui doit réellement rester opérationnel et maintenable.

Comment reprendre la maintenance d’une application développée par un autre prestataire ?

La reprise commence par la récupération de la chaîne de contrôle technique : repositories Git, hébergement ou cloud, bases de données, DNS, certificats, secrets, outils de monitoring, CI/CD, sauvegardes et comptes tiers nécessaires au fonctionnement du produit.

Nous cartographions ensuite l’application et ses dépendances, vérifions les procédures de déploiement et de restauration, puis identifions les principaux risques : dépendances obsolètes, absence de tests sur certains parcours critiques, documentation manquante, accès détenus uniquement par l’ancien prestataire ou opérations encore manuelles.

L’objectif de cette phase n’est pas de refaire l’application. Le premier jalon utile est de pouvoir comprendre l’existant, reproduire son fonctionnement, intervenir sans dépendre de l’équipe précédente et réaliser un premier changement en production de manière maîtrisée.

Comment organiser les tickets, incidents et SLA de maintenance applicative ?

Chaque demande doit être qualifiée selon son impact plutôt que traitée dans une file unique. Un incident bloquant pour l’exploitation n’a pas la même priorité qu’une anomalie visuelle ou qu’une demande d’évolution.

Un SLA, Service Level Agreement, définit les engagements de service : plages de support, priorité des incidents et notamment délai de prise en charge. Il faut distinguer temps de réponse et temps de résolution : promettre une résolution en deux heures n’est pas réaliste pour tous les incidents, alors qu’un engagement de prise en charge peut être clairement contractualisé.

Koragence peut centraliser les demandes dans un système de tickets avec horodatage, criticité, responsable, statut, historique et délai de traitement. Selon le besoin, le support peut fonctionner en heures ouvrées ou avec une couverture élargie pour les applications réellement critiques.

Comment maintenir la sécurité et les dépendances d’une application en production ?

Une application peut continuer à fonctionner tout en accumulant progressivement des risques. Frameworks, librairies, images Docker, systèmes d’exploitation et services tiers évoluent ; certaines mises à jour deviennent nécessaires avant qu’une vulnérabilité ou une incompatibilité ne provoque un incident.

La maintenance préventive consiste donc à surveiller dépendances, vulnérabilités, logs, erreurs récurrentes, certificats, capacité disque, sauvegardes et composants arrivant en fin de support. Toutes les mises à jour ne doivent pas être appliquées immédiatement : leur criticité et le risque de régression doivent d’abord être évalués.

Les sauvegardes doivent également être accompagnées d’une stratégie de restauration. Une sauvegarde existante mais jamais vérifiée ne démontre pas qu’une application pourra réellement être remise en service après un incident.

Maintenance applicative et DevOps : faut-il confier les deux au même prestataire ?

Un incident visible dans l’application peut provenir du code, d’une base de données, d’un déploiement, d’un certificat, d’une file de tâches ou de l’infrastructure. Séparer complètement TMA applicative et DevOps peut donc créer des délais lorsque plusieurs prestataires doivent d’abord déterminer qui est responsable.

Pour les applications de taille intermédiaire, un même dispositif peut couvrir développement et exploitation courante : analyse des logs, correctifs, CI/CD, cloud, déploiements et supervision. Des spécialistes peuvent être mobilisés ponctuellement lorsque l’incident nécessite une expertise infrastructure, sécurité ou base de données plus profonde.

À l’inverse, une infrastructure importante ou soumise à un SLA 24/7 peut justifier une équipe RUN dédiée. Le bon modèle dépend de la charge réellement observée, pas uniquement de la taille de la codebase.

Comment éviter de devenir dépendant de son prestataire TMA ?

La réversibilité désigne la capacité à transférer ultérieurement la maintenance vers une équipe interne ou un autre prestataire sans reconstruire la connaissance du produit depuis zéro. C’est un point qui devrait être prévu dès le démarrage du contrat.

Le client doit conserver un accès clair au code source, aux environnements, à l’hébergement, aux données, aux DNS et aux principaux comptes techniques. La documentation, les procédures de déploiement et les décisions importantes doivent être mises à jour pendant la mission plutôt qu’au moment du départ.

Chez Koragence, la maintenance doit donc rendre progressivement l’application plus facile à comprendre et à reprendre, pas créer une nouvelle dépendance autour de connaissances détenues uniquement par l’équipe de support.

Combien coûte un prestataire de maintenance applicative ?

Le prix dépend davantage de la charge et du niveau de service que du nombre de lignes de code. Une application stable nécessitant quelques correctifs par mois ne doit pas être dimensionnée comme une plateforme critique qui nécessite supervision permanente et astreinte.

Le chiffrage doit notamment considérer : nombre historique d’incidents, complexité technique, infrastructure, fréquence des déploiements, criticité métier, plage de support, SLA et volume d’évolutions souhaité. Les modèles les plus courants sont le forfait mensuel avec capacité incluse, la consommation de jours ou d’heures, ou une combinaison forfait et interventions supplémentaires.

Sur la SERP actuelle, certains prestataires affichent déjà des offres démarrant autour de 1 500 € HT par mois, avec des contrats pouvant dépasser 10 000 € pour des systèmes critiques 24/7. Cela montre pourquoi il est plus pertinent de dimensionner le contrat sur le besoin réel plutôt que d’afficher un forfait unique.

Faut-il externaliser la maintenance applicative ou recruter en interne ?

Un recrutement est pertinent lorsqu’un produit génère suffisamment de maintenance et d’évolution pour occuper durablement une compétence technique. Pour quelques jours d’intervention par mois, un poste senior à temps plein peut au contraire rester largement sous-utilisé.

La TMA externalisée permet de mutualiser plusieurs compétences et d’adapter la capacité au besoin réel. Elle est particulièrement adaptée lorsqu’une entreprise a besoin de conserver une application existante, mais ne souhaite pas reconstruire immédiatement une équipe technique complète.

Le modèle hybride devient intéressant lorsque l’entreprise possède un responsable produit ou technique interne et confie à Koragence la maintenance spécialisée, le DevOps ou les interventions nécessitant davantage de capacité.

Comment Koragence reprend et organise la maintenance de votre application ?

Notre méthode commence par un audit ciblé de reprise : accès, code, infrastructure, données, déploiements, monitoring, documentation et risques majeurs. Nous définissons ensuite le niveau de support, les priorités et la capacité mensuelle réellement nécessaires.

La reprise est sécurisée avant le RUN régulier : documentation des procédures indispensables, vérification des sauvegardes, configuration des accès, traitement des risques immédiats et première mise en production contrôlée.

Le fonctionnement courant devient ensuite simple : ticket → qualification → diagnostic → correction → tests → déploiement → clôture documentée. Les évolutions importantes restent cadrées comme des projets distincts afin que le budget de maintenance reste lisible.