Retour d'expérience : migrer une application WinDev vers Ruby on Rails, sans écrire une ligne de code

Dans nos deux derniers articles, nous avons fait le point sur la nouvelle tarification PCSOFT de juin 2026 et ses conséquences pour les éditeurs et développeurs WinDev, puis sur la migration de WinDev vers l’open source avec l’aide de l’IA. Beaucoup d’entre vous nous ont posé la même question : « Concrètement, ça donne quoi ? Et pourquoi Ruby on Rails plutôt que C#, PHP ou Delphi ? »

Cet article est donc un retour d’expérience concret : la migration réussie d’une application métier développée en WinDev vers une application web développée en Ruby on Rails, entièrement pilotée par l’agent IA Claude Code. Nous verrons pourquoi ce choix nous paraît le plus pertinent pour un développeur WinDev, puis nous le comparerons aux autres alternatives : C#/.NET (Windows et Web), Laravel/PHP et Delphi (VCL ou Web). Enfin, nous détaillerons une stratégie de migration des données en deux temps, d’abord en accédant directement à HFSQL via ODBC, puis en basculant sur PostgreSQL.

Le contexte du projet

L’application de départ est une application WinDev classique : une base HFSQL Client/Serveur, plusieurs dizaines de fenêtres de saisie et de consultation, des états imprimés, des traitements batch, des imports/exports et des documents (PDF, images, fichiers Office) stockés sur un serveur de fichiers Windows.

Les objectifs étaient clairs :

• sortir de la dépendance à PCSOFT et de l’incertitude tarifaire ;
• passer à une application web accessible depuis n’importe quel poste, sans installation ;
• conserver l’accès aux données existantes pendant toute la durée de la migration ;
• garder l’accès aux documents stockés sur le réseau de l’entreprise ;
• obtenir un code propre, versionné, testé et maintenable dans la durée.

Résultat : une application Rails en production, fonctionnellement équivalente, plus rapide à faire évoluer, et sans qu’aucune ligne de code n’ait été écrite à la main. Tout a été décrit en français à Claude Code, relu, testé et validé.

Pourquoi Ruby on Rails quand on vient de WinDev ?

On l’oublie souvent, mais WinDev et Ruby on Rails partagent une même philosophie : la productivité avant tout. Pour un développeur WinDev, le dépaysement est beaucoup moins grand qu’on pourrait le croire.

Les points communs avec WinDev

Un framework complet, « tout-en-un ». WinDev, c’est un environnement qui fournit tout : accès aux données, fenêtres, états, gestion des erreurs, déploiement. Rails, c’est exactement la même promesse côté web : accès aux données (Active Record), écrans (vues et formulaires), envoi d’e-mails (Action Mailer), tâches de fond (Active Job), gestion des fichiers (Active Storage), temps réel (Action Cable), authentification, internationalisation… Tout est prévu, tout est intégré, et tout suit les mêmes conventions.

Une bibliothèque très complète. Le développeur WinDev est habitué aux milliers de fonctions WLangage disponibles « out of the box ». Ruby et Rails offrent l’équivalent avec une bibliothèque standard très riche, complétée par des dizaines de milliers de « gems » (bibliothèques) open source : génération de PDF, lecture/écriture Excel, signature électronique, appels d’API REST et SOAP, génération de factures électroniques, etc.

Un langage interprété. Comme le WLangage, Ruby est un langage interprété. Pas de longue phase de compilation : on modifie, on rafraîchit, on voit le résultat. Le cycle « modifier / tester » est aussi court que le célèbre GO de WinDev.

Une visualisation immédiate dans le navigateur. En développement, l’application tourne localement et s’affiche dans le navigateur. Chaque modification apportée par Claude Code est visible instantanément, à la manière du test d’une fenêtre sous WinDev. On teste, on demande une correction, on rafraîchit.

