Migration WinDev : comment moderniser votre application

Votre Migration WinDev ne devrait pas vous obliger à perdre les données et règles métier qui font fonctionner votre entreprise. Pourtant, une application WinDev désuète peut devenir difficile à faire évoluer, à utiliser à distance ou à connecter à vos autres outils.

Chez CyberPerformance, nous vous aidons à moderniser une application WinDev et à remplacer WinDev par une solution sur mesure, notamment une application web conçue avec React et Node.js. Ainsi, nous sécurisons votre base de données HFSQL ou HyperFile, reprenons les traitements WLangage essentiels et organisons une transition progressive. Découvrez l’approche, le prix et le délai à prévoir.

Étape 1 : faire le point sur votre application WinDev

Repérer les limites : accès à distance, lenteurs et connexions manquantes

Avant de moderniser une application WinDev, nous partons de l’usage réel. Nous observons les postes, les sites distants, les connexions à la base de données et les opérations quotidiennes. Une application WinDev désuète peut rester fonctionnelle au bureau tout en ralentissant dès qu’un collaborateur travaille à distance ou qu’un volume de données augmente.

Nous relevons aussi les échanges qui entourent le logiciel développé en WinDev : exports comptables, fichiers déposés sur un répertoire partagé, impressions spécifiques, automatisations Office, webservices, scanners ou logiciels tiers. Par exemple, un écran de facturation peut sembler autonome alors qu’il produit un fichier attendu chaque mois par la comptabilité.

Pour chaque limite, nous cherchons une réponse vérifiable : quel utilisateur rencontre le problème, dans quel parcours, avec quelle fréquence et quel résultat attendu ? Cette méthode évite de remplacer WinDev sur la seule base d’une impression générale.

Vérifier les hausses de prix attribuées au rachat de PC SOFT

Le rachat de PC SOFT a eu lieu en novembre 2024, puis les modalités commerciales de la suite ont changé. Nous conseillons de comparer votre contrat actuel, les renouvellements prévus et le nombre réel de sessions déployées avant toute décision de Migration WinDev.

Le sujet ne se limite pas aux licences. Un environnement propriétaire en WLangage peut aussi limiter le choix des personnes capables de maintenir le code. En conséquence, nous distinguons le coût de l’abonnement, le coût des évolutions et le coût d’une dépendance durable à l’outil. Une application sur mesure apporte une autre voie : notre équipe peut faire évoluer progressivement le code, les interfaces et les connexions selon les besoins réels de votre activité.

Recenser les écrans, traitements et règles métier en WLangage

Nous cartographions ensuite ce qui fonctionne aujourd’hui, en partant de l’exécutable utilisé et non du seul projet ouvert dans l’éditeur. Les versions déployées, paramètres locaux, composants externes, tâches planifiées et bibliothèques peuvent différer des sources disponibles.

Le recensement couvre notamment :

1. les fenêtres, menus, états imprimés, requêtes et exports ;

2. les procédures WLangage, variables globales, calculs et droits d’accès ;

3. les dépendances, telles que DLL, composants .NET, accès ODBC, répertoires réseau et services externes ;

4. les parcours que les équipes utilisent chaque jour, y compris leurs contrôles manuels.

Nous demandons aussi ce que chacun fait avant et après l’application. Cette question fait apparaître des fichiers Excel, des ressaisies ou des vérifications qui portent parfois une règle métier absente du code. Par exemple, un montant peut être calculé dans l’application puis corrigé manuellement avant l’envoi d’un document.

Cette cartographie prépare un passage de WinDev vers application web, qu’elle s’appuie sur React et Node.js ou sur une autre architecture sur mesure. Nous reprenons les règles à conserver dans un code lisible et organisé, sans recopier automatiquement chaque ancien écran.

Identifier les données et les fonctions à conserver

Nous séparons enfin les données nécessaires au fonctionnement, à l’historique et aux échanges avec des tiers. Avec HFSQL ou HyperFile, nous vérifions si la base fonctionne en mode Classic ou Client/Serveur, si des réplications existent et si d’autres outils lisent ou écrivent directement dans les fichiers.

