Migration PC SOFT : reprendre le contrôle de vos applications métier

Si vous êtes sur cette page, vous avez probablement reçu un devis de renouvellement, lu une annonce sur la tarification à la session, ou vu partir un développeur que personne ne remplace. La question n'est pas « WinDev est-il un bon outil ? », il l'a été et le reste pour beaucoup d'usages. La question est : votre entreprise contrôle-t-elle encore sa trajectoire applicative, ou la subit-elle ?

Cette page fait le tri entre ce qui est confirmé, ce qui est annoncé et ce qui relève de la rumeur, puis déroule un cadre de décision complet : les 5 scénarios possibles, ce qui se migre et comment, et ce que cela coûte. Pas un argumentaire de vente : un cadre pour décider, y compris de rester.

Ce qui a réellement changé chez PC SOFT

Trois évolutions structurantes se sont enchaînées. Fin 2024, la cession de PC SOFT à Two Squared France II, structure liée au groupe Volaris (Constellation Software), apparaît dans les registres publics, repérée par des développeurs avant toute annonce ; elle se confirme publiquement en 2025. Dans le même mouvement, le modèle commercial bascule de la licence perpétuelle à dongle vers l'abonnement annuel sur les nouvelles versions. Enfin, en 2026, une tarification à la session utilisateur est annoncée pour les applications déployées à partir de la génération 2026 des outils.

Tout ce qui n'est pas confirmé officiellement est traité ici au conditionnel, et le reste jusqu'à publication d'un barème. Ce tableau est révisé à chaque évolution publique du dossier ; la date de mise à jour figure en haut de page.

Ce qu'il faut en retenir pour décider : le changement n'est pas d'abord tarifaire, il est contractuel. La licence perpétuelle donnait une position de repli, continuer à utiliser et maintenir ses versions sans payer davantage ; l'abonnement la supprime sur les nouvelles versions, et la tarification à la session déplacerait l'assiette du coût vers l'usage de vos applications déployées. Chaque entreprise doit donc requalifier sa situation : qu'est-ce que je détiens vraiment, qu'est-ce qui peut évoluer sans mon accord, et quelle est ma marge de manœuvre ? Les trois pages dédiées de ce dossier détaillent chaque volet, faits et sources à l'appui.

Faut-il vraiment migrer ? les 5 scénarios

Assumons-le clairement : les scénarios 1 et 2 sont de bonnes réponses pour une partie des lecteurs de cette page. Dans une part significative de nos audits, la recommandation finale est de ne pas migrer maintenant, mais de sécuriser : documenter les traitements critiques, constituer des tests, réduire le risque humain. La migration est une décision de gestion, pas un réflexe.

Ces cinq scénarios ne sont d'ailleurs pas exclusifs : ils se combinent et se séquencent. Le parcours le plus fréquent commence par le scénario 3, la sortie de la base de données, parce qu'il est borné, vérifiable, et qu'il sécurise tous les futurs possibles : une fois vos données dans un moteur SQL standard, geler devient moins risqué, rester devient un choix libre, et migrer devient plus simple. C'est le premier pas sans regret de toutes les trajectoires.

Le choix entre ces scénarios dépend de quatre paramètres mesurables : votre exposition tarifaire réelle (combien de postes, déployés où), votre risque humain (combien de personnes maîtrisent le code, pour combien de temps encore), l'état technique du parc (dette, documentation, tests), et votre horizon métier (l'application sert-elle encore la stratégie dans cinq ans ?). L'audit mesure les quatre ; le diagnostic en ligne en donne une première lecture en dix questions.

Migrer quoi : cartographie de votre parc

« Migrer WinDev » recouvre en réalité cinq chantiers distincts, qui ne se traitent ni ensemble ni dans n'importe quel ordre. WINDEV : les applications desktop, dont on reprend les règles métier et dont on reconstruit les interfaces. WEBDEV : les sites et applications web, souvent basculés vers WordPress ou une stack web standard avec un plan de préservation du référencement. WINDEV Mobile : les applications de terrain, réécrites en Flutter ou React Native avec leur logique de synchronisation. HFSQL : la base de données propriétaire, à extraire vers PostgreSQL, SQL Server ou MySQL, chantier fondateur de toute trajectoire. WLangage : le code lui-même, dont la valeur réelle, les règles métier, se documente puis se transpose avec l'aide de l'IA, jamais par conversion automatique.

Un point d'expérience : la reprise de données est systématiquement plus complexe que la reprise de code. Le code se réécrit ; les données, elles, doivent traverser sans perte ni altération, avec vingt ans d'historique et de cas particuliers. C'est le premier poste que nous chiffrons en audit.

Vers quelle technologie ?

