La « TMA » désigne l’ensemble des activités qui garantissent la continuité, la qualité et l’évolutivité des applications au sein du système d’information. A contrario du seul « MCO » centré sur la disponibilité, la TMA couvre le correctif, l’adaptatif, le préventif et le perfectif.
Autrement dit : résoudre les incidents, traiter les demandes de service, absorber les évolutions, maîtriser la dette technique.
Objectifs concrets : réduire le MTTR, stabiliser le run, fiabiliser les releases, contenir les coûts, apporter de la valeur métier au fil de l’eau.
Le périmètre s’étend des applications legacy aux SaaS, du mobile au data engineering, jusqu’aux intégrations middleware. Dès lors, la TMA dialogue avec la production, la sécurité, les équipes produits, les éditeurs.
Quels sont les modèles d’engagement de la TMA ?
Plusieurs formats contractuels structurent la relation et la prévisibilité économique.
- Forfait : périmètre et niveau de service cadrés, engagements de résultats, pénalités/bonus.
- Régie (T&M) : capacité dédiée, ajustements rapides, pilotage par backlog.
- Capacity-based : unités d’œuvre, vélocité cible, allocation dynamique.
- Outcome-based : objectifs métier (SLO, NPS interne, backlog ≤ X), bonus liés aux gains.
Localisation et couverture : onshore pour proximité, nearshore pour compromis coûts/délais, offshore pour volumes, « follow-the-sun » pour 24/7.
Comparatif synthétique :
| Modèle | Pilotage | Prévisibilité | Réactivité | Risque prestataire | Risque client | Contextes adaptés |
| Forfait | Par SLA & périmètre | Élevée | Moyenne | Fort | Faible | Run stabilisé, périmètre clair |
| Régie | Par capacité | Moyenne | Élevée | Faible | Fort | Backlog volatile, produit en flux |
| Capacity-based | Par UO/story points | Élevée | Élevée | Partagé | Partagé | Organisation agile mûre |
| Outcome-based | Par SLO & résultats | Moyenne | Moyenne | Partagé | Partagé | Transformation orientée valeur |
Cliquez ici pour en savoir plus sur les services managés.
Gouvernance et organisation
Une TMA réussie repose sur une gouvernance nette : rôles, rituels, artefacts.
- Parties prenantes : MOA, MOE, DSI, SecOps, FinOps, éditeurs, équipe TMA.
- Comités : opérationnel (hebdo), pilotage (mensuel), stratégique (trimestriel).
- Artefacts : backlog priorisé, KEDB, carnet d’endettement, scorecard KPI.
RACI type (exemple) :
| Activité | Client | Prestataire TMA | Éditeur |
| Priorisation backlog | A | R | C |
| Résolution incident P1 | C | R | C |
| Change mineur | C | R | I |
| Release mensuelle | A | R | I |
| Patch sécurité éditeur | I | C | R |
R = Responsable, A = Autorité, C = Consulté, I = Informé.
Quels sont les problèmes opérationnels de la TMA ?
La TMA vit au rythme de flux simples. Un signal, une décision, un résultat. Chaque processus répond à une promesse : stabilité, lisibilité, progrès. La logique ne change pas selon la technologie ; seule l’exécution diffère. En revanche, la clarté des rôles et des enchaînements transforme l’expérience au quotidien.
Incident : rétablir la disponibilité puis apprendre de l’événement
Un incident raconte une histoire en trois actes. D’abord le signal. Ensuite le diagnostic. Enfin la remise en service. Puis, le cas échéant, un post-mortem sans blâme.
Un exemple court. Une API critique renvoie des erreurs 5xx à l’heure de pointe. L’alerte se déclenche. L’Incident Manager ouvre le canal d’intervention. Le Tech Lead isole une régression dans un module d’authentification. Un rollback neutralise la version fautive. Les métriques repassent au vert. L’équipe rédige ensuite une note brève : chronologie, causes, actions correctives. Cette trace rejoint la base de connaissances (KEDB).
Ce processus protège la continuité de service. Il réduit le MTTA (délai d’accusé de réception) et le MTTR (temps moyen de rétablissement). Il évite la cacophonie grâce à un « pilote » identifié, un canal unique, des runbooks qui détaillent commandes et contrôles. De surcroît, chaque incident nourrit les chantiers de fond : alertes plus pertinentes, tests plus ciblés, modules moins fragiles.
Service Request : industrialiser les demandes récurrentes
Une demande de service n’a rien d’un incident. Elle suit un chemin calme, standardisé, avec des délais connus. Un catalogue décrit les cas usuels : création d’accès, extraction ponctuelle, déploiement planifié non urgent, ajustement de configuration.
Un bon catalogue fonctionne comme une carte. Chaque « type de demande » dispose d’un formulaire clair, d’un circuit d’approbation, d’un SLA distinct. Le suivi se lit en jalons simples : reçu, en cours, validé, terminé. En fin d’exécution, une preuve clôt le ticket (capture, journal, référence de change). Par ailleurs, des statistiques utiles émergent vite : durée moyenne par type, file d’attente, demandes en retard. In fine, moins d’improvisation, davantage de fluidité.
Problem : traiter la cause, pas seulement le symptôme
Le processus Problem traque la racine des ennuis. Répétitions, signaux faibles, pannes majeures : autant d’indices. La méthode reste sobre. Collecte des faits. 5 Pourquoi pour remonter la chaîne causale. Diagramme d’Ishikawa si plusieurs facteurs convergent. Pareto pour hiérarchiser.
Le résultat prend la forme d’un plan d’actions : correctif applicatif, durcissement d’infrastructure, test supplémentaire sur un parcours critique, alerte plus précise, documentation enrichie. Chaque action entre dans le backlog avec une échéance. Le suivi mesure l’effet : incidents évités, MTTR en baisse, charge réactive qui recule. La KEDB se remplit d’entrées exploitables : « symptôme → cause → solution → prévention », avec liens vers commits et tickets.
Change & Release : livrer souvent, sans casse
Un change modifie un système ; une release le propage. L’objectif : cadence soutenue, risque contenu, retour arrière immédiat en cas de besoin.
Trois catégories suffisent. Change standard : pré-approuvé, faible risque, procédure connue. Change normal : passage en CAB (comité d’arbitrage allégé) avec preuves, plan de rollback, créneau validé. Change urgent : voie rapide contrôlée, pour sécuriser le run.
La mécanique s’appuie sur des pipelines CI/CD déterministes, des artefacts versionnés, des contrôles qualité (tests, sécurité, politiques). Les feature flags autorisent une activation ciblée et un backout en un clic. Côté stratégie de déploiement, blue/green alterne deux environnements, canary expose une fraction d’utilisateurs à la nouvelle version, progressive delivery étend l’audience par paliers. Dès lors, la fréquence de livraison grimpe, alors que le risque reste contenu.
Mesurer ce qui compte : SLI, SLO, SLA, KPI et tableaux de bord
La mesure structure le dialogue entre parties prenantes. Un vocabulaire clair. Des objectifs réalistes. Des indicateurs lisibles. Sans cette base, les échanges dérivent. Avec cette base, les arbitrages gagnent en sérénité.
SLI, SLO, SLA : la grammaire des objectifs
Trois sigles et un fil rouge.
- SLI : la mesure brute. Exemples : disponibilité d’un service, latence p95, taux d’erreurs, réussite des jobs planifiés.
- SLO : la cible chiffrée sur le SLI, par période.
- SLA : l’engagement contractuel, avec bonus-malus le cas échéant.
- Budget d’erreur : 1 − SLO sur la même période.
Un repère utile. Avec un SLO à 99,9 % par mois, le budget d’erreur s’élève à 43 min 49 s d’indisponibilité équivalente. Au-delà, l’équipe consomme du « crédit qualité » et ajuste sa cadence de livraison, a contrario d’une poursuite au même rythme.