Nouvelle tarification PCSOFT juin 2026 : la douche froide, et comment y faire face
La communauté WinDev est en ébullition depuis quelques semaines. Les posts se multiplient sur LinkedIn et les forums spécialisés comme developpez.net, et le ton est clairement à la colère. Après le rachat de PCSOFT par le groupe canadien Volaris fin 2024, les changements de modèle économique s'accélèrent, et la nouvelle tarification annoncée en juin 2026 marque un véritable tournant — potentiellement douloureux — pour les développeurs et les éditeurs de logiciels basés sur la suite WinDev.
Ce qui fait polémique
Le modèle par abonnement, acté depuis la version 2025, était déjà contesté. Mais la nouvelle mesure qui concentre toutes les critiques, c'est la tarification à la session : chaque lancement d'une application WinDev par un utilisateur final déclencherait une session facturée, apparemment à 290 € HT par unité. Un chiffre qui, s'il se confirme, changerait radicalement la donne pour tous les éditeurs et développeurs indépendants qui déploient leurs applications chez leurs clients.
À cela s'ajoutent d'autres sources d'irritation :
- La fin des prix publics : il faut désormais remplir un formulaire pour obtenir un devis, rendant toute comparaison ou planification budgétaire quasi impossible.
- L'obligation de souscrire à des packs complets (WinDev + WebDev + WinDev Mobile + LST + Cél de sécurité + certification), même si l'on n'utilise qu'un seul produit, impossible d'acheter au détail.
Comme le résume un développeur sur les forums : "Pour nous aussi, c'est la douche froide. Non, en fait, c'est carrément le bain dans l'azote liquide." Une réaction qui illustre bien le sentiment général.
Solution 1 : Rester en version 2025 ou rétrograder
La première option — et la plus immédiate — est tout simplement de geler ses projets en version 2025. Cette version restera en licence perpétuelle.
La tarification à la session démarre à partir de la version 2026. Si vous avez conservé vos clefs en version 2025 ou antérieure, vous serez pour l'instant épargné. Si vous n'avez pas encore migré en 2026, c'est le moment de marquer une pause.
Concrètement :
- Conservez vos projets en version 2025 (ou version antérieure) tant que la politique tarifaire 2026 n'est pas clarifiée.
- Ne compilez pas en version 2026 si vos clients sont déjà en production et que la facturation à la session risque de les impacter.
- Documentez vos configurations (environnements, dépendances, licences) pour faciliter une éventuelle reprise ou migration ultérieure.
- Partager une licence Windev 2025 avec un développeur qui ne l'utilise pas ou seulement partiellement, si vous ne disposez plus de clés.
Cette approche permet de gagner du temps sans rompre immédiatement avec l'écosystème PCSOFT, le temps d'y voir plus clair sur l'évolution des tarifs.
Solution 2 : Réduire le nombre de sessions en regroupant les applications
Si vous développez des ERP métiers composés de plusieurs applications WinDev distinctes, la tarification par session va rapidement devenir insoutenable si chaque application génère sa propre session.
La parade naturelle : regrouper toutes les applications en une seule, pilotée par un menu principal qui charge dynamiquement les différents modules. Cette approche, souvent appelée architecture "monoapplication", présente plusieurs avantages :
- Une seule session consommée par utilisateur, quelle que soit la richesse fonctionnelle de votre ERP.
- Un déploiement simplifié : un seul exécutable à mettre à jour.
- Une meilleure cohérence UI/UX pour l'utilisateur final.
Techniquement, dans WinDev, cela peut se réaliser via :
- Un projet "conteneur" qui intègre les fenêtres de tous les autres projets.
- La gestion des droits et menus depuis un module central.
Cette refactorisation représente un effort de développement, mais elle peut être rapidement rentabilisée face à une facturation à la session qui s'envolerait sur des dizaines ou des centaines d'utilisateurs.
Solution 3 : Héberger soi-même pour sortir de PCSCLOUD
Le PCSCLOUD est pratique, mais son coût est devenu significatif, et la dépendance à l'infrastructure de PCSOFT est un risque supplémentaire. Si vous restez en version 2025, vous pouvez tout auto-héberger sous Windows ou Linux — à l'exception du store privé, disponible uniquement sous Windows.
Les bases de données HFSQL
HFSQL Client/Serveur peut s'installer sur vos propres serveurs, aussi bien sous Windows que sous Linux (Ubuntu, Debian, etc.). Nous avions déjà traité ce sujet dans notre article sur Linux et WinDev. Un serveur Linux est nettement moins onéreux qu'un hébergement cloud managé, et vous gardez la maîtrise totale de vos données.
Les webservices et sites WebDev
Le serveur d'applications WebDev s'installe également sous Linux. Il suffit de disposer d'un serveur Apache ou Nginx compatible. Un VPS Linux chez OVH, Scaleway ou Hetzner pour une vingtaine d'euros par mois peut largement suffire pour héberger plusieurs sites ou webservices WebDev d'un ERP métier.
Le store privé (Windows uniquement)
Le store privé WinDev, qui permet de distribuer vos mises à jour applicatives à vos clients, reste pour l'instant limité à Windows. Si vous souhaitez l'auto-héberger, il vous faudra donc un serveur Windows — ce qui est moins économique, mais reste accessible via un VPS Windows.
Solution 4 : Préparer une migration vers d'autres technologies
C'est sans doute la solution la plus stratégique, mais aussi la plus ambitieuse. Face à une politique tarifaire qui peut remettre en cause la rentabilité de tout un parc applicatif, plusieurs développeurs ont déjà annoncé entamer une migration. La question n'est plus vraiment "faut-il migrer ?" mais "par où commencer ?".
Étape 1 : Migrer la base de données HFSQL vers PostgreSQL (ou MySQL/MariaDB)
C'est la première étape logique, car elle est indépendante du langage applicatif et constitue un socle pour la suite. HFSQL est certes efficace, mais PostgreSQL ou MySQL sont libres, gratuits, et universellement supportés.
La migration se déroule généralement ainsi :
- Audit du schéma HFSQL : export des structures de tables, des index, des relations.
- Création du schéma équivalent sous PostgreSQL via un script.
- Migration des données : le plus efficace est de développer soi-même un outil de conversion en Windev. Les tables auront la même structure des deux côtés. L'outil devra se connecter altrnativement sur chaque base de données et recopier les données table par table. Vous devrez régler ponctuellement des problèmes d'index ou de format de colonnes (date, heures, etc..)
- Adaptation des accès données dans WinDev : WinDev supporte nativement les connexions ODBC/OLE DB vers PostgreSQL ou MySQL, ce qui permet de conserver temporairement le code WLanguage en ne changeant que la couche d'accès aux données.
Cette étape seule vous libère d'une partie de la dépendance à PCSOFT, même si vous conservez WinDev pour l'instant.
Étape 2 : Redévelopper les applications avec l'aide de l'IA
C'est là que la donne a radicalement changé en 2025-2026. Des outils comme GitHub Copilot, Claude, ou Cursor permettent aujourd'hui d'accélérer considérablement le portage d'une application d'un langage à un autre.
Les langages et environnements cibles
Pour les développeurs WinDev qui ne souhaitent pas tout réapprendre from scratch, plusieurs alternatives offrent une transition plus douce :
- Xojo : probablement le successeur spirituel le plus proche de WinDev. Xojo est un environnement RAD (Rapid Application Development) avec un langage propriétaire proche du Basic, une approche visuelle similaire (fenêtres, contrôles, événements), et la capacité de compiler pour Windows, macOS, Linux et le Web depuis un seul projet. Pour un développeur WinDev, la courbe d'apprentissage est nettement moins raide qu'avec C# ou Python. Attention cependant : Xojo est lui aussi un éditeur propriétaire avec abonnement, ce qui ne résout pas fondamentalement la question de la dépendance.
- Lazarus / Free Pascal : pour ceux qui veulent une solution 100 % gratuite et open source. Lazarus est visuellement très proche de Delphi (et donc de l'approche RAD), supporte Windows, Linux et macOS, et dispose d'une communauté active. La compilation produit des exécutables natifs sans dépendance runtime. C'est une option sérieuse pour des applications Windows classiques, même si l'écosystème est moins riche que celui de .NET ou Java.
- C# / .NET MAUI : le choix naturel pour cibler Windows, Android, iOS et macOS depuis une base de code unique. L'écosystème est mature, Microsoft investit massivement dedans, et les outils de développement (Visual Studio, Rider) sont excellents. La transition depuis WLanguage demande un effort, mais l'IA facilite énormément la réécriture de la logique métier.
- Python + frameworks web (Django, FastAPI + React/Vue) : particulièrement adapté pour des applications fortement orientées web, des outils de reporting ou d'administration, ou des applications qui n'ont pas besoin d'un client lourd.
- Java / Kotlin : pour des équipes qui ciblent Android en priorité ou qui évoluent dans un écosystème JVM existant.
La voie radicale : développer 100 % avec l'IA
Au-delà de l'aide à la migration, il existe aujourd'hui des plateformes qui permettent de générer une application complète à partir d'une description en langage naturel, sans écrire une seule ligne de code soi-même :
- Replit Agent : Replit a évolué bien au-delà du simple IDE en ligne. Son agent IA peut générer, exécuter, déboguer et déployer une application web complète à partir d'un prompt. On décrit le besoin ("je veux un outil de gestion de clients avec facturation et tableau de bord"), et l'agent produit une application fonctionnelle, hébergée directement sur l'infrastructure Replit. Idéal pour des applications web internes ou des outils métiers légers.
- Lovable (ex-GPT Engineer) : génère des applications web complètes (React + backend) à partir d'une description. Très orienté front-end et prototypage rapide.
- Bolt.new : concurrent direct de Lovable, développé par StackBlitz. Même approche : description en langage naturel → application web déployable.
- Claude Artifacts / ChatGPT Canvas : pour des outils plus ciblés (formulaires, calculateurs, tableaux de bord), il est possible de générer directement une mini-application HTML/JS autonome, sans infrastructure, déployable sur n'importe quel hébergement statique.
Ces approches "no-code IA" ont leurs limites : elles conviennent mieux aux applications web qu'aux applications desktop lourdes, et la maintenabilité du code généré peut être variable. Mais pour un ERP métier dont certains modules pourraient migrer vers le web, elles méritent sérieusement d'être explorées — d'autant qu'elles permettent de tester un re-développement en quelques heures plutôt qu'en plusieurs semaines.
Le processus de migration assistée par IA, qu'il passe par un de ces outils ou par un assistant de code classique, consiste typiquement à :
- Fournir à l'IA le code WLanguage par module fonctionnel, accompagné du contexte métier.
- Lui demander de le retranscrire dans le langage ou l'environnement cible.
- Tester, corriger, et itérer module par module.
Les parties les plus délicates restent l'UI et les spécificités WinDev (états, fenêtres d'analyse, centres de sécurité), qui nécessitent un re-design plus profond. Mais la logique métier pure — calculs, règles de gestion, accès aux données — se porte très bien à la migration assistée par IA.
En conclusion
La nouvelle tarification PCSOFT de juin 2026 agit comme un révélateur : la dépendance totale à un seul éditeur est un risque stratégique. Les développeurs et éditeurs qui avaient bâti tout leur catalogue sur WinDev se trouvent aujourd'hui dans une position délicate. Espérons que PCSOFT reviendra sur ce modèle économique.
Les solutions existent, et elles ne sont pas toutes ou rien : on peut commencer par geler les versions, regrouper les applications, auto-héberger ses infrastructures, et progressivement initier une migration de la base de données. L'IA est aujourd'hui un vrai accélérateur pour qui souhaite aller plus loin.
Chez SEALOG, nous accompagnons nos clients dans ces réflexions stratégiques. N'hésitez pas à prendre rendez-vous pour en discuter.
Commentaires
Enregistrer un commentaire