Votre application WINDEVmérite-t-elle unenouvelle génération ?

Il n'existe pas d'outil qui convertisse fidèlement une application WINDEV en application React. Le code généré automatiquement reproduirait la structure technique de l'existant sans reprendre ses règles métier ni son ergonomie. Nous procédons donc par analyse : lecture du code, identification des traitements, reprise des règles de gestion, puis redéveloppement module par module avec validation des utilisateurs.

Non. Dans de nombreux cas, une modernisation progressive suffit : nouvelles interfaces web, exposition de certaines fonctions par API, reprise des modules les plus contraignants. Le cœur WINDEV peut rester en production pendant cette période. La réécriture complète se justifie surtout lorsque l'application est arrivée en limite d'évolution.

Oui. Il est fréquent de conserver HFSQL pendant la phase de transition, le temps que les nouveaux modules web soient validés. Les accès aux données peuvent être encapsulés dans des services afin de préparer la bascule vers une autre base sans réécrire l'ensemble des traitements.

La démarche commence par l'analyse du modèle de données : tables, index, contraintes, types de champs et règles d'intégrité. Le schéma est ensuite transposé dans PostgreSQL, les données sont reprises par lots, puis contrôlées (volumes, cohérence, cas particuliers). Une phase de fonctionnement en double permet de valider les traitements avant la bascule définitive.

Oui, c'est même la situation la plus courante lors d'une migration progressive. Les deux applications partagent alors les mêmes données ou échangent via des API. Cette cohabitation demande une attention particulière aux règles de gestion et aux droits d'accès, mais elle réduit fortement le risque de rupture d'activité.

Il n'existe pas de prix standard. Le coût dépend du périmètre fonctionnel, de la qualité du code existant, du volume et de la complexité des données, du nombre d'interfaces avec d'autres logiciels et de la stratégie retenue. L'audit permet précisément de chiffrer les scénarios envisageables et de les comparer au coût de maintien de l'existant.

Un premier module web peut être mis en service en quelques semaines. Une modernisation progressive s'étale généralement sur plusieurs mois à plusieurs années selon le périmètre, tandis qu'une réécriture complète se planifie par lots successifs. Les délais sont estimés à l'issue de la cartographie fonctionnelle.

La cartographie fonctionnelle recense l'ensemble des traitements, y compris ceux qui ne sont pas documentés. Chaque fonctionnalité est qualifiée : essentielle, secondaire, obsolète ou à repenser. Les développements sont ensuite validés par lots avec les utilisateurs de référence, ce qui permet de détecter rapidement un écart.

Oui, et c'est souvent recommandé. Un module pilote permet de valider l'ergonomie, l'architecture, les performances et la méthode de travail avant d'engager le reste du projet. Il fournit également une base concrète pour affiner le budget et le planning.

Oui. La reprise d'applications existantes fait partie de notre activité, y compris lorsque la documentation est partielle ou que les développeurs d'origine ne sont plus disponibles. L'audit sert alors aussi à reconstituer la connaissance du logiciel.

C'est un objectif fréquent chez les éditeurs. Le passage en SaaS suppose de traiter l'accès web, la gestion des comptes et des droits, l'isolation des données entre clients, la facturation éventuelle et l'exploitation. Ces sujets sont étudiés pendant l'audit, car ils influencent fortement l'architecture cible.

Par des reprises par lots, des scripts rejouables, des contrôles automatisés de volumes et de cohérence, une comparaison entre l'ancien et le nouveau système, et une procédure de retour arrière. Les données sensibles sont identifiées en amont afin de respecter les obligations de confidentialité.