Les 9 étapes d’une reprise de projet TMA réussie

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

La reprise de projet TMA : de quoi parle-t-on ?

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.

Rapide rappel de ce qu’est la TMA et de ses objectifs

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 :

• d’assurer la continuité de service de l’application ;
• de garantir sa stabilité technique ;
• de permettre des évolutions fonctionnelles dans la durée ;
• d’optimiser les coûts liés à la maintenance.

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 ? »

Les risques techniques d’une reprise de projet TMA

Le passage en TMA peut s’accompagner d’un changement de sous-traitant. Cette situation est fréquente :

• à la fin du contrat avec l’agence ayant réalisé le projet initial ;
• s’il y a volonté d’industrialiser la maintenance ;
• en cas de recherche d’un meilleur pilotage des coûts ;
• lors d’un manque de réactivité du prestataire précédent ou d’une dépendance excessive ;
• en cas de besoin d’une expertise technique spécifique (performance, sécurité, CMS ou framework particulier).

Mais reprendre un projet existant implique souvent de faire face à un certain nombre de risques techniques.

1. Perte de connaissance fonctionnelle : documentation partielle, obsolète ou inexistante, décisions techniques non tracées entraînant une augmentation du temps de résolution et des incompréhensions fonctionnelles, car le nouveau sous-traitant doit parfois reconstituer l’historique du projet.
2. Dette technique invisible : code non ou peu documenté, développement peu qualitatif avec parfois des éléments de code « spaghetti », architecture contournée au fil des urgences, dépendances obsolètes, absence de tests automatisés. Cette dette technique rend la maintenance plus complexe et augmente les risques d’incident.
3. Environnements non reproductibles : différences importantes entre les environnements de développement, de recette et de production, scripts de déploiement manuels, dépendance à une personne clé, configurations non documentées, absence d’infrastructure as code. Ces situations peuvent provoquer des incidents lors des mises en production.
4. Accès incomplets : comptes partagés entre plusieurs intervenants, accès manquants aux outils critiques (dépôts de code, serveurs, outils de monitoring ou services tiers), dépendance aux anciens intervenants. Cela pose à la fois des problèmes de sécurité, de continuité d’activité et parfois de conformité.

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 risques business associés

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 :

• l’interruption ou l’instabilité de service ;
• une baisse de performance de l’application ;
• un impact sur le SEO (référencement naturel) ou sur l’activité e-commerce ;
• une perte de chiffre d’affaires ;
• une dégradation de l’expérience utilisateur ;
• une exposition accrue aux risques de sécurité (accès non maîtrisés à des environnements sensibles, absence de traçabilité des actions réalisées sur l’infrastructure, utilisation de comptes partagés ou de mots de passe faibles, clés API ou identifiants exposés dans le code ou les outils de déploiement, librairies ou frameworks obsolètes contenant des vulnérabilités connues qui n’ont jamais été corrigées, etc.).

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.

Étape 1 : cadrer la passation et définir les objectifs

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.

Identifier les attentes métier et techniques

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 :

• la nature de l’application : site vitrine, plateforme e-commerce, intranet, outil métier, plateforme transactionnelle, etc. ;
• sa contribution au chiffre d’affaires ou à la productivité ;
• la dépendance des utilisateurs internes ou externes ;
• les périodes critiques (pics saisonniers, campagnes marketing, événements).

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 :

• d’améliorer la réactivité sur les incidents ;
• de renforcer la qualité de la maintenance corrective ;
• d’accélérer les évolutions fonctionnelles ;
• de bénéficier d’un accompagnement technique et stratégique ;
• d’industrialiser les processus de développement et de déploiement ;
• d’améliorer la performance ou la sécurité de l’application.

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 :

• les équipes métiers privilégient généralement la rapidité et les évolutions fonctionnelles ;
• les équipes IT internes recherchent avant tout la stabilité et la maîtrise des risques ;
• le prestataire TMA doit garantir la maintenabilité du système et l’industrialisation des processus.

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 :

• les fonctionnalités critiques (impact business immédiat en cas d’incident) ;
• les fonctionnalités importantes (impact business modéré) ;
• les fonctionnalités secondaires (impact limité).

Cette classification servira ensuite de base pour prioriser les incidents et définir les niveaux de service (SLA = Service Level Agreements).

Définir le périmètre exact de la reprise de TMA

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 :

