Sortir de WinDev : par quoi le remplacer ?

Vous avez décidé de sortir de WinDev. Reste à savoir par quoi le remplacer. La question qu’on nous pose est presque toujours formulée ainsi : on part sur quoi, Python, .NET, Java, PHP ? C’est la mauvaise question, et y répondre trop vite est la première cause de migration ratée.

Cet article traite d’une seule question : vers quelle technologie partir
Si vous n’avez pas encore tranché entre rester sur WinDev, réduire votre dépendance ou en sortir complètement, commencez par notre page migration d’applications WinDev, qui compare les trois trajectoires. Cet article suppose que vous avez déjà choisi de sortir.

La technologie cible est une conséquence, pas une décision

Un langage ne se choisit pas dans l’absolu. Il se déduit de quatre éléments qui vous appartiennent, et qu’aucun prestataire ne peut arbitrer à votre place. Attention, ce ne sont pas les mêmes critères que ceux qui décident de partir ou de rester : ceux-là sont traités sur la page migration. Ici, la décision de sortir est acquise, et il s’agit uniquement de désigner la cible.

  1. L’usage réel de l’application
    Saisie intensive sur postes fixes, accès distant multi-sites, ou usage en mobilité ? Ce point structure l’architecture bien avant le langage, et il se mesure sur les journaux d’usage, pas sur le cahier des charges.
  2. La compétence disponible
    Celle de votre équipe interne, et celle que vous pouvez recruter dans votre bassin d’emploi. Une technologie excellente que personne autour de vous ne maîtrise reproduit exactement le problème que vous quittez.
  3. Le système d’information existant
    Avec quoi l’application doit dialoguer : comptabilité, paie, échange de données, outils métier. L’intégration pèse souvent plus lourd dans le choix que l’application elle-même.
  4. L’horizon à cinq ans
    Ouverture d’un portail client, exploitation de vos données, mise en service en ligne, mobilité terrain. Ce qui est prévu à trois ans doit être possible sans deuxième migration.

Les cinq trajectoires que nous rencontrons

Aucune n’est meilleure que les autres dans l’absolu. Chacune s’impose dans un contexte précis, et chacune a un point de vigilance que le prestataire qui la propose ne mentionne pas toujours.

Cible Quand elle s’impose Le point de vigilance
.NET et C# Poste lourd Windows riche en interface, système d’information déjà Microsoft, équipe habituée à un environnement intégré. C’est le paradigme le plus proche de WinDev, donc la conduite du changement la plus faible. Vous restez chez un éditeur, avec une autre gouvernance.
Python Application de gestion, besoins d’analyse de données ou d’IA à court terme, volonté de recruter largement. Le packaging et la mise à jour du poste client sont un poste de travail réel, qui n’existait pas sous WinDev.
Java Grand compte, système d’information déjà Java, exigence de support à très long terme et d’équipes structurées. Coût d’entrée plus élevé et volume de code supérieur. Rarement justifié sous une certaine taille d’organisation.
PHP moderne
Symfony, Laravel
Application de gestion en web, hébergement simple, vivier de développeurs très large en France. Moins adapté au poste lourd et aux traitements de calcul intensif.
TypeScript de bout en bout Service en ligne, portail client, temps réel, volonté de n’avoir qu’une compétence côté serveur et côté navigateur. Écosystème à cadence de renouvellement rapide. À cadrer pour éviter de reconstruire dans quatre ans.

Le critère qui ne devrait jamais compter

La préférence du prestataire. Une entreprise qui ne maîtrise qu’une technologie vous proposera toujours cette technologie, et elle aura toujours de bons arguments. Demandez systématiquement quelles autres cibles ont été écartées, et pourquoi. Une réponse précise vaut plus que n’importe quelle démonstration.

Le piège : remplacer une dépendance par une autre

Certaines plateformes promettent une reconstruction rapide sans écrire de code. Le gain immédiat est réel. Mais vous échangez alors une dépendance à un éditeur contre une dépendance à un autre, avec un modèle par utilisateur, un format propriétaire et la même impossibilité de reprendre l’application ailleurs. Si votre motivation pour sortir de WinDev est la maîtrise de votre patrimoine applicatif, cette voie ne la satisfait pas.

Ce qui ne change pas, quelle que soit la cible

C’est le point le plus important de cet article. L’essentiel du travail d’une migration WinDev est indépendant de la technologie d’arrivée.

Il faut inventorier le code, cartographier les dépendances entre écrans et fichiers de données, extraire les règles métier que personne n’a documentées, puis découper l’application en unités livrables une par une. Il faut reprendre la base HFSQL vers une base relationnelle, le plus souvent PostgreSQL, avec des contrôles de comptage et de totaux au centime près. Il faut reconstruire les états et impressions, poste systématiquement sous-estimé. Il faut enfin prouver par des tests d’équivalence, sur des données réelles, que le nouveau système produit les mêmes résultats que l’ancien.

Ces étapes représentent la majeure partie de l’effort, et elles sont les mêmes que vous partiez vers Python, .NET, Java, PHP ou TypeScript. C’est précisément pour cela que le choix du langage peut, et doit, être pris après l’audit et non avant.

La règle à retenir

Le coût de rester sous WinDev se calcule seul, avec une feuille de calcul et le nombre de postes. Le coût de partir ne se calcule pas sans avoir lu le code. Un chiffrage annoncé avant l’audit est une marge de sécurité, ou une mauvaise surprise différée.

Notre position

ETC SOFT est le pôle WinDev, WebDev et WinDev Mobile d’Euro Tech Conseil. Nous maintenons des applications WinDev depuis 26 ans et nous intervenons sur plusieurs technologies cibles. C’est ce qui nous permet de recommander celle qui correspond à votre situation, y compris quand la bonne réponse est de ne pas migrer et de sécuriser l’existant.

Sur les projets de refonte et de migration d’applications WinDev, WebDev et WinDev Mobile, notre programme de développement augmenté par l’IA applique -40 % sur le prix établi selon notre méthodologie traditionnelle, à périmètre fonctionnel identique. Ce n’est pas une remise commerciale : notre coût de production a baissé, pas notre marge. À l’issue de l’audit, nous remettons les deux chiffrages, pour que l’écart soit vérifiable poste par poste.

Faites lire votre code avant de choisir

Audit technique gratuit, restitué sous 48 heures : analyse du code source, cartographie fonctionnelle, état de la base HFSQL, recensement exhaustif des états, trajectoire recommandée avec les cibles écartées et leurs raisons, planning par lots et double chiffrage. Sans engagement.

Réduction de 40 % appliquée au prix de la refonte établi selon notre méthodologie traditionnelle, sur un périmètre fonctionnel identique. Applicable aux projets de refonte et de migration d’applications WinDev, WebDev et WinDev Mobile validés après audit technique. Les deux chiffrages sont remis au client. Les trajectoires décrites sont celles que nous rencontrons le plus fréquemment et ne constituent pas une liste exhaustive. Informations arrêtées au 21 septembre 2026.