Dépendance logicielle : le guide de survie des équipes IT européennes après l'effet TikTok

# Dépendance logicielle : le guide de survie des équipes IT européennes après l'effet TikTok

> Note de la rédaction — contexte 2026. L'affaire TikTok n'est pas une anecdote de politique américaine. C'est un cas d'école qui a mis sur la table une question que beaucoup de DSI européens évitaient soigneusement : *que se passe-t-il concrètement dans mon SI le jour où un régulateur étranger décide qu'un outil que j'utilise n'existe plus ?* Ce guide ne parle pas de TikTok. Il parle de ce que TikTok a révélé.

Ce que l'affaire TikTok a vraiment démontré — et ce qu'on refuse encore de regarder en face

Quand TikTok a été contraint d'opérer sous la menace d'un bannissement aux États-Unis, puis dans plusieurs juridictions européennes, les entreprises qui l'utilisaient pour leur communication ou leur recrutement ont découvert quelque chose d'inconfortable : elles n'avaient aucun plan B. Pas de données exportées. Pas d'alternative testée. Pas de processus de bascule.

Mais voici la question qui dérange vraiment : en quoi votre stack IT actuelle est-elle fondamentalement différente de cette situation ?

Un outil de visioconférence dont les serveurs sont aux États-Unis, un CRM dont les conditions générales permettent une modification unilatérale des tarifs, un service de messagerie professionnelle hébergé sous juridiction américaine — tout cela repose sur exactement la même logique de dépendance. La seule différence, c'est qu'on ne vous a pas encore imposé de date limite.

Ce guide est fait pour les équipes IT qui ont décidé de ne pas attendre cette date.

Étape 1 — Cartographier honnêtement ce que vous ne contrôlez pas

Avant d'agir, il faut accepter de voir. Et c'est souvent là que le bât blesse.

Ce que font concrètement les équipes IT :

Prenez votre registre des traitements RGPD — vous en avez un, normalement — et traversez-le avec une grille de lecture différente de celle de la conformité. Pour chaque outil listé, posez ces trois questions :

1. Où sont physiquement les données ? Pas où dit le contrat. Où sont-elles réellement, d'après les sous-traitants listés en annexe des CGU ?

2. Sous quelle juridiction l'éditeur peut-il être contraint de transférer ou bloquer l'accès à ces données ? Le Cloud Act américain n'est pas une théorie : il s'applique à toute entité soumise au droit américain, quelle que soit la localisation des serveurs.

3. Quel est votre délai de bascule réaliste si cet outil disparaît dans 72 heures ? Pas dans six mois. 72 heures.

La question qui dérange : Avez-vous déjà testé l'export de vos données depuis chacun de ces outils ? Pas lu la documentation. Testé. En conditions réelles. Beaucoup d'équipes IT découvrent à ce moment-là que les exports sont incomplets, dans des formats propriétaires illisibles sans l'outil source, ou soumis à des délais contractuels qui rendent toute bascule d'urgence impossible.

Productivité concrète : cette cartographie n'a pas besoin d'être exhaustive dès le départ. Commencez par les outils de niveau critique — ceux dont l'indisponibilité arrête l'activité dans les 24 heures.

Étape 2 — Distinguer dépendance acceptable et dépendance subie

Soyons précis : l'objectif n'est pas de remplacer tous les outils américains par des équivalents européens à tout prix. Ce serait à la fois irréaliste et contre-productif. L'objectif est de comprendre *pourquoi* vous utilisez tel outil et *à quel prix* — pas en euros, en souveraineté.

La grille de décision pour les équipes IT :

Classez chaque outil critique selon deux axes :

• Niveau de criticité métier : est-ce que l'arrêt de cet outil bloque l'activité, ralentit, ou est simplement gênant ?
• Niveau de substituabilité réelle : existe-t-il une alternative dont vous maîtrisez l'hébergement, ou au minimum dont l'éditeur est soumis au droit européen ?

Les outils à criticité haute et substituabilité faible sont votre vraie zone de risque. Ce sont eux qui méritent un plan de continuité documenté, pas un post-it mental.

La question qui dérange : Quand votre direction demande pourquoi vous restez sur tel outil de l'acteur américain dominant, est-ce que votre réponse est technique — ou est-ce que c'est *« parce qu'on a toujours fait comme ça »* et *« tout le monde est dessus »* ? Ce sont deux réponses très différentes, et seulement une d'entre elles est une décision IT.

Étape 3 — Exiger la portabilité avant de signer (ou renouveler)

C'est l'étape que la plupart des équipes IT ratent systématiquement, parce qu'elle intervient au mauvais moment : pendant la négociation commerciale, quand la pression est sur les fonctionnalités et le prix, pas sur les clauses de sortie.

Ce que vous devez intégrer dans tout nouveau contrat ou renouvellement :

