En bref : une migration WinDev vers le web dure rarement le même temps d'un projet à l'autre. Tout dépend du nombre de fenêtres et d'états à reprendre, de la complexité des règles métier, de l'état de la base de données et de la disponibilité des équipes métier côté client. Un audit préalable permet de poser un planning réaliste avant tout engagement.
Sommaire
- Pourquoi la durée varie autant d'un projet à l'autre
- Les facteurs qui allongent ou raccourcissent le planning
- Les grandes phases d'un projet de migration
- Migration en une fois ou par étapes : quel effet sur la durée ?
- Les pièges qui font déraper un planning
- Comment obtenir une estimation fiable pour votre application
- Questions fréquentes
Pourquoi la durée d'une migration WinDev varie autant d'un projet à l'autre
Deux applications WinDev peuvent sembler proches sur le papier et demander des plannings très différents. L'une tient sur quelques dizaines de fenêtres avec une base de données propre. L'autre a grossi au fil des années, accumulé des correctifs, et plus personne en interne ne connaît tous les recoins du code. Dans ce second cas, le temps passé à comprendre l'existant pèse autant que le développement lui-même.
Avant de donner une estimation, il faut donc regarder le périmètre réel : nombre d'écrans, de traitements, de rapports, de connexions à d'autres systèmes. C'est ce que couvre un audit préalable à la migration, étape qui conditionne la fiabilité de tout le planning qui suit.
Les facteurs qui allongent ou raccourcissent le planning
Certains éléments pèsent plus que d'autres sur la durée totale du projet. Le tableau ci-dessous résume les principaux.
| Facteur | Effet sur la durée |
|---|---|
| Nombre de fenêtres, d'états et de traitements à reprendre | Impact direct : plus le périmètre fonctionnel est large, plus la phase de développement s'allonge |
| Qualité et documentation du code source existant | Un code mal documenté rallonge la phase de compréhension et augmente le risque d'oublis |
| Etat de la base de données (HFSQL ou autre moteur) | Une base propre et normalisée accélère la reprise ; une base avec des incohérences demande un nettoyage en amont |
| Complexité des règles métier et des calculs | Des règles anciennes, parfois non écrites, demandent du temps d'analyse avec les équipes métier |
| Disponibilité des utilisateurs métier pour les tests | Des retours lents sur les phases de recette font glisser le calendrier, indépendamment du développement |
| Approche choisie (migration en une fois ou par étapes) | Change la répartition du temps dans le planning, pas seulement sa durée totale |
Les grandes phases d'un projet de migration et leur poids dans le planning
Un projet de migration WinDev suit en général la même trame, même si le poids de chaque phase varie selon l'application :
- Audit et cadrage : état des lieux du code, de la base de données et des usages réels de l'application.
- Choix de la cible technique : langage, architecture, hébergement, en fonction des contraintes du client.
- Développement et migration des données : reprise fonctionnelle, reprise des données, intégrations avec les autres systèmes.
- Tests de non-régression : vérifier que la nouvelle application se comporte comme l'ancienne, fonction par fonction. C'est l'objet de la méthode MIRROR, qui structure cette étape en six phases.
- Déploiement et accompagnement : mise en production, formation des utilisateurs, période de double run si nécessaire.
La phase de tests est souvent sous-estimée dans les plannings initiaux. Elle demande pourtant autant de rigueur que le développement, car c'est elle qui garantit qu'aucune règle métier n'a été perdue en route.
Migration en une fois ou par étapes : quel effet sur la durée totale ?
Une migration « big bang », qui bascule toute l'application d'un coup, concentre le risque sur une seule mise en production. Le planning est plus simple à annoncer, mais la moindre erreur apparaît sur l'ensemble du périmètre en même temps.
Une migration progressive, module par module, répartit l'effort sur plusieurs mises en production. La durée totale peut sembler plus longue sur le calendrier, mais chaque étape est plus courte à valider et le risque reste localisé. Le choix entre les deux approches dépend moins de la vitesse recherchée que de la tolérance au risque de l'entreprise et de la manière dont l'application est utilisée au quotidien. Pour aller plus loin sur les options de cible et leurs implications, voir cet article sur le choix de la cible de migration. Le coût du projet suit une logique proche : il dépend du même périmètre que la durée, comme détaillé dans cet article sur le coût d'une migration WinDev.
Les pièges qui font déraper un planning de migration
Certains dépassements de planning reviennent souvent, quel que soit le secteur d'activité. Les règles métier non documentées en sont un bon exemple : un calcul particulier, ajouté pour un client ou une exception réglementaire il y a plusieurs années, ressurgit en cours de développement et personne ne sait plus pourquoi il existe. Il faut alors remonter jusqu'aux utilisateurs métier pour comprendre la logique avant de la reproduire.
Les intégrations avec d'autres logiciels sont une autre source de retard : un échange de fichiers avec la comptabilité, une connexion à un outil de gestion commerciale, une interface avec une machine de production. Chacune de ces connexions doit être testée dans le nouvel environnement, et pas seulement recopiée.
Enfin, la disponibilité des équipes métier pour valider les tests reste le facteur le plus sous-estimé. Un développement terminé dans les délais peut attendre plusieurs semaines une recette qui n'a pas été planifiée en amont.
Comment obtenir une estimation fiable pour votre application
Donner un chiffre avant d'avoir regardé le code reviendrait à deviner. La seule façon d'obtenir un planning crédible est de partir d'un inventaire réel : liste des fenêtres, des états, des traitements automatisés, des connexions externes, et un état de la base de données. Cet inventaire permet ensuite de découper le projet en lots, d'identifier les zones à risque et de poser des jalons de validation avec les équipes métier.
Pour obtenir un planning réaliste, propre à votre application, la première étape reste un audit technique et fonctionnel. Demandez un audit ou un cadrage de votre migration WinDev à Euro Tech Conseil.
Questions fréquentes
Combien de temps dure en moyenne une migration WinDev ?
Il n'existe pas de durée moyenne fiable : le périmètre fonctionnel, l'état du code et celui de la base de données varient trop d'une application à l'autre. Un audit permet de remplacer une estimation générique par un planning propre à votre cas.
Quels éléments faut-il regarder avant d'estimer un planning ?
Le nombre de fenêtres et d'états, la complexité des règles métier, la qualité du code source, l'état de la base de données et la disponibilité des équipes métier pour les tests.
Une migration par étapes prend-elle plus de temps qu'une migration en une fois ?
Pas nécessairement sur la durée totale, mais le temps est réparti différemment : plusieurs mises en production plus courtes, au lieu d'une seule bascule générale.
Peut-on accélérer une migration WinDev sans sacrifier la qualité ?
Dans une certaine mesure, en limitant le périmètre de chaque lot et en automatisant les tests de non-régression. Au-delà d'un certain point, réduire les délais revient surtout à réduire les tests, ce qui augmente le risque.
Que se passe-t-il si le planning dérape en cours de projet ?
C'est souvent le signe que le périmètre initial était mal connu, d'où l'intérêt d'un audit avant de fixer des dates, plutôt que d'ajuster le planning une fois le projet lancé.
