Fin de la licence perpétuelle : que deviennent vos droits ?

Pendant des décennies, le modèle PC SOFT reposait sur un objet physique : le dongle, propriété perpétuelle de l'entreprise, utilisable sans limite de durée. Son remplacement par un abonnement annuel change la nature juridique et économique de votre outillage de développement. Voici ce qui change concrètement, et les options qui restent ouvertes.

Ce qui disparaît avec le dongle

Le dongle perpétuel avait une propriété précieuse : il découplait votre droit d'utiliser l'outil de votre relation commerciale avec l'éditeur. Vous pouviez cesser de payer les mises à jour et continuer à maintenir vos applications avec la version détenue, indéfiniment. Avec l'abonnement, ce découplage disparaît sur les nouvelles versions : le droit d'usage devient annuel, renouvelable, et lié à la continuité du paiement. Ce n'est pas un détail comptable : c'est la perte d'une position de repli qui protégeait structurellement l'entreprise.

Cette perte se mesure aussi en valeur d'entreprise : un actif applicatif adossé à des droits perpétuels et un actif loué à l'année ne s'évaluent pas de la même façon dans un bilan ou une due diligence.

Accès aux sources et continuité de paiement

Le point le plus sensible pour une application métier : vos sources WinDev ne se maintiennent qu'avec les outils PC SOFT. Selon les conditions publiées, l'accès aux environnements de développement serait désormais conditionné à un abonnement actif : suspendre le paiement reviendrait à ne plus pouvoir modifier ses propres applications, alors même que le code vous appartient. La distinction est essentielle et mérite d'être vérifiée contrat en main avec votre conseil : être propriétaire de son code ne suffit pas si l'atelier qui permet de le compiler se loue au mois.

Cette dépendance de l'atelier appelle un inventaire précis, à faire maintenant et à froid : quelles licences détenez-vous exactement, sous quel régime (perpétuel avec dongle, abonnement, mise à jour), pour quelles versions, sur quels postes ? Beaucoup d'entreprises découvrent à cet exercice que leur situation réelle est un patchwork : des dongles historiques ici, des abonnements récents là, des postes de développement dont plus personne ne sait sous quel contrat ils tournent. Or votre marge de manœuvre juridique et votre position de négociation dépendent entièrement de ce détail. L'inventaire des droits détenus est la première pièce de tout dossier, gel compris.

Geler en version 2025 : dans quels cas c'est jouable

• Votre parc fonctionne, son périmètre est stable, et aucune évolution réglementaire lourde ne s'annonce : le gel est une option rationnelle.
• Vous détenez des licences perpétuelles antérieures au changement de modèle : documentez-les précisément (versions, clés, postes), elles sont votre position de repli.
• Votre environnement technique est compatible durablement (systèmes d'exploitation, matériel, interfaces tierces) : un gel ne vaut que si l'écosystème autour ne bouge pas trop vite.
• Vous engagez en parallèle la documentation des traitements critiques : un gel sans documentation ne fige pas le risque, il le cache.

Le gel bien mené obéit à trois disciplines. Un périmètre écrit : quelles applications, quelles versions, quels postes, avec interdiction de dérive silencieuse. Un environnement figé et sauvegardé : les installeurs, les clés, la documentation de configuration, archivés de façon à pouvoir reconstruire un poste de développement dans deux ans. Et une échéance de revue : le gel se redécide chaque année, sur la base des mêmes chiffres d'exposition, sinon il devient de l'oubli organisé.

Les risques d'un gel prolongé

Le gel achète du temps, il ne l'arrête pas. Les années passant, trois pressions montent : la compatibilité (nouvelles versions de Windows, protocoles, exigences de sécurité), le vivier humain (les développeurs disponibles se raréfient et la version gelée les intéresse de moins en moins), et l'écart fonctionnel (chaque besoin nouveau non couvert alimente le contournement par tableurs et outils parallèles). Un gel se pilote donc comme un projet, avec une échéance de sortie et des revues annuelles, pas comme une absence de décision.

Reste la question du support et de la sécurité : une version gelée ne reçoit plus de correctifs. Pour une application interne sur un réseau maîtrisé, le risque se gère par l'isolement et la surveillance ; pour une application exposée (web, échanges externes, postes nomades), il monte plus vite et raccourcit l'horizon raisonnable du gel. C'est un paramètre de plus à intégrer dans la revue annuelle, avec votre responsable sécurité si vous en avez un.

Préparer une sortie ordonnée

Que la sortie soit pour dans un an ou dans cinq, les mêmes gestes la préparent : documenter les règles métier des traitements critiques, sortir les données du format propriétaire (la base migrée vers un moteur standard reste utilisable par tout le monde, pour toujours), et découpler progressivement la logique métier des interfaces. Ces investissements ont une propriété rare : ils sont utiles dans tous les scénarios, y compris celui où vous restez. C'est par eux que commence toute trajectoire sérieuse, et c'est exactement ce que l'audit de cinq jours permet de prioriser.