Migration WinDev / WebDev : votre application est-elle encore un actif ?

Faut-il faire évoluer votre application WinDev ?

Une application WinDev ou WebDev bien conçue peut rendre service très longtemps. La question n'est donc pas d'en « sortir » par principe, mais de savoir si la vôtre reste un atout ou devient une contrainte. Les situations qui justifient d'y regarder de près :

• un besoin d'ouvrir l'application au web et au mobile, là où le poste Windows ne suffit plus ;
• des évolutions de plus en plus difficiles, ou un développeur historique parti sans avoir transmis ;
• la volonté de vous appuyer sur des technologies standard et ouvertes, moins liées à un environnement unique ;
• des données que vous voulez enfin exploiter librement : décisionnel, KPI, interconnexion avec vos autres outils.

Et si rien de tout cela ne vous concerne, si l'application fait bien son travail : la garder est souvent la meilleure décision. Nous vous le dirons franchement plutôt que de vous vendre un chantier inutile.

« Migration » est un abus de langage : c'est une réécriture

Il n'existe aucun convertisseur automatique du WLangage vers un autre langage. Quiconque vous promet une migration « au bouton » d'une application WinDev vers .NET ou vers le web vous vend une illusion. Faire évoluer une application WinDev en profondeur, c'est réécrire — en reprenant fidèlement les règles métier accumulées sur quinze ans, souvent enfouies dans le code et jamais documentées. Reconstruire proprement un système critique sans interrompre l'activité, c'est précisément notre métier de refonte, quelle que soit la technologie d'origine.

Nous connaissons WinDev de l'intérieur

Nous ne découvrons pas le WLangage sur votre dossier. Nous avons tous les trois développé en WinDev et WebDev et administré des bases HFSQL : nous savons ce qu'une fenêtre, un état, une zone répétée ou une procédure stockée HFSQL cache réellement. Cette connaissance de terrain change tout au moment d'estimer la charge et d'éviter les pièges — la différence entre un devis tenu et un dérapage découvert à mi-parcours.

Trois issues possibles — nous vous conseillons la bonne

Notre rôle n'est pas de vous pousser vers la réécriture, mais de vous aider à choisir la bonne réponse :

• Geler — garder votre application telle quelle tant qu'elle fait son travail sans vous freiner. Souvent la réponse la plus rationnelle : moderniser sans nécessité coûte plus que ça ne rapporte. Nous le recommandons sans détour quand c'est le cas.
• Encapsuler — garder le socle WinDev qui fonctionne et ouvrir autour ce qui manque : interfaces web, mobile et API, tableaux de bord et KPI. Vous modernisez l'usage sans réécrire le cœur.
• Réécrire — seulement quand l'application est déjà un frein : écran Windows dans un monde web et mobile, développeur historique parti, évolutions devenues impossibles. Là, nous reconstruisons un socle sur mesure taillé pour les quinze prochaines années.

Vos données ne sont pas prisonnières

Contrairement à une idée reçue, la base HFSQL n'est pas le point dur : elle s'ouvre en ODBC et se migre vers PostgreSQL, SQL Server ou MySQL sans drame. Le vrai travail est ailleurs — les traitements et procédures stockées écrits en WLangage côté serveur, qui n'ont pas d'équivalent portable et se réécrivent un à un. Ouvrir la base, c'est aussi libérer vos indicateurs : une donnée de production enfin requêtable par n'importe quel outil décisionnel.

Pour qui — et pas pour qui

Pour vous si vous exploitez une application WinDev ou WebDev critique, en production, sur un parc déployé conséquent, avec un enjeu métier qui justifie d'y regarder à deux fois avant de la laisser vieillir.

Pas pour vous si votre application tourne sur quelques postes sans criticité : en dessous d'environ cinquante postes déployés, notre audit coûte souvent plus cher que votre problème. Gardez votre application — et notre adresse pour le jour où elle deviendra un vrai frein.