Dépendance à un éditeur unique : évaluer et réduire le risque

La dépendance à un éditeur n'est pas un problème en soi : toute entreprise dépend de ses fournisseurs. Elle devient un risque quand elle est totale, non mesurée et sans porte de sortie. L'écosystème PC SOFT cumule plusieurs niveaux de verrouillage qu'il faut regarder séparément, car ils ne se lèvent pas de la même façon ni au même prix.

Les 4 niveaux de verrouillage

Un point sémantique avant d'entrer dans le détail : verrouillage ne signifie pas malveillance. Tout écosystème intégré, et c'est précisément ce qui fait la productivité de celui de PC SOFT, crée mécaniquement de l'adhérence : format de base dédié, langage propre, outillage unifié. La question n'est donc pas de juger l'éditeur, mais de savoir si cette adhérence est pour vous un confort assumé ou un risque subi, et à quel prix elle se réduit. C'est une analyse d'actifs, pas un procès.

Le verrou des données : HFSQL

C'est le verrou le plus profond et, paradoxalement, le premier à faire sauter. Tant que vos données vivent dans un format que seuls les outils de l'éditeur lisent nativement, toute trajectoire de sortie commence par lui. La bonne nouvelle : la migration de base est un chantier borné, aux résultats vérifiables, qui se mène sans toucher au reste de l'application dans un premier temps. Une fois les données dans PostgreSQL ou SQL Server, elles sont à vous dans un sens qui redevient concret : lisibles, exportables, exploitables par n'importe quel outil, pour toujours.

Ordre de marche classique de ce chantier : extraire le schéma, migrer une copie, faire tourner les contrôles d'intégrité, puis décider. Rien de tout cela ne touche à la production.

Le verrou du langage : WLangage

Votre code vous appartient juridiquement, mais il n'est exécutable et modifiable qu'avec les outils de l'éditeur : c'est la nuance qui fait toute la dépendance. La levée de ce verrou ne passe pas par un convertisseur magique, qui n'existe pas, mais par un mouvement en deux temps : documenter les règles métier (le vrai actif, désormais extractible efficacement avec l'aide de l'IA), puis les réimplémenter progressivement sur un socle ouvert, module par module. Le savoir de l'entreprise cesse alors d'être enfermé dans une syntaxe pour devenir une spécification que toute équipe peut porter.

Le WLangage pose une question supplémentaire, plus subtile : celle de la relecture. Un contrat, un auditeur de due diligence ou un assureur cyber peuvent faire expertiser un code C#, PHP ou Java par des dizaines de cabinets ; pour un code WLangage, le cercle des relecteurs qualifiés est étroit, et cette rareté de la contre-expertise est en soi une forme de dépendance. Documenter les règles métier en langage naturel, indépendamment du code, redonne cette capacité de relecture à n'importe quel tiers compétent.

Le verrou contractuel

Le passage de la licence perpétuelle à l'abonnement a transformé une dépendance dormante en exposition active : les conditions d'usage de vos propres applications peuvent désormais évoluer avec les barèmes de l'éditeur. Deux gestes de gestion s'imposent, sans conseil juridique de notre part car ce n'est pas notre rôle : faire préciser par écrit ce qui s'applique à vos versions et à vos déploiements, avec l'appui de votre conseil habituel ; et inventorier précisément ce que vous détenez (licences, versions, clés, postes), car cet inventaire est votre position de négociation.

Comment mesurer votre propre niveau de verrouillage ? Trois questions suffisent pour un premier diagnostic. Si votre prestataire ou votre développeur disparaissait demain, en combien de temps un tiers pourrait-il reprendre la maintenance ? Si vous cessiez de payer l'abonnement, que pourriez-vous encore faire de vos applications et de vos données ? Et si un acheteur auditait votre entreprise, que répondriez-vous à la question de la dépendance technologique ? Toute réponse floue à l'une de ces questions localise précisément votre verrou prioritaire.

Une stratégie de sortie progressive

Réduire la dépendance ne signifie pas tout quitter demain : c'est reconquérir les niveaux de verrouillage un par un, dans l'ordre où chaque geste crée de la valeur même si l'on s'arrête là. D'abord les données, parce qu'une base ouverte sécurise tout le reste. Puis la connaissance, parce qu'un code documenté et testé se maintient et se négocie mieux. Puis le découplage, parce qu'un métier exposé en API rend chaque brique remplaçable. La migration complète n'est que la dernière étape de cette reconquête, et certaines entreprises s'arrêtent sereinement en chemin : la dépendance mesurée et réversible est un choix ; c'est la dépendance subie qui n'en est pas un.