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

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 événement du côté du fournisseur vous force à vous adapter, vous plaçant alors en position de faiblesse pour renégocier. À 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 :

  1. Si tel fournisseur a une défaillance 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, 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 comme une imprimante dont seules les cartouches du fabricant fonctionnent : vous avez acheté l’imprimante, mais c’est lui qui fixe le prix des cartouches. Tant qu’il reste raisonnable, tout va bien.

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, qui acquiert, renforce et développe des entreprises de logiciels sectoriels.

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 1 068 € 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.

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.

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 mes choix d’architecture : la souveraineté n’est pas l’absence de dépendances, c’est la maîtrise de celles que l’on choisit. Je privilégie donc les protocoles et outils ouverts, pour qu’aucun éditeur ni intégrateur ne devienne indispensable par accident.

Lorsqu’aucune alternative viable n’existe à un composant propriétaire, la bonne pratique est de l’isoler : c’est tout l’enjeu du découplage en architecture logicielle. En plaçant des interfaces neutres et des abstractions autour de briques incertaines, on conserve la liberté de changer de fournisseur ou de remplacer le composant à tout moment, sans devoir reconstruire tout le système.

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, 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 dépendre d’un 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, à condition de procéder par étapes :

  1. Cartographier l’existant pour cibler précisément les dépendances non maîtrisées.
  2. Prioriser les urgences, en traitant d’abord les points de blocage qui empêcheraient toute reprise du système.
  3. Traiter le reste progressivement.

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 la capacité de changer de composant, d’outil ou de prestataire sans bloquer le système ni subir de chantage opérationnel.

La souveraineté, c’est le contrôle effectif du système : avoir la garantie et la maîtrise juridique de qui détient la donnée, qui exploite l’infrastructure et sous quelles lois s’exécutent les services (un enjeu capital pour le cloud et l’hébergement).

À retenir

  • Une dépendance technologique ne coûte rien tant qu’elle n’est pas testée par un imprévu, et l’indépendance 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.

L’approche pragmatique

  • Cartographie de ce qui est effectivement propriétaire ou fermé.
  • Évaluation de la reprenabilité par un tiers.
  • Priorisation des points bloquants.
  • Plan de sortie progressif.

Sans casser ce qui fonctionne, et sans remplacer une dépendance par une autre.

Réservez un échange préalable de 15 minutes pour en parler : la première cartographie révèle presque toujours des dépendances que personne n’avait identifiées.

Sources