Facturation & finance
Sauvetage et gain de performance
Nous avons repris une migration en échec (DOS → VFP9/VFX). Grâce à une solide expertise VFP, notamment une optimisation Rushmore ciblée des requêtes, nous avons ramené le temps d’exécution d’un processus critique de facturation de 20 heures à 4 heures. Après la migration complète de l’application et le passage à PostgreSQL, ce temps est descendu à moins de 15 minutes.
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.
Nos DBF sont un chaos (codepages, indicateur "Deleted", memos)...
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.
Et les spécificités VFP comme `SET ANSI`/`EXACT` ?
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.
Notre application utilise un framework VFP (Acodey, Visual Extend). Est-ce un problème ?
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.
Comment garantissez-vous les performances sur le web ? VFP est très rapide en local.
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.
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