La sécurité intégrée. Là où WinDev gère pour vous beaucoup d’aspects techniques, Rails protège nativement contre les attaques les plus courantes : injections SQL (requêtes paramétrées par Active Record), failles XSS (échappement automatique dans les vues), CSRF (jetons de formulaires), paramètres non autorisés (strong parameters), secrets chiffrés (credentials), politique de sécurité du contenu (CSP). Depuis Rails 8, les nouveaux projets intègrent aussi par défaut l’analyseur de sécurité Brakeman et un générateur d’authentification. Et pour une application métier, on peut aller encore plus loin en ne la rendant accessible qu’à travers un VPN comme Tailscale (voir plus bas).

Un déploiement simple, piloté par Claude Code. Le déploiement d’une application WinDev (setup, store privé, mises à jour réseau) est un point fort reconnu. Avec Rails, on retrouve cette simplicité, avec en plus l’agent qui fait le travail : installation du serveur (Ubuntu, Nginx, Puma, PostgreSQL), certificats TLS, services systemd, sauvegardes, ou déploiement par conteneurs avec Kamal, intégré par défaut à Rails 8. On décrit l’infrastructure cible, Claude Code exécute les commandes, vérifie et documente.

Les avantages par rapport à WinDev

• Aucune licence, aucune session facturée : Ruby, Rails, PostgreSQL et Linux sont libres et gratuits. Votre modèle économique ne dépend plus de la politique tarifaire d’un éditeur.
• Une application web nativement multi-plateforme : Windows, macOS, Linux, tablettes, smartphones. Aucun déploiement sur les postes clients.
• Des technologies standards : le code produit est lisible par des milliers de développeurs dans le monde, et non par une communauté restreinte.
• Un écosystème vivant : Rails est utilisé par GitHub, Shopify, Basecamp ou GitLab. Les mises à jour de sécurité sont publiées rapidement et documentées publiquement.
• Une IA particulièrement efficace : Ruby on Rails est l’une des stacks que les modèles d’IA maîtrisent le mieux, grâce à ses conventions fortes et à l’énorme quantité de code public disponible. Nous y revenons plus bas.

Développer sans écrire une ligne de code avec Claude Code

Comme expliqué dans notre article précédent, le changement de paradigme est total : on ne dessine plus les fenêtres, on ne tape plus le code. On décrit.

Une session typique ressemble à ceci :

« Reprends la fenêtre FEN_Commande de l’application WinDev (je te fournis la description de ses champs et de ses traitements). Crée l’écran équivalent en Rails : un formulaire de commande avec sélection du client, un tableau de lignes éditables, le calcul automatique du total HT, TVA et TTC, et le contrôle de saisie qui empêche une quantité nulle. Ajoute les tests correspondants. »

Claude Code analyse le projet, crée le modèle, le contrôleur, les vues, les tests, lance la suite de tests, corrige ce qui échoue, puis propose un résumé des modifications. On vérifie dans le navigateur, on demande des ajustements, et on valide.

Pour reprendre l’existant, nous avons fourni à l’agent les exports de l’analyse HFSQL, le code WLangage des traitements importants (exporté en texte) et des captures d’écran des fenêtres. L’IA est parfaitement capable de lire du WLangage et d’en extraire les règles métier.

La rigueur du code

« Sans écrire de code » ne veut pas dire « sans rigueur ». C’est même l’inverse. Rails impose des conventions strictes (où se trouve chaque fichier, comment nommer les tables, les modèles, les contrôleurs), et nous avons ajouté des règles explicites dans le fichier CLAUDE.md du projet, que l’agent lit à chaque session :

• toujours écrire les tests avant ou avec chaque fonctionnalité ;
• faire passer RuboCop (style et qualité) et Brakeman (sécurité) avant chaque commit ;
• ne jamais mettre de logique métier dans les vues ;
• documenter chaque règle métier reprise de WinDev.

Le résultat est un code plus homogène et mieux testé que la plupart des projets écrits à la main.

La gestion des sources avec GitHub

Fini le GDS et ses limites. Le projet est versionné avec Git et hébergé sur GitHub :

