01
Ne rien faire pour l'instant
Raisonnable si
Application en fin de vie, peu de postes déployés, horizon court.
Ce que ça coûte vraiment
Rien aujourd'hui. Le risque est de décider dans l'urgence plus tard.
Sortie de WinDev, WebDev et HFSQL
Sortir de WinDev sans casser ce qui tourne autour
Votre application tourne sous WinDev, WebDev ou HFSQL, et la nouvelle redevance pose la question de la suite. Rester, négocier, moderniser ou sortir : nous vous aidons à décider en connaissant le coût de chaque option, y compris celle de ne rien faire.
- Technologies PC SOFT et WLangage depuis 2009
- La cible choisie d'après vos contraintes : web, bureau, mobile ou hors ligne
- Jusqu'à la production : données, échanges, bascule
Là où vous en êtes
Ce qui a changé en juin 2026
Depuis juin 2026, des tarifs de l'ordre de 200 à 290 € HT par session sont rapportés publiquement par des développeurs et par la presse spécialisée. PC SOFT n'a pas publié de grille officielle.
Vous avez peut-être déjà reçu un chiffrage, ou essayé d'en obtenir un. Vous avez peut-être calculé ce que représenterait une redevance appliquée à votre parc installé. Si vous vendez votre logiciel à des clients, vous vous êtes peut-être demandé comment vous alliez le leur annoncer.
La question utile : quelle décision prenez-vous, et sur quelle base ?
Les options
Sept options, et le coût réel de chacune
Le projet réel
Sortir de WinDev ne consiste pas seulement à réécrire du code
Réécrire le code est une partie réelle du projet, et sur certaines applications, avec des règles métier denses accumulées sur quinze ans, c'est une partie lourde. Mais c'est aussi la partie la mieux outillée aujourd'hui. Trois autres chantiers pèsent au moins autant, et sont beaucoup moins visibles au départ.
01
Le code
Des outils de conversion existent, des méthodes complètes sont publiées, un développeur compétent avance beaucoup plus vite qu'il y a trois ans. Réel, mais outillé.
02
Les données
Quinze ans d'exploitation laissent des doublons, des champs remplis différemment selon les époques, des références disparues, des champs mémo et binaires dont personne ne connaît plus le format. Reprendre ces données demande de comprendre ce que chaque cas particulier voulait dire.
03
Les échanges
Écritures envoyées à la comptabilité, commandes reçues d'un portail, CRM synchronisé, fichier déposé chaque nuit pour un partenaire, douchette ou imprimante d'étiquettes pilotée. Chaque flux a été construit à une époque précise, avec des contraintes qui ne sont écrites nulle part.
04
La bascule
Le jour où l'ancien s'arrête, tout ce qui n'avait pas été identifié se manifeste en même temps, et c'est en production que ça se règle, pas en développement.
Nous travaillons sur les quatre. Une application métier n'est jamais seule ; nous modernisons aussi ce qui la relie au reste de votre activité.
Méthode
Notre façon de travailler
Comprendre ce qui existe réellement
Le code, la structure des données, ce qui est effectivement utilisé, les traitements qui s'exécutent et les systèmes connectés. Savoir ce que fait votre application, pas ce qu'elle est censée faire.
Décider quoi faire de chaque partie
Chaque fonction reçoit une décision explicite : conserver, simplifier, améliorer, automatiser ou supprimer. Une application de quinze ans contient toujours des parties qui ne méritent pas d'être migrées.
Choisir la cible ensuite
Web, bureau, mobile, base de données ouverte, fonctionnement hors connexion. La décision dépend de vos contraintes réelles : matériel, mobilité, déploiement, compétences, hébergement. Pas avant d'avoir regardé.
Reconstruire les flux en même temps
Les échanges avec vos autres systèmes sont traités comme une partie du projet, pas comme une reprise de l'existant. Un export de fichier utilisé depuis dix ans faute de mieux n'a pas vocation à être reproduit.
Basculer par périmètres
L'ancien et le nouveau cohabitent le temps nécessaire. Tant qu'un module n'est pas arrêté, le retour en arrière reste possible.
Vous rendre autonome
Le code source et son historique, la description des données et des échanges, les procédures de mise en service, les tests. Une autre équipe compétente doit pouvoir reprendre derrière nous.
Cette méthode est déroulée sur un cas détaillé, de l'inventaire à la bascule, avec un exemple de livrable.
Voir la méthode sur un cas concretVous ne savez pas encore quelle option vous concerne ? C'est précisément l'objet du premier échange. 30 minutes.
Demander un échangePourquoi nous
Ce qui nous distingue
Technologies PC SOFT et WLangage depuis 2009
Des applications métier développées et maintenues dans cet écosystème depuis 2009, dont une application critique reliée à plusieurs systèmes externes que nous faisons évoluer depuis plus de dix ans, bien avant les outils d'assistance actuels. Nous savons lire ce que contient votre application, pas seulement la traduire.
Des systèmes qui n'ont pas été conçus pour se parler
Salesforce et autres CRM, Sage X3, Sage 200 et autres ERP, logiciels comptables, sites marchands, échanges automatiques avec vos partenaires, paiement, signature électronique, AS400, traitements planifiés. Nous concevons et exploitons ce type d'échanges en production, par exemple un outil de liaison qui relie un ERP, une boutique en ligne et plusieurs bases, avec traçabilité, reprise sans doublon et surveillance.
Jusqu'à la production
Déploiement, exploitation, surveillance, diagnostic quand quelque chose ne va pas. La bascule fait partie du projet, pas de l'après-projet.
Quand le web n'est pas la bonne réponse
Applications de bureau, mobiles iOS et Android, fonctionnement hors ligne, pilotage de matériel. Quatre applications mobiles publiées sur les stores, dont certaines fonctionnent sans réseau.
Libres de recommander ce qui vous sert
Aucun partenariat éditeur, aucune technologie à placer : la trajectoire retenue est celle qui vous coûte le moins pour ce qu'elle vous apporte.
La personne qui comprend votre problème reste impliquée
Celui qui analyse votre application suit le projet jusqu'à la mise en service : vous n'avez rien à réexpliquer à une nouvelle équipe. Le projet est découpé en périmètres livrables séparément plutôt qu'en un bloc. Les décisions se prennent directement avec la direction.
Questions fréquentes
Ce qu'on nous demande le plus souvent
Est-ce qu'un outil de conversion automatique ne suffirait pas ?
Parfois, oui. Si votre application est simple, isolée, sans échanges avec d'autres systèmes et sans historique de données compliqué, un outil de conversion peut vous amener assez loin pour un coût très faible.
Ce que ces outils produisent, c'est du code traduit. Ce qu'il vous faut, c'est un système qui tourne : avec vos données reprises, vos échanges rebranchés, vos utilisateurs qui travaillent et vos traitements automatiques qui s'exécutent. L'écart entre les deux est le projet.
Mon développeur pourrait-il le faire lui-même avec l'IA ?
Pour la partie code, souvent oui, et de mieux en mieux. Les outils d'assistance ont réellement changé ce travail, et des équipes l'ont fait en interne.
Ce que ces outils ne font pas à sa place : comprendre pourquoi une règle de gestion a été écrite ainsi en 2013, décider quelles données méritent d'être reprises, et gérer une bascule en production. Si votre développeur connaît bien l'application, c'est un atout considérable : nous travaillons avec lui, et il garde la main sur l'application.
Faut-il migrer HFSQL avant ou après l'application ?
Cela dépend de la raison pour laquelle vous migrez. Sortir de HFSQL en premier est un chantier autonome : il ouvre vos données, réduit une dépendance, et a de la valeur même si vous ne changez jamais l'application. Mais si vos écrans doivent changer de toute façon, tout faire en même temps évite de payer deux fois la reprise des données.
Combien de temps, et combien ?
Cela dépend de votre application et de ce qui y est relié. Dès le premier échange, nous vous disons de quel ordre de grandeur relève votre situation et quels facteurs la feront varier.
Est-ce que je risque de perdre des règles métier ?
C'est le risque principal, et il ne se traite pas par une promesse. Il se traite en identifiant les règles avant de toucher au code, en les vérifiant avec les personnes qui les utilisent, et en comparant le comportement de l'ancien et du nouveau pendant la période où les deux tournent.
Et si PC SOFT revient en arrière ?
C'est possible, et c'est une raison légitime d'attendre avant d'engager un projet complet. Cela dit, certains travaux gardent leur valeur dans tous les cas : savoir ce que contient votre application, ouvrir vos données, rendre vos traitements accessibles à vos autres logiciels. Ils ne dépendent pas de l'issue de ce dossier.
La prochaine étape
Évaluer votre sortie de WinDev
Dites-nous en deux mots où vous en êtes, puis un échange de 30 minutes.
Nous parlons de quatre choses : sur quoi vous êtes réellement exposé ; à quoi votre application est reliée ; vos options et leur coût ; ce que nous recommandons. Selon votre situation, vous repartez avec une réponse directe, une note courte, ou une proposition d'audit technique si un vrai projet se dessine. L'audit est une prestation distincte, payante, et son livrable vous appartient.