Sortir de WinDev : migrer vers .NET ou moderniser progressivement son application ?

L’évolution récente du modèle de commercialisation de WINDEV peut amener certaines entreprises à réexaminer l’avenir d’une application historique. PC SOFT propose désormais sa suite sous forme d’abonnement et oriente les utilisateurs des versions récentes vers cette offre. Cette évolution peut modifier les prévisions de coût, mais elle ne suffit pas à justifier une migration.

Une application métier développée depuis dix ou quinze ans ne se résume pas à son langage. Elle concentre des règles de gestion, des données, des interfaces avec le système d’information et une connaissance parfois implicite des opérations. La vraie question n’est donc pas seulement « comment sortir de WinDev ? », mais : quelle trajectoire offre le meilleur équilibre entre coût, risque, maintenabilité et capacité d’évolution ?

Pourquoi certaines entreprises réévaluent aujourd’hui leur application WinDev ?

Un changement de licence ou de mode de facturation est souvent un déclencheur visible. L’entreprise peut vouloir comparer le coût cumulé des outils, du support, de l’infrastructure et des évolutions sur plusieurs années. Elle doit toutefois raisonner en coût total : conserver WinDev, migrer vers .NET ou choisir une autre plateforme mobilisent tous du temps, des compétences et de l’exploitation.

D’autres motifs sont généralement plus structurants : difficulté à faire évoluer certains modules, dépendance à quelques personnes, besoin d’ouvrir des API, création d’une interface web, intégration à un ERP, un CRM ou un WMS, exigences de déploiement cloud ou sur site, et transformation des processus métier.

La disponibilité des compétences peut également entrer dans l’analyse, mais elle doit être évaluée sur le bassin d’emploi et le contexte de l’entreprise. Il ne faut pas déduire automatiquement qu’une technologie est impossible à recruter ou à maintenir. Il faut mesurer le délai réel de recrutement, la dépendance aux profils clés et la capacité de l’équipe à transmettre sa connaissance.

Sur le licensing, les documents officiels montrent une transition : la grille de mise à jour 2025 présentait encore une version avec clé tout en recommandant la version SaaS ; pour la version 2026, PC SOFT renvoie vers son offre d’abonnement. La documentation de la Suite SaaS précise aussi qu’une connexion est nécessaire au premier lancement, puis régulièrement après une période d’utilisation hors ligne. Les conditions exactes dépendant de la version et du contrat, elles doivent être vérifiées auprès de PC SOFT avant toute décision.

Le coût des licences n’est qu’une partie de l’équation

La valeur principale d’une application métier historique réside souvent dans ce qu’elle sait faire : calculs tarifaires, contrôles, exceptions, droits, éditions, échanges de fichiers, traitements planifiés et enchaînements validés par des années d’usage. Une partie de ces règles peut n’exister que dans le code ou dans les habitudes des utilisateurs.

Une réécriture mal préparée peut perdre des comportements utiles, introduire des régressions, immobiliser les personnes qui doivent expliquer l’existant et créer un long tunnel avant le premier bénéfice. Le coût d’une migration comprend donc l’analyse, les tests, la reprise de données, la conduite du changement, la coexistence temporaire et l’exploitation — pas seulement le développement du nouveau code.

Avant de choisir une cible, un audit de l’application et du code legacy permet de relier les risques techniques aux usages métier. Il aide à distinguer ce qui doit être remplacé, stabilisé, encapsulé ou simplement documenté.

Pourquoi .NET peut constituer une alternative à WinDev

C# et .NET moderne constituent une cible possible pour construire des applications métier, des services et des API. ASP.NET Core fonctionne sur Windows et Linux, s’intègre aux conteneurs Docker et peut être déployé dans le cloud ou sur une infrastructure privée. L’écosystème facilite aussi l’automatisation des tests, l’intégration continue et le déploiement continu.

• Des API REST pour découpler progressivement les fonctions et connecter des systèmes tiers.

• Des services métier en C# testables indépendamment de l’interface.

• SQL Server ou PostgreSQL selon les contraintes de données, d’exploitation et de licence.

• Une interface React ou Next.js lorsqu’une expérience web multi-écran est pertinente.

• Keycloak ou une autre solution compatible OAuth 2.0 et OpenID Connect pour centraliser l’identité.

• Des pipelines CI/CD et des conteneurs pour rendre les livraisons plus reproductibles.

Dire que « .NET est gratuit » serait pourtant trompeur. Le runtime et le framework .NET sont open source, mais le coût total dépend des outils de développement, de l’hébergement, des bases de données, des composants tiers, de la supervision, du support et des compétences nécessaires. Le bon comparatif porte sur l’architecture complète et sa durée de vie.