• chaque fonctionnalité est développée dans une branche, puis fusionnée après vérification ;
• chaque modification est tracée, commentée et réversible ;
• GitHub Actions exécute automatiquement les tests, RuboCop et Brakeman à chaque envoi (Rails 8 génère d’ailleurs ce fichier de CI par défaut) ;
• Dependabot signale les bibliothèques à mettre à jour et les failles connues.

Claude Code gère lui-même les commits, les branches et les messages, en langage naturel : « Crée une branche pour la gestion des avoirs, développe-la, et fais un commit quand tous les tests passent. »

Accéder aux documents sur un serveur grâce à WSL

C’est un point souvent sous-estimé lors d’une migration : une application métier WinDev manipule énormément de documents stockés sur le réseau de l’entreprise (bons de livraison scannés, PDF de factures, photos, plans, fichiers Excel…). Une application web hébergée « dans le cloud » perd cet accès direct.

Notre solution : déployer l’application Rails dans WSL (Windows Subsystem for Linux) sur un serveur Windows de l’entreprise. On obtient le meilleur des deux mondes :

• l’application tourne dans un véritable environnement Linux (Ubuntu), l’environnement naturel de Ruby on Rails ;
• elle accède directement aux disques Windows (/mnt/c, /mnt/d…) et aux partages réseau montés dans WSL, donc à tous les documents de l’entreprise, quel que soit leur type ;
• elle reste dans le réseau local, au plus près du serveur HFSQL existant et du serveur de fichiers ;
• pas besoin d’acheter un serveur Linux supplémentaire.

Le développement se fait lui aussi dans WSL sur le poste du développeur, avec Claude Code. L’environnement de développement et celui de production sont donc identiques, ce qui évite les mauvaises surprises lors de la mise en production. Et c’est Claude Code qui a configuré l’ensemble : installation de Ruby, de PostgreSQL, montage des partages, démarrage automatique des services, ouverture des ports et reverse proxy.

Sécuriser l’accès avec un VPN : Tailscale

Une application métier n’a pas vocation à être visible de tout Internet. Plutôt que d’exposer l’application Rails publiquement (avec tous les risques que cela comporte : scans automatisés, tentatives d’intrusion, attaques par force brute), nous avons fait le choix de la rendre accessible uniquement à travers un VPN, en l’occurrence Tailscale.

Le principe est simple :

• Tailscale crée un réseau privé chiffré (basé sur WireGuard) entre le serveur et les appareils autorisés, où qu’ils se trouvent : au bureau, en télétravail, en déplacement ;
• l’application n’a aucun port ouvert sur Internet : pour un attaquant extérieur, elle n’existe tout simplement pas ;
• chaque utilisateur se connecte avec son compte (Google, Microsoft, etc.), et l’administrateur décide précisément qui accède à quoi grâce aux règles d’accès (ACL) ;
• pas de configuration de routeur, pas de redirection de ports, pas de serveur VPN à maintenir ;
• la révocation d’un appareil perdu ou d’un collaborateur qui quitte l’entreprise se fait en un clic.

Cette protection réseau vient s’ajouter à la sécurité applicative de Rails (authentification, protections CSRF, XSS, injections SQL…) : c’est une défense en profondeur, à la fois simple et très robuste.

Une application accessible sur tous les appareils

Tailscale est disponible sur Windows, macOS, Linux, iOS et Android. Une fois Tailscale installé sur l’appareil, l’application métier est accessible depuis un PC, une tablette ou un smartphone, simplement depuis le navigateur, sans rien installer d’autre.

Et c’est là un autre atout majeur de Rails par rapport à WinDev : il est très facile d’adapter les pages aux différents appareils. Là où WinDev impose souvent de développer une application WinDev Mobile distincte pour les tablettes et les téléphones, une application web Rails est nativement « responsive » : les écrans s’adaptent automatiquement à la taille de l’écran. Il suffit de le demander à Claude Code :

