Tierce maintenance applicative : le guide pour votre ERP

Le jour du go-live, l’équipe projet se disperse et l’entreprise pense que le plus difficile est passé. En réalité, c’est à ce moment que le vrai travail commence : l’ERP entre dans la vie quotidienne de l’entreprise et doit s’adapter à une activité qui évolue chaque jour.

La tierce maintenance applicative (TMA) est important, car c’est ce qui décide si le système reste un accélérateur ou s’il se dégrade en silence, mais beaucoup la réduisent à une simple hotline de dépannage.

Dans cet article, on vous explique ce qu’est réellement une TMA, ce qu’elle couvre, les types de contrats existants et pourquoi elle est particulièrement stratégique sur un ERP comme Microsoft Dynamics 365.

Tierce maintenance applicative (TMA) : définition

La tierce maintenance applicative désigne le fait de confier à un prestataire externe la maintenance, le support et l’évolution d’une application, comme l’exemple dans cet article qui est votre ERP.

La TMA intervient après la mise en place de la solution et une fois l’ERP en production il faut quelqu’un pour corriger les anomalies, absorber les mises à jour, faire évoluer le paramétrage et garantir la continuité de service. C’est le rôle d’un contrat de TMA, c’est à dire assurer dans la durée que l’outil reste fiable et aligné sur les besoins.

Concrètement, une TMA recouvre trois natures de maintenance qu’il est utile de distinguer.

Maintenance corrective, évolutive, préventive : que couvre une TMA ?

La maintenance corrective traite ce qui dysfonctionne : C’est la part la plus visible, mais pas la plus créatrice de valeur avec le réglage des anomalies, des blocages, des lenteurs et des erreurs de données.

La maintenance évolutive fait grandir l’ERP : C’est elle qui apporte une forte valeur ajoutée parce qu’elle transforme l’outil au rythme de l’entreprise comme : ajouter de nouvelles fonctionnalités, optimiser des flux, intégrer un nouveau processus métier et répondre à une obligation réglementaire.

La maintenance préventive anticipe : Elle réduit la charge de la TMA sur le long terme en évitant que les petits problèmes ne deviennent des urgences comme : la surveillance, les contrôles réguliers et les corrections avant que l’incident ne survienne.

Une TMA complète combine les trois avec un objectif constant : la qualité de service. C’est aussi la différence entre une maintenance qui maintient l’ERP en survie et une maintenance qui le fait progresser.

Pourquoi le vrai projet ERP commence après le go-live

Un ERP n’est pas un logiciel qu’on installe et qu’on oublie. Il est branché sur des processus qui bougent en permanence : un pays à ouvrir, une acquisition à intégrer, une règle fiscale qui change, un canal de vente qui se lance. Le paramétrage figé au démarrage se décale de la réalité dès le lendemain.

Quand la maintenance est négligée le scénario est toujours le même et silencieux : les contournements se multiplient, les utilisateurs ressortent leurs fichiers Excel, les données se dégradent, la confiance s’érode. Douze à dix-huit mois plus tard l’entreprise constate que son ERP « ne marche plus très bien » alors qu’il marchait au go-live, mais ce n’est pas l’outil qui a échoué, c’est l’absence d’entretien.

C’est pourquoi les projets les mieux menés traitent la TMA non comme une dépense de fin de projet, mais comme la suite logique du déploiement. Le go-live n’est pas une ligne d’arrivée, c’est le premier jour d’exploitation.

Le ticketing ne suffit pas : réactif contre proactif

L’erreur la plus coûteuse consiste à réduire la maintenance à un flux de tickets : quelque chose casse, on signale, on corrige. Cette approche purement réactive stabilise l’ERP au mieux, mais elle ne l’améliore jamais.

Une TMA qui crée de la valeur est aussi proactive : elle surveille, anticipe les points de rupture, propose des optimisations avant le problème. Le ticketing répond à « qu’est-ce qui ne marche pas ? » ; l’amélioration continue répond à « qu’est-ce qui pourrait marcher mieux ? ».

