Prestataire TMA choix - couverture article

Choisir son prestataire TMA et savoir quand en changer

Prestataire TMA choix - couverture article

Choisir son prestataire TMA et savoir quand en changer

Catégories : Expertise MétierPar

Qu’est-ce que la TMA ?

La Tierce Maintenance Applicative désigne l’externalisation de la maintenance corrective, évolutive et adaptative d’un patrimoine applicatif à un prestataire tiers, sur un périmètre et un niveau de servce contractualisés (SLA)

Ce que cet article couvre et pour qui ?

Si vous lancez votre premier appel d’offres TMA, la partie 1 de cet article vous donne les cinq critères qui font vraiment la différence entre deux candidats comparables sur le papier.

Si vous avez déjà un contrat en place et que quelque chose ne va plus tout à fait, la partie 2 est celle qui vous concerne : comment détecter la dégradation avant qu’elle ne devienne critique, comment calculer le coût réel de rester VS partir, et comment porter cette décision en CODIR sans endosser l’échec seul.

Partie 1 : Sélectionner un prestataire TMA : les 5 critères qui peuvent faire la différence

La plupart des appels d’offres TMA se concluent sur des critères trop homogènes : tous les candidats sérieux proposent des SLA corrects, une équipe dédiée, un portail de tickets. Le vrai tri se fait ailleurs.

Critère n°1 : la capacité à reprendre une application avec une documentation faible ou inexistante.

C’est le test de réalité numéro 1. Demandez comment le prestataire procède quand il reprend un patrimoine applicatif sans documentation à jour, ce qui est le cas sur la majorité des périmètres. Un prestataire solide décrit un processus : audit initial, sessions de knowledge transfer avec l’équipe sortante, cartographie des flux critiques, identification des zones à risque. Un prestataire qui répond « on s’adapte » ou « on a l’habitude » ne répond pas à la question. Un bon prestataire va aussi savoir expliquer en quoi ces livrables sont nécessaires (risques couverts, apport concret) et proposer un plan priorisé : ce qui doit être repris immédiatement, ce qui peut l’être plus tard, en cohérence avec le plan projet (par exemple : pas de refonte UX, mais faut-il quand même refaire les maquettes pour maintenir l’ergonomie ?).

Question à poser : « Décrivez-moi la dernière reprise TMA que vous avez effectuée sur un périmètre peu documenté. Quels livrables avez-vous produits à l’issue de la phase d’entrée ? »

Critère n°2 : la composition réelle de l’équipe affectée à votre compte

Le profil qui répond à l’appel d’offres n’est pas toujours celui qui travaillera sur vos applications. Ce point est systématiquement sous-évalué lors de la sélection et figure dans la quasi-totalité des retours d’expérience négatifs.

Question à poser :

  • Qui sera le référent technique sur mon compte au démarrage ?
  • Quelle est son expérience sur [technologie spécifique] en conditions de production ?
  • Que se passe-t-il contractuellement s’il quitte votre structure dans les 12 premiers mois ?
  • Quel niveau de séniorité et quelles compétences sont contractuellement garanties sur la durée ?
  • Quelles sont les conditions de remplacement, la période de transfert prévue en cas de départ, et l’existence éventuelle de profils backup ?

Critère bonus : la gouvernance du contrat

Au-delà des cinq critères précédents, la façon dont le prestataire propose de piloter le contrat mérite un examen à part entière : instances de pilotage prévues (comité opérationnel, comité de pilotage), fréquence et niveau des interlocuteurs, procédures d’escalade formalisées, format et périodicité du reporting. Un prestataire qui décrit précisément ces mécanismes évite les zones grises qui pourront coûter cher plus tard.

Question à poser :

  • Quelle est votre gouvernance type sur un compte comparable, et à quelle fréquence les instances se réunissent-elles ?

Critère n°3 : la différenciation selon la criticité des applications