« Adapte l’écran de consultation des commandes pour une utilisation sur smartphone : affiche les commandes sous forme de cartes plutôt qu’en tableau, et place les boutons d’action en bas de l’écran. »

Une seule application, un seul code, pour tous les matériels. Rails permet même de transformer l’application en PWA (Progressive Web App), installable sur l’écran d’accueil d’une tablette ou d’un mobile comme une application native.

Comparatif des alternatives pour migrer une application WinDev

Ruby on Rails n’est pas la seule option. Voici comment se positionnent les principales alternatives, dans le contexte précis d’une migration pilotée par Claude Code. Les notes reflètent notre expérience et notre analyse ; elles ne constituent pas un benchmark scientifique.

Les solutions comparées

• Ruby on Rails : application web, framework complet, open source.
• C#/.NET pour Windows : WinForms ou WPF, application desktop Windows, la plus proche d’une application WinDev en termes d’usage.
• C#/.NET pour le Web : ASP.NET Core (MVC, Razor Pages ou Blazor).
• Laravel/PHP : le framework PHP le plus populaire, philosophie très proche de Rails.
• Delphi VCL : application desktop Windows, approche RAD avec éditeur de fiches, la plus proche de WinDev dans l’esprit.
• Delphi Web : Delphi avec des frameworks web tiers (TMS WEB Core, UniGUI, IntraWeb…).

Tableau de synthèse

Notation de ★ (faible) à ★★★★★ (excellent).

Ruby on Rails et C#/.NET

Critère	Ruby on Rails	C#/.NET Windows	C#/.NET Web
Efficacité de Claude Code / consommation de tokens	★★★★★	★★★	★★★★
Maintenabilité avec Claude Code	★★★★★	★★★	★★★★
Sécurité et mises à jour des bibliothèques	★★★★★	★★★★	★★★★★
Contrôle de la qualité du code	★★★★★	★★★★	★★★★★
Tests de non-régression	★★★★★	★★★	★★★★
Open source	★★★★★ (MIT)	★★★★ (.NET MIT, Windows requis)	★★★★★ (MIT)
Accès HFSQL via ODBC	★★★★	★★★★★	★★★★ (Windows) / ★★ (Linux)
Accès PostgreSQL et bases open source	★★★★★	★★★★★	★★★★★
Coût des outils	Gratuit	Gratuit à payant	Gratuit à payant

Laravel et Delphi

Critère	Laravel/PHP	Delphi VCL	Delphi Web
Efficacité de Claude Code / consommation de tokens	★★★★★	★★	★★
Maintenabilité avec Claude Code	★★★★	★★	★★
Sécurité et mises à jour des bibliothèques	★★★★	★★★	★★★
Contrôle de la qualité du code	★★★★	★★★	★★★
Tests de non-régression	★★★★★	★★	★★
Open source	★★★★★ (MIT)	★ (propriétaire)	★ (propriétaire)
Accès HFSQL via ODBC	★★	★★★★★	★★★★
Accès PostgreSQL et bases open source	★★★★★	★★★★	★★★★
Coût des outils	Gratuit	Payant	Payant

Utilisation de Claude Code et consommation de tokens

Un agent IA « paie » en tokens tout ce qu’il lit et tout ce qu’il écrit. Plus un langage est verbeux et plus un projet est dispersé, plus chaque intervention coûte cher et plus le contexte de l’agent se remplit vite.