Ce volet proactif s’appuie de plus en plus sur l’automatisation, flux Power Automate, traitements planifiés, alertes… pour détecter et traiter en amont ce qui finirait sinon en ticket. C’est l’objet d’une démarche d’automatisation des processus intégrée à la maintenance et c’est ce qui distingue un simple support d’une vraie amélioration des performances dans la durée.

One Version : pourquoi un ERP Dynamics 365 ne peut pas rester figé

C’est le point que les articles génériques sur la TMA ignorent parce qu’ils mélangent tous les ERP. Microsoft Dynamics 365 Finance & Operations a une contrainte spécifique qui rend la maintenance non négociable : le modèle One Version.

One Version est la politique de mise à jour continue de Microsoft : tous les clients restent sur une version unique et à jour de la plateforme. Microsoft diffuse des mises à jour de service régulières (les versions Finance évoluent à un rythme soutenu) et deux vagues de lancement majeures par an apportent de nouvelles capacités, impossible de « rester sur sa version » comme à l’époque des ERP installés sur site.

Cette cadence a deux conséquences pour la maintenance. D’abord, chaque mise à jour doit être testée, avec les développements spécifiques et les intégrations qui sont à valider à chaque vague pour éviter les régressions faute de quoi une mise à jour peut casser un processus critique. Ensuite, la gestion des fonctionnalités (feature management) devient un travail récurrent, en décidant quelles nouvelles capacités activer et quand fait partie intégrante d’une bonne TMA.

Autrement dit, sur D365FO la maintenance reste indispensable même quand « tout va bien » le sol bouge en continu. Une TMA compétente transforme cette contrainte en avantage, pour le détail de la plateforme la documentation officielle des applications de finances et d’opérations fait référence.

Les types de contrats de TMA

Au-delà du contenu la TMA se décline en plusieurs types de contrats qu’il faut choisir selon vos besoins et votre maturité :

• Le forfait : un engagement de résultat sur un périmètre défini à prix maîtrisé, qui est adapté quand le besoin est stable et bien cadré.
• La régie (souvent forfaitisée) : la mise à disposition d’une expertise technique pour un volume de temps donné avec une obligation de moyens, qui est adapté aux périodes d’évolution forte.
• Le contrat au ticket : l’intervention est facturée à l’unité d’œuvre, qui est adapté aux besoins ponctuels.

À cela s’ajoutent les niveaux de service (SLA) : disponibilité, temps de réponse, délais de résolution… selon l’état. Sans SLA chiffré le mot « réactif » ne veut rien dire, c’est le SLA qui garantit la prise en charge dans des délais tenus.

Internaliser ou externaliser la maintenance de son ERP ?

Externaliser la maintenance permet de recentrer vos équipes sur votre cœur de métier plutôt que sur l’administration quotidienne de l’ERP et d’accéder à une expertise pointue sans la recruter. Garder la main en interne offre de la proximité, mais suppose des ressources internes disponibles, formées et maintenues à niveau sur une plateforme qui évolue sans cesse.

En pratique, le bon modèle est souvent hybride avec un noyau interne qui connaît le métier appuyé par un prestataire de TMA pour l’expertise technique, l’absorption des mises à jour et les pics de charge. La montée en compétence des équipes internes par la formation fait d’ailleurs partie d’une bonne TMA : un partenaire qui transmet vaut mieux qu’un partenaire qui rend dépendant.

Le coût d’un ERP mal maintenu

Renoncer à une vraie TMA semble une économie. La facture existe pourtant, mais elle est simplement différée car elle se lit sur trois plans.

Combien coûte une TMA : ce qui fait varier le prix

Personne ne peut annoncer un prix de tierce maintenance applicative sans connaître le périmètre, et c’est la raison pour laquelle les grilles publiées en ligne renseignent si peu. Deux ERP qui portent le même nombre d’utilisateurs peuvent demander un effort de maintenance du simple au triple. Mieux vaut donc comprendre ce qui fait bouger le montant que chercher un tarif de référence.