• Clause d'export des données dans un format ouvert et documenté, dans un délai défini contractuellement — pas « sur demande ».
• Clause de réversibilité : qu'est-ce que l'éditeur s'engage à fournir pour faciliter une migration ? Documentation d'API ? Accompagnement technique ? Pour combien de temps après résiliation ?
• Notification préalable en cas de modification unilatérale substantielle des conditions — et définissez contractuellement ce qu'est une modification substantielle.

Ces clauses existent. Elles se négocient. Les éditeurs européens — notamment ceux qui ont fait de la souveraineté leur argument commercial, comme certains acteurs nordiques ou allemands dans l'espace collaboration — les intègrent de plus en plus nativement. Ce n'est pas un hasard : c'est une réponse de marché à exactement ce type de demande.

La question qui dérange : Votre service juridique et vos acheteurs ont-ils une grille de lecture souveraineté dans leurs processus de validation contractuelle ? Ou est-ce que la responsabilité retombe entièrement sur l'IT, qui n'a ni le mandat ni l'autorité pour bloquer un contrat déjà validé commercialement ?

Étape 4 — Construire des compétences internes sur la donnée, pas sur les interfaces

Voici le piège que TikTok a révélé dans sa version grand public : des community managers qui savaient parfaitement utiliser l'interface, mais qui ne savaient pas du tout ce qu'ils feraient sans elle. Aucune compétence transférable. Aucune maîtrise des données sous-jacentes.

En milieu IT professionnel, le même piège existe.

Ce que ça implique concrètement pour vos équipes :

Formez vos équipes sur les standards ouverts, pas sur les implémentations propriétaires. Un collaborateur qui comprend le protocole et le modèle de données peut migrer vers un autre outil. Un collaborateur formé uniquement sur les clics d'une interface propriétaire, non.

Cela concerne l'administration système, la gestion des identités, les pipelines de données, les intégrations entre outils. À chaque fois qu'une compétence clé de votre équipe est liée à une certification propriétaire d'un acteur américain, posez-vous la question : cette compétence nous appartient-elle, ou appartient-elle à l'éditeur ?

La question qui dérange : Combien de vos processus IT ne sont documentés que dans les wikis internes de l'outil lui-même — hébergés, donc, chez l'éditeur ? Si l'accès est coupé, perdez-vous aussi la documentation de vos propres processus ?

Étape 5 — Intégrer le risque souveraineté dans votre gouvernance IT, pas dans un projet ponctuel

C'est l'étape la plus difficile, et la plus souvent sabotée par la réalité opérationnelle.

La souveraineté numérique n'est pas un projet. Ce n'est pas un chantier avec une date de fin. C'est un critère d'évaluation permanent, au même titre que la sécurité ou la performance.

Ce que ça change dans le travail quotidien des équipes IT :

• Chaque décision d'outil — même un outil « mineur » de productivité adopté par une équipe métier sans passer par l'IT — devrait passer par une vérification minimale de souveraineté. Qui héberge ? Quelle juridiction ? Y a-t-il un plan de sortie ?
• Le shadow IT, dans ce contexte, n'est pas seulement un risque de sécurité. C'est un risque de dépendance invisible que vous découvrirez uniquement en cas de crise.
• Votre comité de direction doit comprendre que le coût d'un outil souverain légèrement plus cher aujourd'hui est une prime d'assurance, pas un gaspillage.

La question qui dérange : Est-ce que la souveraineté numérique apparaît dans vos KPIs IT ? Dans votre rapport annuel au COMEX ? Ou est-ce un sujet dont vous parlez entre vous, sans mandat formel et sans budget dédié ?

Ce que TikTok nous a appris que nous n'avions pas envie d'entendre

L'affaire TikTok n'a pas créé le problème de la dépendance logicielle. Elle l'a rendu visible à des personnes qui ne travaillent pas dans l'IT.

Pour les DSI et RSSI qui lisent ces lignes, la leçon n'est pas technique. Elle est politique, au sens littéral : les décisions prises dans des salles de réunion à Washington, Pékin ou San Francisco ont des conséquences directes sur la continuité opérationnelle de votre organisation. Vous n'avez pas voté pour ces décisions. Vous n'avez pas été consultés. Et pourtant, ce sont vos équipes qui gèrent l'urgence le jour où elles tombent.

Reprendre la main sur son SI, ce n'est pas rejeter la technologie américaine par idéologie. C'est refuser de subir des décisions que vous n'avez pas prises — et construire, outil par outil, contrat par contrat, formation par formation, un SI dont vous êtes réellement responsables.

Pas juste en théorie. En cas de 72 heures de crise.

*Ce guide est destiné aux équipes IT de PME et ETI européennes. Il ne constitue pas un conseil juridique. Les clauses contractuelles mentionnées doivent être validées avec un conseil spécialisé en droit du numérique.*