• l’application principale ;
• les interfaces d’administration ou back-office ;
• les APIs ;
• les connecteurs externes ;
• les micro-services ;
• les outils ou scripts nécessaires au fonctionnement global du système.

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 :

• l’hébergement et l’infrastructure ;
• les réseaux de diffusion de contenu (CDN) ;
• les services cloud utilisés ;
• les outils d’analyse ou de tracking ;
• les solutions de paiement ;
• les services tiers critiques.

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 :

• des technologies non maintenues ;
• des modules tiers sous contrat éditeur ;
• des infrastructures hors responsabilité (autre sous-traitant).

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 :

• le prestataire TMA ;
• le client ;
• l’hébergeur ou infogéreur ;
• les éditeurs de solutions tierces ;
• les équipes internes.

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.

Formaliser les indicateurs de succès

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 :

• le délai de prise en charge d’un incident ;
• le délai de correction selon la criticité ;
• la disponibilité du service ;
• le délai de livraison des évolutions.

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 :

• le nombre d’incidents sur une période donnée ;
• le temps moyen de résolution (MTTR) ;
• le taux de réouverture des tickets ;
• la fréquence des déploiements ;
• le taux de réussite des mises en production.

Au-delà des indicateurs techniques, certaines métriques peuvent également être orientées vers la valeur métier, à l’instar de :

• la performance perçue par les utilisateurs ;
• la stabilité lors des périodes d’activité critiques ;
• la capacité à livrer des évolutions ;
• la réduction progressive de la dette technique.

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 :

• fréquence des reportings ;
• format des tableaux de bord ;
• comités de suivi opérationnels et stratégiques ;
• interlocuteurs responsables.

Il est impératif d’installer une gouvernance claire dès le démarrage.

Formaliser la gouvernance de la reprise

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 :

• un responsable du côté client ;
• un référent TMA ;
• un responsable technique ;
• des interlocuteurs métier.

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.

Étape 2 : organiser la passation avec l’ancien prestataire

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.

Structurer les échanges de transfert

Tout d’abord, il convient d’organiser concrètement les échanges entre l’ancien et le nouveau prestataire ainsi que le client à l’aide :

• d’un planning de réversibilité qui définit les modalités et le calendrier de la passation, afin de prévoir suffisamment de temps pour transmettre les informations essentielles et répondre aux questions liées au fonctionnement du projet ;
• d’une liste des interlocuteurs clés impliqués dans la passation ;
• des livrables attendus.

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é.

Collecter les éléments indispensables

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 :

• l’architecture générale et détaillée (diagrammes, schémas d’infrastructure) ;
• les outils d’intégration continue et de déploiement (CI/CD) ;
• les pipelines de déploiement  ;
• les dépendances externes et librairies ;
• les scripts de build ;
• les tests automatisés ;
• la documentation sur bases de données ;
• les API et micro-services ;
• l’historique des incidents et corrections majeures.

À 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 :

• les parcours utilisateurs ;
• les règles métier ;
• les spécifications fonctionnelles, user stories ou cahiers des charges ;
• les workflows internes et automatisations ;
• le reporting existant et KPI métier.

Enfin, la passation doit permettre de récupérer l’ensemble des accès et droits nécessaires au fonctionnement du projet, par exemple :

• les dépôts de code (Git, SVN, autres) ;
• les environnements de développement, de recette et de production ;
• les services cloud et tiers (API, CRM, paiement, analytics) ;
• les outils de suivi (ticketing, monitoring, alerting) ;
• la gestion des mots de passe et comptes sensibles (une rotation des mots de passe et des clés d’accès est recommandée afin de sécuriser les environnements après la transition).

Formaliser la passation

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 :

• un dossier technique complet (architecture, code, scripts, documentation) ;
• une documentation fonctionnelle à jour ;
• des accès fonctionnels et techniques validés ;
• un historique des incidents majeurs et des corrections ;
• une formation ou des ateliers knowledge transfer réalisés et validés.

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 validation de l’intégralité des éléments récupérés ;
• le rapport d’écarts (documentation manquante, accès manquants, zones à risques) ;
• la check-list de conformité avec le périmètre TMA défini à l’étape 1 ;
• des audits ou rapports d’étonnement en phase d’initialisation du projet.

La gouvernance ici repose souvent sur :

