Votre logiciel Visual FoxPro. Enfin prêt pour l’avenir.

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).

C’est la situation la plus fréquente. Notre démarche inclut un audit de données approfondi. Nous savons migrer les champs `Memo`, gérer correctement les `codepages` (jeux de caractères comme Windows-1252) et préserver la sémantique de la commande `SET DELETED`. Nous assainissons les structures héritées et les transférons dans un schéma SQL relationnel propre, avec une gestion correcte des `NULL` plutôt que des chaînes vides. Cela résout aussi les anciens problèmes de `codepage` et permet un vrai support `UTF-8`, par exemple pour l’allemand ou le chinois. Nous maîtrisons également les pièges des intégrations `ODBC`, comme les problèmes liés à `varchar(max)`, et les traitons pendant la refonte du modèle de données.

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.

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.

Bien au contraire. C’est un avantage. Nous connaissons parfaitement ces architectures. Notre expertise couvre explicitement les migrations d’applications construites sur des frameworks VFP établis comme Visual Extend (VFX) ou des bibliothèques de composants comme Acodey (de ProLib). Nous comprenons leur fonctionnement, y compris leurs parties "magiques", et savons transférer cette logique spécifique dans des structures modernes indépendantes du framework.

Ces commandes modifient en profondeur la manière dont VFP compare les données, par exemple `SET EXACT` pour les comparaisons de chaînes. Nous en maîtrisons la sémantique en détail. Pendant l’audit, nous identifions ces commandes `SET` et en préservons le comportement grâce à des tests « Golden Master », c’est-à-dire des cas automatisés qui valident le comportement historique en 1:1 afin que le nouveau système reste fonctionnellement identique.

Excellente question. C’est l’un des enjeux majeurs d’une migration web. La gestion de conflits de `TABLEUPDATE()` dans VFP, lorsqu’un autre utilisateur a modifié l’enregistrement, doit être modélisée explicitement dans le nouveau système. Sur le web, cela se traite généralement via un contrôle de concurrence : au chargement, l’enregistrement reçoit un jeton invisible (ETag). Lors de l’enregistrement, le serveur vérifie si ce jeton est toujours identique. Si ce n’est plus le cas, parce qu’un autre utilisateur a enregistré avant, l’opération est bloquée et l’utilisateur est informé. Cela crée un processus sûr et transparent pour éviter les conflits de données.

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.

Oui, tout à fait. Nous connaissons très bien l’écosystème VFP. Les modèles de base issus de `xCase` constituent une source précieuse pour la rétro-ingénierie. Nous sommes familiers des outils de reporting comme `Stonefield Query`, des générateurs de codes-barres comme `FoxBarcode` et des stratégies de traitement des DBF chiffrés avec `Cryptor`. Nous connaissons aussi les contrôles ActiveX courants d’éditeurs comme `DBITech` ou `Codejock`, ainsi que leurs équivalents web modernes.

C’est un sujet très fréquent. L’automatisation Office depuis VFP est lente et impose une installation locale d’Office. Nous migrons cette logique vers des solutions serveur performantes, par exemple des bibliothèques .NET, capables de générer des fichiers Word ou Excel *sans* nécessiter Office sur le serveur ni sur le poste client. Pour l’analyse et le reporting, nous connectons souvent des outils self-service comme PowerBI directement à la nouvelle base de données.

Nous traitons ce sujet avec le plus grand sérieux. La souveraineté des données reste entièrement entre vos mains. Vous choisissez si la nouvelle solution fonctionne on-premise ou dans le cloud, y compris la région souhaitée, par exemple Francfort. Nous vous conseillons dans le respect du RGPD, masquons les données de test et, si nécessaire, accompagnons la mise en place d’exigences de conformité comme les audit logs, le KYC ou l’AML. Bien entendu, nous disposons également d’une assurance responsabilité civile pour projets IT couvrant les risques liés à la migration des données.

C’est une préoccupation légitime. L’écart entre des DBF locales et la latence web est bien réel. Nous traitons la performance via (1) une architecture API propre plutôt qu’un accès direct à la base, (2) une mise en cache intelligente des données de référence et (3) l’optimisation des requêtes et des index. Avec vous, nous définissons des objectifs de performance (KPI) pour les écrans et les processus métier les plus critiques.