Maintenir votre application WinDev pendant la migration

Une migration dure des mois ; votre activité, elle, ne s'arrête jamais. Pendant toute la transition, l'application WinDev existante reste l'outil de travail quotidien et doit être maintenue : bugs corrigés, obligations réglementaires suivies, sécurité assurée. C'est le rôle de la TMA transitoire, le volet le plus discret de la méthode et l'un des plus décisifs.

Pourquoi une TMA transitoire est indispensable

Le scénario à éviter est connu : toute l'énergie part sur le nouveau système, l'ancien se dégrade, et les utilisateurs perdent confiance dans le projet au moment où l'on a le plus besoin d'eux. Il s'aggrave quand le développeur historique est parti : plus personne ne peut corriger l'outil qui fait tourner l'entreprise. La TMA transitoire répond aux deux situations : elle garantit la continuité de l'existant et reconstitue, au passage, la connaissance du code qui servira à la migration.

Une situation type

Le cas le plus fréquent : le développeur qui maîtrisait seul l'application quitte l'entreprise en plein milieu du projet de migration. Sans TMA transitoire organisée, chaque anomalie qui survient sur l'existant devient une urgence non couverte, et l'équipe de migration se retrouve sollicitée pour des corrections qui n'étaient pas prévues à son planning. Avec une TMA en place, cette même anomalie suit un circuit connu, avec un délai de prise en charge défini, sans venir perturber l'avancement du chantier de migration.

Périmètre : correctif, évolutif, préventif

• Correctif : anomalies bloquantes et non bloquantes, avec des délais de prise en charge adaptés à la criticité.
• Évolutif contraint : les évolutions imposées (réglementaire, partenaires, formats d'échange), maintenues sur l'existant tant que le module concerné n'a pas migré.
• Préventif : sauvegardes vérifiées, surveillance de la base HFSQL, mises à jour de sécurité de l'environnement, documentation des traitements critiques au fil des interventions.

Gérer le gel fonctionnel

Le gel fonctionnel est une discipline, pas un dogme : on n'ajoute plus de fonctions nouvelles à un système en cours de remplacement, sauf obligation. Chaque demande d'évolution passe par un arbitrage simple : est-elle réglementaire ou bloquante ? Elle se fait sur l'existant. Peut-elle attendre le module migré ? Elle rejoint le backlog de la cible, où elle coûtera moins cher et vivra plus longtemps. Ce tri, rendu explicite, évite le double développement qui ruine les budgets de transition.

Les questions à poser à tout prestataire

• Qui décide, en cas de doute, si une demande est bloquante ou peut attendre la cible ?
• Quel est le délai de prise en charge garanti pour une anomalie critique en pleine période de migration ?
• Comment une demande refusée sur l'existant est-elle tracée pour ne pas se perdre avant d'arriver sur la cible ?
• Le prestataire de TMA a-t-il un accès réel au code, ou dépend-il d'une personne tierce pour intervenir ?

Articulation avec l'équipe de migration

TMA et migration se nourrissent mutuellement quand elles sont coordonnées : chaque intervention corrective documente un peu plus le code existant, chaque bizarrerie découverte alimente la cartographie, et le calendrier des bascules s'ajuste en fonction de la santé réelle des modules. Un point de synchronisation régulier entre les deux volets fait partie du dispositif : l'information circule dans les deux sens, sans double saisie pour vos équipes.

Erreurs fréquentes

• Séparer TMA et migration dans deux équipes qui ne se parlent qu'en cas de crise.
• Laisser le gel fonctionnel devenir un blocage informel, sans arbitrage explicite ni délai de réponse.
• Perdre la documentation produite pendant la TMA parce qu'elle n'est jamais transmise à l'équipe de migration.
• Traiter une même anomalie deux fois, une fois sur l'existant, une fois oubliée sur la cible faute de suivi commun.

Engagement de service et réversibilité

La TMA transitoire s'appuie sur un engagement écrit : périmètre, délais de prise en charge par criticité, points de suivi, conditions de sortie. Réversibilité comprise : documentation à jour et transfert de connaissance organisé, que la suite se fasse avec nous, avec votre équipe formée pendant le projet, ou avec un tiers. Une TMA qui enferme son client reproduirait la dépendance dont la migration cherche justement à sortir ; la nôtre est conçue pour se rendre remplaçable.

FAQ