• un comité de passation réunissant le client, l’ancien et le nouveau sous-traitant ;
• des rituels quotidiens ou hebdomadaires pour s’assurer de l’avancement ;
• une validation formelle avant de passer à l’étape suivante (audit technique et fonctionnel).

Étape 3 : réaliser un audit complet du système existant

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.

Audit technique

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 qualité du code et son niveau de documentation ;
• l’architecture logicielle et son respect des bonnes pratiques ;
• l’identification de la dette technique accumulée dans le temps ;
• la couverture des tests automatisés existants ;
• les versions des frameworks, librairies et composants utilisés.

Audit infrastructure et sécurité

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 :

• développement, recette, production (vérifier leur cohérence et leur reproductibilité) ;
• gestion des versions et des configurations entre ces différents environnements ;
• procédures de déploiement (manuelles ou automatisées).

La dimension sécurité fait également partie intégrante de cette étape. Elle peut inclure notamment :

• à l’identification de vulnérabilités potentielles dans l’application ;
• à la vérification des protocoles d’authentification et de gestion des droits utilisateurs ;
• à l’analyse des accès aux serveurs et aux services critiques ;
• au contrôle des procédures de sauvegarde et de restauration des données.

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é.

Audit performance et scalabilité

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 :

• l’analyse de la performance technique : temps de réponse des pages ou services critiques, charge maximale supportée, monitoring existant et alertes ;
• l’identification des goulots d’étranglement : points de saturation possibles, services ou modules fortement dépendants, risques liés aux flux concurrents ou pics d’utilisation ;
• la capacité d’évolution et la scalabilité.

Audit fonctionnel

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 :

• l’analyse des parcours utilisateurs et des fonctionnalités afin de vérifier que le fonctionnement observé correspond bien à ce qui est documenté ;
• l’identification des dépendances externes (interfaces avec ERP, CRM, outils analytics, plateformes de paiement), des points de fragilité ou de rupture potentielle et la compatibilité avec les évolutions prévues ;
• l’historique des incidents et problèmes récurrents (synthèse des tickets critiques ou répétitifs, identification des causes profondes, priorisation des correctifs selon l’impact métier et la fréquence).

Restitution d’audit et priorisation des risques

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 :

• les risques critiques nécessitant une action rapide ;
• les risques majeurs pouvant impacter la stabilité ou la sécurité  ;
• les points d’amélioration moins urgents, mais à traiter à moyen terme.

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.

Étape 4 : mise en place de l’environnement de développement et récupération de l’environnement de production

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 :

• l’environnement local pour les développeurs ;
• l’environnement de recette ou de préproduction pour les tests ;
• l’environnement de production.

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.

Étape 5 : mettre en place les processus TMA

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 :

• un outil de ticketing pour centraliser l’ensemble des demandes et suivre les incidents, les corrections et les évolutions dans un environnement unique et partagé ;
• une qualification des demandes pour évaluer leur impact (incident technique, anomalie fonctionnelle, demande d’évolution, assistance ou question métier) ;
• une priorisation des demandes en fonction de leur criticité et de leur impact business.

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 :

• les conventions de code ;
• le processus de revue de code ;
• la validation qualité avant mise en production ;
• la stricte gestion des branches et versions ;
• la formalisation des procédures d’urgence.

Étape 6 : transférer la responsabilité de l’ancien prestataire

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 :

• l’ensemble des accès techniques et fonctionnels doit avoir été récupéré ;
• les environnements de développement, de recette et de production sont opérationnels ;
• les processus de maintenance et de gestion des demandes sont en place ;
• les équipes disposent d’un niveau de connaissance suffisant pour intervenir sur le projet.

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.

Étape 7 : traiter la dette technique progressivement

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 :

• corriger progressivement les points fragiles ;
• améliorer le code au fil des évolutions ;
• prioriser les actions selon leur impact métier ;
• mettre à jour les librairies et frameworks pour maintenir les technologies utilisées à jour, réduire les failles de sécurité et les incompatibilités techniques.

Étape 8 : Co-construction de la nouvelle roadmap

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 à :

• donner de la visibilité aux équipes ;
• prioriser les évolutions ;
• éviter les demandes urgentes permanentes ;
• inscrire la TMA dans une logique d’amélioration continue.

Ici, on passe d’une logique purement corrective à une dynamique d’évolution maîtrisée.

Étape 9 : Formaliser le nouveau cadre de fonctionnement de la TMA

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