Contexte technique
J’aime ces histoires non pas pour le côté mème, mais pour la conclusion d’ingénierie très honnête. Vous demandez à un modèle de faire une évaluation « invulnérable » et, au lieu de simplement faire tourner la graine dans le code, il va chercher le réseau principal Bitcoin comme source d’aléa « vraiment imprévisible ». C’est là qu’on voit comment l’implémentation de l’IA peut soudainement dévier du bon sens vers le culte de la rigueur absolue.
Blague à part, il y a une logique technique. Le hachage d’un futur bloc Bitcoin ne peut effectivement pas être prédit à l’avance, et en tant que source d’entropie externe, cela fonctionne. Mais j’appuierais immédiatement sur pause : pour évaluer un modèle, j’ai généralement besoin de reproductibilité, d’une graine contrôlée et de statistiques claires, pas d’une attente de dix minutes pour un bloc et d’une dépendance supplémentaire à un réseau tiers.
Ce qui m’interpelle ici, ce n’est pas Bitcoin, mais la trajectoire de pensée du modèle. On lui a donné l’objectif de « ne pas faire confiance à l’aléa local » et il est consciencieusement parti chercher une source d’aléa plus « pure ». Pas la plus optimale, ni la moins chère, ni la plus rapide. Juste la plus protégée contre un défaut imaginaire.
Et c’est très révélateur pour les systèmes agentiques modernes. Si dans le prompt ou la spécification on laisse un trou du type « rends-le aussi fiable que possible », le modèle va commencer à bâtir une architecture IA pour le cas extrême, et non pour la tâche réelle. Ensuite, les gens s’étonnent qu’un simple eval nécessite soudainement un accès réseau, des API externes et une demi-journée pour s’exécuter.
Impact sur les affaires et l’automatisation
Pour les entreprises, la conclusion est simple : les exigences trop héroïques sont aussi dangereuses que les exigences faibles. Lorsque je conçois l’automatisation avec l’IA, je sépare toujours « statistiquement assez bon » de « cryptographiquement parfait ». Ces deux modes coûtent des sommes radicalement différentes.
Seuls de rares scénarios y gagnent, là où une source d’entropie externe et publiquement vérifiable est nécessaire. Presque tous les pipelines appliqués y perdent : eval, tests A/B, tests internes d’agents, évaluation par lots de la qualité. Vous obtenez alors des retards, une complexité d’intégration et une fragilité au lieu de bénéfices.
Je le vois constamment chez les clients : le problème ne vient pas du modèle, mais de la formulation des exigences. Chez Nahornyi AI Lab, nous ramenons précisément ces choses sur terre pour que l’automatisation IA ne se transforme pas en un fantasme d’ingénierie coûteux. Si votre système commence déjà à « penser de manière trop fondamentale » là où un simple résultat fonctionnel suffit, examinons l’architecture et construisons des solutions IA pour l’entreprise sans le culte de la perfection.