Un prestataire TMA qui propose le même niveau de service pour votre ERP de production et pour votre outil de reporting RH n’a pas réfléchi à votre contexte. La criticité applicative doit piloter les SLA, les astreintes et les niveaux de priorité. Si cette granularité n’est pas dans la proposition, c’est que le prestataire applique un modèle standard plutôt qu’une réponse calibrée. La criticité ne se déduit ps mécaniquement du type d’application : une appli RH peut devenir critique en période de clôture, un ERP peut contenir des modules non critiques. Un bon prestataire montre qu’il a compris les enjeux métier du client et identifie ce qui est critique, pourquoi, et dans quel contexte (par exemple un site e-commerce en période de soldes).

Questions à poser :

  • Comment adaptez-vous vos engagements de service selon les niveaux de criticité applicative ?
  • Pouvez-vous me montrer un exemple de matrice de criticité utilisée chez un client comparable ?

Critère n°4 : la gestion de l’interface entre TMA et projets d’évolution

Sur un périmètre applicatif actif, la TMA coexiste presque toujours avec des chantiers de modernisation ou d’intégration en parallèle. Cette interface est un point de friction fréquent : qui est responsable de quoi quand une évolution introduit une régression ? Comment les SLA évoluent pendant une phase de migration ? Un prestataire qui n’a pas de réponse structurée à ces questions vous laissera arbitrer seul quand le problème se posera.

Questions à poser :

  • Comment gérez-vous contractuellement et opérationnellement la coexistence entre maintenance et projet évolutif sur un même périmètre ?
  • Quelles sont vos responsabilités en cas de régression introduite par un projet évolutif ?
  • Quelles garanties associez-vous à un livrable ?
  • Comment gérez-vous concrètement le passage d’une phase projet vers la TMA (recette, transfert de responsabilité, delivery) ?

Critère n°5 : les conditions de sortie… avant d’entrer

La réversibilité se négocie avant la signature, jamais après. Elle couvre trois dimensions : le préavis, les livrables de sortie (sources, documentation, transfert de connaissance, accès aux environnements, …), et l’assistance à la transition. Un prestataire qui minimise ce point ou qui renvoie à « les conditions standard du marché » mérite d’être pressé davantage. C’est précisément parce que cette phrase est rarement encadrée que les transitions passent mal.

Questions à poser :

  • Que livrez-vous précisément en fin de contrat ? Sur quelle durée ? Avec quels profils ?
  • Ces engagements sont-ils dans le contrat ou dans une annexe optionnelle ?

Grille d’évaluation pondérée

Adaptez à votre contexte les coefficients proposés dans le tableau ci-dessous.

Sur un périmètre 24/7 ou avec des applications métier critiques, augmentez le poids des critères 1 et 3.

Notation de 0 à 5 par critère :

  • 0 = aucune réponse ou hors sujet
  • 1 = déclaration générale sans méthode
  • 2 = méthode décrite mais sans livrable ni preuve
  • 3 = méthode structurée avec livrables identifiés
  • 4 = méthode étayée par un cas comparable
  • 5 = méthode, preuves, engagements contractuels et équipe nommée.

Définissez également, en amont, les critères éliminatoires (par exemple : la réversibilité renvoyée à une annexe optionnelle).

Critère

Coeff

Poids max

Prestataire A

Prestataire B

Prestataire C

Capacité à reprendre sans documentation

X5

25

/5

/5

/5

Composition et stabilité de l'équipe réelle

X5

25

/5

/5

/5

Différenciation selon criticité applicative

X4

20

/5

/5

/5

Gestion interface TMA / projets évolutifs

X3

15

/5

/5

/5

Conditions de réversibilité

X3

15

/5

/5

/5

Score total

/100

Checklist : les 10 questions qui feront la différence

À utiliser lors de vos entretiens prestataires (sélection) ou de vos revue de contrat (suivi). Chaque question appelle une réponse binaire, soit le prestataire a une réponse concrète, soit il n’en a pas.

En sélection initiale : 

  1. Le prestataire décrit-il un processus d’entrée précis, avec des livrables nommés et des délais ? Ou se contente-t-il d’évoquer son expérience ?
  2. Les profils affectés sont-ils nommés et vérifiables ? Ou génériques ?
  3. Les SLA sont-ils différenciés par niveau de criticité applicative ?
  4. La réversibilité est-elle dans le corps du contrat, avec des engagements datés ? Ou dans une annexe optionnelle ?
  5. Le prestataire a-t-il déjà géré une coexistence TMA + projet évolutif sur un même périmètre ? Comment ?

