Trois trajectoires types de migration PC SOFT

Les trois parcours ci-dessous sont des trajectoires types, anonymisées et représentatives des dossiers que nous instruisons. Ils illustrent la méthode, pas des références nommées. Aucun montant, aucun résultat chiffré et aucun témoignage ne sont attribués à un client identifiable : ce que nous décrivons, ce sont des contextes fréquents, des choix de trajectoire et les raisons qui les expliquent.

Un éditeur ISV passe en SaaS

Contexte type : un éditeur de logiciel de gestion métier (facturation, planification ou suivi d'activité), vendu sous licence perpétuelle à des clients qui l'installent en desktop sur leur propre parc. L'application est développée en WinDev depuis plus de dix ans, avec une base HFSQL classic hébergée chez chaque client.

Problème rencontré : les prospects récents demandent un accès web ou mobile, parfois multi-utilisateurs à distance, que l'architecture desktop ne permet pas nativement. Les concurrents plus récents, nativement web, gagnent des appels d'offres sur ce seul critère. En interne, recruter des développeurs WinDev devient plus difficile d'une année sur l'autre.

Trajectoire retenue : un audit du code et de la base existante pour cartographier les modules réellement utilisés (1 à 2 mois). Un découplage du cœur métier derrière une API, pour que la logique ne dépende plus d'une seule interface (3 à 4 mois). Une reconstruction de l'interface en web sur la cible choisie, menée en parallèle du produit desktop existant (4 à 6 mois). Une bascule progressive des clients historiques par cohortes, le desktop restant disponible jusqu'à ce que chaque cohorte ait validé son passage.

Facteurs de réussite : impliquer le support client dans la cartographie fonctionnelle, car ce sont eux qui connaissent les usages réels, souvent différents de la documentation. Stabiliser l'API avant de dessiner le moindre écran, pour ne pas reconstruire l'interface deux fois. Garder le desktop existant comme filet de sécurité tant que la nouvelle version n'a pas prouvé sa fiabilité en conditions réelles.

Un ERP industriel migré par modules

Contexte type : un site de production avec un ERP interne développé en WinDev, couvrant la gestion des stocks, l'ordonnancement et le contrôle qualité sur plusieurs ateliers. Le système fonctionne depuis longtemps et reste au cœur de l'activité quotidienne.

Problème rencontré : la connaissance du code repose sur une seule personne, parfois proche de la retraite ou déjà partie, ce qui expose l'entreprise à un risque opérationnel direct. La base HFSQL est volumineuse et alimentée en temps réel par la production, ce qui interdit toute interruption prolongée pour migrer.

Trajectoire retenue : un audit et une cartographie précise des modules et de leurs dépendances (environ 1 mois). Une extraction de la base vers un moteur relationnel ouvert, en double écriture pendant la phase de bascule, pour ne jamais couper la production (2 à 4 mois). Une migration module par module, en commençant par les fonctions les moins critiques comme le suivi de stock, avant de s'attaquer à l'ordonnancement. Chaque palier est validé en conditions réelles avant d'aborder le suivant, sur un total de 12 à 18 mois selon le nombre de modules.

Facteurs de réussite : prioriser les modules par niveau de risque plutôt que par facilité technique, pour traiter en premier ce qui menace le plus la continuité d'activité. Maintenir les deux systèmes en parallèle le temps de valider chaque palier en production. Documenter au fur et à mesure : la dette de documentation est souvent le premier obstacle rencontré sur ce type de parc ancien.

Un site WebDev basculé sous WordPress

Contexte type : un site vitrine et un espace client développés en WebDev, en place depuis plusieurs années, dont la moindre mise à jour de contenu passe par la seule personne technique capable d'intervenir sur le code.

Problème rencontré : l'équipe marketing ne peut publier ni corriger le contenu par elle-même, ce qui ralentit chaque campagne. Le référencement reste fragile, car la structure des URLs et des pages est étroitement liée à l'architecture WebDev. Aucun écosystème de modules ou de plugins ne vient accélérer les évolutions.

Trajectoire retenue : un audit du contenu existant et du maillage interne, avec un plan de redirections construit avant toute reconstruction (environ 1 mois). Une reconstruction du gabarit sous WordPress, en conservant strictement les URLs et la hiérarchie des pages qui portent le référencement (1 à 2 mois). Une migration du contenu et une validation complète des redirections, du plan de site et de l'indexation avant la bascule finale du nom de domaine (2 à 3 mois au total).

Facteurs de réussite : penser les redirections dès le premier jour du projet plutôt qu'en fin de parcours, où elles deviennent un correctif dans l'urgence. Impliquer l'équipe marketing dans le choix des blocs éditoriaux pour qu'elle s'approprie l'outil dès la bascule. Surveiller le trafic organique dans les semaines qui suivent, pour détecter et corriger rapidement toute anomalie d'indexation.

Ce que ces projets ont en commun

Au-delà de leurs contextes différents, ces trois trajectoires types s'appuient sur les mêmes invariants de méthode, ceux que nous appliquons à chaque dossier :

• L'audit d'abord : aucune cible technique n'est choisie avant d'avoir cartographié le code, la base et les usages réels.
• Jamais de big bang : chaque migration avance par paliers réversibles, jamais par une bascule unique et irréversible.
• La réversibilité à chaque palier : pouvoir revenir en arrière à tout moment tant que le palier suivant n'est pas validé en conditions réelles.
• Les données avant le code : sortir de HFSQL est presque toujours le prérequis qui rend les autres trajectoires possibles.

Vous retrouverez ces mêmes principes détaillés dans notre méthode. Si votre parc PC SOFT présente des similitudes avec l'une de ces trajectoires, un premier échange permet généralement d'identifier laquelle s'applique le mieux à votre situation.