La confusion entre TMA, infogérance et support utilisateur est fréquente et compréhensible. Ces trois termes circulent souvent dans les mêmes conversations, parfois comme des synonymes, alors qu’ils désignent des périmètres d’intervention bien distincts.

Elle devient problématique au moment de rédiger un contrat, qualifier un incident ou décider quelle équipe doit prendre en charge un dysfonctionnement. Mal délimités, ces périmètres génèrent des zones grises, des escalades sans responsable identifié, et des coûts que personne n’avait anticipés.

Derrière ces trois notions et quelques services connexes comme l’AMOA ou la garantie post-projet se cachent des logiques d’intervention, des objectifs et des déclencheurs distincts.

La Tierce Maintenance Applicative (TMA) : le cœur de votre application

Définition :

La Tierce Maintenance Applicative (TMA) est un contrat par lequel une entreprise confie à un prestataire externe la responsabilité de maintenir, corriger et faire évoluer ses applications logicielles. Elle s’inscrit dans une logique de run applicatif : le logiciel est en production, et doit continuer à fonctionner, se corriger et évoluer.

La TMA se distingue facilement d’un projet de développement (qui a un début et une fin) : c’est un service continu, piloté par des indicateurs de qualité de service (SLA, taux de disponibilité, délais de traitement des tickets).

Périmètre d’intervention

La TMA intervient sur tout ce qui constitue l’application elle-même :

• Le code source et son architecture,
• Les bases de données applicatives (modèles de données, requêtes, performances) et l’exclusion des données elles-mêmes,
• Les fonctionnalités métier et leur comportement,
• Les interfaces (API, connecteurs, interfaces utilisateur),
• La documentation technique et fonctionnelle.

Elle ne touche en revanche pas à l’infrastructure sur laquelle tourne l’application (serveurs, réseau, OS). Il s’agit du périmètre de l’infogérance.

Les 4 types de maintenance couverts

• Maintenance évolutive : ajout ou modification de fonctionnalités pour répondre à un nouveau besoin métier.
• Maintenance corrective : correction de bugs et anomalies signalées en production.
• Maintenance adaptative : adaptation de l’application à un changement de son environnement technique ou réglementaire, sans modifier le besoin métier initial.
• Maintenance préventive : actions menées pour améliorer la maintenabilité ou réduire la dette technique, afin d’anticiper et d’éviter des incidents futurs.

Ces quatre types de maintenance sont définis par la norme ISO/IEC 14764, référence internationale du cycle de vie logiciel

Exemple :

Un éditeur de logiciel RH nous confie la TMA de sa plateforme SaaS après le départ de son équipe interne.

Objectif : stabiliser le produit et continuer à livrer des évolutions pour ses clients sans recruter en urgence.

Chaque mois : 

• 3 à 5 correctifs remontés par les clients finaux
• 2 évolutions priorisées en comité produit,
• 1 chantier de réduction de dette technique planifié.

Le tout piloté via un backlog partagé, avec des SLA distincts selon la criticité.

L’infogérance : la gestion de votre infrastructure IT

Définition :

L’infogérance (ou ITO pour IT Outsourcing) concerne l’externalisation de la gestion et de l’exploitation de l’ensemble, ou d’une partie du SI d’une entreprise. Là où la TMA s’occupe de ce qui se passe dans l’application, l’infogérance s’occupe de ce sur quoi elle tourne.

Selon le référentiel ITIL, il s’agit de l’ensemble des pratiques visant à garantir la disponibilité, la sécurité et la performance des composants d’infrastructure : serveurs physiques ou virtuels, réseaux, stockage, système d’exploitation.

Périmètre d’intervention

• Serveurs (physiques, virtuels, cloud)
• Infrastructure réseau (LAN, WAN, VPN, pare-feu)
• Systèmes d’exploitation et middlewares système
• Base de données en tant qu’infrastructure (moteur, sauvegardes, haute disponibilité)
• Sécurité matérielle et logicielle (antivirus, patch management, supervision)
• Plans de reprise d’activité (PRA) et plans de continuité (PCA)

Les différents niveaux d’infogérance

• Infogérance partielle : le prestataire prend en charge une partie du SI (ex : uniquement les serveurs de production)
• Infogérance totale : externalisation complète de la gestion du SI, souvent accompagnée d’un transfert d’actifs ou de personnel

Attention, le piège de la frontière TMA / Infogérance

TMA et infogérance coexistent dans le même SI, les points de contact sont donc nombreux, et les zones grises inévitables si le contrat ne les anticipe pas. La base de données est souvent citée en exemple, mais elle est loin d’être la seule source de flou.

Les principaux points de friction à délimiter contractuellement :

• Les bases de données : la dimension infrastructure (moteur, instances, sauvegardes, performance système) relève de l’infogérance. La dimension applicative (modèle de données, requêtes métier, procédures stockées) relève de la TMA.
• La gestion des incidents : quand l’application tombe, qui prend le lead pour analyser ? Qui coordonne entre les équipes ? Sans règles claires, le temps de réponse s’allonge et les responsabilités se renvoient.
• Les incidents de performance : une application lente peut avoir une cause infra (ressources, réseau) ou applicative (requête mal optimisée, régression). Le diagnostic initial doit être attribué à l’une ou l’autre partie.
• Les incidents post-déploiement : un dysfonctionnement survenu après une mise en production engage-t-il la TMA seule, ou l’infogérance si l’environnement cible est en cause ?
• La configuration technique de l’application : la gestion des secrets, variables d’environnement et paramètres de configuration est souvent un angle mort contractuel.
• Les APIs tierces : quand un service externe ne répond plus, qui assure le suivi, la communication et le contournement ?
• La sécurité opérationnelle : la gestion des failles et des correctifs de sécurité peut relever des deux parties selon qu’elles touchent l’infrastructure ou le code applicatif.