• Ruby on Rails : Ruby est un langage très concis, et les conventions de Rails font que l’agent sait immédiatement où chercher (le modèle Client est dans app/models/client.rb, son contrôleur dans app/controllers/clients_controller.rb…). Il lit moins de fichiers, écrit moins de lignes, et se trompe moins. C’est, dans notre expérience, la stack la plus économique en tokens.
• Laravel/PHP : très proche de Rails sur ce point, grâce à des conventions fortes. PHP est un peu plus verbeux que Ruby, mais l’écart est faible.
• C#/.NET Web : C# est plus verbeux (types, interfaces, injection de dépendances, fichiers de configuration), ce qui augmente la consommation. Les modèles maîtrisent toutefois très bien l’écosystème.
• C#/.NET Windows : aux contraintes du C# s’ajoutent les fichiers générés par le concepteur visuel (.Designer.cs en WinForms, XAML en WPF), longs et coûteux à lire et à modifier. Et l’agent ne « voit » pas les fenêtres : il faut lui décrire ou lui montrer les problèmes d’affichage.
• Delphi (VCL et Web) : les fiches .dfm, le code Pascal plus verbeux, et surtout une quantité de code public bien moindre rendent l’agent nettement moins efficace. Il faut davantage d’allers-retours, donc davantage de tokens. Les frameworks web Delphi, moins répandus encore, accentuent ce phénomène.

Facilité de maintenance avec Claude Code

La vraie question n’est pas « l’IA peut-elle créer l’application ? », mais « pourra-t-elle la faire évoluer dans trois ans ? ».

• Rails et Laravel offrent une structure prévisible : n’importe quel agent (ou développeur) reprend un projet sans effort. Les tests automatisés servent de filet de sécurité à chaque modification.
• .NET Web est très maintenable, à condition de fixer l’architecture dès le départ dans les consignes de l’agent, car l’écosystème laisse beaucoup de liberté (et donc de variantes).
• .NET Windows et Delphi souffrent de la même limite que WinDev : une grande partie de l’application est dans des fenêtres conçues visuellement, que l’agent manipule moins bien que du code pur.

Sécurité et mises à jour des bibliothèques

• Rails : correctifs de sécurité publiés régulièrement et annoncés publiquement, Brakeman intégré, bundle audit pour détecter les gems vulnérables, Dependabot sur GitHub. Claude Code peut effectuer une montée de version en lançant les tests à chaque étape.
• .NET : Microsoft publie des correctifs mensuels et la commande dotnet list package --vulnerable liste les paquets NuGet vulnérables. Attention au cycle de support : chaque version de .NET a une durée de vie limitée (versions LTS de trois ans).
• Laravel : composer audit et des versions à support défini. PHP lui-même doit être maintenu à jour sur le serveur.
• Delphi : les mises à jour dépendent d’Embarcadero et de l’abonnement, et de nombreux composants tiers sont commerciaux. On retrouve une dépendance éditeur comparable à celle de PCSOFT.

Contrôle de la qualité du code

• Rails : RuboCop (avec la configuration « omakase » générée par défaut depuis Rails 8) et Brakeman, exécutés automatiquement par Claude Code et par la CI GitHub.
• .NET : excellents analyseurs Roslyn intégrés au compilateur, dotnet format, typage strict qui détecte beaucoup d’erreurs à la compilation. C’est le point fort de C#.
• Laravel : PHPStan/Larastan pour l’analyse statique, Laravel Pint pour le style.
• Delphi : outils d’analyse moins nombreux et souvent payants.

Tests de non-régression

C’est le point décisif pour une migration : il faut prouver que la nouvelle application se comporte comme l’ancienne, et continuer à le prouver à chaque évolution.

• Rails a été conçu autour des tests : tests de modèles, de contrôleurs, et tests système qui pilotent un vrai navigateur (clic, saisie, vérification d’affichage). Claude Code les écrit et les exécute naturellement, à chaque modification.
• Laravel est au même niveau (PHPUnit, Pest, Laravel Dusk pour le navigateur).
• .NET Web dispose de xUnit/NUnit et de Playwright pour les tests de navigateur, très efficaces mais plus longs à mettre en place.
• .NET Windows et Delphi VCL : les tests unitaires de la logique sont possibles, mais les tests automatisés des interfaces desktop restent complexes et fragiles. C’est exactement le problème que l’on rencontre déjà avec WinDev.

Open source ou non

