Ce qui se passe le jour où votre éditeur ou intégrateur n'est plus là

Tant que tout fonctionne, la question ne se pose jamais.

Le logiciel tourne. L'intégrateur répond au téléphone. Les automates communiquent avec la supervision.
Personne ne se demande ce qui se passerait si l'un de ces trois maillons disparaissait.

Puis un jour, l'un d'eux disparaît.

L'éditeur est racheté et change sa grille tarifaire.
L'intégrateur ferme, part à la retraite ou n'a plus de disponibilité.
Le fabricant de l'automate arrête un modèle et son logiciel de programmation avec.

Et c'est à cet instant précis que l'entreprise découvre l'étendue réelle de sa dépendance.

Une situation qui revient souvent

Une PME industrielle fait appel à un intégrateur unique pour concevoir sa supervision.

Tout se passe bien pendant des années. Les évolutions sont livrées, les pannes corrigées, la relation est de confiance.
Puis l'intégrateur annonce qu'il cesse son activité.

L'entreprise se retrouve alors avec :

• un logiciel de supervision dont le code source ne lui appartient pas ;
• des automates programmés dans un format propriétaire, lisible uniquement par l'outil de cet intégrateur ;
• aucune documentation détaillée des choix techniques, puisque tout était géré en direct ;
• aucun autre prestataire capable de reprendre l'ensemble sans tout redévelopper.

Rien n'est cassé. Le système fonctionne toujours.
Mais la moindre évolution, la moindre panne un peu sérieuse, devient un problème sans solution rapide.

L'indépendance technologique, concrètement

Ce n'est pas un principe abstrait. C'est une réponse simple à trois questions :

1. Si ce fournisseur disparaît demain, qui d'autre peut reprendre le système ?
2. Vos données sont-elles stockées dans un format que vous pouvez extraire et réutiliser sans lui ?
3. Vos équipements communiquent-ils via des protocoles ouverts (OPC UA, Modbus, MQTT) ou uniquement via le logiciel propriétaire d'un seul fournisseur ?

Si la réponse à l'une de ces questions est non, il existe une dépendance - qu'elle pose problème aujourd'hui ou non.

Les trois formes de dépendance les plus fréquentes

1. Dépendance à un éditeur unique

Un logiciel métier ou une supervision dont le code n'est pas accessible, sans API documentée, sans export de données dans un format standard.

Tant que l'éditeur existe et reste disponible, ça fonctionne.
Le jour où il change de stratégie commerciale - hausse tarifaire, fin de support d'une version, rachat par un concurrent - le client n'a aucun levier de négociation.

C'est exactement ce qui est arrivé aux entreprises ayant construit leurs outils métier avec WinDev.

Fin 2024, PC SOFT - l'éditeur historique de WinDev, WebDev et WinDev Mobile - est racheté par Volaris Group, filiale du groupe canadien Constellation Software, spécialisé dans le rachat d'éditeurs logiciels à clientèle captive.
L'opération n'est confirmée publiquement qu'en mai 2025.

Ce qui suit est prévisible : la licence perpétuelle historique est abandonnée au profit d'un abonnement annuel obligatoire.
L'abonnement catalogue passe d'environ 749 € à environ 1 068 € par an en quelques mois - une hausse d'environ 43 %.
Des discussions autour d'une redevance par session d'utilisation de l'application suivent.

Les entreprises ayant développé leurs outils métier en WinDev n'ont eu aucun levier de négociation. Leur logique métier était enfermée dans un environnement propriétaire, sans alternative de migration rapide.

Ce n'est pas un cas isolé. Le rachat de VMware par Broadcom, finalisé en novembre 2023, suit exactement le même schéma - à une échelle bien plus large, puisque VMware équipe l'infrastructure virtualisée d'une grande partie des entreprises du monde entier.

La vente de nouvelles licences perpétuelles est stoppée.
Les offres sont regroupées en bundles imposés, plus larges et plus chers que les licences à la carte précédentes.
Le mode de facturation change (du CPU vers le cœur de processeur), et le nombre minimum de cœurs requis par licence passe de 16 à 72 en mars 2025 - ce qui multiplie mécaniquement la facture pour de nombreux clients. Selon les configurations, les hausses constatées vont de 30 % à plusieurs centaines de pour cent.

Les entreprises qui avaient bâti toute leur infrastructure virtualisée autour de VMware, sans architecture de sortie préparée, se sont retrouvées à négocier dans l'urgence - ou à payer.

2. Dépendance à un intégrateur unique

La configuration, les scripts, les mots de passe et la logique du système existent uniquement dans la tête d'une personne ou d'une entreprise externe.

Aucune documentation transférable.
Aucun autre prestataire ne peut reprendre le dossier sans repartir de zéro - audit complet, rétro-ingénierie, parfois reconstruction pure et simple.

3. Dépendance à un protocole fermé

Un automate qui ne communique qu'avec le logiciel de son propre fabricant, sans passerelle vers un protocole standard.

Toute intégration future - nouvelle supervision, nouvel ERP, nouvel outil de reporting - passe obligatoirement par ce même fabricant, à ses conditions et à son tarif.

Pourquoi ça ne se voit pas tout de suite

Une dépendance technologique ne produit aucun symptôme visible tant que le fournisseur reste disponible et coopératif.
Elle ne coûte rien tant qu'elle n'est pas testée.

C'est exactement ce qui la rend dangereuse : elle ne figure sur aucun tableau de bord, ne déclenche aucune alerte, et n'apparaît dans aucun rapport de supervision.

Elle devient visible uniquement le jour où un changement - chez le fournisseur, pas chez le client - force une renégociation en position de faiblesse.

