Dans beaucoup d'entreprises, un logiciel de gestion développé il y a vingt ou trente ans tourne encore tous les jours. Écrit en Clipper, dBase, FoxPro, Access ou 4D, il fait son travail… jusqu'au jour où il ne le fait plus. Voici les risques à connaître, et une méthode pour moderniser sans perdre des années d'historique.

Pourquoi ces logiciels durent si longtemps

Ils ont souvent été très bien conçus : rapides, adaptés au métier, développés par quelqu'un qui connaissait l'entreprise. Ils contiennent des années de clients, de dossiers, d'interventions et de règles de calcul. Les remplacer fait peur, et tant que ça marche, on repousse.

Les risques qui augmentent chaque année

Le matériel et le système

Beaucoup de ces logiciels ne tournent que sur une vieille version de Windows, un émulateur DOS ou un poste « à ne surtout pas toucher ». Une panne de ce poste, et l'activité s'arrête.

Les compétences

Le développeur d'origine est parfois parti à la retraite. Plus personne ne sait modifier le logiciel, ni même expliquer certaines règles cachées.

Les données

Les fichiers (DBF pour Clipper et dBase, MDB pour Access) utilisent des formats et des encodages anciens. Les sauvegardes sont souvent manuelles, quand elles existent.

L'usage

Pas d'accès à distance, pas de smartphone, pas d'export simple, impressions capricieuses : l'outil freine de plus en plus le quotidien.

La méthode pour en sortir sans tout perdre

  1. Faire l'inventaire : récupérer une copie des fichiers de données et documenter leur structure (tables, champs, liens).
  2. Convertir les données vers une base moderne (MySQL, MariaDB…) avec un outil de conversion contrôlé : correspondance des champs, conversion des encodages (les accents des vieux fichiers DOS sont un classique), contrôles de cohérence.
  3. Reconstruire l'outil en application web, en reprenant les écrans utiles et en profitant de l'occasion pour simplifier.
  4. Faire tourner les deux en parallèle le temps de valider le nouveau.
  5. Basculer, former les équipes, et archiver l'ancien logiciel.

Un exemple réel

Pour une entreprise de maintenance industrielle installée à Mimet, je développe un outil qui lit les fichiers DBF et les index de leur logiciel Clipper historique pour les transférer vers une base SQL moderne. C'est la première étape indispensable avant de moderniser leurs outils. Le détail est dans l'étude de cas SAFM-Localicsol.

Faut-il avoir le code source ?

Non. Le plus important, ce sont les fichiers de données. Le code source aide à comprendre certaines règles de calcul, mais on peut s'en passer en observant le logiciel en fonctionnement et en interrogeant ses utilisateurs.

Le bon moment pour agir

Le meilleur moment, c'est pendant que l'ancien logiciel fonctionne encore : on peut tout récupérer sereinement et basculer sans interruption. Après une panne, on travaille dans l'urgence. Si votre activité repose sur un tel outil, faites au moins une copie de ses fichiers de données dès aujourd'hui.

Pour aller plus loin, la page moderniser un logiciel Clipper, Access ou dBase détaille la démarche, et vous pouvez m'en parler pour un premier avis.

ClipperdBaseAccessmigration de donnéesmodernisation
Partager