• Ruby on Rails, Laravel et .NET sont open source sous licence MIT. Pour .NET Windows, le runtime est libre mais WinForms/WPF imposent Windows, et l’IDE Visual Studio est gratuit en édition Community sous conditions, payant au-delà (les alternatives VS Code ou Rider existent).
• Delphi est propriétaire. L’édition Community est gratuite mais limitée aux structures réalisant moins de 5 000 dollars de chiffre d’affaires annuel ; au-delà, une licence payante est obligatoire. Quitter WinDev pour Delphi, c’est changer d’éditeur, pas sortir de la dépendance.

Accès aux données : ODBC sur HFSQL et bases open source

PCSOFT fournit un driver ODBC HFSQL (Classic et Client/Serveur), en lecture et en écriture, pour Windows et pour Linux. Un point de vigilance important : sous Linux, le driver repose sur iODBC et non sur unixODBC, le gestionnaire le plus répandu. Une version unixODBC est réclamée par la communauté depuis 2019 sur le blog de PCSOFT, sans suite à ce jour.

• Ruby on Rails : la gem ruby-odbc (maintenue, dernière version en 2026) permet l’accès à HFSQL, idéalement via la bibliothèque Sequel qui fournit une couche d’accès propre au-dessus d’ODBC. Sur notre projet, le driver ODBC HFSQL fonctionne parfaitement avec Ruby on Rails. Il a simplement fallu une recompilation spécifique d’iODBC pour le serveur, et c’est bien évidemment Claude Code qui s’en est chargé : téléchargement des sources, compilation, configuration des sources de données, compilation de la gem contre cette version d’iODBC et tests de connexion. Depuis, l’accès fonctionne sans aucun problème. Pour PostgreSQL, Rails offre un support natif de premier ordre.
• C#/.NET Windows : System.Data.Odbc sous Windows fonctionne parfaitement avec le driver HFSQL. C’est le scénario le plus simple.
• C#/.NET Web : excellent si le serveur est sous Windows/IIS ; sous Linux, System.Data.Odbc s’appuie sur unixODBC, ce qui pose problème avec le driver HFSQL. Pour PostgreSQL, le connecteur Npgsql et Entity Framework Core sont excellents.
• Laravel/PHP : PDO_ODBC fonctionne sous Windows ; sous Linux, l’usage du driver HFSQL nécessite de recompiler PHP avec le support iODBC, et des développeurs rapportent des difficultés. C’est l’option la plus délicate pour un accès direct à HFSQL.
• Delphi : FireDAC dispose d’un pont ODBC qui fonctionne très bien sous Windows avec le driver HFSQL, et de connecteurs natifs performants pour PostgreSQL.

La migration des données : une stratégie en deux temps

Dans notre article précédent, nous recommandions de migrer d’abord la base HFSQL vers PostgreSQL, puis de réécrire l’application. Avec Ruby on Rails, une autre séquence est possible, et elle s’est révélée très confortable sur ce projet : réécrire d’abord, migrer les données ensuite.

Étape 1 : la nouvelle application lit les données HFSQL via ODBC

Pendant la phase de réécriture, l’application Rails accède directement à la base HFSQL de production via le driver ODBC :

• l’application WinDev continue de fonctionner normalement, les utilisateurs ne sont pas impactés ;
• la nouvelle application est développée et testée sur les vraies données, avec tous leurs cas particuliers ;
• les utilisateurs peuvent comparer les deux applications côte à côte ;
• on peut même mettre en production certains modules en consultation (tableaux de bord, recherches, éditions) avant la bascule complète.

Techniquement, Claude Code isole l’accès HFSQL dans une couche dédiée (un module de lecture basé sur Sequel et ruby-odbc), de façon à ce que le reste de l’application ne dépende pas de la base sous-jacente. Il suffit de configurer une source de données ODBC pointant vers le serveur HFSQL (port 4900 par défaut).

Retour d’expérience : cela fonctionne parfaitement. La seule difficulté a été la recompilation d’iODBC spécifiquement pour le serveur, une opération entièrement réalisée par Claude Code. Une fois cette étape passée, l’application Rails lit les données HFSQL de manière fiable et performante.