Il n'y a pas de réponse unique, et méfiez-vous de qui en donne une avant d'avoir vu votre parc. Le choix se construit sur quatre questions : desktop ou web ? quelle volumétrie et combien d'utilisateurs ? des contraintes hors ligne ? quelle équipe pour maintenir ensuite ? Selon les réponses, la cible s'appelle .NET pour rester au plus près du desktop de gestion, React ou PHP pour passer au web, Java pour les SI critiques, Flutter pour la mobilité, WordPress pour les sites issus de WebDev. Notre page dédiée aux technologies cibles déroule la grille de décision complète, famille par famille.

• Application de gestion interne sur postes fixes : .NET / C# est la transition la plus douce, même paradigme, vivier de développeurs large.
• Besoin d'ouvrir l'accès à des clients, des sites distants ou du télétravail : cible web, avec un cœur métier exposé en API et un front moderne.
• Éditeur de logiciel : trajectoire SaaS multi-tenant, les nouveaux clients signent sur la nouvelle plateforme pendant que le parc installé migre par vagues.
• Applications de terrain (inventaire, tournées, atelier) : Flutter ou React Native, avec une vraie spécification du mode hors ligne.
• Sites et portails WebDev : WordPress ou Symfony selon la part de contenu et de métier, avec plan de redirections SEO systématique.

Dans tous les cas, un invariant : la base de données d'abord. Quelle que soit la cible applicative, vos données doivent sortir du format propriétaire HFSQL vers PostgreSQL, SQL Server ou MySQL. Ce chantier conditionne tous les autres et se mène sans toucher aux applications dans un premier temps.

Une précision d'honnêteté sur ce parc : tout ne mérite pas de migrer. L'audit révèle régulièrement des pans entiers de code mort, des fenêtres jamais appelées, des états que plus personne n'imprime. Les identifier avant de chiffrer évite de payer la migration de fonctions que personne n'utilise : sur des applications de vingt ans, l'économie n'est pas marginale.

Notre méthode en 4 temps

• Audit : cinq jours ouvrés, six axes d'analyse, un diagnostic chiffré avec trois scénarios comparés et une trajectoire recommandée. Gratuit et sans engagement : c'est notre façon de commencer la relation par la preuve.
• Trajectoire : le découpage en briques, leur ordre de passage, les jalons de décision où vous restez maître du rythme et du budget.
• Migration progressive : cohabitation de l'ancien et du nouveau, bascule par modules ou par populations, retour arrière possible à chaque palier. Jamais de big bang.
• TMA : l'existant reste maintenu pendant toute la transition, correctif et réglementaire compris, pour que l'activité ne s'arrête jamais.

Notre point différenciant technique : l'usage industrialisé de l'IA pour cartographier le code WLangage non documenté, en extraire les règles métier et assister le transcodage, toujours sous revue humaine. Cela ne rend pas la migration automatique ; cela change son économie, en déplaçant l'effort humain de la lecture fastidieuse vers les décisions d'ingénierie.

Budget et délais

Les ordres de grandeur honnêtes se formulent en durée : un chantier ciblé (sortir la base, basculer un site WebDev) se compte en semaines ; la migration d'une application de gestion se compte en mois, par briques ; une trajectoire complète de parc ou une transformation SaaS d'éditeur se planifie en années, précisément parce qu'elle avance sans arrêter l'activité. Côté budget, cinq facteurs font varier le prix du simple au triple : volumétrie réelle du code, état de la base, exigence d'interface, nombre d'interfaces avec le SI, disponibilité de la connaissance métier. Toute fourchette annoncée sans avoir mesuré ces cinq facteurs est un argument commercial, pas un chiffrage : le nôtre sort de l'audit, en cinq jours, scénario par scénario.

Le budget se raisonne toujours face au coût du statu quo projeté à trois et cinq ans : évolution du modèle de licence, prime de rareté sur les compétences, dette technique qui renchérit chaque évolution. C'est la comparaison de ces deux courbes, établie dans l'axe contractuel de l'audit, qui dit si et quand migrer est rationnel pour votre situation, pas une conviction technologique.

Un mot sur le rythme enfin : la migration progressive étale la dépense au fil des briques livrées, et chaque jalon est une occasion de poursuivre, de ralentir ou de marquer une pause sans perdre l'acquis. C'est l'inverse du projet forfaitaire monolithique dont on ne sort qu'à la fin.

Cas clients

Trois trajectoires types, anonymisées et représentatives des dossiers que nous instruisons, illustrent la méthode de bout en bout : un éditeur qui bascule son logiciel métier vers le SaaS en trois ans sans perdre un client ; un ERP industriel migré module par module pendant que la production continue ; un site WebDev refondu sous WordPress avec son référencement préservé. Chacune détaille le contexte de départ, les choix d'arbitrage et les invariants qui font réussir ce type de chantier.

FAQ

Transparence enfin : Smartshift n'est ni affilié, ni partenaire, ni concurrent de PC SOFT. Nous ne vendons pas d'outil concurrent ; nous accompagnons des entreprises qui décident de leur trajectoire applicative, et notre recommandation, dans une part significative des dossiers, est de ne pas migrer maintenant.