Reprendre une application média legacy et sa TMA

Situation initiale

Une application métier centralisait la préparation de plans média pour la télévision, la radio et le web. Elle restait indispensable aux équipes, mais sa maintenance était devenue risquée : technologie ancienne, environnement Windows avec Plesk coûteux, nombreuses anomalies et relation dégradée avec le prestataire historique.

Certaines incohérences touchaient les montants à facturer et l’utilisation des espaces média. Les évolutions demandées depuis longtemps restaient bloquées. Le premier enjeu n’était donc pas d’ajouter une nouvelle interface, mais de récupérer suffisamment de connaissance pour intervenir sans aggraver les données métier.

Le problème à résoudre

La reprise combinait quatre difficultés :

• assurer une passation alors que l’équipe précédente quittait le projet ;
• comprendre un code ancien et peu documenté ;
• corriger des anomalies liées à des calculs métier sensibles ;
• réduire le coût d’hébergement sans provoquer une interruption supplémentaire.

Une réécriture immédiate aurait ajouté une migration fonctionnelle et des données au projet déjà fragilisé. Nous avons privilégié une reprise progressive de l’existant.

Notre intervention

1. Audit du code et des dépendances

Nous avons identifié les composants actifs, les versions réellement utilisées, les dépendances d’hébergement et les parcours ayant un impact sur la facturation.

2. Passation et reconstruction de la connaissance

Les informations disponibles ont été transformées en documentation exploitable : accès, déploiement, structure des données, traitements métier et points de vigilance. Ce travail a permis de ne plus dépendre uniquement de la mémoire de l’ancien prestataire.

3. Correction des anomalies

Les incohérences fonctionnelles ont été reproduites avant correction. Les contrôles ont porté en priorité sur les calculs et les enchaînements susceptibles d’affecter la facturation ou l’utilisation des médias.

4. Reprise des évolutions

Une fois le socle stabilisé, les demandes restées en attente ont été requalifiées et remises dans un backlog lisible. L’objectif était de reprendre les livraisons sans mélanger incidents, dette technique et nouvelles fonctionnalités.

5. Migration de l’hébergement

Le mode d’hébergement a été revu pour réduire les coûts récurrents et sortir d’un environnement devenu trop contraignant. La migration a été préparée avec sauvegarde, validation et possibilité de retour arrière.

Résultat

L’entreprise a retrouvé un interlocuteur capable de maintenir l’application, de corriger ses règles métier et de reprendre les évolutions. L’hébergement a été simplifié et son coût réduit. La relation s’est poursuivie sous la forme d’un contrat de TMA, avec un périmètre et un backlog explicites.

Les chiffres détaillés et le nom du client restent confidentiels. Nous ne publions pas de pourcentage de réduction ni de volume de corrections sans autorisation.

Ce que ce cas démontre

Une application ancienne n’est pas nécessairement condamnée à être réécrite. Lorsque le métier en dépend encore, une reprise de projet informatique peut rétablir la maîtrise des accès, des données et des livraisons avant de décider d’une modernisation.

Vous rencontrez une situation comparable ? Le diagnostic IT permet de cartographier l’existant, les risques et les premières décisions sans engager immédiatement une réécriture.