Mes aventures avec Fable

On a beaucoup parlé récemment de Fable, le nouveau super modèle d'IA. Les forums débattent avec passion de ses implications en matière de cybersécurité, les législateurs discutent de son impact politique et les analystes financiers sont atterrés par ses coûts d'exploitation.

Pour mettre les choses en perspective, le prix de Fable est prohibitif. Nous parlons d'un coût d'accès à son API environ 10 fois plus élevé que celui d'Opus 4.8, incroyablement 50 fois plus coûteux que Sonnet 5, et environ 15 fois plus cher que la génération précédente de GPT (avant la sortie de Sol).

Malgré cet « impôt sur le génie », j'ai décidé de l'essayer sans préjugés. Mon ambition était la même que celle de tout directeur technique : faire plus, avec moins, et plus rapidement. Je voulais voir si le coût se justifiait par un retour sur investissement brutal.

Alors, mon équipe et moi avons connecté Fable directement à nos flux de travail et à nos analyses quotidiennes. Ce qui s'est passé au cours des 48 heures suivantes a été une leçon magistrale de brillance technique et d'absurdité commerciale.

Le génie proactif et la vulnérabilité de GitLab

Quelques minutes après avoir scanné notre infrastructure, Fable a levé la main. Il avait trouvé que notre environnement GitLab contenait des bibliothèques open-source vulnérables.

Pour ceux qui ne sont pas du domaine technique, GitLab est la plate-forme de développement collaboratif et de contrôle de version par excellence, utilisée par plus de 100 000 organisations dans le monde pour stocker leur code source et automatiser leurs déploiements. C'est, littéralement, le cœur de nos opérations logicielles.

Fable ne nous a pas seulement averti du problème. De sa propre initiative (et en consommant des tokens à la vitesse de la lumière), il est allé chercher le code source des bibliothèques, a analysé les correctifs et nous a fourni le processus de remédiation complet. Il est incroyable de penser que GitLab a cohabité avec ces détails pendant des années sans que presque personne ne les remarque, et que Fable les a démembrés en quelques minutes.

La base de données intouchable

Peu après, nous l'avons lâché sur un problème historique que nous avions : une dette technique dans une base de données MySQL très ancienne. Pendant des années, nous avions refusé de la toucher, en argumentant que, pour des problèmes de rétrocompatibilité avec les systèmes anciens, si nous la mettions à jour, nous romprions l'opération.

Lorsque nous avons demandé à Fable d'analyser pourquoi nous ne pouvions pas la migrer, le modèle a simplement ignoré notre prémisse humaine défaillante. Il a décidé que oui, c'était possible. En quelques heures, il a créé un script maître qui a mis à jour complètement le moteur MySQL et, en outre, a programmé tout le processus intermédiaire (un middleware) pour garantir la rétrocompatibilité. Il a résolu un problème que nous avions archivé dans le tiroir des « un jour ».

Le choc avec la réalité (et avec la facture)

Vu de l'ingénierie pure, Fable est de la magie. Mais vu de la direction des affaires, l'histoire est très différente. Quel a été l'impact de cette proactivité sur notre opération réelle ? Absolument rien.

Je confesse que nous n'avons pas mis en œuvre le correctif de GitLab. Pourquoi ? Parce que, après avoir analysé la vulnérabilité, nous nous sommes rendu compte que, dans notre contexte spécifique, cette faille ne mettait pas en danger mes données, ni celles de mes clients, ni nos projets internes. Nous pouvions vivre parfaitement ainsi.

D'un autre côté, la base de données MySQL que Fable a réparée magnifiquement est un système legacy (hérité) qui part bientôt. La réparer ne contribue pas à la valeur de nos objectifs pour ce trimestre, car le système entier sera bientôt mis hors service.

Et puis est venue la facture : les premières 48 heures d'utilisation autonome de Fable nous ont coûté 845 dollars de frais d'API. Nous avons dépensé presque mille dollars pour que une supercalculatrice résolve brillamment deux problèmes qui, opérationnellement, n'existaient pas.

Une hirondelle ne fait pas le printemps

À ce jour, Fable ne nous a pas trouvé d'autres problèmes opérationnels qui justifient son tarif quotidien. En fait, notre cheval de bataille actuel, Sonnet 5, trouve 95 % des mêmes problèmes avec un coût nettement inférieur.

Je ne doute pas de la puissance de Fable. Je suis sûr qu'il pourrait être utile dans les entreprises de cybersécurité offensive ou dans les laboratoires de biotechnologie. Mais je n'ai pas de preuve qu'il vaille la peine pour la grande majorité des entreprises traditionnelles aujourd'hui.

Bien sûr, ce sont des cas anecdotiques. Mon équipe et moi ne rejetterons pas Fable, mais nous le reléguerons sur l'étagère des « cas d'urgence ». Il ne sera utilisé que pour les projets impossibles.

Le véritable orchestrateur

Aujourd'hui, notre stratégie est beaucoup plus pragmatique. Nous utilisons Sonnet 5 pour les tâches lourdes et migrons les charges complexes vers GPT Sol (le nouveau modèle phare d'OpenAI qui a remplacé la numérotation traditionnelle, axé sur le raisonnement continu et les agents de très haute fiabilité).

Mais notre véritable pari pour l'avenir est l'IA locale. Nous suivons de très près Kimi K3, le puissant modèle chinois. Notre objectif est de le mettre en place sur nos propres serveurs. Le défi actuel de Kimi K3 est la quantité énorme de GPUs et de mémoire VRAM qu'il exige pour fonctionner, mais nous espérons que, avec une distillation et une quantification bien réalisées dans les prochains mois, Kimi pourra devenir le grand orchestrateur interne de nos agents d'IA, gratuit et privé.

En 2026, l'intelligence ne manque plus ; ce qui manque, c'est le bon sens pour savoir quand acheter une Ferrari pour aller au coin de la rue et quand il vaut mieux y aller à pied.

J'aimerais lire vos expériences. Êtes-vous en train de payer l'impôt de Fable ou préférez-vous optimiser ? Je vous lis.