Kill switch : et si votre prochaine panne n'était pas technique ?

On pensait que c'était un risque théorique. C'est fini.

Je travaille avec des DSI depuis plus de quinze ans. La question de la dépendance technologique a longtemps été traitée comme un sujet de veille, pas d'urgence. On cochait la case "plan de continuité", on négociait des SLA, et on passait à autre chose.

L'affaire Anthropic change la donne. Pas parce qu'elle est unique — elle est au contraire le symptôme d'un mouvement de fond. Broadcom a racheté VMware et multiplié les prix par 10 pour certains clients. Des éditeurs SaaS ont fermé des modules sans préavis. Et maintenant, une décision politique à Washington peut priver une entreprise française de ses outils d'IA du jour au lendemain.

Le kill switch existe. Et il n'est pas entre vos mains.

Le vrai problème, ce n'est pas le cloud

J'entends souvent : "On a rapatrié nos données en France, on est souverains." Non. La souveraineté d'infrastructure ne suffit plus.

Le vrai risque, c'est la dépendance applicative. Vos applications métier critiques — celles qui font tourner votre facturation, votre logistique, votre relation client — sont-elles réellement sous votre contrôle ? Ou reposent-elles sur des frameworks propriétaires que vous ne maîtrisez pas, des API tierces qui peuvent disparaître, des licences que vous ne possédez pas ?

Un DSI m'a dit récemment une phrase qui m'a frappé : "Je sais où est hébergée la donnée. Je ne sais plus à qui appartient le code qui la traite."

C'est exactement le problème.

Le refactoring d’application métier n'est pas un projet technique. C'est une stratégie de résilience.

Chez Claranet, nous accompagnons des entreprises dans la modernisation de leurs applications depuis des années. Ce que l'actualité récente révèle, c'est que ce travail n'est plus seulement une question de performance ou de dette technique : c'est une question de survie opérationnelle.

Concrètement, le refactoring d’applications métiers permet de :

Clarifier sa dépendance au code. Sortir des applications monolithiques non documentées, identifier précisément où votre architecture repose sur un éditeur unique sans alternative possible. L'objectif n'est pas de tout réécrire en open source, mais de savoir exactement ce que vous risquez — et de garder la main quand c'est stratégique.

Découpler les composants. Une architecture microservices bien conçue vous permet de remplacer un brique sans faire tomber le reste. Si demain votre modèle d'IA favori est coupé, votre système doit pouvoir basculer sur une alternative en heures, pas en mois.

Construire pour la portabilité. La containerisation (Docker, Kubernetes) n'est pas qu'une mode DevOps. C'est la capacité de migrer d'un cloud à un autre, d'un fournisseur à un autre, sans réécriture intégrale.

Intégrer le FinOps dès le départ. La dépendance technologique a un coût financier direct. Pouvoir switcher de fournisseur, c'est aussi négocier en position de force — pas sous contrainte.

La modernisation applicative est devenue un enjeu de gouvernance

Je vais être direct : trop d'entreprises abordent encore la modernisation applicative comme un projet IT parmi d'autres, avec un budget serré et un horizon de 18 mois. C'est une erreur de cadrage.

La question du kill switch doit remonter au COMEX. Parce que le jour où votre application critique tombe — non pas pour une raison technique, mais pour une décision politique ou commerciale prise à des milliers de kilomètres — ce n'est pas votre DSI qui sera en difficulté. C'est votre business.

Ce que je recommande aux DSI que je rencontre aujourd'hui : commencez par cartographier vos dépendances critiques. Quelles applications seraient paralysées si un fournisseur clé disparaissait demain ? Quelles sont celles où vous n'avez ni accès au code source, ni capacité de migration rapide ?

Ce diagnostic prend peu de temps. Les conclusions sont souvent inconfortables. Mais c'est le point de départ de toute stratégie de résilience sérieuse.

Il ne s'agit pas de bannir toute solution propriétaire ou tout fournisseur étranger. Une dépendance maîtrisée, documentée et assumée n'est pas un problème en soi. Le danger, c'est la dépendance subie, celle qu'on découvre le jour où elle se rompt. L'enjeu n'est pas l'indépendance à tout prix, mais la capacité à choisir et à réagir.

La bonne nouvelle

La modernisation n'implique pas de tout reconstruire. C'est l'idée reçue qui bloque le plus de projets. Une approche incrémentale — par sprints, par domaine fonctionnel, avec une feuille de route claire — permet de réduire progressivement l'exposition au risque sans déstabiliser le business.

Le premier niveau, c'est de savoir où vous en êtes. Le dernier, c'est une application résiliente, portable, et réellement sous contrôle. 

Entre les deux, il y a un chemin. C'est précisément ce chemin que nous construisons avec nos clients.. 

Vous souhaitez cartographier vos dépendances applicatives ?