Chaque fonction reçoit une priorité : utilisée, critique ou remplaçable. Un export lancé par une seule personne peut rester critique s’il alimente un client ou la paie. De même, une table rarement consultée peut contenir l’historique requis pour une recherche ou un état.

Chez CyberPerformance, nous utilisons cet inventaire pour proposer une migration vers du sur mesure par étapes. Nous pouvons commencer par le module qui apporte le plus de valeur, conserver l’ancien logiciel pendant la transition et préparer les correspondances entre l’ancienne base de données et la nouvelle application.

Étape 2 : choisir comment moderniser votre application WinDev

Comparer maintenance, mise à jour et remplacement de WinDev

Après l’inventaire, nous choisissons une trajectoire selon les usages, les dépendances et le budget d’évolution. Une application WinDev peut encore répondre aux besoins métier. Dans ce cas, nous pouvons reprendre la maintenance, corriger les incidents, documenter le code WLangage et réaliser une montée de version. Cette option convient lorsque les utilisateurs travaillent surtout sur des postes Windows, que les besoins restent stables et que les connexions avec les autres outils demeurent suffisantes.

Une mise à jour technique ne corrige toutefois pas tous les sujets. Elle conserve l’architecture existante, les modes d’installation et les limites déjà relevées. Par exemple, passer à une version récente de WinDev ne crée pas automatiquement un portail client, une interface mobile ou des API adaptées à vos partenaires.

Le remplacement de WinDev devient cohérent lorsque nous devons revoir plusieurs éléments à la fois : accès distant, intégrations, ergonomie, sécurité ou rythme des évolutions. Nous évitons de remplacer WinDev par réflexe. Nous comparons le coût de la maintenance, celui des licences PC SOFT et le travail nécessaire pour répondre aux demandes à venir.

Les conditions commerciales doivent aussi entrer dans cette comparaison. Les prix de la suite PC SOFT ont changé depuis son rachat, avec des modalités liées notamment aux sessions et aux capacités d’hébergement. Nous calculons donc vos dépenses réelles sur plusieurs années, plutôt que de limiter la décision au coût initial d’une Migration WinDev.

Passer par WebDev ou migrer de WinDev vers une application web sur mesure

WebDev permet de conserver l’environnement PC SOFT et une partie des acquis WinDev, notamment certaines procédures, classes et analyses partagées. Cette voie convient lorsque nous voulons créer un front-office web relié à l’application WinDev, sans remplacer immédiatement le cœur du logiciel développé en WinDev.

Toutefois, nous ne transposons pas les fenêtres de bureau telles quelles dans un navigateur. Une application web impose des parcours, une gestion des sessions et des usages différents. Nous redessinons les écrans en fonction des tâches réelles : consulter une commande, saisir une intervention depuis le terrain ou suivre une facture. Le WLangage serveur s’exécute alors dans le serveur d’application WebDev, qui gère aussi les accès à la base de données et les webservices.

L’autre choix consiste à migrer de WinDev vers une application web sur mesure, par exemple avec React pour l’interface et Node.js pour les services. Nous séparons alors l’affichage, les règles métier et les accès à HFSQL, HyperFile ou une autre base. Cette architecture facilite la création d’API et les connexions avec un CRM, un ERP, une plateforme comptable ou un portail client.

Comprendre les avantages du sur mesure : fonctions adaptées, maîtrise du code et évolutions progressives

Chez CyberPerformance, nous proposons la migration d’une application WinDev désuète vers du sur mesure. Nous reprenons les fonctions qui servent réellement vos équipes, puis nous écartons les écrans ou traitements devenus inutiles. Le résultat suit vos procédures plutôt que les contraintes d’un produit générique.

Le sur mesure donne aussi un cadre clair pour la propriété et l’évolution du code. Nous définissons avec vous les priorités, les interfaces, les connexions et les lots de développement. Ainsi, une nouvelle fonction peut être ajoutée quand un besoin apparaît, sans attendre qu’un éditeur l’intègre à sa feuille de route.

Nous avançons par modules validés avec vos utilisateurs. Un premier lot peut couvrir la consultation des dossiers, puis la saisie, les calculs et enfin les échanges externes. Cette progression permet de conserver l’application historique pendant la transition et prépare le choix de la future base de données.