Ce que change une architecture indépendante

Concrètement, quand un système repose sur des standards ouverts et une documentation réelle :

• Vous pouvez changer de prestataire sans réécrire l'ensemble du système, parce que la logique métier n'est pas enfermée dans un format propriétaire.
• Vos automates et applications restent pilotables via des protocoles standards (OPC UA, MQTT, API REST / SOAP documentées, ...) même si vous changez de fournisseur.
• Vos données restent exploitables dans un format que vous maîtrisez, indépendamment du logiciel qui les a produites.
• Vous négociez en position d'égal, parce que vous avez une alternative crédible si les conditions ne vous conviennent plus.

L'indépendance technologique ne signifie pas rejeter tout logiciel propriétaire ou tout intégrateur spécialisé.
Elle signifie garder la capacité de changer si nécessaire - ce qui change fondamentalement le rapport de force, même si vous ne changez jamais.

C'est ce principe qui guide chaque choix d'architecture, de protocole ou d'outil chez C'PRAG : le minimum de liens possible avec un éditeur ou un intégrateur - parfois un composant propriétaire reste incontournable, mais il n'est jamais retenu par défaut - et aucune solution retenue parce qu'elle figure dans un catalogue plutôt que parce qu'elle correspond au contexte réel du client.

Indépendance et souveraineté : deux risques liés, mais différents

L'indépendance protège contre un fournisseur qui change unilatéralement ses conditions.
La souveraineté technologique va plus loin : elle interroge qui contrôle réellement vos outils et vos données, et sous quelle juridiction.

WinDev, racheté par un groupe canadien. VMware, racheté par un groupe américain. Dans les deux cas, les décisions stratégiques - tarifs, feuille de route, conditions d'accès - sont passées entre des mains extérieures, sans recours pour les entreprises françaises qui en dépendaient.

Pour une PME industrielle, la question de souveraineté se pose concrètement sur :

• l'hébergement des données de production : dans quel pays sont-elles stockées, et quel droit s'applique ;
• la dépendance à des services cloud soumis à une législation étrangère, comme le CLOUD Act américain, qui peut contraindre un fournisseur basé aux États-Unis à donner accès à des données même hébergées hors du pays ;
• la capacité à continuer d'exploiter un système si l'éditeur change de politique pour des raisons réglementaires ou géopolitiques, pas seulement commerciales.

Ce ne sont pas des questions théoriques.
Ce sont des critères de choix d'architecture, au même titre que la fiabilité ou la performance.

Questions fréquentes

L'indépendance technologique coûte-t-elle plus cher au départ ?

Pas nécessairement.
Elle demande surtout un choix différent : privilégier des protocoles ouverts et une documentation réelle plutôt qu'une solution tout-en-un fermée.
Le surcoût, quand il existe, est généralement documentaire (temps de rédaction) plutôt que technique.

Est-il possible de sortir d'une dépendance déjà installée ?

Oui, progressivement.
Un audit permet d'abord de cartographier précisément ce qui est réellement propriétaire ou fermé, puis de prioriser les points les plus critiques (ceux qui bloqueraient une reprise en cas d'urgence) avant les moins urgents.

Un intégrateur qui garde la main sur ses développements est-il forcément un problème ?

Non. Le savoir-faire méthodologique d'un prestataire lui appartient légitimement.
Le problème apparaît quand le système lui-même - code, configuration, données - ne peut être repris par personne d'autre, y compris vous.

Quelle est la différence entre indépendance et souveraineté technologique ?

L'indépendance, c'est pouvoir changer de fournisseur si nécessaire.
La souveraineté, c'est savoir qui contrôle réellement l'outil et sous quelle juridiction - un critère qui compte particulièrement pour l'hébergement de données de production ou le choix d'un service cloud.

À retenir

• Une dépendance technologique ne coûte rien tant qu'elle n'est pas testée par un imprévu.
• Trois questions suffisent à l'évaluer : qui peut reprendre le système, dans quel format sont vos données, et via quels protocoles communiquent vos équipements.
• L'indépendance ne s'improvise pas le jour où le fournisseur disparaît - elle se construit avant, par des choix d'architecture ouverts et documentés.
• Le rachat de PC SOFT (WinDev) par un groupe canadien, et celui de VMware par Broadcom (États-Unis), en sont deux illustrations récentes : hausses tarifaires massives pour des clients sans alternative de migration rapide.
• Au-delà de l'indépendance commerciale, la souveraineté technologique interroge la juridiction qui contrôle réellement vos outils et vos données.

C'PRAG audite les dépendances réelles de votre système d'information industriel : cartographie de ce qui est effectivement propriétaire ou fermé, évaluation de la reprenabilité par un tiers, priorisation des points bloquants, puis plan de sortie progressif. Sans casser ce qui fonctionne, et sans remplacer une dépendance par une autre.

Prenez rendez-vous pour un audit de votre existant : la première cartographie révèle presque toujours des dépendances que personne n'avait identifiées.

Sources

• Volaris Group. Volaris Group Acquires PC Soft.
• Next.ink. PC Soft, l'éditeur de WinDev, passe sous pavillon canadien.
• Next.ink. Les développeurs WinDev s'alarment d'une possible redevance par installation client.
• LeMagIT. Comment le secteur européen de l'éducation subit le rachat de VMware par Broadcom.
• IT-Connect. Broadcom – VMware : des hausses de tarifs de 800 % à 1 500 % sur le tarif des licences.
• Les situations décrites dans cet article sont par ailleurs inspirées de cas réels rencontrés sur des systèmes industriels. Elles ont été anonymisées et généralisées afin de préserver la confidentialité des organisations concernées.