FAQ migration PC SOFT

Rester sur une version existante reste techniquement possible tant qu'elle fonctionne et que votre contrat de maintenance le permet. Le risque n'est pas immédiat, il est cumulatif : moins de correctifs de sécurité dans la durée, un vivier de développeurs qui se réduit, et une dépendance croissante à un éditeur unique. C'est un choix défendable à court terme, à réévaluer régulièrement plutôt qu'à ignorer.

Selon les conditions commerciales annoncées publiquement par l'éditeur, l'accès à certains outils de développement et de mise à jour serait conditionné à la continuité du paiement de l'abonnement. Ce point mérite d'être vérifié précisément dans votre propre contrat avant toute décision, car les conditions exactes dépendent de la formule souscrite et peuvent évoluer.

Dans la plupart des trajectoires par paliers, oui : tant qu'une partie du parc reste en production sous WinDev, WebDev ou HFSQL, l'accès aux outils et à la maintenance reste nécessaire pour cette partie. Le coût de licence diminue généralement au fur et à mesure que les modules migrés sortent du périmètre PC SOFT.

Oui, c'est même l'approche la plus fréquente. Un parc applicatif se migre rarement d'un bloc : on isole d'abord l'application la plus exposée ou la plus stratégique, on la migre, puis on traite les suivantes selon leur propre calendrier. Les deux environnements cohabitent le temps nécessaire.

En règle générale, le code applicatif écrit par vos équipes ou par un prestataire pour votre compte vous appartient, selon les termes du contrat de développement ou de prestation. Ce qui appartient à l'éditeur, ce sont l'environnement de développement WinDev et le moteur HFSQL, pas le code métier que vous avez fait écrire avec ces outils. Une vérification contractuelle reste recommandée au cas par cas.

Oui, dans la mesure où le code vous appartient. Un tiers peut l'auditer, le documenter et proposer une trajectoire de migration sans autorisation particulière de l'éditeur. Ce qui peut nécessiter une licence, en revanche, c'est l'accès à l'environnement WinDev pour ouvrir et faire tourner le projet source pendant la durée de l'audit.

C'est la situation la plus fréquente à l'origine d'un audit : un audit de code permet de reconstituer la logique métier directement à partir du code source et de la base de données, sans dépendre de la mémoire d'une personne. Le résultat est plus lent à produire qu'avec le développeur d'origine, mais reste fiable.

La réécriture totale est rarement le bon calcul. La plupart des trajectoires que nous accompagnons combinent la reprise de certaines logiques métier telles quelles, la réécriture ciblée des parties les plus dépendantes de WinDev, et l'abandon pur et simple des fonctions devenues obsolètes. La proportion se décide après audit, pas avant.

Oui, c'est une opération courante dans ce type de migration. HFSQL expose ses données via des connecteurs standard (ODBC notamment), ce qui permet d'extraire les tables et de les recréer dans un moteur relationnel ouvert comme PostgreSQL. Le point d'attention n'est pas l'export lui-même, mais la reprise des règles métier portées par des procédures stockées, des triggers ou du code applicatif.

Dans la grande majorité des trajectoires que nous concevons, oui. Sortir des données de HFSQL en premier ouvre toutes les options techniques pour la suite, alors que l'inverse enferme le projet dans les contraintes du moteur d'origine. Ce n'est pas une règle absolue, mais c'est le sens dans lequel va la grande majorité des dossiers.

Ils ne se copient pas automatiquement d'un moteur à l'autre : chaque règle portée par une procédure stockée ou un trigger doit être identifiée pendant l'audit, puis réécrite dans le langage de la base cible ou déplacée dans la couche applicative. C'est un travail d'inventaire avant d'être un travail technique.

Cela dépend du volume et des usages, pas d'une règle générale : un moteur relationnel ouvert bien indexé et bien dimensionné se comporte au moins aussi bien que HFSQL sur des charges comparables, avec en plus un choix plus large d'outils de supervision et d'optimisation. Aucun gain chiffré ne peut être promis sans mesure sur votre propre base.