Migration WinDev vers .NET : trois stratégies possibles

1. Continuer avec WinDev

Conserver l’application peut être rationnel lorsqu’elle est stable, bien maîtrisée, correctement documentée et qu’elle répond aux besoins futurs. Si l’équipe possède les compétences, que les intégrations restent gérables et que le coût total est acceptable, une migration risquée n’apporte pas forcément de valeur. Des actions ciblées — tests, documentation, supervision ou sécurisation des sauvegardes — peuvent suffire.

2. Réécrire complètement

Une réécriture peut être pertinente lorsque l’architecture actuelle bloque profondément les usages visés, que le périmètre métier est clairement maîtrisé et qu’une transition progressive serait plus complexe qu’un remplacement. Elle permet de repartir sur un modèle cohérent, mais exige un cadrage rigoureux, une stratégie de reprise des données et de solides tests de non-régression.

Le principal risque est la refonte tunnel : l’ancien système continue d’évoluer pendant que le nouveau tente de le rattraper. Plus le projet dure, plus l’écart fonctionnel et le coût de double maintenance augmentent.

3. Moderniser progressivement

La modernisation progressive consiste à remplacer des capacités par étapes tout en laissant temporairement coexister l’ancien et le nouveau système. Elle peut réduire le risque de bascule et produire plus tôt des résultats utiles, mais elle ajoute pendant un temps des interfaces et une complexité d’exploitation qu’il faut assumer.

1. Auditer l’application WinDev existante.

2. Cartographier les fonctions, les données et les dépendances.

3. Identifier les règles métier critiques et leurs propriétaires.

4. Créer des API ou des mécanismes d’échange pour découpler un premier périmètre.

5. Développer de nouveaux modules en .NET et, si nécessaire, une nouvelle interface web.

6. Faire coexister les deux environnements avec une responsabilité claire sur chaque donnée.

7. Remplacer progressivement les briques lorsque leurs critères de validation sont atteints.

Cette stratégie, parfois rapprochée du pattern Strangler Fig, n’est pas automatiquement la meilleure. Elle convient lorsque les frontières fonctionnelles sont suffisamment identifiables, que la coexistence est techniquement possible et que l’entreprise veut éviter une bascule unique. Notre page sur la migration d’application legacy détaille cette logique de trajectoire par lots.

Peut-on convertir automatiquement une application WinDev en C# ?

Réponse courte : une conversion automatique complète et fiable est rarement réaliste pour une application métier.

Des outils d’analyse, des assistants de code ou des scripts peuvent aider à inventorier le projet, documenter certaines procédures et traduire des portions isolées. Ils ne remplacent pas la compréhension de l’architecture, des comportements attendus et des dépendances propres à l’application.

• Le WLangage et les bibliothèques .NET n’ont pas toujours les mêmes concepts ni le même cycle d’exécution.

• Les règles métier peuvent être réparties entre fenêtres, procédures, requêtes, base de données et traitements planifiés.

• Les accès aux données et les transactions doivent être redessinés, pas seulement traduits.

• Les composants, états et impressions peuvent nécessiter des solutions différentes.

• Les interfaces et intégrations doivent être testées sur leurs comportements, y compris les cas limites.

Une migration WinDev vers C# n’est donc généralement pas une traduction ligne par ligne. L’automatisation est utile comme accélérateur sous contrôle humain, pas comme garantie d’équivalence fonctionnelle.

À quoi pourrait ressembler une architecture cible moderne ?

Une cible possible, à adapter au contexte, sépare l’expérience utilisateur, les contrats d’échange et les règles métier :

React / Next.js → API ASP.NET Core → services métier C# → SQL Server ou PostgreSQL → ERP, CRM, WMS et services tiers.

Une couche d’identité telle que Keycloak peut appliquer OAuth 2.0 et OpenID Connect. Des pipelines CI/CD automatisent les contrôles et les déploiements. Docker peut homogénéiser les environnements lorsque cela simplifie réellement l’exploitation.

Ce schéma n’est pas une prescription. Une application de bureau, un monolithe modulaire ou une architecture plus simple peut être préférable. Les microservices ne sont pas un objectif en soi : ils introduisent des coûts de distribution, d’observabilité et d’exploitation qui doivent être justifiés.

Comment préparer une migration WinDev vers .NET ?

1. Inventorier les applications, bibliothèques, composants, traitements, états et tâches planifiées.

2. Identifier les règles métier critiques avec les utilisateurs qui les appliquent au quotidien.

3. Cartographier les données, leurs propriétaires, leur qualité et leurs flux.

