La mise en production d’une refonte ne marque pas la fin du projet. Les premiers usages réels révèlent des cas absents des tests, les systèmes mobiles se mettent à jour progressivement et l’ancienne version peut encore traiter une partie des données. Une TMA préparée avant la bascule transforme cette période sensible en amélioration continue.
Prévoir une période de stabilisation
Pendant les premières semaines, l’équipe qui connaît la refonte doit rester disponible. Elle surveille les parcours critiques, les erreurs, les performances et les retours du support. Les changements fonctionnels importants sont limités afin de distinguer les défauts de migration des nouvelles évolutions.
Le plan de stabilisation précise :
- les indicateurs surveillés ;
- les personnes joignables et leurs responsabilités ;
- les seuils qui déclenchent une intervention ;
- la procédure de correction et de retour arrière ;
- la durée de coexistence des anciennes versions ;
- les critères de fin de stabilisation.
Distinguer garantie, maintenance et évolution
Ces activités répondent à des besoins différents :
- la garantie corrige les écarts par rapport au périmètre livré ;
- la maintenance corrective traite les incidents apparus en exploitation ;
- la maintenance préventive réduit un risque avant l’incident ;
- la maintenance adaptative suit les systèmes, stores et services externes ;
- la maintenance évolutive ajoute ou modifie des fonctions.
Le contrat doit préciser leur traitement et leur mode de facturation. Sans distinction, chaque demande devient une discussion sur ce qui était implicitement prévu.
Organiser l’entrée des demandes
Les utilisateurs, le support et la direction doivent disposer d’un canal clair. Chaque ticket indique l’environnement, l’utilisateur touché, les étapes de reproduction, le résultat obtenu et l’impact métier.
La priorité ne dépend pas uniquement de la gêne ressentie. Une erreur rare exposant des données peut passer avant un défaut visuel fréquent. La classification doit combiner impact, urgence, nombre d’utilisateurs et solution de contournement.
Définir des SLA réalistes
Un SLA peut fixer un délai de prise en compte, de diagnostic, de contournement ou de résolution selon la criticité. Ces délais n’ont de sens que si les horaires de couverture, les dépendances externes et les responsabilités sont explicites.
Une indisponibilité générale n’est pas traitée comme une anomalie mineure. Nos exemples de SLA et TMA donnent des repères selon les contextes.
Maintenir la chaîne technique
La TMA couvre aussi ce que les utilisateurs ne voient pas immédiatement :
- mises à jour des dépendances et systèmes ;
- certificats, noms de domaine et comptes stores ;
- sauvegardes et tests de restauration ;
- capacité des bases et serveurs ;
- supervision et qualité des alertes ;
- tests et pipelines de livraison ;
- documentation et gestion des accès.
Ces travaux préventifs doivent apparaître dans le backlog. Les repousser jusqu’à l’incident augmente le coût et réduit le choix des solutions.
Conserver une capacité d’évolution
Une TMA efficace ne transforme pas l’application en produit figé. Réservez une capacité aux petites évolutions et regroupez les changements plus importants dans une roadmap. Le même processus de revue, test, préproduction et déploiement s’applique aux corrections comme aux fonctions nouvelles.
La fréquence de livraison, le délai de correction, le nombre d’incidents récurrents et la part de travail imprévu permettent d’observer la santé du dispositif. Ils doivent conduire à des améliorations, pas à une surveillance individuelle.
Préparer la réversibilité
Même avec une relation durable, l’entreprise doit rester propriétaire du code, des comptes, des données et de la documentation. Un autre intervenant doit pouvoir comprendre l’architecture, construire le produit et accéder à l’historique des décisions.
Cette réversibilité protège les deux parties et rend la collaboration plus saine. Notre guide pour choisir un prestataire TMA fiable détaille les critères contractuels et opérationnels.
De la reprise à la TMA : le cas MyTwiga
Après avoir repris et terminé les refontes mobiles et API de MyTwiga, Farrago a poursuivi l’accompagnement par la maintenance, les évolutions et le DevOps. La même équipe pouvait relier un incident de production aux choix produit et à l’infrastructure. Découvrez la réalisation MyTwiga.
Si la refonte n’est pas encore sous contrôle, commencez par le guide pour faire reprendre une application existante ou par notre article pour décider s’il faut terminer ou repenser une refonte bloquée.