Étape 3 : sécuriser et préparer la base de données

Sauvegarder HFSQL ou HyperFile et tester la restauration

Nous gelons d’abord une copie complète de la base de données avant la Migration WinDev, tout nettoyage ou transfert. Nous conservons cette source intacte dans un emplacement, puis nous restaurons la sauvegarde sur un environnement séparé. Avec HFSQL, nous pouvons planifier des sauvegardes complètes et différentielles, y compris à chaud. Nous vérifions pourtant la restauration, les droits, les index, les relations et un échantillon de dossiers. Nous écartons toute sauvegarde incapable de recréer une base exploitable.

Choisir de conserver HFSQL ou de migrer vers une autre base

Nous choisissons ensuite le moteur selon les usages, les compétences internes et les autres bases administrées. Nous pouvons conserver HFSQL lorsque son fonctionnement répond au périmètre retenu. Nous pouvons aussi migrer vers PostgreSQL, SQL Server, MySQL, MariaDB ou Oracle si l’environnement visé le demande. Dans ce cas, nous convertissons explicitement schémas, types, index, contraintes et requêtes. Par exemple, nous réservons un type numérique à précision fixe aux montants, et nous traitons les dates vides avant de les inscrire dans la cible.

Préparer les correspondances entre les anciennes et les nouvelles données

Nous créons un dictionnaire de correspondance qui relie chaque champ source à sa destination. Pour chaque ligne, nous indiquons le type, le format, la règle de transformation et la personne qui valide. Ainsi, nous pouvons conserver l’ancien identifiant dans un champ de référence et importer d’abord les tables de référence, puis les enregistrements qui y renvoient. Nous testons le mappage sur un lot et comparons volumes, clés, totaux et résultats métier avant le transfert complet.

Nettoyer les doublons sans perdre les historiques utiles

Nous commençons par profiler les tables afin de repérer valeurs manquantes, formats incohérents, doublons et relations orphelines. Nous classons ensuite chaque donnée : transfert, archivage ou retrait. Nous ne supprimons jamais un historique sans avoir décidé son usage futur. Pour les doublons, nous appliquons une clé fiable ou plusieurs règles, telles que le nom, le numéro et la date pertinente. Nous faisons examiner manuellement les rapprochements approximatifs avant toute fusion. Nous normalisons les libellés, dates et types de données, puis nous documentons chaque correction et sa justification.

Créer des scripts de transfert rejouables

Nous écrivons des scripts qui extraient, transforment et chargent les données par lots, en gardant l’état d’avancement. Après exécution, nous contrôlons les lignes transférées et relançons le script jusqu’à obtenir des résultats identiques et traçables dans le temps.

Étape 4 : réécrire les modules et valider leur fonctionnement

Commencer par un module pilote et organiser la coexistence des applications

Nous sélectionnons un module pilote borné, tel que la consultation d’un dossier et son export. Il réunit des règles, un accès à la base de données et une interface externe. Nous attribuons chaque donnée à l’ancien logiciel développé en WinDev ou au nouveau service sur mesure. Ainsi, aucune double saisie ne crée d’écart. Nous fixons flux, synchronisation et arrêt d’écriture WinDev.

Reprendre les règles métier dans le nouveau code

Face aux hausses de prix de PC SOFT, nous ne traduisons pas le WLangage ligne par ligne. À partir des scénarios, nous formulons chaque règle, ses seuils, exceptions et branches d’erreur. Par exemple, une remise au-delà de dix articles exige un test différent de celui de dix articles. Le code sur mesure sépare l’interface React, les services Node.js et les calculs métier. Chez CyberPerformance, nous gardons les sources comme référence et validons les décisions avec ceux qui appliquent ces règles.

Comparer les calculs, les états et les échanges avec les autres logiciels

Nous rejouons un jeu de données connu dans les deux applications. Nous rapprochons totaux, taxes, écritures, états imprimés et fichiers transmis. Chaque différence reçoit une explication : règle voulue, donnée ancienne ou défaut. Les tests de non-régression cherchent les défauts apparus après une modification. Nous vérifions aussi les API, imports et exports, y compris lorsque le logiciel tiers répond mal.