4. Mesurer les fonctions réellement utilisées au lieu de reproduire tout l’historique.

5. Analyser les intégrations, les protocoles, les fréquences, les erreurs et les responsabilités.

6. Définir une architecture cible proportionnée aux besoins et aux capacités d’exploitation.

7. Choisir un premier périmètre utile, limité et suffisamment représentatif.

8. Mettre en place des tests de non-régression fonctionnels et des critères de bascule.

9. Migrer par lots si la stratégie progressive est retenue, avec un plan de retour arrière.

Le premier livrable utile n’est pas forcément du code. Il peut s’agir d’une cartographie, d’un registre de risques et d’une comparaison chiffrée des scénarios. Cette base évite de choisir une technologie avant d’avoir compris le problème.

Comment Kodeva peut intervenir ?

Kodeva n’est pas un spécialiste du développement WinDev ni du WLangage. Notre expertise porte sur la modernisation d’applications métier existantes et sur la construction de leur architecture cible avec C#, .NET, ASP.NET Core, React, Next.js et les technologies web modernes.

• Auditer l’existant et relier les risques techniques aux enjeux métier.

• Comprendre les règles de gestion, les données et les dépendances avec le SI.

• Étudier la faisabilité d’un maintien, d’une réécriture ou d’une migration progressive.

• Définir une architecture cible et un premier périmètre mesurable.

• Développer les nouvelles API et applications .NET.

• Construire un frontend React ou Next.js lorsqu’il répond au besoin.

• Intégrer la nouvelle solution aux outils existants et accompagner la coexistence.

• Sécuriser progressivement les tests, les déploiements et la reprise de données.

Les réalisations de logiciels métier sur mesure présentent des exemples de construction et d’évolution d’outils métier. Elles ne constituent pas des références WinDev et ne sont pas présentées comme telles.

FAQ sur la migration WinDev vers .NET

Pourquoi migrer une application WinDev vers .NET ?

Une entreprise peut envisager cette migration pour faciliter de nouvelles intégrations, ouvrir des API, moderniser l’interface, diversifier les compétences ou réduire une contrainte d’architecture. Une évolution de licence peut déclencher l’étude, mais la décision doit reposer sur le coût total, le risque et les besoins métier.

Quel est le coût d’une migration WinDev vers .NET ?

Il n’existe pas de prix universel. Le coût dépend de la taille fonctionnelle réellement utilisée, des règles métier, de la qualité des données, des interfaces, des états, des intégrations, des tests, de la criticité et de la stratégie de bascule. Un audit permet d’établir des scénarios comparables plutôt qu’un montant trompeur.

Peut-on convertir automatiquement du WinDev en C# ?

Certains fragments peuvent être analysés ou traduits avec assistance, mais une application métier ne se réduit pas à sa syntaxe. L’architecture, les données, les composants, les interfaces et les comportements doivent être compris, redessinés et testés.

Faut-il réécrire entièrement une application WinDev ?

Non. Le maintien, la réécriture et la modernisation progressive sont trois options légitimes. Le choix dépend de l’état de l’application, de l’urgence, des frontières fonctionnelles, des capacités de l’équipe et de la possibilité de faire coexister l’ancien et le nouveau.

Peut-on faire fonctionner WinDev et .NET en parallèle pendant une migration ?

Oui, si des échanges fiables peuvent être mis en place par API, base partagée maîtrisée, messages ou fichiers. Il faut définir quel système est responsable de chaque donnée, gérer les erreurs et prévoir la fin de cette coexistence.

.NET est-il une alternative à WinDev ?

Oui, .NET peut servir de socle à une nouvelle architecture métier, notamment avec C#, ASP.NET Core et des frontends web. Ce n’est pas un remplacement automatique : l’effort dépend des fonctions à reconstruire et l’écosystème cible possède lui aussi des coûts d’outillage et d’exploitation.

Combien de temps prend une migration WinDev vers .NET ?

La durée varie selon le périmètre utilisé, les dépendances, la reprise des données, le niveau de tests, la disponibilité des experts métier et la stratégie choisie. Un petit module isolé et une application centrale accumulant quinze ans de règles ne peuvent pas partager une estimation générique.

Décider sur des faits, pas uniquement sur une licence

Vous vous interrogez sur l’avenir d’une application WinDev ? Avant de décider d’une réécriture complète, Kodeva peut analyser l’existant, les dépendances et les règles métier afin de comparer les trajectoires possibles et d’évaluer la pertinence d’une architecture .NET moderne.

Commencez par découvrir notre démarche d’audit de code legacy ou contactez Kodeva pour cadrer votre situation.