Les variables qui déterminent le montant

Le périmètre du contrat. Un contrat purement correctif ne coûte pas le même prix qu’un contrat qui embarque l’évolutif, le préventif et la veille réglementaire. C’est le premier écart entre deux propositions, et souvent celui qu’on ne voit pas en comparant les totaux.

Le volume de développements spécifiques. C’est le multiplicateur principal. Un ERP proche du standard se maintient presque à l’unité près ; chaque spécifique ajoute une surface à tester à chaque mise à jour de l’éditeur. Un environnement très personnalisé peut coûter davantage à maintenir qu’un environnement deux fois plus peuplé mais resté standard.

Le nombre d’entités légales et de pays. Les obligations déclaratives se multiplient avec les juridictions. Une société mono-entité et un groupe à cinq filiales dans trois pays n’ont pas la même charge de maintenance réglementaire, à effectif utilisateur égal.

Les interfaces. Chaque flux entrant ou sortant est un point de rupture potentiel, et une source de tickets qui n’ont rien à voir avec l’ERP lui-même. Le nombre d’interfaces pèse souvent plus lourd que le nombre d’utilisateurs.

La criticité des processus. Un système qui porte une production en continu appelle une amplitude horaire et des engagements de réactivité qu’un back-office administratif ne justifie pas. Ces engagements se paient, et ils doivent se payer : ils immobilisent des compétences.

L’état de la documentation à la reprise. Reprendre un ERP documenté, c’est un transfert de connaissance. Reprendre un ERP dont personne ne sait pourquoi un paramètre a été posé, c’est une phase d’audit à part entière. L’écart se voit sur les premiers mois du contrat.

La séniorité des intervenants. Une équipe qui connaît le produit et votre métier traite en une heure ce qu’un profil junior explore en une journée. Le taux le plus bas ne produit pas toujours le coût le plus bas.

Comparer deux propositions sans se tromper

Le mode de facturation — forfait, régie ou ticket, décrits plus haut — change la façon dont le prix se lit, mais il ne change pas la charge réelle. Pour comparer deux devis, il faut d’abord les ramener au même périmètre : les mêmes natures de maintenance, la même amplitude, le même traitement des montées de version, le même engagement sur les développements spécifiques.

Trois questions suffisent le plus souvent à révéler l’écart. Les montées de version Microsoft sont-elles incluses ou facturées à chaque vague ? Les tests de non-régression sur vos spécifiques font-ils partie du forfait ? Que se passe-t-il lorsque le volume consommé dépasse le volume contractualisé — report, facturation complémentaire, ou renégociation ?

Un contrat moins cher qui exclut les montées de version reporte simplement la dépense, en la rendant imprévisible. Sur un ERP qui évolue plusieurs fois par an, ce report est rarement une économie : c’est le même sujet que le coût d’un ERP mal maintenu, décrit plus haut, sous une autre forme.

Sur le plan technique, la dette s’accumule : chaque spécifique non testé à une mise à jour, chaque correctif posé dans l’urgence alourdit le système et le rattrapage coûte d’autant plus cher qu’on a attendu.

Sur le plan humain l’adoption s’érode : un incident qui traîne, une évolution sans réponse et les utilisateurs cessent de faire confiance à l’outil.

Sur le plan du pilotage : des données moins fiables produisent des analyses moins fiables et la direction perd la vision temps réel qui justifiait l’investissement. Mis bout à bout ces coûts invisibles dépassent presque toujours celui d’un contrat de maintenance.

Bien choisir sa TMA Dynamics 365

Si vous évaluez une tierce maintenance applicative pour votre ERP, quelques questions trient les offres au-delà du prix :

1. Le périmètre couvre-t-il l’évolutif ou seulement le correctif ?
2. Les SLA sont-ils chiffrés et adaptés à la criticité de vos processus ?
3. Comment sont gérées les vagues de mise à jour Microsoft et les tests de non-régression ?
4. Quelle est la séniorité réelle des intervenants ?
5. L’équipe connaît-elle votre métier, ou découvre-t-elle l’ERP générique ?
6. Et comment la connaissance de votre paramétrage est-elle documentée et conservée ?

