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 termes de cybersécurité, les législateurs discutent de son impact politique et les analystes financiers sont atterrés par ses coûts opérationnels.

Pour mettre les choses en perspective, le prix de Fable est prohibitif. Nous parlons d'un accès à son API qui est environ 10 fois plus cher que l'utilisation d'Opus 4.8, asombrosamente 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 vite. 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 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 plateforme 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 jetons à 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émonté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 des systèmes anciens, si nous la mettions à jour, nous casserions 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éfaitiste. Il a décidé que oui, c'était possible. En l'espace de quelques heures, il a créé un script maître qui a mis à jour complètement le moteur MySQL et, en plus, 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 n'apporte pas de valeur aux objectifs de ce trimestre, car le système entier sera bientôt mis hors service.

Et puis est arrivé le coup de grâce : 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 sa tarification quotidienne. En fait, notre cheval de bataille actuel, Sonnet 5, trouve 95 % des mêmes problèmes avec un coût considérablement inférieur.

Je ne doute pas de la puissance de Fable. Je suis sûr qu'il pourrait être utile dans des entreprises de cybersécurité offensive ou dans des 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 des 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 migrer les charges complexes vers GPT Sol (le nouveau modèle phare d'OpenAI qui remplace 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 l'installer 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 qu'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 pas ; 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. Payez-vous l'impôt de Fable ou préférez-vous optimiser ? Je lis vos commentaires.