Logistique & terrain
Sauvetage d’une « boîte noire »
Point de départ : FoxPro DOS (échanges de données via clés USB), back-office VFP 6 et code source partiellement perdu. Grâce à la décompilation et à la rétro-ingénierie, nous avons reconstitué la logique métier et l’avons transformée en une solution web (Angular) et mobile (iOS/Android) moderne pour 5 000 clients finaux.
Les questions qui reviennent précisément dans ce type de projet
Les points suivants sont régulièrement décisifs pour ce type de système ancien - et la raison pour laquelle une migration échoue rarement à cause du langage de programmation.
Que faire des appels `DECLARE DLL`, de `VFPX` ou de `wwipstuff` ?
C’est un volet central de l’"archéologie". Nous analysons les appels `DECLARE DLL` cryptiques pour en comprendre le rôle et les traduire vers des équivalents modernes en .NET ou via API. Des bibliothèques comme `wwipstuff` de Rick Strahl (West Wind Internet Protocols), le framework `West Wind Web Connection (WWWC)` ou les nombreuses extensions `VFPX` font partie de notre quotidien. Nous avons par exemple déjà intégré des fonctionnalités .NET dans des systèmes VFP historiques via `wwDotnetBridge` et savons migrer cette logique de façon native.
Qu’en est-il des batchs nocturnes et de l’usage de Terminal Server ?
Faire tourner VFP sur Terminal Server est un contournement classique pour lui donner une apparence "web". La nouvelle application web rend ce détour inutile. Nous analysons les batchs nocturnes et les migrons vers des processus serveur modernes, comme des fonctions serverless, des jobs conteneurisés de type Kubernetes CronJobs ou des workflows pilotés par API.
Comment fonctionne techniquement la coexistence en parallèle ?
Nous nous appuyons sur le "Strangler (Fig) Pattern", autrement dit un remplacement itératif. C’est une phase sensible. Plutôt que d’opter pour un "dual-write" risqué, où les données sont écrites simultanément à deux endroits, nous privilégions des mécanismes plus sûrs comme des API intermédiaires ou des événements synchrones. Ainsi, tant que l’ancien système tourne encore, la nouvelle application peut renvoyer ses données vers la base historique via une interface contrôlée. Le risque de divergence des données diminue nettement et la transition en production devient beaucoup plus sûre.
Que deviennent nos rapports FRX et nos contrôles ActiveX/OCX ?
C’est un sujet critique. Nous migrons les rapports (`FRX/LBX`), souvent produits via des outils comme `XFRX`, `FoxyPreviewer` ou des pilotes PDF tels que `Amyuni`, vers des plateformes de reporting modernes. Nous recommandons et utilisons des plateformes commerciales éprouvées, comme DevExpress ou Telerik, pour lesquelles nous détenons des licences et bénéficions d’un support éditeur complet. Si un client privilégie explicitement une alternative open source, nous pouvons aussi l’implémenter, en explicitant clairement les compromis possibles, par exemple des lacunes de support ou des fonctionnalités manquantes. Les contrôles `ActiveX/OCX` obsolètes, notamment côté interface, sont remplacés par des composants web modernes, et nous profitons de cette étape pour améliorer l’UI/UX et l’accessibilité (a11y).
Cela ressemble à votre système ?
Alors accordons-y 45 minutes. Sans engagement, sans frais, et avec une évaluation honnête à la fin - y compris si celle-ci consiste à d’abord sécuriser l’exploitation existante.
Demander un entretien stratégique