Ce document synthétise les stratégies techniques discutées pour préserver la continuité des projets WINDEV / WEBDEV, limiter la dépendance à une version ou à un modèle d’abonnement, et préparer des sorties progressives vers des architectures plus ouvertes. Il privilégie les approches structurantes en entreprise : documentation, extraction, modularisation, API, données, Git, CI et transition vers .NET / SQL.
La meilleure réponse au lock-in est de réduire progressivement la dépendance : sortir la donnée, sortir la logique métier, figer le legacy quand c’est nécessaire, créer des points d’extension contrôlés, puis déplacer les nouveaux développements vers des technologies maîtrisées comme .NET, API REST, SQL Server ou PostgreSQL.
Le tableau place volontairement la comparaison en tête du document. Les charges sont des fourchettes indicatives en jours-homme, à ajuster selon la taille du patrimoine, la qualité des sources, le niveau d’accès au projet et la maturité de l’équipe.
| Stratégie | Objectif | Pré-requis | Faisabilité technique | Charge estimée | Délai réaliste | Impact anti-lock-in | Acceptabilité grand compte / DSI | Limites | Priorité |
|---|---|---|---|---|---|---|---|---|---|
| Mode texte / Git / extraction WLangage | Récupérer, versionner et analyser le patrimoine code. | Projet encore ouvrable ou sources déjà exportées. | Très bonne | 5–20 JH pour mise en place ; 15–40 JH avec analyse outillée. | 1–6 semaines. | Très fort | Très bonne : standard d’ingénierie logicielle. | Ne compile pas sans WINDEV ; zones opaques à ne pas modifier à l’aveugle. | Très haute |
| Export documentation native avec code | Créer un référentiel lisible pour audit, IA, migration et revue. | Projet ouvrable et génération de documentation possible. | Très bonne | 1–8 JH selon packaging et automatisation. | Quelques jours à 2 semaines. | Fort | Très bonne : livrable clair pour DSI/intégrateurs. | Dépend de la qualité de la documentation générée et du périmètre inclus. | Très haute |
| Extraction HFSQL vers SQL Server / PostgreSQL | Sortir la donnée et réduire le verrou principal. | Accès schéma, données, drivers/export, règles d’intégrité. | Bonne | 15–40 JH pour MVP ; 80–180 JH pour migration robuste. | 3–8 semaines MVP ; 3–9 mois programme complet. | Très fort | Très bonne : logique DSI et urbanisation SI. | Mapping types, contraintes, performances, historique, synchronisation. | Très haute |
| API de désencapsulation autour de la base | Exposer les fonctions/données via API hors WINDEV. | Schéma compris, droits, contrats API, stratégie d’intégration. | Bonne | 20–60 JH MVP ; 60–150 JH robuste. | 1–4 mois selon périmètre. | Très fort | Très bonne : architecture maîtrisable. | Risque de logique métier doublonnée si le legacy reste actif. | Très haute |
| Nouveaux modules hors WINDEV : .NET / C# / API REST | Stopper l’aggravation de la dette WLangage. | Contrats d’échange, données accessibles, règles d’intégration. | Très bonne | 20–80 JH pour premiers modules ; variable ensuite. | 4–10 semaines pour un premier module utile. | Très fort | Très bonne : cible moderne et gouvernable. | Intégration UX, droits, cohérence transactionnelle. | Très haute |
| Dernière build extensible avant gel | Compiler une version finale contenant des points d’extension. | Projet encore ouvrable/recompilable dans un environnement de build disponible. | Bonne | 15–30 JH pour shell ; 40–120 JH avec workers/API/logs. | 2–10 semaines. | Fort tactique | Bonne si présenté comme continuité applicative. | Impossible à ajouter après coup si l’EXE n’a aucun hook. | Haute |
| MCU Survival Kit for WINDEV | Créer une couche d’extension par Macro-Codes Utilisateur gouvernés. | Projet ouvrable pour activer/positionner les MCU, ou MCU déjà activés. | Bonne si prévu | POC 3–7 JH ; MVP 12–25 JH ; entreprise 35–70 JH. | 1–6 semaines MVP ; 2–4 mois entreprise. | Moyen à fort tactique | Bonne si gouvernance, logs, profils d’accès et versioning. | Ne remplace pas WINDEV ; dette macro si non contrôlé. | Haute |
LanceAppli vers workers externes | Déléguer traitements, batches, imports/exports vers des exécutables externes. | Point d’appel dans l’application ou dernière build extensible. | Très bonne | POC 2–5 JH ; architecture 20–50 JH. | Quelques jours à 2 mois. | Fort si workers hors WINDEV | Bonne : pattern legacy/wrapper classique. | UX, erreurs, logs, contrats d’échange, sécurité d’exécution. | Haute |
| WEBDEV reverse proxy / remplacement URL par URL | Remplacer progressivement des pages WEBDEV par modules externes. | Contrôle serveur web, routage URL, auth, données/API. | Bonne | POC 5–15 JH ; premier module 20–60 JH ; programme 80–200 JH. | 2–8 semaines POC ; 6–24 mois stratégie complète. | Fort | Très bonne pour applications web. | SSO, session, cohérence navigation, coexistence front/legacy. | Haute |
ChargeWDL comme plugins WINDEV | Charger des bibliothèques WINDEV externes. | EXE prévu pour charger/appeler des WDL ; compatibilité testée. | Moyenne à bonne | POC 3–8 JH ; système plugin 20–60 JH. | 1–8 semaines. | Moyen | Moyenne : reste dans l’écosystème WINDEV. | Compatibilité versions, dépendances, états/fenêtres, HFSQL. | Moyenne |
ExécuteCode / Compile | Gérer de petites règles dynamiques contrôlées. | Moteur de règles embarqué avant gel ; catalogue et tests. | Moyenne | POC 3–10 JH ; gouverné 15–40 JH. | 1–6 semaines. | Moyen tactique | Acceptable seulement très encadré. | Pas une architecture complète ; debug, performance, traçabilité. | Moyenne |
| Transpileur partiel WLangage → C# | Convertir fonctions/classes pures vers C# avec tests. | Code extrait, classification, cas sans IHM ni HFSQL complexe. | Moyenne sur sous-ensemble | MVP 30–60 JH ; robuste 100–200 JH. | 2–4 mois MVP ; 6–12 mois robuste. | Fort sur logique pure | Bonne si limité et vérifié par tests. | Transpileur généraliste non raisonnable ; forte validation humaine. | Moyenne |
| Édition/extraction HTML/CSS/JS WEBDEV | Récupérer le front comme support de migration. | Accès fichiers générés, compréhension du rendu et assets. | Moyenne | 3–15 JH audit/extraction ; variable pour reconstruction. | Quelques jours à plusieurs mois selon refonte. | Moyen | Moyenne : utile pour migration front. | Ne modifie pas la logique serveur ; risque d’écrasement à régénération. | Moyenne |
| Reprise depuis une ancienne source WINDEV saine | Repartir d’une ancienne version ouvrable et la stabiliser. | Source historique WINDEV réelle, base test, dépendances disponibles. | Bonne si source saine | Socle 38–70 JH ; avec réintégration 60–120 JH. | 2–4 mois selon périmètre. | Moyen à fort | Moyenne : projet de reprise legacy. | Ne récupère pas automatiquement les évolutions récentes. | Prudente |
| WINDEV Exit Toolkit / audit de dépendance | Mesurer, classer, prioriser et documenter la sortie progressive. | Accès sources/doc/base ; modèle de scoring ; scripts d’analyse. | Bonne | MVP 30–60 JH ; utile 90–160 JH ; stratégique 200–400 JH. | 6–10 semaines MVP ; 4–18 mois selon ambition. | Très fort | Très bonne : langage DSI/achats. | Outil d’aide à décision, pas migration automatique. | Très haute |
| CI officielle / batch supporté / tests / rapports | Industrialiser les builds et validations sans ouvrir manuellement l’IDE. | Environnement WINDEV/WEBDEV de build disponible, scripts, runners, Git. | Bonne | 5–15 JH POC ; 15–40 JH robuste. | 1–6 semaines. | Moyen | Très bonne : pratique standard. | Automatise le flux de build, mais ne remplace pas l’environnement WINDEV/WEBDEV. | Haute |
Chaque fiche reprend le principe, le vrai bénéfice, les limites et l’impact potentiel sur la dépendance. Les fiches sont ouvertes/fermées localement et restent imprimables.
Principe. Passer les éléments disponibles en format texte, les versionner dans Git, produire des diffs, extraire le code lisible et bâtir un corpus exploitable par des outils d’analyse, de documentation ou de migration.
Ce que cela permet vraiment. Rechercher massivement les dépendances, classifier les procédures, identifier les appels HFSQL ou IHM, préparer une conversion partielle vers C#, documenter l’existant, produire un rapport DSI/achats et limiter le risque de perte de connaissance.
Ce que cela ne permet pas. Cela ne compile pas sans WINDEV/WEBDEV et ne rend pas magiquement toutes les parties internes modifiables. Les zones opaques ou binarisées doivent rester hors modification automatique.
Impact commercial. Très fort à moyen terme : un patrimoine lisible et mesuré réduit la captivité. Le client n’est plus face à une boîte noire, mais face à un portefeuille de modules classables et progressivement extractibles.
Recommandation. À faire immédiatement tant que le projet est ouvrable. C’est l’une des premières mesures de survie.
Principe. Générer une documentation native complète avec code, éléments, procédures, fenêtres, requêtes, états, dépendances et éventuellement statistiques de volumétrie.
Ce que cela permet. Alimenter un RAG, un audit de dépendance, une revue humaine, un moteur de classification et un plan de migration. C’est souvent la source la plus directement exploitable par une équipe qui n’a pas encore industrialisé Git ou l’extraction texte.
Limites. La documentation n’est pas une source compilable et peut masquer certains détails internes. Elle doit être complétée par sources, export base et tests.
Impact sur le pouvoir de négociation. Moyen à fort : la DSI peut chiffrer et objectiver le patrimoine au lieu d’accepter une dépendance floue.
Recommandation. À faire en parallèle du mode texte/Git. Très faible coût, rendement élevé.
Principe. Documenter schéma, fichiers, index, contraintes, volumétrie et relations, puis mettre en place export, réplication ou migration vers un SGBD standard.
Ce que cela permet. Créer des API indépendantes, développer de nouveaux modules hors WINDEV, construire des rapports, préparer un remplacement progressif et réduire la dépendance à l’analyse HFSQL.
Ce que cela ne permet pas. Sortir la donnée ne sort pas automatiquement la logique métier ni les écrans. Il faut traiter les règles enfouies dans le code.
Risques. Types spécifiques, intégrité référentielle implicite, performances, encodage, historique, procédures de migration, cohérence transactionnelle si coexistence legacy/nouveau.
Impact commercial. Très fort : une fois la donnée libérée, l’éditeur perd le verrou le plus lourd. C’est l’une des rares stratégies réellement structurantes pour les grands comptes.
Recommandation. Priorité majeure. À lancer même si le code reste temporairement dans WINDEV.
Principe. Ajouter une API REST ou service métier qui expose progressivement les données et opérations critiques, sans dépendre de l’interface WINDEV.
Ce que cela permet. Nouveaux frontaux, intégration SI, modules mobiles/web, automatisations, migration progressive, supervision et contrats stables.
Limites. Il faut éviter la duplication incohérente des règles métier. L’API doit être versionnée, testée et alignée sur les transactions réelles.
Impact sur le pouvoir de négociation. Très fort à moyen terme : le cœur fonctionnel devient accessible sans acheter plus de postes WINDEV pour chaque besoin.
Recommandation. À combiner avec extraction HFSQL et nouveaux modules .NET/API.
Principe. Décider que toute nouvelle logique métier significative est développée hors WINDEV, idéalement en C#/.NET, API REST, service Windows, worker ou composant web.
Ce que cela permet. Diminuer progressivement la surface WINDEV, réduire le nombre de postes nécessaires, faciliter le recrutement et s’aligner sur les standards d’architecture SI.
Ce que cela ne permet pas. Cela ne remplace pas instantanément l’application existante. Il faut une stratégie d’intégration : base, API, lancement depuis legacy, reverse proxy ou portail.
Impact commercial. Très fort : chaque nouveau module hors WINDEV est une fonctionnalité qui n’accroît plus la dépendance l’éditeur.
Recommandation. Règle de gouvernance immédiate : plus de nouveau métier critique enfermé dans WINDEV sans justification.
Principe. Tant que le projet est encore ouvrable et compilable dans un cadre valide, produire une dernière version contenant menus dynamiques, hooks, appels workers/API, logs, gestion d’erreurs et configuration externe.
Ce que cela permet. Figer le cœur, ajouter des extensions périphériques, déléguer les traitements et gagner du temps pour migrer.
Ce que cela ne permet pas. Si l’application n’a pas été préparée, un EXE fermé ne devient pas extensible après coup. Les fonctions d’extension doivent être appelées par le programme.
Impact commercial. Fort tactique : le client réduit l’urgence de renouvellement et peut négocier avec un plan de continuité.
Recommandation. À faire avant tout gel ou rupture d’accès. C’est une assurance technique.
Principe. Ne pas laisser les MCU devenir du code sauvage. Construire un kit avec points d’extension, dispatcher, catalogue, logs, profils d’accès, versioning, import/export, mode recette et modèles de macros.
Ce que cela permet. Ajouter des règles, validations, petits traitements, appels workers/API et adaptations limitées sans recompiler le cœur, si les MCU ont été activés/prévus.
Ce que cela ne permet pas. Les MCU ne remplacent pas WINDEV : ils ne sont pas faits pour maintenir massivement un ERP, refondre l’IHM ou changer profondément l’analyse.
Risques. Dette macro, manque de tests, sécurité fonctionnelle, dérive de versions, difficulté de debug. À traiter par gouvernance.
Impact commercial. Moyen à fort comme première brique : il donne du temps, réduit certains besoins de maintenance ponctuelle et améliore la négociation.
Recommandation. À proposer rapidement à la communauté comme “kit de survie” avant gel, mais toujours avec un avertissement clair : contrôlé, limité, tracé.
LanceAppli vers workers externesPriorité hautePrincipe. L’application WINDEV lance des programmes externes : worker .NET, CLI, batch, service, import/export, moteur de calcul, génération documentaire.
Ce que cela permet. Déporter des traitements lourds ou nouveaux hors WINDEV, tout en gardant le legacy comme point d’entrée temporaire.
Limites. Ne pas bricoler avec des fichiers temporaires non contrôlés. Prévoir JSON, logs, codes retour, statut, erreurs, timeout, droits et supervision.
Impact commercial. Fort si les workers sont hors écosystème WINDEV : chaque traitement externalisé réduit le besoin de développement WINDEV futur.
Recommandation. Prioritaire dans une dernière build extensible et dans le MCU Survival Kit.
Principe. Placer l’application WEBDEV derrière un reverse proxy ou portail, puis remplacer progressivement certaines routes par des pages ou modules externes.
Ce que cela permet. Strangler pattern : garder le legacy, migrer page par page, développer les nouveaux écrans dans une stack moderne, brancher une API commune.
Limites. Gestion de session, authentification, droits, cohérence navigation, assets, SEO éventuel, monitoring, coexistence legacy/nouveau.
Impact commercial. Fort : les nouveaux développements web ne sont plus captifs de WEBDEV.
Recommandation. À privilégier pour tout patrimoine WEBDEV significatif.
ChargeWDL comme mécanisme de plugins WINDEVPriorité moyennePrincipe. Charger dynamiquement des bibliothèques WDL et appeler des fonctions ou modules prévus pour fonctionner comme plugins.
Ce que cela permet. Modulariser certains traitements dans l’écosystème WINDEV, mettre à jour des briques séparées, isoler des fonctionnalités.
Ce que cela ne permet pas. Cela ne sort pas du lock-in : on reste dans WINDEV, avec compatibilité de versions, runtime, dépendances et limites de packaging.
Impact commercial. Moyen : utile pour gagner du temps, moins puissant que .NET/API/SQL.
Recommandation. À utiliser seulement si l’intégration est simple ou si l’équipe doit rester temporairement en WINDEV.
ExécuteCode / Compile comme moteur de règles contrôléPriorité moyennePrincipe. Ajouter un moteur de règles ou scripts WLangage dynamiques pour calculs, validations ou paramètres métier.
Ce que cela permet. Formules simples, règles évolutives, scripts limités, ajustements métier sans recompiler si le moteur est prévu.
Ce que cela ne permet pas. Ce n’est pas une architecture de remplacement. Il ne faut pas y loger toute l’application.
Risques. Debug difficile, performance, sécurité fonctionnelle, absence de tests, traçabilité et dette invisible.
Recommandation. À réserver aux règles simples, avec catalogue, tests, versioning, droits et logs.
Principe. Extraire les procédures/classes pures, sans IHM et sans accès HFSQL complexe, puis générer du C# candidat avec tests unitaires.
Ce que cela permet. Accélérer la sortie de règles de calcul, transformations, validations et logique métier isolée.
Ce que cela ne permet pas. Convertir les fenêtres, états, champs, événements IHM, analyse HFSQL complète ou tout WLangage métier complexe automatiquement.
Impact commercial. Fort si ciblé : le code métier transféré en C# n’alimente plus la dépendance WINDEV.
Recommandation. À lancer après extraction code et classification. Ne jamais promettre un transpileur généraliste.
Principe. Utiliser les pages HTML/CSS/JS générées comme support d’analyse, de reprise graphique ou de reconstruction frontale.
Ce que cela permet. Comprendre le rendu, récupérer assets/styles, préparer un nouveau front ou corriger temporairement un habillage.
Ce que cela ne permet pas. Modifier proprement la logique serveur WEBDEV. Les modifications manuelles peuvent être écrasées à la prochaine génération.
Recommandation. Utile en migration front et reverse proxy, déconseillé comme méthode de maintenance principale.
Principe. Repartir d’une ancienne application métier version antérieure existante, la nettoyer, stabiliser, compiler et documenter, puis réintégrer seulement quelques fonctions utiles des versions plus récentes.
Ce que cela permet. Obtenir un socle minimal ouvrable et maîtrisable, éviter un conversion massive trop risqué, réduire le périmètre.
Ce que cela ne permet pas. Récupérer automatiquement toutes les évolutions récentes. Cela reste un projet legacy, pas une sortie définitive de WINDEV.
Recommandation. À considérer si une source ancienne saine existe. Moins prioritaire que l’extraction données/API pour une stratégie anti-lock-in globale.
Principe. Créer un outil ou une méthode d’audit qui classe le patrimoine : dépendance IHM, dépendance HFSQL, logique pure, candidats C#, candidats API, risques, coûts et roadmap.
Ce que cela permet. Donner aux développeurs, DSI et achats une vision chiffrée : ce qui peut être figé, extrait, migré, réécrit, externalisé ou maintenu.
Ce que cela ne permet pas. Ce n’est pas une migration automatique ; c’est un accélérateur d’analyse, de décision et de négociation.
Impact commercial. Très fort : il transforme le lock-in perçu en plan de sortie mesurable.
Recommandation. À positionner publiquement comme kit de continuité et de désengagement progressif, pas comme convertisseur miracle.
Principe. Utiliser les mécanismes supportés de compilation batch, scripts, rapports, tests et archivage, dans un environnement WINDEV/WEBDEV valide.
Ce que cela permet. Reproductibilité, traçabilité, build de survie, rapports, réduction des erreurs humaines, consolidation Git et documentation.
Ce que cela ne permet pas. Cela ne supprime pas la dépendance à l’outil ; cela professionnalise l’usage existant.
Impact commercial. Moyen : cela réduit l’urgence et le nombre de postes nécessaires, surtout si couplé à extraction/API.
Recommandation. À intégrer à toute stratégie sérieuse de réduction de dépendance.
Dernière build extensible, export documentation, mode texte/Git, MCU Survival Kit, LanceAppli vers workers simples, CI officielle. Ces stratégies ne sortent pas tout de WINDEV, mais elles empêchent d’être bloqué sans visibilité.
Extraction HFSQL, API de désencapsulation, nouveaux modules .NET/API, reverse proxy WEBDEV, classification du code et extraction de logique métier pure. L’objectif est que chaque nouveau besoin ne crée plus de dette WINDEV.
WINDEV Exit Toolkit, migration données complète, refonte progressive, transpilation partielle testée, remplacement URL par URL côté WEBDEV et retrait graduel du legacy. C’est là que le lock-in baisse réellement.
Export documentation avec code, mode texte/Git, inventaire HFSQL, scoring de dépendance, POC workers externes. Ce sont les premiers gestes à réaliser avant tout projet lourd.
Maintenance massive par macros, édition manuelle du HTML WEBDEV généré, ExécuteCode utilisé comme application parallèle, ChargeWDL présenté comme sortie du lock-in, reprise depuis une source antérieure sans source saine. Ces pistes peuvent dépanner, mais doivent rester encadrées.
Inventorier projets, versions, fenêtres, états, requêtes, procédures, composants, base HFSQL, dépendances, outils de build et risques d’accès. Sortie attendue : cartographie de dépendance et priorités.
Exporter la documentation avec code, activer le mode texte si possible, archiver les sources, installer Git, définir une convention de dépôt, produire les premiers rapports de recherche et diff.
Si le projet est encore ouvrable : ajouter routeur, hooks, configuration externe, logs, appels API, LanceAppli, éventuellement MCU gouvernés, puis produire une build stable archivée.
Déployer un cadre contrôlé : catalogue de points d’extension, droits, logs, versions, exemples de macros, workers .NET ou CLI, contrats JSON et supervision.
Documenter schéma/volumétrie, exporter ou répliquer les données, créer API de désencapsulation, stabiliser les contrats et éviter la duplication incontrôlée de règles métier.
Faire sortir les nouvelles fonctionnalités : .NET/API pour gestion et traitements, reverse proxy pour WEBDEV, remplacement URL par URL, intégration SSO et données.
Classer ce qui reste en legacy assumé, migrer la logique pure, retirer les modules remplacés, diminuer le nombre de postes nécessaires et piloter les arbitrages par coût/risque.
Les grands comptes adopteront plus facilement les stratégies qui ressemblent à de l’urbanisation SI qu’à du bricolage applicatif. Les plus crédibles en comité architecture sont : mode texte/Git, documentation avec code, extraction HFSQL, API, nouveaux modules .NET, reverse proxy WEBDEV, CI officielle et audit de dépendance.
Réduction des développements WINDEV futurs, centralisation de quelques postes de build et de maintenance, externalisation des traitements via workers/API, développement de nouveaux modules hors WINDEV, gel du legacy et sortie progressive de la donnée.
Un rapport de dépendance chiffré, une roadmap de sortie, une dernière build extensible, une API hors WINDEV, une base migrable et des modules déjà développés hors écosystème WINDEV / WEBDEV.
MCU seuls, ExécuteCode, ChargeWDL, édition HTML généré ou reprise depuis une ancienne source27. Ces briques peuvent aider, mais ne suppriment pas la dépendance sans stratégie données/API/code.
0–3 mois : signal et POC. 3–6 mois : premiers effets de continuité. 6–12 mois : réduction de l’urgence de renouvellement. 12–24 mois : impact visible sur le nombre de postes et les remises. 18–36 mois : baisse structurante du pouvoir de négociation si données/API/.NET sont en place.
Mode texte/Git, export documentation avec code, extraction HFSQL, API externe, nouveaux modules hors WINDEV, WINDEV Exit Toolkit. Ce sont les stratégies qui changent durablement le rapport de dépendance.
Dernière build extensible, MCU Survival Kit, LanceAppli vers workers externes, WEBDEV reverse proxy, CI officielle. Ces stratégies donnent du temps, structurent la transition et évitent le blocage brutal.
ChargeWDL, ExécuteCode/Compile, transpileur partiel WLangage → C#, extraction HTML/CSS/JS WEBDEV. À utiliser sur des périmètres limités, avec tests et gouvernance.
Reprise depuis une ancienne source27, maintenance massive par macros, édition manuelle du HTML WEBDEV généré. Ces pistes peuvent avoir du sens dans certains contextes, mais ne doivent pas être présentées comme stratégie principale.
La stratégie la plus solide consiste à combiner plusieurs briques : documenter et exporter le patrimoine, sortir la donnée, figer le legacy lorsque nécessaire, ajouter des points d’extension gouvernés, déplacer les nouveaux développements vers .NET/API/SQL, et remplacer progressivement les modules WEBDEV par routes ou services externes. Le lock-in baisse quand le patrimoine devient lisible, mesurable et substituable, pas quand on cherche une solution unique ou magique.
Document imprimé depuis le fichier HTML autonome. Les estimations sont des ordres de grandeur issus de l’analyse du scénario ; elles doivent être recalées par audit réel.