C’est l’accès à l’IA, et non les capacités, qui représente le véritable risque de dépendance.
Cet article analyse des incidents récents de contrôle des exportations concernant Claude et GPT-5.6 afin de démontrer que l’accès aux modèles d’IA est une variable instable indépendante des capacités brutes.
Qu’est-ce qui distingue réellement la location d’intelligence de sa possession ?
Pendant environ trois ans, l’industrie s’est concentrée entièrement sur la mauvaise métrique.
Des débats ont eu lieu au sujet des points de référence, de la capacité de raisonnement, des taux d’hallucinations et de la taille de la fenêtre contextuelle — autant d’indicateurs de l’intelligence de ces systèmes.
Mais la question qui est plus importante aujourd’hui est différente : qui détient l’interrupteur permettant d’éteindre cette intelligence ?
Le 12 juin 2026, le gouvernement américain a imposé des restrictions à l’exportation sur deux des derniers modèles d’Anthropic, Claude Fable 5 et Claude Mythos 5.
Cette ordonnance exigeait qu’Anthropic bloque l’accès aux ressources pour les citoyens étrangers, quel que soit leur lieu de résidence aux États-Unis.
Anthropic a affirmé ne disposer d’aucune méthode fiable pour vérifier la nationalité en temps réel.
Face à cette situation, l’entreprise a pris une mesure drastique : elle a désactivé les deux modèles pour tous les ressortissants étrangers, y compris ceux qui figuraient sur sa propre liste de salariés.
Dix-huit jours se sont écoulés avant que le gouvernement ne retire ces restrictions. Fable 5 est redevenu accessible dans le monde entier le 1er juillet, tandis que Mythos 5 a été réactivé pour un groupe spécifique d’organisations américaines après avoir obtenu l’approbation gouvernementale le 26 juin.
OpenAI a ensuite suivi une trajectoire presque identique, mais en partant d’un angle opposé.
Le 26 juin, OpenAI a lancé GPT-5.6, mais à la demande du gouvernement, il a d’abord limité son accès à un petit groupe de partenaires préalablement sélectionnés dont les identités avaient déjà été communiquées aux autorités. OpenAI a clairement indiqué publiquement qu’il ne souhaitait pas que ce type de déploiement facilité par le gouvernement devienne une pratique courante à l’avenir.
Déjà le 9 juillet, GPT-5.6 était accessible à tous.
Considérez ce que cette séquence révèle réellement.
Rien n’a été saisi, supprimé ou endommagé à cause d’un code défectueux.
Pourtant, pendant une certaine période, certains des systèmes d’IA commerciaux les plus performants qui existent étaient techniquement opérationnels, mais inaccessibles aux utilisateurs eux-mêmes qui en avaient besoin.
Toute cette affaire ajoute une nouvelle dimension au débat en cours sur le rythme du développement de l’IA : il ne s’agit plus seulement de savoir à quelle vitesse nous devrions améliorer ses capacités, mais aussi de déterminer comment le déploiement et l’accès devraient être planifiés avec prudence.
La véritable leçon n’est pas que l’accès disparaît. C’est plutôt que l’accès fonctionne comme une variable indépendante, déconnectée des capacités elles-mêmes, guidée par sa propre logique, suivant son propre calendrier, et capable de changer de direction plus rapidement que toute organisation ne peut y réagir.
C’est une réalité bien plus inquiétante que celle d’une fenêtre qui se ferme lentement, car on peut s’adapter à une fenêtre qui rétrécit. On ne peut pas, en revanche, s’adapter à un interrupteur qui est actionné administrativement, dans des directions imprévisibles, sur une échelle de temps de quelques jours.
Voici donc la question à laquelle il vaut la peine de réfléchir : si le modèle sur lequel vous comptez disparaissait du jour au lendemain, votre travail survivrait-il ?
La propriété n’est pas un téléchargement
Lorsque les gens perçoivent une dépendance, leur réaction instinctive est d’aller acquérir quelque chose.
On récupère les poids ouverts, on les stocke sur un disque dur et on pense pouvoir être tranquille. Mais détenir un ensemble de paramètres ne couvre qu’une infime partie de ce que requiert une véritable indépendance, et confondre les deux crée un genre particulier de sécurité illusoire — l’équivalent, pour l’IA, d’acheter un groupe électrogène de secours sans jamais vérifier s’il fonctionne.
« Open weights » et « open source » ne sont pas des termes interchangeables — la définition de l’Open Source Initiative exige bien plus que simplement la possibilité de télécharger des paramètres, et une licence permissive pour l’exécution ne couvre pas automatiquement tous les modèles qui s’y exécutent.
Il est nécessaire de lire attentivement la licence spécifique qui régit chaque artefact et de conserver une copie archivée à côté de cet artefact.
La propriété des données relève d’un axe complètement distinct. Selon les conditions commerciales d’Anthropic, les clients conservent les droits sur tout ce qu’ils soumettent, détiennent la propriété des résultats générés entre les deux parties, et Anthropic est interdite d’entraîner ses modèles sur le contenu des clients via ces services. Le simple fait d’envoyer son contenu à un prestataire ne transfère pas la propriété. Le fait que ce contenu soit conservé par la suite est une question distincte, dont la réponse dépend du produit, du contrat et de la configuration précisément en vigueur — et non de ce que l’on a pu lire quelque part par hasard.
Rien de tout cela ne constitue un argument contre l’utilisation de modèles hébergés.
C’est simplement un rappel que l’expression « nous possédons notre IA » englobe cinq ou six conditions distinctes qui doivent toutes être remplies, et la plupart des équipes ne prennent même pas la peine de vérifier aucune d’entre elles.
L’arithmétique de l’autosuffisance
Calculer la quantité de mémoire nécessaire à un modèle est la partie simple de l’équation : il suffit de prendre le nombre de paramètres, de le multiplier par le nombre de bits utilisés par paramètre, puis de diviser par huit.
Un modèle de huit milliards de paramètres avec une précision de seize bits nécessite environ seize gigaoctets ; en passant à une précision de quatre bits, cette valeur diminue à environ quatre gigaoctets. Un modèle de soixante-dix milliards de paramètres consomme environ cent quarante gigaoctets avec seize bits, ou autour de trente-cinq gigaoctets avec quatre bits.
C’est généralement là que les gens cessent de réfléchir aux exigences en matière d’équipement, et c’est aussi le calcul qu’ils effectuent le plus souvent correctement.
Les vrais erreurs apparaissent plus tard dans le processus.
Le cache KV — la structure qui stocke l’état d’attention au cours d’une conversation — s’agrandit à mesure que les fenêtres de contexte s’allongent, et il augmente également avec chaque requête simultanée que vous traitez.
Les architectures de type mélange d’experts ajoutent leur propre complexité : puisque chaque token n’active qu’un sous-ensemble du réseau, le calcul effectif par token reste faible, mais chaque expert, actif ou non, doit néanmoins être stocké quelque part en mémoire.
Savoir combien de paramètres sont activés vous indique le coût de traitement par token. Cela ne vous dit rien sur l’espace occupé par le modèle.
Déplacer une partie du modèle ailleurs ne résout pas le problème de stockage, il le déplace simplement — et vous devez désormais payer une pénalité de transfert de données qui n’existait pas auparavant.
Un modèle qui parvient à s’charger en mémoire n’a pas pour autant prouvé qu’il peut réellement gérer le trafic.
La vitesse de traitement d’une requête, la vitesse de génération et le temps total nécessaire pour terminer une tâche sont trois indicateurs distincts ; être rapide à l’ingestion d’une requête ne vous dit rien sur la rapidité avec laquelle une réponse longue sera générée.
La charge de travail qui compte réellement est celle qui est exigeante : grands documents, plusieurs utilisateurs en même temps, appels d’outils qui se renvoient indéfiniment les uns aux autres.
Tester avec une seule requête courte masque précisément les retards de file d’attente et les conflits de mémoire qui rendent l’inference locale difficile dès que plusieurs personnes l’utilisent.
Ce qui relie ces erreurs, c’est un schéma récurrent : chacune d’elles prend un chiffre facile à citer et le confond avec le véritable facteur limitant.
Menez vos propres tests de référence sur le matériel que vous possédez déjà, ou louez du temps d’exécution avec exactement la configuration que vous évaluez avant de prendre une décision.
Acheter de la capacité avant d’avoir identifié où se trouve le véritable goulot d’étranglement est un bon moyen de s’assurer que ce dernier persistera.
Un prompt n’est pas une autorisation
Le malentendu le plus important dans la conception des agents n’a presque rien à voir avec le modèle que l’on utilise.
Lorsqu’un modèle génère une demande d’utilisation d’outil, il s’agit simplement d’une requête, rien de plus.
Un mécanisme distinct doit décider si cette requête est effectivement exécutée.
Il est surprenant de constater qu’il est facile de créer un système où ce mécanisme distinct n’est, en réalité, que le modèle qui se fait confiance à lui-même — renforcé par une instruction polie quelque part dans le prompt lui demandant de rester dans les limites.
Ce n’est qu’une préférence, pas une véritable limite, et c’est précisément ce que les attaques par injection de prompt exploitent.
Tout ce que votre agent récupère à partir de sources externes est considéré comme une entrée non fiable.
Héberger soi-même les poids détermine l’endroit où vos données se trouvent physiquement et si votre système dépend du fait qu’une autre entreprise reste en ligne. Cela n’a absolument aucun impact sur les actions que l’agent est réellement autorisé à effectuer.
Les équipes qui confondent ces deux aspects se retrouvent avec un modèle entièrement auto-hébergé qui peut néanmoins causer des dommages importants à leur propre base de code.
Au niveau d’une équipe entière, la même logique suggère de placer un gateway authentifié devant votre point d’extrémité d’inférence, de définir des budgets d’utilisation par utilisateur et d’établir une politique explicite pour chaque flux de travail : l’exécuter localement, autoriser un modèle hébergé autorisé ou le rediriger vers un humain pour examen.
Enregistrez des points de contrôle avant de réessayer les étapes échouées, et conçuez tous les outils ayant des effets secondaires de manière à ce qu’ils soient idempotents, afin qu’une tentative de récupération ne puisse pas répéter silencieusement une action qui a déjà eu lieu.
Pourquoi la fiabilité aggrave les choses
Imaginez que chaque étape d’un flux de travail automatisé ait une probabilité indépendante de 95 % d’aboutir avec succès. En enchaînant dix telles étapes, le taux de réussite global tombe à environ 60 % — 0,95 élevé à la puissance dix donne environ 0,599.
Avec vingt étapes, on tombe à environ 36 %.
Les étapes dans le monde réel ne sont pas vraiment indépendantes, donc considérez cela comme une illustration plutôt que comme une mesure précise. Néanmoins, cela montre quelque chose que la qualité du modèle ne peut pas annuler : la fiabilité par étape ne s’additionne pas, elle se multiplie, et ce de manière exponentielle avec la longueur de la chaîne.
Si l’on passe de 95 % à 98 % de fiabilité par étape, une séquence de dix étapes voit son taux de réussite passer de 60 % à 82 %. Mais si l’on ajoute dix étapes supplémentaires à un processus fonctionnant avec 95 % de fiabilité, on annule presque entièrement cette amélioration.
Cela change ce que l’on devrait réellement attendre d’un petit modèle local. Sa véritable fonction n’est pas d’être exceptionnel — c’est d’être fiable au sein d’un flux de travail court, à portée restreinte, facile à examiner et dont on peut facilement se remettre en cas de panne.
Et surtout, le nombre d’étapes dans ce flux de travail n’est pas déterminé par les poids du modèle. C’est un choix de conception que l’on fait en construisant l’application.
Réduire la chaîne de traitement, vérifier les résultats intermédiaires et intégrer des points de contrôle permettant de reprendre là où on s’est arrêté plutôt que de tout recommencer à zéro offre généralement plus de fiabilité que le remplacement par un modèle plus grand.
C’est aussi pourquoi l’évaluation ne peut pas rester vague ou basée sur des anecdotes.
Prenez cinquante tâches de votre liste de travail réelle, chacune avec un résultat attendu enregistré à un endroit où l’agent n’a pas la capacité d’écrire ou de modifier quoi que ce soit.
Suivez la correction : vérifiez si les appels aux outils étaient valides, l’latence, le nombre de tentatives nécessaires, ainsi que le temps passé par un humain pour corriger les problèmes par la suite — tout cela mesuré avec des tailles de contexte et des niveaux de concurrence réalistes, évalué selon les seuils que vous avez définis avant de savoir quel modèle s’avère le plus performant.
Une distinction mérite une colonne à part entière dans vos données de telemétrie : un modèle inatteignable et un modèle qui fournit une mauvaise réponse représentent des pannes fondamentalement différentes.
La première est un problème de routage et de récupération. La seconde est un problème de qualité.
En les fusionnant en un seul chiffre de taux de réussite, vous perdez précisément les informations qui indiquent si la véritable solution réside en plus de capacité, en un meilleur modèle, ou en une tâche plus petite et mieux ciblée.
Ce que vous achetez réellement
La seule comparaison qui vaille la peine d’être faite est le coût par tâche acceptée.
Comparer les prix des tokens, c’est comparer des choses qui ne sont pas similaires ; comparer les tâches acceptées, c’est comparer des choses qui le sont. Du côté local, vos coûts comprennent l’amortissement du matériel, l’énergie électrique, la maintenance, le temps d’inactivité et les efforts de révision. Du côté hébergé, il s’agit des tokens, des tentatives de relance et des efforts de révision.
Exécutez la même combinaison de tâches en respectant le même seuil d’acceptation des deux côtés — tout autre approche transforme la comparaison en simple spectacle.
Les calculs se font comme on pourrait s’y attendre.
Disons que l’infrastructure locale vous coûte six cents dollars par mois en frais fixes, avec chaque tâche acceptée coûtant deux cents en local contre vingt cents via une API hébergée. Le point d’équilibre se situe autour de 3 333 tâches acceptées par mois.
Ces chiffres sont indicatifs et non mesurés, mais le schéma de base reste inchangé : l’exécution des inférences localement représente un investissement à coût fixe qui ne s’avère rentable qu’une fois que l’on dépasse un certain seuil de volume, et qui entraîne des pertes en dessous de ce seuil.
La plupart des équipes resteront en deçà de ce seuil.
C’est là que l’argumentaire honnête en faveur de l’IA locale s’éloigne fortement du discours marketing.
Lorsque le point d’équilibre n’est pas atteint, l’exécution locale des inférences n’est pas la solution la moins chère, et prétendre le contraire rend ce choix indéfendable dès que quelqu’un examine réellement les chiffres.
En réalité, ce que l’on achète, c’est une optionnalité — la garantie de pouvoir continuer à fonctionner même en cas de changement des conditions d’accès, selon des critères que l’on contrôle.
Les options sont tarifées en fonction de leur volatilité, et non en fonction des résultats moyens attendus.
Si les perturbations récentes ont montré une chose, c’est que cette volatilité est réelle, qu’elle provient de décisions administratives plutôt que techniques, et qu’elle survient sans préavis.
C’est une raison légitime de dépenser de l’argent.
Mais c’est une raison différente de celle qui est généralement avancée, et elle mérite d’être défendue sur ses propres mérites plutôt que de être dissimulée sous prétexte d’une mesure d’économie.
Le test qui vous dit vraiment quelque chose
Rien de tout cela ne dépend du fait de croire que les lois de scalage continueront de s’appliquer, qu’une certaine fenêtre d’accès se ferme réellement, ou que l’AGI pourra ou non finir par tenir dans une quantité donnée de VRAM.
Ce sont des prédictions, et le risque de dépendance n’exige pas qu’elles soient vraies.
Tout ce qui est nécessaire, c’est de reconnaître qu’un système sur lequel on compte peut cesser de fonctionner pour des raisons qui n’ont rien à voir avec ses performances ou avec notre propre comportement. Cela a été le cas pour les réseaux électriques, les câbles sous-marins et les réseaux de paiement, et il en va désormais clairement de même pour les modèles d’IA avancés.
La réponse pratique n’est pas très enthousiasmante. Elle consiste principalement à acquérir des compétences que l’on prend actuellement pour acquises, ou que l’on suppose déjà gérées par quelqu’un d’autre.
Essayez ceci : reconstituez entièrement votre stack à partir des notes et sauvegardes que vous avez conservées, puis donnez ces mêmes notes à un autre ingénieur et observez-le tenter de la reconstituer de manière indépendante. Cette seule expérience vous apprendra davantage sur votre véritable autonomie que n’importe quel nombre de conversations fluides avec un modèle qui se trouve être en ligne aujourd’hui. Le fait que le modèle soit disponible maintenant ne prouve rien pour demain, et la seule preuve réelle de résilience est de savoir si votre configuration fonctionne sans lui.
Lectures complémentaires
- ReAct Explained : Comment les agents IA combinent le raisonnement et des actions dans le monde réel — Découvrez comment le framework ReAct combine raisonnement et utilisation d’outils pour donner de l’énergie aux agents IA, ainsi que ses différences par rapport aux modèles Chain-of-Thought, RL et de raisonnement.