1. Accueil
  2. Savoir-faire
  3. Modernisation

VB5 · VB6 · VBA · VB.NET · WinForms

Garder le métier.
Changer ce qui fragilise.

Un ancien logiciel contient souvent des années de décisions utiles. Le moderniser consiste à préserver cette valeur tout en faisant évoluer l’interface, l’architecture et les données.

  • Reprise d’existant
  • Migration web
  • Bases de données
  • Compatibilité
  • Mise en production

Aperçu illustratif · chaque trajectoire dépend de l’existant

Cas concret · en production

FactureReader : de Windows au web, avec ses données.

Cette modernisation a porté simultanément sur l’interface, l’architecture applicative et le moteur de base de données, tout en conservant les règles comptables déjà éprouvées.

Aperçu illustratif de la transformation technique

Modernisation réussie · en production

Ne pas simplement refaire les écrans.

La première version de FactureReader était une application Windows en VB.NET et DevExpress, adossée à SQL Server. Elle a été reconstruite comme application web, avec migration de la base vers PostgreSQL.

  • Préserverles règles comptables et le fonctionnement métier déjà validé.
  • Transformerl’interface et l’architecture pour un usage depuis le navigateur.
  • Migrerles données existantes de SQL Server vers PostgreSQL.
  • Validerla reprise avant le passage de la nouvelle version en production.
Découvrir FactureReader

Trois trajectoires

Moderniser ne signifie pas toujours tout réécrire.

La bonne décision dépend de la criticité, du budget, de la connaissance disponible et du risque accepté pendant la transition.

01

Reprendre et stabiliser

Comprendre une application ancienne, corriger les défauts prioritaires et reprendre sa maintenance sans bouleverser immédiatement les utilisateurs.

Exemples : VB5, Oracle, applications industrielles en production
02

Faire évoluer par étapes

Isoler progressivement les règles, sécuriser les échanges et remplacer uniquement les composants devenus trop fragiles ou incompatibles.

Coexistence temporaire et changements maîtrisés
03

Changer d’architecture

Reconstruire l’application pour un nouvel environnement lorsque les bénéfices justifient la transformation, puis reprendre les données existantes.

Exemple : Windows vers web, SQL Server vers PostgreSQL

Migration des données

Changer de moteur sans imposer une ressaisie.

Une migration applicative ne vaut rien si les informations utiles restent prisonnières de l’ancien système. La reprise doit identifier les structures, préparer les correspondances et contrôler les données transférées.

Cette compétence s’appuie aussi sur une expérience plus ancienne : le développement d’un logiciel dédié au transfert de données entre différents moteurs, notamment d’Oracle vers MySQL.

Schéma de principe · la stratégie est adaptée à chaque base

Le juste périmètre

Savoir ce qu’il faut conserver, remplacer ou abandonner.

Le diagnostic distingue ce qui porte réellement le métier de ce qui n’est qu’une contrainte historique. Cette séparation évite de reproduire les mêmes fragilités dans une technologie plus récente.

CONSERVER

La valeur métier

  • Règles et calculs validés
  • Données et historiques utiles
  • Parcours compris des utilisateurs
REMPLACER

Ce qui fragilise

  • Composants incompatibles
  • Installations trop dépendantes
  • Échanges et contrôles insuffisants
SIMPLIFIER

Ce qui ne sert plus

  • Fonctions abandonnées
  • Doublons et ressaisies
  • Complexité sans usage réel

Méthode

Une transition contrôlée, pas un saut dans le vide.

L’existant reste la référence tant que la nouvelle solution et la reprise des données ne sont pas suffisamment vérifiées.

  1. 01

    Inventorier

    Code, données, dépendances, postes concernés et fonctions réellement utilisées.

  2. 02

    Cartographier

    Règles métier, échanges, calculs, cas particuliers et informations à reprendre.

  3. 03

    Construire

    Avancer par ensembles vérifiables sans attendre une réécriture monolithique.

  4. 04

    Migrer

    Préparer les correspondances et contrôler la reprise sur des données représentatives.

  5. 05

    Basculer

    Mettre en production avec des points de contrôle et une solution de retour adaptée au risque.

Votre ancien logiciel mérite un diagnostic avant une réécriture.

Une démonstration de l’outil, son installation et quelques données représentatives permettent déjà d’identifier les risques et les trajectoires possibles.

Présenter l’existant