En suivi de contrat : 

  1. Le reporting mensuel fait-il apparaître des tendances (évolution du correctif vs évolutif, délais moyens par niveau) ? Ou se limite-t-il à des comptages bruts ?
  2. Le prestataire remonte-t-il proactivement les signaux d’alerte (dette technique identifiée, composant en fin de vie, risque de régression) ? Ou attend-il que vous posiez les questions ?
  3. En cas d’incident P1 (priorité 1), le délai de prise en charge réel correspond-il au délai contractuel sur les 6 derniers mois ?
  4. L’équipe affectée à votre compte est-elle stable depuis le démarrage ? Ou a-t-elle connu un turnover significatif ?
  5. Êtes-vous en mesure de reprendre le périmètre en main dans un délai proportionné à sa complexité (de quelques semaines pour un site statique à plusieurs mois pour un ERP) si le contrat se termine demain ?

Partie 2 : Détecter la dégradation d’un contrat TMA et décider d’agir

C’est la vraie question pour un DSI qui gère déjà des contrats TMA. Les problèmes ne surgissent pas du jour au lendemain : ils s’installent progressivement, souvent sous le seuil de visibilité des indicateurs contractuels. Le risque est de réagir trop tard, quand la situation est devenue difficile à défendre en interne.

Les signaux faibles d’un contrat qui se dégrade

Les indicateurs contractuels (taux de respect des SLA, nombre de tickets ouverts) mesurent ce qui est déjà visible. Les signaux faibles précèdent toujours la dégradation mesurable.

Signaux côté prestataire

  • Le référent technique change sans que vous en soyez informé formellement. Vous le découvrez lors d’une réunion de suivi.
  • Les délais de traitement des demandes d’évolution s’allongent sans explication documentée.
  • Le reporting devient moins précis, les indicateurs se simplifient, les anomalies disparaissent des comptes rendus.
  • Les escalades arrivent de plus en plus de votre côté, jamais du leur.
  • Les réponses techniques deviennent génériques : on retrouve les mêmes formulations sur des tickets très différents.

Signaux côté utilisateurs métier

  • Les remontées d’insatisfaction ne passent plus par le canal officiel (tickets) mais par vous directement ou par voie hiérarchique.
  • Les contournements prolifèrent : les équipes métier développent des solutions de bord (Excel, exports manuels) pour pallier des anomalies non résolues.
  • Le volume de tickets « mineurs » augmente, signe que des corrections précédentes ont introduit de nouvelles instabilités.

Signaux contractuels de second niveau

  • Le taux de respect des SLA reste dans les clous mais le délai moyen de résolution effective s’allonge.
  • La part de correctif augmente par rapport à l’évolutif sans que la complexité de l’application ait changé.
  • Les demandes de dérogation ou d’avenant se multiplient sur des points qui étaient couverts implicitement au démarrage.

À quel moment ces signaux justifient une décision ?

Un signal isolé ne justifie pas nécessairement une action. Plusieurs signaux concomitants de reporting consécutifs justifient un recadrage formel et l’exigence d’un plan de remédiation.

Le cadre d’arbitrage se structure en trois questions : 

  1. Le problème est-il structurel ou conjoncturel ? Un turnover dans l’équipe du prestataire est conjoncturel s’il est suivi d’un remplaçant de niveau équivalent et d’une période de montée en compétences encadrée. Il devient structurel si le prestataire ne dispose plus des profils compétents sur vos technologies, ou si le renouvellement d’équipe est une pratique récurrente sur votre compte.
  2. Le prestataire a-t-il la capacité et la volonté de se corriger ? Formalisez vos constats par écrit. Organisez une réunion de recadrage avec les niveaux hiérarchiques appropriés chez le prestataire. Un prestataire qui joue le jeu produit un dans un délai proportionné à la gravité et à la complexité du sujet, tout en prenant des mesures conservatoires immédiates si la situation l’exige.
  3. Quel est le coût comparé de rester et de partir ? C’est la question que le DSI doit pouvoir chiffrer avant d’aller en CODIR.

Calculer le coût réel d’un changement de prestataire

