La reprise d’un projet digital en TMA est rarement une situation simple. Sur le terrain, elle s’accompagne souvent de nombreuses zones d’ombre : documentation incomplète, dette technique, dépendances inconnues ou mal identifiées, voire environnements difficiles à reproduire.
À cela s’ajoute la compréhension du métier et des usages réels de l’application (nous utiliserons ce terme ci-dessous pour englober l’ensemble des projets digitaux : site internet, intranet, extranet, outils métiers, etc.), ce qui implique de monter en compétence à la fois sur les aspects techniques et fonctionnels.
L’enjeu dépasse largement la simple maintenance. Il faut garantir la continuité de service, le transfert de compétences entre l’ancien et le nouveau prestataire, la sécurité, la performance et l’évolutivité de l’application. Une passation mal structurée peut rapidement générer des incidents, des retards ou des coûts importants, parfois supérieurs à ceux d’un nouveau développement complet.
C’est pourquoi peu d’agences proposent la reprise de projet TMA. La plupart préfèrent repartir de zéro. Mais pas chez Adimeo. Nous aimons relever les défis et la TMA fait partie de notre cœur de métier. Nous sommes une agence TMA ! Dans cet article, découvrez les étapes clés pour réussir une passation de TMA
Avant d’entrer dans la méthodologie, il nous semble essentiel de poser un cadre clair pour bien comprendre ce que recouvre une reprise de projet en TMA, car ce n’est ni une simple maintenance ni un onboarding technique.
Une reprise de projet en TMA est effectivement une phase critique de transition opérationnelle et stratégique durant laquelle un nouveau prestataire reprend la responsabilité d’un système existant, avec ses contraintes techniques, son historique et ses enjeux métier.
La Tierce Maintenance Applicative (TMA) consiste à externaliser la maintenance et l’évolution d’une application à un prestataire spécialisé, généralement après la phase de développement initiale.
Elle intervient donc après le build, c’est-à-dire lorsque le produit (site Web, Intranet, Extranet, application métier, etc.) est en production et utilisé. Là où un projet build vise à concevoir et développer une application, la TMA s’inscrit dans une logique de pérennisation et d’amélioration continue.
Ses objectifs principaux sont notamment :
Si vous souhaitez approfondir ce sujet, vous pouvez consulter notre article dédié : « Quels sont les enjeux de la TMA dans un projet de développement Web ? »
Le passage en TMA peut s’accompagner d’un changement de sous-traitant. Cette situation est fréquente :
Mais reprendre un projet existant implique souvent de faire face à un certain nombre de risques techniques.
Ces éléments montrent bien qu’une passation de projet TMA ne consiste pas simplement à récupérer le code source. Elle nécessite une compréhension approfondie de l’ensemble de l’écosystème technique.
Les difficultés rencontrées ne sont pas uniquement techniques. Elles peuvent aussi entraîner des conséquences directes sur l’activité de l’entreprise, comme :
Lorsque l’application est au cœur du business (site e-commerce, plateforme transactionnelle, outils métiers critiques), ces impacts peuvent être particulièrement importants.
Une passation de projet en TMA doit donc être abordée comme un projet à part entière, avec une organisation et une méthodologie adaptées.
C’est précisément pour cette raison qu’une transition réussie repose sur une démarche structurée, que nous allons détailler dans les étapes suivantes.
Une reprise TMA échoue rarement pour des raisons purement techniques, mais le plus souvent par manque d’alignement initial entre les différentes parties prenantes sur les objectifs, le périmètre ou les responsabilités de chacun.
Elle ne commence donc pas par la récupération du code, mais par la définition d’une vision commune de l’exploitation applicative.
La première étape consiste à comprendre précisément le rôle de l’application. Toutes les applications ne présentent pas le même niveau de criticité. Certaines sont simplement informatives, tandis que d’autres soutiennent directement l’activité commerciale ou les opérations internes.
Il est donc essentiel d’identifier les enjeux business associés au projet, par exemple :
Cette analyse permet de hiérarchiser les priorités de maintenance et d’intervention en fonction de leur impact business réel.
En parallèle, il est nécessaire de clarifier les attentes opérationnelles du client vis-à-vis du nouveau prestataire TMA. Les motivations d’un changement de sous-traitant peuvent venir d’un besoin :
Dans certains cas, une première vision de la roadmap peut également être évoquée dès cette étape afin de mieux comprendre les ambitions d’évolution du produit.
Enfin, cette étape doit permettre l’alignement entre les équipes métier, car chaque acteur possède une vision différente. Par exemple :
Il est donc important de définir clairement les missions de chacun et de détailler leurs responsabilités, notamment lorsque plusieurs prestataires interviennent sur le projet (hébergement, infrastructure, TMA, éditeurs tiers, etc.).
À l’issue de ce travail, une synthèse des objectifs et des priorités de la TMA est formalisée et validée par l’ensemble des parties prenantes.
Dans cette logique, il est également utile de définir les niveaux de criticité des fonctionnalités de l’application, avec par exemple :
Cette classification servira ensuite de base pour prioriser les incidents et définir les niveaux de service (SLA = Service Level Agreements).
Dans la même logique, il faut aussi définir précisément le périmètre de la passation. Découvrir tardivement que certains composants ou dépendances n’étaient pas inclus dans le périmètre initial est l’un des risques les plus fréquents en TMA.
Il faut donc identifier l’ensemble des éléments techniques (applications et composants) concernés par la maintenance, tels que :
Certaines dépendances sont parfois moins visibles, mais tout aussi critiques, comme les tâches automatisées (cron jobs), les scripts d’intégration ou certains services tiers.
Dans cette logique, il est également pertinent de mettre en place des outils permettant de monitorer la qualité du code et la santé technique du projet, par exemple via des solutions d’analyse continue comme SonarQube.
La reprise doit aussi s’accompagner d’une cartographie complète de l’écosystème technique, incluant notamment :
Cette cartographie permet ainsi d’éviter les zones hors périmètre découvertes trop tardivement.
Il est également nécessaire d’identifier clairement les exclusions de périmètre, qui sont souvent négligées lors des premières discussions. Cela peut concerner :
L’objectif ici est d’éviter les attentes irréalistes dès le démarrage.
Enfin, cette étape permet de clarifier les responsabilités entre les différents acteurs :
Qui gère l’infrastructure ? Qui valide les mises en production ? Qui pilote les sujets de sécurité ? Répondre à ces questions permet de limiter les zones de friction et les conflits futurs.
La performance d’une TMA ne peut pas être évaluée uniquement sur des impressions ou des ressentis. Elle doit s’appuyer sur des indicateurs objectifs définis dès la phase de cadrage.
Cette étape consiste à définir les SLA, c’est-à-dire les engagements de service. Ils peuvent notamment concerner :
Ces engagements doivent être réalistes, mesurables et alignés avec les enjeux métier. Pour cela, il est important de qualifier et prioriser les demandes en amont, afin d’éviter une surcharge permanente de demandes urgentes.
En complément, il faut déterminer des KPI de pilotage opérationnel afin de suivre la qualité de la maintenance dans le temps, comme :
Au-delà des indicateurs techniques, certaines métriques peuvent également être orientées vers la valeur métier, à l’instar de :
Cette approche permet de repositionner la TMA comme un levier de performance globale, et non comme une simple action corrective.
Enfin, les mécanismes de reporting doivent être définis dès le cadrage :
Il est impératif d’installer une gouvernance claire dès le démarrage.
La dernière étape de ce cadrage consiste à structurer la gouvernance. Or, cela passe d’abord par l’identification des rôles clés, dont :
Il est également nécessaire de définir les circuits de décision : validation des priorités, gestion des urgences, arbitrages budgétaires ou techniques.
Enfin, la transition doit être planifiée avec un calendrier précis : étapes, jalons intermédiaires et critères permettant de valider le passage aux étapes suivantes.
Une TMA performante ne commence donc pas par la première correction de bug ou la première évolution technique, mais par un cadrage stratégique solide qui garantit la réussite de tout le projet.
Cette étape est souvent la plus critique, car elle conditionne la qualité de l’audit, la sécurisation des environnements et la montée en compétence rapide du nouveau sous-traitant. Une passation mal préparée peut créer des pertes d’informations irréversibles, des incidents ou des délais importants.
La passation doit donc être structurée et documentée avec une méthodologie claire.
Tout d’abord, il convient d’organiser concrètement les échanges entre l’ancien et le nouveau prestataire ainsi que le client à l’aide :
Dans la pratique, cette transmission de connaissances s’appuie souvent sur des ateliers de knowledge transfer organisés autour des principaux aspects du projet (architecture technique, code et framework, infrastructure et hébergement, dépendances externes, flux métiers et process critiques).
Selon la complexité du projet, certains ateliers peuvent être menés en parallèle durant la phase d’initialisation, par exemple sur les volets fonctionnels, techniques ou organisationnels avec les prestataires.
Disposer d’une méthodologie d’initialisation clairement documentée permet de structurer ces échanges et de s’assurer qu’aucun sujet essentiel n’est oublié.
La passation repose également sur la récupération d’un ensemble d’informations et de ressources indispensables à la maintenance de l’application.
La première catégorie concerne la documentation technique. Elle peut notamment inclure :
À ces éléments techniques s’ajoute la documentation fonctionnelle (charte graphique, charte éditoriale, etc.), qui permet de comprendre le fonctionnement métier de l’application, comme :
Enfin, la passation doit permettre de récupérer l’ensemble des accès et droits nécessaires au fonctionnement du projet, par exemple :
Pour éviter toute ambiguïté, la passation doit être formalisée et validée par l’ensemble des acteurs impliqués.
Du côté de l’ancien prestataire, plusieurs livrables sont généralement attendus :
Le nouveau prestataire doit ensuite vérifier que tous les éléments nécessaires ont bien été récupérés. Cela se traduit généralement par :
La gouvernance ici repose souvent sur :
Une fois la passation organisée et les principaux éléments récupérés, c’est le moment d’analyser en profondeur le système existant. Cet audit permet au nouveau prestataire de comprendre l’état réel de l’application, d’identifier les risques techniques et de prioriser les actions à mener après la reprise.
Même lorsque la documentation est disponible, elle ne reflète pas toujours la réalité du projet. L’audit permet donc de confronter les informations transmises lors de la passation à l’état réel du code, de l’infrastructure et du fonctionnement applicatif.
L’objectif est double : sécuriser la passation technique et disposer d’une base fiable pour organiser les futures interventions de maintenance.
L’audit technique consiste à analyser la qualité et la structure du code afin d’évaluer sa maintenabilité et sa robustesse.
Plusieurs aspects sont généralement étudiés, comme :
La passation d’un projet TMA ne concerne pas uniquement le code. L’environnement technique dans lequel l’application fonctionne joue également un rôle essentiel dans sa stabilité et sa sécurité.
L’audit infrastructure commence généralement par une revue de ces différents environnements :
La dimension sécurité fait également partie intégrante de cette étape. Elle peut inclure notamment :
Dans certains contextes, l’audit peut également vérifier la conformité à certaines obligations réglementaires, notamment en matière de protection des données personnelles (RGPD), de normes d’accessibilité (RGAA), d’éco-conception (RGESN) ou de contraintes spécifiques à certains secteurs d’activité.
La performance de l’application est un autre point clé à analyser. Cet audit permet d’évaluer la capacité du système à supporter la charge actuelle et les éventuelles évolutions futures, avec notamment :
Au-delà des aspects techniques, l’audit doit également permettre de comprendre comment l’application est réellement utilisée. L’audit fonctionnel inclus notamment :
Une fois les analyses réalisées, les résultats de l’audit sont généralement synthétisés dans un document de restitution partagé avec le client.
Les différents points identifiés sont alors classés selon leur niveau de criticité, par exemple :
Cette synthèse permet de définir un premier plan d’action, qui servira de base pour les étapes suivantes et pour les premières interventions de maintenance.
Au-delà de l’analyse technique, la restitution joue aussi un rôle important dans la relation avec le client. Elle permet de partager une vision claire de l’état du projet et de prioriser collectivement les actions à mener.
Après l’audit, le nouveau prestataire doit vérifier qu’il est bien en mesure de reprendre les développements et de déployer les modifications du projet en production.
Le but ici est d’assurer la stabilité, la sécurité et la disponibilité des systèmes avant toute intervention corrective ou évolutive.
Cette phase passe par la récupération des accès et de gouvernance, le changement obligatoire des mots de passe et clés d’accès critiques, et l’attribution de rôles et responsabilités clairs.
Une fois les accès sécurisés, le nouveau sous-traitant doit vérifier que l’application peut être exécutée correctement dans les différents environnements techniques.
L’objectif est de reconstruire ou de valider les environnements nécessaires au cycle de développement :
Cette étape permet de vérifier que le projet peut être installé et exécuté sans erreur, que les dépendances techniques sont correctement configurées et que les procédures de déploiement fonctionnent comme prévu.
Dans certains cas, la reconstruction des environnements permet également de détecter des problèmes qui n’avaient pas été identifiés lors de la passation ou de l’audit.
Au final, cette étape garantit de disposer d’un environnement de travail stable et reproductible, assurant au nouveau prestataire qu’il peut intervenir en toute sécurité sur le projet.
Une fois ces environnements validés, l’équipe peut alors commencer à assurer la maintenance corrective et préparer les premières évolutions, tout en garantissant que les modifications pourront être déployées en production dans des conditions maîtrisées.
L’objectif de cette étape vise à transformer la passation technique et fonctionnelle réalisée lors des étapes précédentes en un fonctionnement opérationnel durable, industrialisé et pilotable.
Il s’agit de définir et valider conjointement l’organisation concrète de la maintenance corrective.
Tout d’abord, il faut structurer la manière dont les demandes sont remontées et traitées, avec :
Pour garantir un niveau de service cohérent, la TMA s’appuie généralement sur des SLA qui définissent les engagements du prestataire, comme les délais de prise en charge, de correction et les niveaux d’urgence.
La TMA ne repose pas uniquement sur des interventions techniques. Elle nécessite également une organisation de pilotage permettant de suivre l’activité et d’ajuster les priorités dans le temps (gouvernance projet, comités de pilotage, reporting, rituels opérationnels, etc.).
Enfin, la mise en place de processus TMA implique de standardiser certaines pratiques techniques afin d’améliorer la qualité et la fiabilité des interventions, comme :
Le nouveau prestataire est désormais responsable du projet TMA. Il va pouvoir commencer à implémenter les changements techniques prioritaires recommandés lors de l’audit et prendre en charge la maintenance corrective.
Pour que ce transfert se déroule dans de bonnes conditions, il est important qu’il soit formalisé et validé par l’ensemble des parties prenantes. Plusieurs éléments doivent être vérifiés :
Cette validation permet de s’assurer que le nouveau sous-traitant est réellement en mesure d’assumer la maintenance de l’application sans dépendre de l’ancien.
Dans certains cas, une courte période de chevauchement entre les deux prestataires peut être organisée afin de sécuriser la transition et faciliter les derniers transferts d’information.
Cette étape vise à assurer la maintenabilité et la durabilité du système en réduisant progressivement les fragilités accumulées au fil du temps, sans compromettre la stabilité opérationnelle.
Après la reprise, l’audit et la mise en place des processus TMA, le projet entre dans une phase essentielle, à savoir l’assainissement de l’existant tout en maintenant la production. C’est le moment de :
Une reprise de projet en TMA ne consiste pas seulement à maintenir l’existant, elle marque aussi le début d’une nouvelle phase pour le produit.
Une fois le projet stabilisé et mieux compris, il faut définir la trajectoire future du projet en concertation avec les équipes métier et techniques. La co-construction d’une roadmap permet d’inscrire la TMA dans une logique d’amélioration continue et d’évolution maîtrisée.
Cette roadmap vise à :
Ici, on passe d’une logique purement corrective à une dynamique d’évolution maîtrisée.
Après avoir stabilisé le projet et défini la roadmap d’évolution, il est nécessaire de transformer la passation en un fonctionnement pérenne. Cette étape permet de passer de la logique de transition à un mode de TMA mature et structuré garantissant que le projet ne reste pas dans une situation de transition trop longtemps.
Il faut alors stabiliser les pratiques après les premières semaines et s’assurer que la reprise est réellement terminée : connaissance projet, vérification des accès, finalisation de la documentation technique et fonctionnelle, et validation de l’ensemble des processus de maintenance et de suivi.
Cette étape marque la clôture effective de la passation et le passage à une TMA stable, capable de soutenir les évolutions futures de manière sécurisée et structurée.
En bref, une reprise de projet TMA réussie dépasse la simple transition technique. C’est un véritable projet stratégique qui exige méthode, collaboration et anticipation pour sécuriser l’existant tout en préparant l’avenir. Bien cadrée, elle permet non seulement de stabiliser l’application, mais aussi de transformer la maintenance en levier d’évolution continue. La phase de cadrage peut paraître longue, mais c’est un temps indispensable. Si chaque passation est unique et complexe, elle peut aussi offrir l’opportunité de renforcer l’architecture, d’optimiser les processus et d’aligner la TMA sur les ambitions métier, plutôt que de se limiter à un simple passage de relais entre prestataires. En cas de besoin, n’hésitez pas à contacter nos experts, particulièrement bien rodés lorsqu’il s’agit de gérer une reprise de TMA.
Crédit photo : Jacob Wackerhausen