Tester les performances, la sécurité et les parcours avec les utilisateurs

Nous mesurons les temps de réponse sous la charge attendue, puis lors d’une hausse rapide d’utilisateurs. Les parcours sont exécutés sur navigateur et mobile lorsque prévu. En parallèle, nous contrôlons les droits par rôle. Un test d’intrusion ajoute des scénarios manuels aux recherches automatiques. Enfin, les utilisateurs métiers réalisent la recette de chaque module sur leurs cas réels et consignent chaque résultat à terme.

Étape 5 : organiser la mise en service avec CyberPerformance

Quel prix et combien de temps prévoir selon le périmètre retenu ?

Nous chiffrons après audit des écrans, échanges et volume de la base de données. Le délai va de quelques semaines pour un portage ciblé à plusieurs mois pour une réécriture étendue.

Comment CyberPerformance accompagne la migration WinDev vers du sur mesure

CyberPerformance facilite la Migration WinDev de l’analyse au lancement. Face aux hausses tarifaires de PC SOFT, nous remplaçons le WLangage utile par du sur mesure, React et Node.js, avec sources, documentation et tests remis.

Planifier le dernier transfert, les contrôles et le retour arrière

Nous fixons une fenêtre de bascule, gelons les écritures, exécutons la sauvegarde finale et synchronisons les données. Ensuite, nous contrôlons les parcours convenus. Des critères écrits désignent la personne qui ordonne le retour arrière.

Former les équipes et garder l'ancien logiciel en lecture seule

Nous formons chaque profil sur ses tâches, avec des cas réels. Puis nous ouvrons le nouveau logiciel en écriture et conservons l’application WinDev désuète en lecture seule pour consulter l’historique.

Prévoir le suivi et les prochaines évolutions après le lancement

Après le lancement, nous suivons incidents, performances et demandes, puis priorisons les évolutions dans une feuille de route partagée avec vous.

Conclusion

La hausse marquée des prix des solutions WinDev depuis le rachat de PC SOFT pousse de nombreuses entreprises à revoir leurs options. Une simple mise à jour peut prolonger l’existant, mais elle ne répond pas toujours aux besoins d’accès distant, d’intégration et d’évolution. Nous analysons les règles métier, sécurisons les données HFSQL et validons chaque module avant la bascule. Ainsi, une application sur mesure offre un code maîtrisé, des interfaces adaptées et des évolutions progressives selon vos priorités. Chez CyberPerformance, nous assurons la migration de votre application développée en WinDev vers une solution sur mesure, avec accompagnement, tests et formation.

FAQ

Q1. Faut-il remplacer WinDev ou simplement mettre à jour son application ?
Une mise à jour peut suffire si l’application répond encore aux besoins. Un remplacement devient pertinent lorsque l’accès à distance, les connexions avec d’autres outils ou les évolutions demandées nécessitent de revoir son architecture.

Q2. Quelles options permettent de passer de WinDev à une application web ?
WebDev permet de rester dans l’environnement PC SOFT et de réutiliser certains éléments existants. Une application web sur mesure, par exemple avec React et Node.js, permet de repenser les interfaces et les connexions selon vos besoins.

Q3. Peut-on conserver ses données HFSQL lors d’une migration WinDev ?
Oui, il est possible de conserver HFSQL ou de transférer les données vers une autre base. Avant tout transfert, il faut sauvegarder les données, tester leur restauration et vérifier les correspondances entre les anciens et les nouveaux champs.

Q4. Comment migrer progressivement sans perturber le travail des équipes ?
Commencez par un module pilote, puis faites coexister les deux applications avec des règles claires pour les saisies et la synchronisation. Validez chaque module avec les utilisateurs et prévoyez une procédure de retour arrière avant la bascule.

Q5. Quel budget et quel délai prévoir pour une migration WinDev ?
Le budget dépend du nombre d’écrans, des règles métier, des échanges externes et du volume de données. Un audit permet de le préciser. Le délai peut aller de quelques semaines pour un périmètre ciblé à plusieurs mois pour une réécriture étendue.