L’erreur fréquente est de calculer le TJM du prestataire entrant avec celui du prestataire sortant. Le coût d’un changement TMA ne se résume pas à l’écart tarifaire : il intègre plusieurs composantes que les équipes financières n’anticipent pas spontanément.

Composante 1 : le coût de transition

La période de transfert de connaissance mobilise à la fois le prestataire sortant (en vertu des clauses de réversibilité) et le prestataire entrant, pendant une durée qui va typiquement de 1 à 3 mois selon la complexité du périmètre. Sur cette période, vous payez en pratique les deux structures simultanément, même partiellement. Sur un contrat TMA d’une taille comparable à l’exemple ci-dessous, cette période de chevauchement peut représenter de l’ordre de 15 à 25 % du budget TMA annuel. Ce coût est toutefois à relativiser : dans un appel d’offres bien cadré, la contribution du prestataire sortant à la réversibilité est déjà prévue au contrat (ce qui n’est pas systématiquement le cas).

Composante 2 : la dégradation de service pendant la montée en compétence

Le prestataire entrant ne sera pas opérationnel à 100 % dès le premier jour. La courbe de montée en compétences génère une période de risque accru, particulièrement sur les incidents complexes. La durée de cette période dépend directement de la qualité de la documentation transmise et du niveau d’accompagnement du prestataire sortant, deux variables que les clauses contractuelles de sortie sont censées encadrer. Dans les cas où ces clauses sont absentes ou floues, la période de risque peut être longue.

Composante 3 : le temps DSI et équipe interne mobilisée

Un changement de prestataire TMA mobilise un volume important de « temps interne » : rédaction du cahier des charges, animation du processus de sélection, pilotage de la transition, gestion des incidents de la période de bascule. Ce coût est rarement comptabilisé mais il est réel. Sur un périmètre applicatif d’une taille comparable à l’exemple ci-dessous, il représente entre 20 et 40 jours de travail cumulés sur 6 mois, répartis principalement entre le DSI, le responsable applicatif, le responsable technique et les référents métier.

Composante 4 : le coût d’opportunité

Un changement de prestataire TMA mobilise de l’énergie managériale qui aurait pu être allouée à des projets à valeur ajoutée. C’est la composante la plus difficile à quantifier mais souvent la plus pertinente pour un CODIR.

Exemple chiffré : périmètre intermédiaire, budget TMA 180 K€/an

Voici ce que donne l’arbitrage sur un cas type (ETI industrielle, périmètre de 4 applications, dont un ERP critique, contrat TMA à 180k€ annuels, prestataire en place depuis 3 ans).

Note : le cas présenté ci-dessous est fictif. Il vise à illustrer la méthode d’arbitrage, non à décrire une situation client réelle.

Coût estimé du changement :

Composante

Hypothèse

Estimation

Chevauchement prestataire sortant / entrant

2 mois à mi-régime

15K€

Surcoût prestataire entrant (montée en compétences)

+30% pendant 3 mois

13K€

Temps interne (DSI + Responsable applicatif + métier)

30 jours x 600€/j (estimation)

18K€

Incidents supplémentaires pendant la transition

2 à 3 P2 non résolus dans les délais

5 à 10K€

Total estimé du changement

51 à 56K€

Soit environ 28 à 31% du budget TMA annuel (fourchette cohérente avec des retours terrain sur des périmètres de cette taille).

Coût estimé du statu quo sur 12 mois supplémentaires

Composante

Hypothèse

Estimation

Gestion des escalades (temps DSI)

1 jour / semaine perdu sur 12 mois

28K€

Contournements non résolus (coût productivité métier)

2 équipes à 0.5j / semaine

30K€

Risque d'incident P1 non couvert (ERP)

1 incident majeur probable, durée 2 jours

15 à 40K€

Total estimé du statu quo

73 à 98K€

Dans ce scénario, le coût attendu du statu quo ressort supérieur de 20 à 45k€ à celui du changement, sous réserve des hypothèses retenues et avant même de comptabiliser le coût d’opportunité sur les projets mis en attente.
L’arbitrage devient défendable en CODIR dès lors qu’il est présenté sous cette forme : deux options chiffrées, avec leurs hypothèses explicitées, plutôt qu’un constat qualitatif sur la dégradation du service.