Par comparaison, cette approche est un peu plus immédiate en C#/.NET ou en Delphi sous Windows, où l’ODBC HFSQL est « chez lui », mais ces solutions n’apportent pas les autres avantages de Rails. Elle est en revanche plus laborieuse avec PHP, qui nécessite de recompiler PHP lui-même, et avec .NET sous Linux, qui s’appuie sur unixODBC. Avec Rails, elle est parfaitement opérationnelle, surtout avec un déploiement sous WSL sur un serveur Windows proche du serveur HFSQL.

Étape 2 : migration des données vers PostgreSQL

Une fois l’application validée, on migre les données vers PostgreSQL. Deux options :

1. L’outil de migration en WinDev, décrit dans notre article précédent, qui connaît parfaitement HFSQL ;
2. Des tâches de migration en Ruby (tâches Rake), écrites par Claude Code, qui lisent HFSQL via ODBC et écrivent dans PostgreSQL en passant par les modèles Rails. Avantage majeur : les règles de validation de la nouvelle application s’appliquent dès l’import, et chaque enregistrement rejeté est journalisé avec la raison du rejet.

Nous avons retenu la seconde option : la migration est rejouable autant de fois que nécessaire (sur une copie de la base) jusqu’à obtenir zéro anomalie, puis exécutée une dernière fois le jour de la bascule.

Étape 3 : la bascule

Le jour J, on arrête l’application WinDev, on exécute la migration finale, on bascule la configuration de l’application Rails vers PostgreSQL. Grâce à l’isolation de la couche d’accès aux données et aux tests de non-régression, la bascule tient en quelques heures. L’application WinDev reste disponible en lecture seule le temps nécessaire, par précaution.

Bilan de l’expérience

Ce qui a fonctionné :

• la productivité : Claude Code produit en quelques heures ce qui demandait des jours de développement ;
• la qualité : code homogène, testé, analysé, versionné, documenté ;
• la continuité : grâce à l’ODBC, aucune interruption de service pendant la migration ;
• les coûts : zéro licence, zéro session facturée, un serveur existant réutilisé grâce à WSL ;
• la sécurité et la mobilité : aucune exposition sur Internet grâce à Tailscale, et une application utilisable sur PC, tablette et smartphone.

Les points de vigilance :

• l’IA ne remplace pas la connaissance métier : il faut savoir décrire précisément ce que fait l’application existante, et valider avec les utilisateurs ;
• l’accès ODBC à HFSQL sous Linux demande une recompilation d’iODBC pour le serveur : une étape technique, mais que Claude Code a menée de bout en bout, et qui fonctionne parfaitement ;
• les états imprimés WinDev doivent être repensés (génération PDF), ce qui est l’occasion de les moderniser ;
• il faut garder la rigueur : branches, tests, revues, consignes claires à l’agent.

Vous souhaitez migrer votre application WinDev vers Ruby on Rails ?

Chez SEALOG, nous développons en WinDev, WebDev et WinDev Mobile depuis de nombreuses années. Nous connaissons parfaitement HFSQL, le WLangage et les contraintes des applications métier. Nous maîtrisons aussi Ruby on Rails, PostgreSQL, Linux, WSL et le développement assisté par IA avec Claude Code.

Nous vous proposons de vous accompagner à chaque étape :

• audit de votre application WinDev et estimation de la migration ;
• mise en place de l’environnement (WSL, GitHub, Claude Code, serveur) et de l’accès sécurisé par VPN Tailscale ;
• accès aux données HFSQL via ODBC depuis la nouvelle application ;
• réécriture de l’application en Ruby on Rails, module par module ;
• migration des données vers PostgreSQL et bascule ;
• formation de vos équipes au développement avec Claude Code, pour que vous restiez autonomes.

Que vous soyez éditeur de logiciels, développeur indépendant ou entreprise utilisatrice, contactez-nous pour en parler : fgirardeau@sealog.info

Et si vous avez déjà entamé une migration, partagez votre expérience en commentaire !