En bref : une réécriture complète d'une application WinDev est risquée et longue : tout le métier bascule d'un coup, sans filet. La méthode progressive, parfois appelée « strangler fig », consiste à faire cohabiter l'ancien et le nouveau : les modules sont repris un par un, testés, puis mis en service, pendant que le reste de l'application continue de tourner sans interruption.
Sommaire
- Pourquoi éviter la réécriture complète ?
- Qu'est-ce que la modernisation progressive ?
- Par où commencer : identifier les modules prioritaires
- Comment faire cohabiter l'ancien et le nouveau ?
- Quelles étapes concrètes sur plusieurs mois ?
- Quels sont les risques de cette méthode ?
- Questions fréquentes
Pourquoi éviter la réécriture complète ?
Une application WinDev vieille de dix ou quinze ans contient rarement une documentation à jour de toutes ses règles de gestion. Une partie de cette connaissance vit uniquement dans le code, et une autre dans la tête des utilisateurs qui ont appris à contourner certains écrans. Réécrire l'ensemble d'un coup oblige à retrouver cette connaissance avant la mise en production, sous peine de découvrir les manques une fois l'ancien système coupé. C'est souvent cette étape, et non la technique, qui fait déraper les plannings et les budgets.
Une bascule totale impose aussi un seul grand jour de mise en service, avec tous les risques que cela comporte : si un module critique a été mal repris, toute l'entreprise en subit les conséquences en même temps.
Qu'est-ce que la modernisation progressive ?
L'idée vient du développement logiciel : au lieu de remplacer un système d'un bloc, on l'entoure progressivement de nouveaux modules, jusqu'à ce que l'ancien code ne gère plus qu'une part résiduelle, puis plus rien. Appliquée à une application WinDev, la méthode consiste à :
- Choisir un premier module autonome (un écran de saisie, un rapport, une fonction périphérique) à réécrire en priorité.
- Le faire fonctionner en parallèle de l'ancien module, avec un moyen clair de basculer les utilisateurs de l'un à l'autre.
- Vérifier que les deux versions produisent les mêmes résultats sur les mêmes données, avant de couper l'ancien module.
- Répéter l'opération module par module, jusqu'à ce que l'application WinDev d'origine ne subsiste plus, ou ne subsiste que pour des fonctions mineures qu'il n'est pas utile de reprendre.
Pour garantir que chaque bascule ne casse rien, nous appliquons une méthode de vérification en plusieurs phases, détaillée dans notre article sur la méthode MIRROR pour prouver qu'une migration ne casse rien.
Par où commencer : identifier les modules prioritaires
Deux critères guident ce choix, et ils pointent rarement vers le même module. D'un côté, la valeur métier : quel module coûte le plus cher à maintenir, ou freine le plus l'activité au quotidien ? De l'autre, le risque technique : quel module est le plus autonome, avec le moins de dépendances vers le reste de l'application, donc le plus simple à isoler sans tout perturber ?
La pratique la plus sûre consiste à démarrer par un module à risque technique faible, même si sa valeur métier est modeste. Ce premier module sert de test grandeur réelle pour la méthode elle-même : il valide l'outillage, la façon de faire cohabiter les deux systèmes, et le rythme de bascule avant de s'attaquer aux modules les plus sensibles. Un audit préalable de l'application aide à repérer ces dépendances avant de se lancer ; nous détaillons cette étape dans pourquoi auditer une application WinDev avant de changer de technologie.
Comment faire cohabiter l'ancien et le nouveau ?
La cohabitation repose en général sur un point de passage commun : souvent la base de données, parfois une couche d'accès ajoutée devant elle. Le nouveau module web lit et écrit dans les mêmes tables que l'application WinDev, ou dans une base synchronisée, de façon à ce qu'un utilisateur sur l'ancien système et un utilisateur sur le nouveau travaillent sur les mêmes données sans décalage.
Cette étape est la plus délicate techniquement, et c'est aussi celle qui demande le plus de rigueur sur HFSQL : structure des tables, verrous, cohérence des mises à jour simultanées. Elle mérite d'être cadrée avant le premier module, pas découverte en cours de route.
Quelles étapes concrètes sur plusieurs mois ?
| Phase | Objectif | Durée indicative |
|---|---|---|
| Audit et cadrage | Cartographier les modules, les dépendances et les règles métier | Quelques semaines |
| Premier module pilote | Valider la méthode de cohabitation et de bascule | 4 à 8 semaines |
| Modules suivants | Reprendre les écrans par ordre de priorité métier | Variable selon le nombre d'écrans |
| Bascule finale | Arrêter l'application WinDev d'origine, ou la conserver pour des fonctions résiduelles | Selon l'avancement |
Ce découpage permet d'avancer à un rythme compatible avec l'activité de l'entreprise, sans bloquer le reste des projets informatiques pendant toute la durée de la modernisation.
Quels sont les risques de cette méthode ?
La modernisation progressive n'élimine pas tous les risques, elle les répartit dans le temps au lieu de les concentrer sur un seul jour de bascule. Le principal piège est la durée : si la cohabitation s'étire trop longtemps, l'entreprise finit par maintenir deux systèmes en parallèle, ce qui coûte plus cher que prévu. D'où l'intérêt de fixer, dès le départ, un nombre limité de modules et un calendrier de bascule pour chacun, plutôt que de laisser le projet s'étaler sans échéance. La question se pose aussi en miroir de la tierce maintenance applicative : parfois, continuer la TMA sur un module précis coûte moins cher que de le moderniser tout de suite. Nous comparons les deux logiques dans TMA WinDev ou migration : quelle stratégie choisir.
Quel rôle pour les équipes internes pendant la transition ?
Les développeurs WinDev de l'entreprise, quand il en reste, sont souvent les meilleurs garants de la connaissance métier accumulée dans l'ancien code. Les associer au projet, plutôt que de les mettre de côté, accélère la reprise des règles de gestion et réduit le risque d'oublier un cas particulier que seul le code d'origine traitait. Le prestataire qui mène la modernisation gagne à documenter chaque module au moment où il le reprend, pas seulement à le réécrire : cette documentation sert ensuite à la maintenance du nouveau système, bien après la fin du projet.
Vous voulez moderniser votre application WinDev sans arrêter l'activité ? Demandez un audit de cadrage à Euro Tech Conseil : nous identifions les modules prioritaires et construisons avec vous un calendrier de bascule réaliste.
Questions fréquentes
La méthode progressive coûte-t-elle plus cher qu'une réécriture complète ?
Pas nécessairement. Elle répartit le coût sur plusieurs phases au lieu de le concentrer sur un seul projet, ce qui réduit le risque de dérapage budgétaire global, même si la durée totale peut être plus longue.
Combien de temps dure une modernisation progressive ?
Cela dépend du nombre de modules et de leur complexité. Un audit initial permet d'estimer un calendrier par module plutôt qu'une durée globale approximative.
Faut-il moderniser tous les modules, même les moins utilisés ?
Non. Certains modules peuvent rester en tierce maintenance applicative sur l'ancien système, s'ils sont peu utilisés et ne justifient pas l'investissement d'une réécriture.
Les utilisateurs doivent-ils apprendre deux systèmes en même temps ?
Pendant la phase de cohabitation, oui, pour le module concerné. C'est pourquoi la méthode privilégie des bascules par petits groupes d'utilisateurs, avec un accompagnement au changement à chaque étape.
Cette méthode fonctionne-t-elle aussi pour une migration vers WebDev plutôt que vers une stack web classique ?
Oui. Le principe de cohabitation progressive ne dépend pas de la technologie cible : il s'applique aussi bien à une bascule vers WebDev qu'à une réécriture en PHP, Java ou Node.