Comment porter la décision en CODIR ?

Un DSI qui arrive en CODIR avec une recommandation de changement de prestataire sans cadre structuré s’expose à deux risques : passer pour celui qui a mal géré son prestataire, ou se voir opposer « Pourquoi maintenant et pas avant ? »
Le cadre qui fonctionne repose sur trois éléments.

Documenter la chronologie des faits (pas les ressentis)

La décision doit s’appuyer sur des faits datés et tracés : taux de SLA sur les 6 derniers mois, liste des incidents non résolus au-delà des délais contractuels, compte-rendu de la réunion de recadrage, réponse ou absence de réponse du prestataire. Un tableau de bord simple sur 6 mois est plus convaincant qu’une synthèse qualitative.

Présenter l’alternative, pas seulement le problème

Arriver en CODIR avec « le prestataire actuel ne va plus » sans solution de remplacement identifiée expose à l’inaction. L’idéal est d’arriver avec plusieurs scénarios crédibles : remédiation avec le prestataire actuel, consultation du marché, calendrier de remplacement et critères de sélection, éventuellement un ou plusieurs acteurs pré-identifiés (selon les règles d’achat de l’entreprise). Ces scénarios sont ensuite à assortir d’une estimation du coût total pour chacun.

Cadrer la responsabilité sans l’endosser seul

La sélection initiale du prestataire a été validée dans un cadre de décision qu’il faut reconstituer (parties prenantes, critères retenus, arbitrages). La dégradation est intervenue dans un contexte qui a évolué (croissance du périmètre, changement d’équipe chez le prestataire, hausse de la complexité applicative). Présenter la décision comme une réévaluation stratégique, fondée sur des faits et sur un calcul coût / risque, permet de sortir du registre de l’échec personnel pour entrer dans celui de la gestion rigoureuse d’un contrat.

Conclusion

Choisir un prestataire TMA et gérer un contrat TMA dans la durée sont deux exercices distincts. Le premier se joue en quelques semaines d’appel d’offres, sur des critères que beaucoup d’entreprises évaluent trop vite. Le second s’étale sur des années et demande de maintenir une lecture active d’un contrat qui a tendance à se normaliser vers le bas sans que personne ne le décide vraiment.
Ce que cet article a vocation à vous donner, c’est le cadre pour agir avant d’être en position de réagir : identifier les signaux, calculer l’arbitrage, structurer la décision. Si vous avez reconnu votre situation dans la partie 2, votre prochaine étape sera d’identifier un prestataire capable de reprendre votre périmètre dans de bonnes conditions.
Si vous envisagez un changement de prestataire TMA sur des applications métier critiques, nous pouvons vous montrer comment SoftFluent organise une reprise : audit initial structuré, équipe dédiée nommée dès le démarrage, et clauses de réversibilité incluses dans le contrat.

F.A.Q

Un prestataire TMA peut-il refuser de participer au transfert de connaissance en fin de contrat ?2026-09-17T12:16:59+02:00

La capacité à imposer une participation au transfert dépend principalement des engagements contractuels et du cadre juridique applicable. Une clause de réversibilité précise réduit fortement les zones de discussion, et elle doit être validée avec les conseils juridiques de l’entreprise.

Comment encadrer contractuellement la réversibilité ?2026-09-17T12:15:40+02:00

La clause de réversibilité doit préciser : le préavis minimum (généralement 3 à 6 mois selon la complexité), les livrables du prestataire sortant (documentation, cartographie applicative, accès aux environnements, sessions de passation), la durée de l’assistance à la transition et son coût, et les conditions dans lesquelles le prestataire entrant peut participer aux sessions de transfert.

À quel moment enclencher une procédure de sortie TMA ?2026-09-17T12:14:46+02:00

Quand deux conditions sont réunies : plusieurs signaux de dégradation concomitants sur plusieurs cycles de reporting, et l’absence de plan de remédiation crédible du prestataire après une réunion de recadrage formelle. Attendre un incident majeur pour déclencher la sortie, c’est partir en position de faiblesse.

Ne ratez plus aucune actualité avec la newsletter mensuelle de SoftFluent

Newsletter SoftFluent
Aller en haut