Un contrat bien rédigé doit explicitement délimiter ces responsabilités, idéalement via une matrice RACI, pour éviter que chaque incident ne devienne un sujet de gouvernance avant d’être un sujet technique.

Le support utilisateur : l’assistance aux usagers

Définition :

Le support utilisateur (ou helpdesk) est le service qui assiste les utilisateurs finaux dans leur utilisation quotidienne des outils informatiques. Contrairement à la TMA (qui corrige l’application) ou à l’infogérance (qui maintient l’infrastructure), le support s’adresse aux personnes, pas aux systèmes.

Son objectif est simple : permettre à chaque collaborateur d’être opérationnel et productif, quel que soit l’outil qu’il utilise.

Périmètre d’intervention

• Réponse aux questions d’utilisation (comment faire X dans l’outil Y ? »),
• Résolution des problèmes bloquants au niveau utilisateur,
• Gestion des droits d’accès et des habilitations,
• Formation et accompagnement au changement,
• Prise en main à distance (TeamViewer, RDP, etc.),
• Gestion des postes de travail et de la téléphonie,
• Escalade vers les interlocuteurs techniques compétents (TMA ou infogérance) en cas de problème dépassant le périmètre utilisateur.

Les niveaux de support

• Niveau 1 : front line, réponse aux questions simples, filtrage et qualification des tickets. Souvent assuré par une hotline ou un chatbot.
• Niveau 2 : traitement des incidents plus complexes, nécessitant une expertise sur les outils ou les processus métiers.
• Niveau 3 : escalade vers les équipes techniques ou applicatives. A ce stade, on sort du support pour entrer dans la TMA (si c’est un bug) ou l’infogérance (si c’est un problème infra).

Le support résout des problèmes d’usage. Si la résolution nécessite de modifier le code ou la configuration d’un serveur, on sort du périmètre support.

Exemple typique chez un éditeur de logiciel : un utilisateur final signale que le module de facturation « ne fonctionne pas ». Le niveau 1 du support ne reproduit pas le bug, le niveau 2 non plus. Le niveau 3 lui, identifie un calcul erroné dans le code. C’est un ticket TMA, pas un ticket support. Il doit être requalifié et facturé en conséquence. C’est souvent à ce moment que les incompréhensions de facturation apparaissent entre l’éditeur et son client, faute d’une frontière contractuelle explicite.

Services connexes : AMOA et garantie post-projet

Garantie post-projet

La garantie post-projet est souvent la source de confusion numéro un avec la TMA. Pourtant ces deux notions répondent à des logiques différentes.

La réponse dépend du contenu du contrat et d’une lecture attentive du périmètre de chaque phase.

L’AMOA : en amont, pas en run

L’assistance à maîtrise d’ouvrage (AMOA) intervient dans une logique radicalement différente : c’est un service de conseil et d’accompagnement en phase de build, pas de run.

L’AMOA aide les équipes métiers à formaliser leurs besoins, à rédiger les cahiers des charges et les spécifications fonctionnelles, à piloter les projets et à conduire le changement. Elle n’a donc pas vocation à corriger les bugs, ni à gérer une infrastructure, mais elle peut tout à fait intervenir en conseil sur leur qualification, leur priorisation ou leur impact métier.

L’AMOA en bref

• Quand ? En phase de conception/lancement du projet
• Qui ? Le consultant AMOA travaille avec les métiers et traduit leurs besoins en specs.
• Résultat ? Un cahier des charges exploitable par les équipes de développement.

Ce n’est ni de la TMA, ni du support, ni de l’infogérance… c’est du conseil projet.

Tableau récapitulatif

Quelle solution pour votre situation ? La checklist

Des frontières claires pour une IT sereine

TMA, infogérance et support utilisateur ne sont pas des synonymes, ni des services interchangeables. Chacun répond à une logique propre :

• La TMA s’occupe de ce qui est dans l’application (code, fonctionnalités, performance applicative).
• L’infogérance s’occupe de ce sur quoi tourne l’application (infrastructure, serveurs, réseau, sécurité).
• Le support utilisateur s’occupe de ceux qui utilisent l’application (formation, assistance, gestion des accès).

La confusion entre ces services a des conséquences : zones grises contractuelles, escalades sans responsable clairement identifié, coûts cachés liés à des périmètres mal définis. À l’inverse, une bonne cartographie de vos besoins vous permettra de choisir les bons contrats, de négocier des SLA pertinents et d’optimiser vos budgets IT.

Chez SoftFluent, nous accompagnons les DSI et les responsables applicatifs dans la structuration de leurs contrats de TMA depuis plus de 20 ans. Si vous souhaitez clarifier votre situation ou obtenir une proposition adaptée à votre contexte, n’hésitez pas à nous contacter.