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

Une dépendance technologique ne coûte rien tant qu'elle n'est pas testée par un imprévu : un rachat d'éditeur, un intégrateur qui ferme, un automate en fin de vie.
Le jour où l'un de ces trois maillons disparaît, l'entreprise découvre d'un coup l'étendue réelle de ce qu'elle ne maîtrisait pas. L'indépendance technologique se construit avant cet incident, par des choix d'architecture ouverts et documentés, pas le jour où le fournisseur disparaît.

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, et 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.

Pourquoi la dépendance ne se voit qu'au dernier moment

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, et c'est exactement ce qui la rend dangereuse : elle ne figure sur aucun tableau de bord, ne déclenche aucune alerte, 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 moment-là, il est trop tard pour construire une alternative dans le calme.

L'indépendance technologique, concrètement

Ce n'est pas un principe abstrait. C'est une réponse simple à trois questions : si ce fournisseur disparaît demain, qui d'autre peut reprendre le système ? Vos données sont-elles stockées dans un format que vous pouvez extraire et réutiliser sans lui ? Vos équipements communiquent-ils via des protocoles ouverts, standards partagés par plusieurs fabricants comme OPC UA, Modbus ou 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.

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, dont le tarif catalogue passe d'environ 749 € à environ 1068 € par an en quelques mois, soit une hausse d'environ 43 %. Des discussions autour d'une redevance par session d'utilisation suivent. Les entreprises ayant développé leurs outils métier en WinDev n'ont eu aucun levier de négociation, leur logique métier étant 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 dans le monde. La vente de nouvelles licences perpétuelles est stoppée, les offres 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.

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.

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.

Ce que change une architecture indépendante

Quand un système repose sur des standards ouverts et une documentation réelle, le rapport de force change du tout au tout. 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 même si vous changez de fournisseur, et vos données restent exploitables dans un format que vous maîtrisez, indépendamment du logiciel qui les a produites. Vous négociez enfin 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 de fournisseur.

C'est ce principe qui guide chaque choix d'architecture, de protocole ou d'outil chez C'PRAG : le minimum de liens possibles 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 a été racheté par un groupe canadien, VMware 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 trois terrains : le pays où sont stockées les données de production et le droit qui s'y 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), et 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.

Ce que je vérifierais si j'arrivais chez vous demain

Avant même de parler d'évolution ou de modernisation, voici les questions auxquelles je chercherais à répondre en premier :

• Si votre éditeur ou votre intégrateur principal disparaissait demain, qui d'autre pourrait reprendre le système ?
• Vos données sont-elles stockées dans un format que vous pouvez extraire et réutiliser sans l'accord du fournisseur ?
• Vos automates et applications communiquent-ils via des protocoles ouverts, ou uniquement via un logiciel propriétaire ?
• La documentation technique existe-t-elle ailleurs que dans la tête d'une seule personne, interne ou externe ?
• Savez-vous précisément où sont hébergées vos données de production, et sous quelle juridiction ?

Si une seule réponse est "je ne sais pas", il existe probablement une dépendance qui mérite d'être évaluée.

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, et elle ne s'improvise pas le jour où le fournisseur disparaît.
• 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.
• 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.