On a appris à coder, écrire, débugger et prototyper avec une IA, jusqu'à ne plus la voir. Puis, le 12 juin 2026, deux modèles ont été suspendus du jour au lendemain par décision d'un État. L'occasion de regarder en face une dépendance qu'on avait cessé de sentir, et de se demander ce qui reste vraiment à nous le jour où l'accès s'arrête.
Repensez à votre dernière vraie journée de travail. Le bug obscur résolu en dix minutes au lieu de deux heures. Le POC monté en trois jours quand il en aurait fallu trois mois. La doc, les tests, le mail relou, le bout de SQL que vous n’aviez pas envie d’écrire. Quelque part dans tout ça, vous avez ouvert un chat avec une IA, probablement plusieurs fois, sans même y penser.
C’est la signature d’une dépendance réussie : on ne la sent plus. En deux ans, l’IA générative n’a pas seulement rendu les équipes plus productives. Elle a baissé le niveau de stress, relevé la barre de qualité, raccourci la distance entre l’idée et la chose qui tourne. On s’y est habitué au point d’en faire le sol sous nos pieds.
Le 12 juin 2026, des centaines de millions de personnes ont découvert que ce sol pouvait se dérober. Le gouvernement américain a suspendu l’accès à deux modèles d’Anthropic, Fable 5 et Mythos 5, au nom de la sécurité nationale. Ni une panne ni une cyberattaque, mais une décision prise ailleurs, par d’autres, sans recours et sans préavis pour quiconque s’en servait pour travailler, y compris les propres salariés étrangers de l’éditeur.
La question cesse alors d’être théorique, et elle ne concerne pas que les directions : que devient votre façon de travailler le jour où l’IA s’arrête ?
Le jour où le sol s’est dérobé
Anthropic affirme que ses garde-fous sont « nettement plus efficaces que ceux de tout modèle déployé auparavant ». Le gouvernement, lui, s’appuie sur l’existence d’une méthode permettant de contourner ces protections (un jailbreak, en clair) pour justifier la suspension. L’éditeur conteste et prévient : si ce standard devenait la règle, plus aucun nouveau modèle ne pourrait être mis sur le marché.
Le bras de fer juridique est réel, et il est intéressant. Mais pour celui qui avait branché ces modèles sur son éditeur de code, sa CI, son support ou son pipeline de données, le débat sur la doctrine de sécurité nationale est secondaire. Ce qui compte tient en un constat simple : l’outil était là le 11 juin, il n’y était plus le 12, et il n’y avait ni ligne de code à corriger ni ticket à ouvrir, parce que l’interrupteur n’était pas dans le bâtiment. L’événement lui-même restera un cas particulier, mais ce qu’il met au jour ne l’est pas.
La dépendance qu’on ne sent pas
Un outil qu’on utilise consciemment, on sait qu’on en dépend. Un outil devenu réflexe, on l’a déjà intégré à soi, et c’est précisément là qu’on cesse de le voir. Le marteau disparaît dans la main du charpentier. L’IA a disparu dans la nôtre, plus vite que n’importe quel outil avant elle, parce qu’elle ne s’est pas glissée dans une tâche, mais dans la manière de penser une tâche.
C’est ce qui rend la dépendance difficile à mesurer. Demandez à une équipe « êtes-vous dépendants de votre IA ? » et la réponse sera mesurée : « c’est un outil parmi d’autres ». Coupez l’accès une journée et la réponse change. Ce qui revient n’est pas seulement un chatbot manquant. C’est une vitesse perdue, une barre de qualité qui redescend, une charge mentale qui remonte. On ne mesure pas une dépendance tant qu’elle fonctionne ; on la mesure à l’instant précis où elle s’arrête.
En termes d’ingénierie, ce que nous avons construit a un nom : un point de défaillance unique. Sauf qu’à la différence d’un serveur ou d’une base de données, celui-là ne figure sur aucun schéma d’architecture. Il est dans les habitudes, dans les réflexes, dans la façon dont une nouvelle recrue apprend désormais le métier. Un single point of failure qu’on a oublié de dessiner, parce qu’il n’est pas dans l’infra mais dans la méthode, et un point de défaillance qu’on ne voit pas reste un point de défaillance qu’on ne sauvegarde pas.
Trois mains sur l’interrupteur
Quand on cesse de regarder l’IA comme un produit et qu’on la regarde comme un accès, la bonne question devient : qui peut couper cet accès ? Il y a au moins trois mains sur l’interrupteur, et le cas Fable n’en illustre qu’une.
La main politique. C’est le scénario du 12 juin. Un État décide, pour des motifs de sécurité, de géopolitique ou de régulation, qu’un modèle ne doit plus être accessible. La décision ne vous vise pas, vous n’en êtes que l’effet collatéral. Vous ne pouvez ni l’anticiper ni la contester. C’est la forme la plus spectaculaire, et la plus récente.
La main commerciale. La plus banale, et de loin la plus fréquente. Un fournisseur déprécie le modèle sur lequel vous aviez calibré vos prompts. Il change ses conditions d’utilisation. Il multiplie ses tarifs, ou ferme l’offre que vous utilisiez. Rien d’illégal, rien de dramatique : juste un produit qui évolue à son rythme, pas au vôtre. La trajectoire de Tailwind Labs, contraint de licencier malgré son succès parce que l’IA a redéfini la valeur de son produit, rappelle que les modèles économiques bougent vite, et qu’un outil sur lequel vous comptiez peut disparaître pour des raisons qui n’ont rien à voir avec vous.
La main extraterritoriale. La plus discrète. La plupart des modèles propriétaires que nous utilisons sont édités par des entreprises domiciliées hors d’Europe, surtout aux États-Unis, et restent soumis à leur droit national même quand l’inférence tourne dans un datacenter européen. Une loi comme le CLOUD Act peut alors atteindre l’éditeur indépendamment de l’endroit où sont stockées les données, et les conditions de service relèvent d’un cadre sur lequel vous n’avez aucune prise. Il existe des exceptions, un éditeur européen comme Mistral ou un modèle open-weight que vous faites tourner vous-même, mais elles restent minoritaires dans les usages. C’est l’angle mort classique de la souveraineté technologique, celui que le diagnostic de souveraineté numérique et l’Indice de Résilience Numérique cherchent justement à rendre visible.
Trois mains pour un même geste possible, avec ce point commun que la décision, dans chacun de ces cas, se prend sans vous.
Ce que ça dit du métier
Voici la vérité contrariante, celle qu’on préfère éviter : une entreprise ne possède pas le modèle d’IA sur lequel elle bâtit sa façon de travailler. Elle en loue l’accès, et ce qui se loue peut se reprendre.
La conséquence est moins confortable qu’elle n’en a l’air. Si le modèle est loué, alors la valeur ne peut pas résider dans le modèle : il est, par construction, accessible à tous vos concurrents au même tarif. Le modèle est une commodité. Ce qui ne l’est pas, c’est ce que vous savez en faire, ce que vous comprenez quand il se trompe, ce que vous êtes encore capable de produire quand il n’est plus là.
C’est exactement le déplacement que nous décrivions dans « Le Code est mort, vive le Code ! » : quand le prix de la ligne de code s’effondre, la valeur migre vers les concepts, le jugement, la capacité à structurer un problème. Le cas Fable ajoute une raison de plus de prendre ce déplacement au sérieux. Ce n’est pas seulement que l’IA fait baisser la valeur de l’exécution. C’est que l’exécution déléguée peut, elle, vous être retirée, tandis que la compréhension, non.
La question pertinente n’est donc pas « quel est le meilleur modèle ? ». C’est « qu’est-ce qui reste à moi quand l’accès s’arrête ? », et la réponse à cette question-là ne s’achète pas au mois.
Travailler comme si l’accès pouvait s’arrêter
Tout ceci serait déprimant si la conclusion était « débranchez l’IA ». Ce n’est pas le propos. L’IA reste le meilleur multiplicateur de productivité que notre métier ait connu, et y renoncer par prudence serait une faute. L’enjeu n’est pas de moins dépendre, mais de dépendre de façon réversible, en gardant de l’optionalité là où on n’en avait plus pensé.
Concrètement, à l’échelle d’un poste et d’une équipe :
- Gardez la compétence sous le réflexe. Si vous ne savez plus faire sans l’IA ce que vous lui déléguez, vous n’avez pas gagné un outil, vous avez perdu une capacité. Sachez encore lire le code que vous ne tapez plus, débugger sans assistance, écrire le prompt mental avant le prompt réel. La maîtrise des fondamentaux est la première sauvegarde, celle que personne ne peut couper. C’est tout l’objet d’une pratique du code assisté qui renforce au lieu d’atrophier.
- Abstrayez le fournisseur dans votre outillage. Un workflow critique câblé en dur sur un seul modèle est un workflow à une seule main sur l’interrupteur. Passez par une couche d’orchestration, gardez vos prompts portables, évitez les dépendances profondes à une API que vous ne pourriez pas remplacer en une journée. La sécurité des agents et des connecteurs MCP impose déjà cette discipline d’architecture ; la résilience la prolonge.
- Ayez un modèle de repli, et testez-le pour de vrai. Un second fournisseur, ou un modèle open-weight que vous savez faire tourner localement, ne sert à rien s’il n’a jamais été branché. Faites l’exercice de bascule au moins une fois, comme on teste un PRA : coupez le modèle principal une demi-journée, et regardez ce qui casse. Vous découvrirez votre vraie dépendance, pas celle que vous imaginez.
- Décidez ce qui mérite d’être internalisé. Tout ne se loue pas avec le même risque. Un usage de confort tolère une coupure ; un usage au cœur de la production, non. C’est l’arbitrage build vs buy appliqué à l’IA : pour les fonctions vraiment critiques, la question de maîtriser sa propre stack n’est pas idéologique, elle est opérationnelle.
Aucune de ces actions ne demande de renoncer à la vitesse. Elles demandent seulement de ne pas confondre vitesse et solidité, et de se souvenir qu’un système rapide qui dépend d’un seul accès n’est pas un système rapide, mais un système exposé qui n’a pas encore rencontré son mauvais jour.
Aller plus loin
Mesurer sa dépendance avant qu’elle ne se rappelle à soi, c’est tout l’objet de notre diagnostic de souveraineté numérique : vingt-et-une questions, six axes, un score et une cartographie de vos angles morts. Gratuit, et conçu pour produire des réponses honnêtes plutôt que rassurantes.