Le prix le plus bas cache souvent un périmètre purement correctif et des profils juniors. Sur un ERP qui porte vos finances et votre supply chain c’est rarement l’économie qu’on croit.

Conclusion

La tierce maintenance applicative n’est pas l’épilogue d’un projet ERP. Elle en est le cœur, parce que c’est en production et dans la durée que le système tient ou non ses promesses. Sur Dynamics 365 où le modèle One Version impose une évolution continue, cette exigence n’est pas un luxe, c’est la condition pour que l’investissement initial continue de payer.

Spécialisé exclusivement sur Dynamics 365 Finance & Operations, FiveForty conçoit la TMA comme une relation durable, réactive et proactive menée par des consultants qui maîtrisent autant le métier que la technique. Parce qu’un ERP bien entretenu n’est jamais une contrainte, c’est un accélérateur qui dure.

Vous voulez comprendre les coulisses des projets ERP, ce qu’ils révèlent sur le métier et les équipes ? Recevez Le Vendredi ERP, notre newsletter hebdomadaire.

FAQ

C’est quoi la tierce maintenance applicative (TMA) ?

C’est l’externalisation auprès d’un prestataire spécialisé de la maintenance, du support et de l’évolution d’une application après sa mise en production. Pour un ERP elle couvre la correction des anomalies, les évolutions fonctionnelles, l’absorption des mises à jour et l’optimisation continue afin de garantir la continuité de service dans la durée.

Quelle est la différence entre la TMA et la TME ?

La TMA (tierce maintenance applicative) porte sur l’applicatif lui-même : le paramétrage, le code, les fonctionnalités de votre ERP. La TME (tierce maintenance d’exploitation) porte sur l’exploitation et l’infrastructure : serveurs, hébergement, supervision technique. Sur un ERP en cloud comme Dynamics 365, une partie de l’exploitation est gérée par Microsoft, ce qui recentre la TMA sur l’applicatif et les processus métier.

Quelle est la différence entre la TMA et le MCO ?

Le MCO (maintien en condition opérationnelle) est l’objectif : garder un système pleinement opérationnel dans le temps. La TMA est l’un des moyens d’y parvenir, le contrat par lequel un prestataire externe assure cette continuité côté applicatif en combinant maintenance corrective, évolutive et préventive.

Comment fonctionne une TMA ?

Un contrat de TMA définit un périmètre (corrective, évolutive, préventive), des niveaux de service (SLA) et un mode de facturation (forfait, régie ou au ticket). Le prestataire prend en charge les demandes via un canal dédié, traite les incidents selon leur criticité, planifie les évolutions et gère les mises à jour. Sur Dynamics 365 il pilote aussi les vagues de lancement et les tests de non-régression liés à One Version.

Combien coûte une TMA ?

Il n’existe pas de tarif de référence, parce que la charge dépend du périmètre plus que de la taille. Les facteurs déterminants sont le contenu du contrat (correctif seul ou correctif, évolutif et préventif), le volume de développements spécifiques, le nombre d’entités légales et d’interfaces, la criticité des processus et l’état de la documentation à la reprise. Un chiffrage sérieux passe par un cadrage de ce périmètre, pas par une grille.

Comment comparer deux devis de TMA ?

En les ramenant au même périmètre avant de comparer les montants. Vérifiez si les montées de version Microsoft sont incluses, si les tests de non-régression sur vos développements spécifiques font partie du forfait, et ce qui se passe lorsque le volume consommé dépasse le volume contractualisé. Ces trois points expliquent la plupart des écarts entre deux propositions qui semblent porter sur la même prestation.

Et parfois, les deux propositions n’emploient même pas le même mot : AMS, TMA ou TME désignent des périmètres largement comparables, avec un centre de gravité différent selon le contrat.