· 6 min de lecture
Et si, demain, l'API s'éteignait ?
Fable 5 a disparu en trois jours sans dégâts. L'occasion de tester, à froid, ce que devient votre organisation si l'accès au modèle s'arrête.
Fable 5 a vécu trois jours. Serveurs tombés, chiffre d'affaires perdu : quasi rien. Pourtant l'incident a eu lieu, pas dans les machines, dans les têtes. Une chose qu'on croyait acquise a cessé de l'être du jour au lendemain.
Prenez-le pour ce qu'il est : un exercice à blanc, gratuit. Le retrait de Fable 5 a fait surgir une question que la plupart des organisations repoussent depuis qu'elles bâtissent sur l'IA. Et il l'a fait surgir d'un coup, comme quand on franchit une ligne... Il y aura un avant et un après dans la façon dont les entreprises penseront leur dépendance à l'IA.
Reste à le prendre pour ce qu'il est : une première fois. Le premier tremblement avant les répliques et le seul moment où il soit encore confortable de répondre à la question qu'il pose.
La disponibilité, l'axe que personne ne chiffre
On choisit un modèle pour ce qu'il permet de faire. C'est rationnel - et c'est exactement là qu'est le piège. La dépendance ne naît pas d'un mauvais choix, mais d'un bon choix répété : meilleur modèle, donc plus de tâches, donc intégration plus profonde, donc repli de moins en moins crédible.
La boucle de la dépendance
boucle de renforcement
un bon choix répétéOr plus un modèle vous est stratégique, plus il l'est pour ceux qui en contrôlent l'accès. Vous voyez une API ; un État voit une ressource sensible, exportable, révocable.
Un même accès, quatre regards
L'entreprise voit une API
Un service performant qu'on appelle, qu'on intègre, qu'on paie à l'usage. Un outil, parmi les outils.
Le risque change selon l'endroit depuis lequel on regarde l'objet.
Le risque n'est donc pas seulement la panne ou la hausse de prix : c'est l'accès décidé ailleurs, à votre insu.
Ou, pour le dire avec un sourire un peu crispé, d'un matin où quelqu'un à Washington se réveille avec une idée nouvelle de ce qui devrait ou non traverser une frontière.
Les marchés appellent cela un risque géopolitique ; le reste du monde a parfois tendance à lui donner un prénom...
Les benchmarks mesurent ce que le modèle apporte tant qu'il est là. Jamais ce que son absence retire, une fois le travail réorganisé autour de lui.
La dépendance reste invisible jusqu'au test
Demandez-vous ce qui casserait, demain, si l'outil partait.
L'iceberg de la dépendance
- Surface : l'intégration technique. Facile à remplacer : on change une adresse, on re-teste.
- Milieu : prompts réglés par rapport au modèle, évaluations calées sur ce modèle, contournements devenus réflexes.
- Fond : vos équipes réorganisées, les compétences qu'on a laissées s'endormir. Invisible tant que l'outil fonctionne.
Ce qu'il faut garder chez soi
Pas question de refuser le meilleur modèle. Juste de ne pas lui confier toute la mémoire de votre façon de travailler. Trois choses restent chez vous : les tests qui disent si une réponse est bonne pour votre métier, les exemples réels d'usage, la mémoire des décisions prises avec l'outil.
D'où le seul test qui compte : pouvez-vous débrancher un modèle et en brancher un autre sans perdre l'expertise accumulée ?
Si oui, votre valeur est dans votre organisation, pas dans l'outil. Sinon, elle n'a jamais été chez vous.
Et c'est préventif. Une fois l'outil parti, les traces qui vous rendaient portable sont parties avec lui. On bâtit pendant que tout fonctionne...
Ce que ça change
Une seule bascule : de « quel est le meilleur modèle ? » à « mon organisation survit-elle au départ de n'importe quel modèle ? »
De là, des gestes que vous savez déjà nommer ailleurs : concevoir pour la substitution dès le premier jour, mesurer la portabilité comme un actif, faire entrer le « risque de disparition d'un modèleLe risque, propre à l'IA, que l'accès au modèle dont vous dépendez s'arrête du jour au lendemain - coupé, restreint ou rendu trop cher par une décision prise ailleurs. » à côté du risque fournisseurLe risque qu'un prestataire dont vous dépendez change ses prix ou ses conditions, ou cesse son service. Une entreprise sait déjà le suivre. et du risque homme-cléLe risque qu'une personne irremplaçable parte en emportant un savoir-faire que personne d'autre ne détient..
Rien à prédire. Juste à retenir une chose que Fable a rendue gratuite à apprendre : un modèle de pointe n'est pas un acquis ; c'est un accès que quelqu'un d'autre contrôle, et peut reprendre. On peut tout à fait s'appuyer dessus - à condition de pouvoir s'en passer du jour au lendemain.
Par où commencer
Pas besoin d'un grand chantier pour démarrer. Prenez un usage non critique et faites-le tourner sur un autre modèle, pour de vrai : regardez ce qui casse. C'est le moyen le plus simple, et sans risque, de découvrir ce que vous pourriez réellement garder le jour où il faudrait changer.
Tout ceci vaut pour une entreprise, qui peut changer de fournisseur. Mais changer de fournisseur, ce n'est pas cesser d'en avoir un. À l'échelle d'un pays, la nuance devient un gouffre et ça sera sûrement le sujet d'un prochain essai.
Sources
- 1.System card — Fable 5 & Mythos 5 (PDF)
- 2.La coupure comme kill-switch réglementaire : SLA, contrats, fallback
- 3.Le vendor lock-in de l'IA, plus subtil et plus dangereux que dans le logiciel classique
- 4.Le Commerce Department coupe l'accès au nom de la sécurité nationale
- 5.Dépendance fournisseur IA, en chiffres : 81 % inquiets, 47 % à l'arrêt, 6 % migrables sans heurt
- 6.Le lock-in IA sur cinq couches, au coût de sortie multiplicatif
- 7.Des prompts réglés pour un modèle précis : en changer devient un chantier
- 8.Portabilité multi-modèles : passerelles, clauses, stress-test annuel