Oui, c'est une configuration transitoire fréquente. L'application WinDev continue de fonctionner pendant que la base cible reçoit les données en parallèle (double écriture ou synchronisation régulière), le temps que la nouvelle interface soit prête à prendre le relais. Cela réduit le risque de coupure au moment de la bascule finale.

Aucune ne le remplace terme à terme, car WinDev fusionne interface, logique et données dans un seul environnement que les stacks modernes séparent. Le choix se fait selon votre contexte : .NET ou Java pour rester proche d'une logique desktop ou d'un système critique, PHP ou React pour une cible web, WordPress pour un site ou un portail de contenu.

Non, rester en desktop est un choix légitime quand les utilisateurs travaillent sur des postes fixes et que l'accès à distance n'est pas un besoin réel. Le passage au web se justifie surtout par un besoin d'ouverture : clients, partenaires ou équipes distantes qui doivent accéder à l'outil sans installation locale.

Non, pas de façon fiable et autonome. L'IA aide à accélérer certaines étapes, comme le transcodage assisté de portions de code ou la documentation automatique de fonctions existantes, mais chaque conversion nécessite une revue humaine pour valider la logique métier. Un WLangage converti sans relecture expose à des régressions silencieuses.

Elle se remplace généralement par une application native ou par un framework cross-plateforme comme Flutter ou React Native, selon les contraintes d'accès matériel (scanner, capteurs, mode hors ligne) identifiées pendant l'audit. C'est souvent le composant migré en dernier, une fois le cœur métier stabilisé sur sa nouvelle cible.

.NET convient bien à une application de gestion desktop proche de l'existant, sur un parc Windows. Java s'impose plutôt sur un système critique à fort volume ou fortement intégré au reste du système d'information. PHP (Symfony, Laravel) reste pertinent pour une application de gestion web à budget maîtrisé. Le choix se confirme en audit, pas sur catalogue.

Cela dépend directement de l'ampleur du parc. Une application ciblée et bien circonscrite se migre généralement en quelques mois. Un ERP multi-modules ou un parc de plusieurs applications s'étale plutôt sur douze à dix-huit mois, migré par paliers. Aucune durée ne se fixe sérieusement avant l'audit initial, qui objective le périmètre réel.

Une implication est nécessaire, mais rarement à temps plein. Les profils métier qui connaissent les usages réels de l'application (pas seulement sa documentation) doivent rester disponibles ponctuellement, en particulier pendant l'audit et les phases de validation de chaque palier. Le reste du travail technique est porté par l'équipe de migration.

C'est même l'approche que nous recommandons systématiquement. Une migration en un seul bloc concentre tout le risque sur un seul instant de bascule. Une migration par paliers réversibles permet de valider chaque étape en conditions réelles avant de passer à la suivante, et de revenir en arrière si besoin.

La formation fait partie de la trajectoire, pas d'un service annexe : elle s'organise en parallèle des dernières phases de migration, une fois l'interface cible stabilisée, pour que les équipes prennent en main l'outil définitif plutôt qu'une version encore provisoire.

Oui, c'est même une condition que nous posons par défaut sur les systèmes qui font tourner une activité en continu. Cela passe par une double écriture temporaire entre l'ancien et le nouveau système, ou par une migration module par module qui laisse le reste du parc fonctionner normalement pendant la transition.

Chaque palier fait l'objet d'une phase de validation en conditions réelles avant d'être considéré comme acquis. Une régression détectée à ce stade se corrige avant de passer à l'étape suivante, ce qui évite d'accumuler des anomalies sur plusieurs paliers en même temps.

Le système précédent reste généralement disponible pendant une période de sécurité après chaque bascule, précisément pour ce cas de figure. Un bug identifié se corrige rapidement sur le nouveau système ; si sa gravité l'exige, un retour temporaire à l'ancien système reste possible tant que ce filet de sécurité n'a pas été levé.

Par une bascule progressive plutôt que brutale : les premiers utilisateurs migrés servent de retour d'expérience avant d'élargir à l'ensemble du parc, accompagnés d'une documentation courte et de sessions de prise en main ciblées sur ce qui change réellement dans leurs usages quotidiens.