Blog · Série « Erreurs d'entreprise »

Le Centre de Sécurité PCSOFT, et la dépendance qu'il installe

On a beaucoup parlé du prix des sessions WinDev. Trop, peut-être — parce que le prix se négocie, et qu'à force de discuter le tarif, on a oublié de regarder l'objet qui le rend possible : le Centre de Sécurité.

Lisez la page officielle de PCSOFT, elle est limpide. Le Centre de Sécurité est une machine installée dans votre propre infrastructure, qui fonctionne hors ligne, sur laquelle on dépose des « packs de sessions » en mode déconnecté. PCSOFT le résume d'une formule rassurante : « pas de dépendance externe ». C'est exact. Et c'est précisément ce qui mérite qu'on s'arrête.

Local ne veut pas dire indépendant

Le Centre de Sécurité ne se connecte à rien : voilà pour la dépendance réseau. Mais ce n'est pas de celle-là qu'il faut se méfier.

Ce boîtier « valide les sessions » des utilisateurs qui lancent vos applications. Autrement dit : entre votre programme — que vous avez payé — et le fait qu'il s'exécute, il y a désormais un organe de contrôle qui n'existait pas avant. Il connaît vos exécutables (la page parle de « restriction des packs par origine des exécutables clients »). Il compte. Il autorise. Une session est « activée pour 30 jours », renouvelée tant que l'usage se maintient, et il faut réapprovisionner les packs.

La dépendance n'est pas au bout d'un câble. Elle est dans la boucle d'exécution. Vous n'hébergez pas un service : vous hébergez la condition de fonctionnement de vos propres logiciels, et cette condition a une date de péremption.

La question que personne ne pose

Que se passe-t-il quand un pack de sessions arrive à échéance et n'est pas réapprovisionné ?

Cherchez la réponse. Elle n'est écrite nulle part. La page qui décrit le dispositif porte, en pied, une mention qui dit tout : « Document non contractuel. »

Je pèse mes mots, parce que c'est ici qu'on bascule facilement dans le procès d'intention, et je ne veux pas y tomber. Je ne dis pas que PCSOFT coupera quoi que ce soit : l'éditeur n'en a probablement aucune envie. Le problème n'est pas l'intention — c'est la structure : vous ne possédez plus la condition d'exécution de votre logiciel, et l'éditeur ne s'engage par écrit sur rien quant à ce qui arrive si cette condition n'est plus alimentée.

Pour un particulier, c'est une gêne. Pour un hôpital, une usine, un cabinet comptable, une administration — pour quiconque a une obligation de continuité — c'est une question qu'on ne peut pas laisser sans réponse contractuelle.

Le dongle qu'on remplace aujourd'hui, lui, avait un défaut et une qualité. Le défaut : une clé physique à ne pas perdre. La qualité : une fois la licence acquise, l'application tournait, indéfiniment, sans demander la permission à personne. Le modèle par session inverse exactement ce rapport. Ce que vous possédiez, vous le louez désormais à durée déterminée, et la reconduction n'est garantie ni sur le prix, ni sur les conditions, ni sur l'existence même du fournisseur dans cinq ans.

La bonne question n'est pas « vais-je être coupé »

C'est : suis-je prêt à ne plus dépendre de la réponse ?

Un éditeur qui va bien peut être racheté — ça vient d'arriver. Une politique qui semble stable peut changer — c'est en train de se produire. La dépendance n'est pas un risque parce que le fournisseur serait mal intentionné ; elle est un risque parce qu'elle vous retire une décision qui devrait vous appartenir : celle de continuer à faire tourner ce que vous avez construit.

La captivité n'est pas une fatalité technique. On en sort. Mais on en sort méthodiquement, pas dans la panique d'une échéance. Voici l'ordre que je recommande.

1. Ne changez pas de version tant que vous pouvez l'éviter. La version 2025 reste en licence perpétuelle : c'est votre marge de manœuvre. On ne quitte pas un écosystème sur un coup de tête ni sous la pression d'un devis — on gèle, on sécurise le présent, on décide à froid. Tant que vous compilez en 2025, le compteur ne tourne pas.
2. Faites le reverse engineering complet, jusqu'au cahier des charges exhaustif. On ne réécrit pas ce qu'on croit avoir : on réécrit ce qu'on a vraiment. Vingt ans de développement contiennent des règles métier que plus personne ne sait énoncer, mais que le code applique tous les jours. L'application existante est la spécification ; il faut l'extraire noir sur blanc avant de toucher à quoi que ce soit.
3. Recensez les états. Les éditions, les impressions, les exports. C'est ce qu'on oublie systématiquement dans une migration, et c'est pourtant ce que l'utilisateur regarde en premier. Un projet de sortie déraille rarement sur la logique métier ; il déraille sur les cinquante états que personne n'avait listés.
4. Migrez la base vers PostgreSQL — en nettoyant et en optimisant au passage. C'est l'étape indépendante du langage applicatif, donc le socle de tout le reste. Et c'est l'occasion de ne pas recopier la dette : on ne transporte pas vingt ans de rustines dans la nouvelle base, on les solde. Une fois vos données en terrain libre, vous avez déjà rompu une partie de la dépendance, même sans avoir touché à une ligne de code métier.
5. Établissez un planning de livrables. Une sortie sans jalons est un vœu, pas un projet. Module par module, chaque livrable testable et réversible, avec des dates. C'est ce qui transforme « il faudrait migrer un jour » en une trajectoire qu'on peut tenir et financer.
6. Réécrivez sans dette technique ni fuite mémoire — et sans nouvelle prison. Rust pour le client lourd ; Rust et JavaScript vanilla pour l'API et le web. Le choix n'est pas dogmatique : il consiste à ne pas remplacer une dépendance par la suivante. On sort d'un enfermement propriétaire — l'erreur serait d'y entrer à nouveau en s'attachant au framework à la mode qui sera la captivité de 2032. Des fondations sobres, contrôlées, sans runtime qui décide à votre place.

En résumé

Le Centre de Sécurité n'est pas un scandale technique : c'est un choix d'architecture qui déplace un pouvoir. Il transfère à l'éditeur la décision de faire tourner, ou non, un logiciel que vous avez payé — et il le fait sans contrepartie écrite sur la continuité. Vous pouvez l'accepter en connaissance de cause. Mais si votre activité repose sur ces applications, la prudence n'est pas de négocier le prochain prix : c'est de reprendre la main sur la condition d'exécution.

Avant de décider quoi que ce soit, mesurez votre exposition — sur vos propres hypothèses, dans votre navigateur, sans envoyer aucune donnée : mon calculateur d'exposition. Et si vous avez reçu un engagement écrit de PCSOFT sur le comportement du Centre de Sécurité à l'échéance des sessions, il m'intéresse : c'est exactement le document qui manque au débat.

Articles précédents : PCSOFT retire son seul prix public · Migrer hors de WinDev : il n'y a pas de bouton magique · La grille se précise — 75, 100, 225