AI — Jakub Ćwirlej

Un jeu de lecture : quand vous lisez régulièrement, un robot mange une ligne du code de ce site et marque des points ; un défilement trop rapide ou irrégulier lui fait rater des caractères. Décoratif — il n’affecte jamais le texte.

…Je n’ai aucune formation formelle en programmation ni en entraînement de LLM.

Je me suis lancé dans le développement d'applications et l'entraînement d'IA à la suite d'un concours de circonstances complètement étrange, qui, avec le recul, me paraît pourtant assez logique. Et qui dit, je crois, quelque chose d'important sur notre époque. Je ne l'avais pas prévu ; je n'imaginais pas avoir un jour plus affaire à la technologie qu'un utilisateur lambda d'iPhone. Pendant des années, ma seule fenêtre sur le monde de la Big Tech a été le podcast Hard Fork. Salut à Casey et Kevin :)

Tout a commencé avec le vibe coding et l'application OrsonAI. En m'amusant avec l'intelligence artificielle, je me suis mis à créer des outils qui pouvaient m'aider dans mon travail quotidien de journaliste. Transcrire les interviews pendant l'enregistrement et les importer dans l'éditeur de texte, ou encore un mode d'édition permettant de soumettre au chat des passages choisis du texte sans jongler entre les fenêtres ni recopier tout le contexte : à l'époque, c'étaient vraiment des outils sympas, qui accéléraient nettement mon travail.

Avec le temps, j'ai commencé à y penser comme à un projet, à quelque chose qui pourrait aussi servir à d'autres. L'idée était simple : partir des fonctions qui me font gagner du temps et en faire un produit pour ceux qui se heurtent aux mêmes problèmes. J'ai consacré beaucoup de temps à concevoir l'interface et des mécanismes capables d'offrir aux rédactions une IA sûre – une IA qui aide le journaliste sans faire le travail à sa place. J'ai même conçu un système délivrant des certificats d'origine humaine pour les textes, publié sur le registre public de Hedera Hashgraph. Une preuve immuable, ayant valeur probante devant un tribunal, qui montre comment le texte a été produit et quelle part l'humain a prise dans sa création.

Vous trouverez ici une description de la technologie HDKVous pouvez télécharger ici la bibliothèque HDK gratuiteHDK sur Hugging Face

J'ai pourtant essuyé une sérieuse déception. Les gens du métier à qui je montrais l'application lui ont réservé un accueil plus que froid. La question qui revenait à la fin de chaque présentation me faisait mesurer douloureusement à quel point je m'étais trompé : « Pourquoi est-ce que quelqu'un paierait pour ton appli, alors qu'on a ChatGPT gratuit ? » Le certificat d'origine humaine, la protection des données, ou même un net gain d'efficacité par rapport à ce que proposait un simple chatbot : rien de tout cela ne comptait. Je l'entendais de la bouche de gens qui rappellent tous les jours l'importance d'un journalisme rigoureux.

Le travail sur l'application, et sur un système d'IA agentique assez fiable pour servir dans des rédactions, m'a toutefois poussé dans une direction entièrement nouvelle. En cherchant à mieux comprendre d'où viennent les hallucinations des modèles de langage, je me suis mis à lire des articles scientifiques publiés sur arXiv, et j'ai fini par concevoir et mener une série d'expériences sur l'activation des portes SwiGLU dans plusieurs modèles de langage ouverts. J'en ai exposé les conclusions dans plusieurs articles, mis en ligne sur ResearchGate. Avec le recul, certaines thèses de ces travaux me semblent mégalomanes, et le texte mériterait sans doute d'être corrigé et doté d'un vocabulaire plus scientifique ; je ne les retire pas pour autant – ne serait-ce que par intégrité scientifique.

Vous trouverez ici mes travaux sur ce sujet

Aujourd'hui, avec davantage d'humilité, acquise sur le terrain d'entraînement des modèles de langage, après bien des expériences ratées et des déceptions, si j'écrivais sur les signaux GSI que j'ai trouvés, je parlerais plutôt de signaux proxy de la connaissance que de « conscience épistémique » du modèle. En revanche, des données solides m'ont permis d'observer que la confabulation est en grande partie un processus en deux temps, dans lequel le modèle – faute de pouvoir s'appuyer sur des faits – choisit presque toujours la cohérence de la forme au détriment de la vérité. Ce fut pour moi, personnellement, le moment le plus intéressant de ces expériences : celui où mes anciens intérêts pour la philosophie et l'épistémologie ont trouvé un reflet inattendu, et entièrement mesurable, dans l'architecture des transformers. Reste une autre question : l'utilité au quotidien de ces signaux en conditions de production. Comparer leur efficacité à celle des autres méthodes de détection des hallucinations exigerait sans aucun doute des recherches supplémentaires.

Cette tâche m'a absorbé tout entier. C'est peut-être un peu dans ma nature : j'aime m'investir dans des activités qui représentent un défi, mais qui me permettent aussi d'apprendre quelque chose sur le monde qui m'entoure et de mieux le comprendre. D'ailleurs, avant de me tourner vers le journalisme, j'ai étudié la philosophie, en m'intéressant surtout à la philosophie des sciences et à l'épistémologie.

Vous trouverez ici un essai qui résume certaines de mes réflexions

L'entraînement de mon propre modèle a tourné à la catastrophe totale. J'ai sans doute commis toutes les erreurs possibles, et ce malgré mon habitude de me documenter sérieusement et l'énorme quantité de littérature spécialisée que j'avais engloutie. Les premiers résultats semblaient prometteurs, mais je n'ai compris qu'après coup qu'ils devaient beaucoup à une régularisation par le bruit. L'avantage du modèle dans les tests d'ablation ne compensait pas le surcoût de calcul (compute) qu'imposait le Gini des activations des portes. À cela se sont ajoutés des défis purement techniques liés à l'entraînement. Laissées hors normalisation, mes modifications freinaient l'apprentissage ; normalisées, elles s'aplatissaient, et le modèle devenait un transformer standard, simplement plus cher à entraîner. Je mets les détails de l'architecture en téléchargement ici – peut-être quelqu'un y trouvera-t-il de quoi tirer des leçons des erreurs d'autrui.

Une solution mérite malgré tout, à mon avis, l'attention : la porte M2. Grâce à une ancre affine, elle permet de conserver un fonctionnement fondé sur la fonction sigmoïde sans risquer d'être tirée vers le bas par un optimiseur paresseux, en quête d'un moyen facile de faire baisser la perte d'entraînement. Dans mon modèle, cette porte, apprise à partir des signaux de Gini des activations, devait couper le bruit pendant la génération. Mais sortir le signal de la normalisation – je l'ai dit plus haut – conduisait à un modèle dont la distribution de confiance était excessive : plus habile sur le plan logique, mais de facto moins doué pour apprendre les faits. Cette solution pourrait peut-être servir dans d'autres modèles, pour appliquer un gating à d'autres éléments, et faciliter l'entraînement.

J'ai fini par considérer tous mes échecs d'entraînement sur ma propre architecture comme un capital à ne pas gaspiller. Aujourd'hui, j'entraîne mon propre petit modèle, EUGEN 160M, spécialisé dans le code. Au vu de ses résultats aux benchmarks jusqu'ici, je suis d'un optimisme prudent et je pars du principe que ce ne sera pas du temps perdu. J'ai choisi un modèle spécialisé dans les langages backend parce qu'avec ce type d'architecture, il est plus facile de suivre les progrès, et que le modèle lui-même peut faire un outil d'autocomplétion utile, capable de tourner en inférence sur un simple CPU. On peut tester le modèle dans un terminal spécialement conçu sur mon site, et le comparer à d'autres solutions ouvertes de taille similaire.

Vous pouvez tester le modèle Eugen 160M ici

Les résultats obtenus jusqu'ici, je les dois avant tout à un suivi rigoureux des progrès du modèle et des erreurs qu'il commet lors de la génération. Cela m'a permis d'intervenir au fil de l'eau, en ajoutant des données d'entraînement pour renforcer le modèle là où il montrait des faiblesses. J'ai aussi eu régulièrement recours aux techniques STaR et LEMA, en créant des données synthétiques à partir de ce que le modèle avait lui-même généré, ainsi que des données de traduction qui enseignent au modèle la logique du code en lui montrant des exemples de traduction entre le Python et le C++, le Java ou le Rust. L'ensemble de ces données représente actuellement environ 0,35 % du jeu de données total, et leur part augmentera progressivement à mesure que l'entraînement avancera.

Travailler sur l'entraînement du modèle m'amuse énormément et – comme autrefois le journalisme – me donne le sentiment de faire quelque chose d'important ; quelque chose qui m'aide à mieux saisir les transformations du monde qui m'entoure. Je ne suis pas capable d'écrire seul un code C++ complexe en partant de zéro, c'est un fait, mais j'essaie de comprendre la logique des processus. C'est ainsi que j'engrange de petites victoires, qui me permettent d'avancer dans mon travail. Oui – avec l'aide d'un agent IA de codage, j'ai créé mon propre kernel Triton, qui permet d'entraîner un modèle sparse en améliorant le TPS (Tokens Per Second) de 23 % par rapport à un modèle dense ; les optimisations suivantes du kernel y ont ajouté 36 %. J'ai l'intention de m'en servir pour entraîner mon prochain modèle, un peu plus grand.

Vous pouvez télécharger le kernel iciLe kernel sur Hugging Face

Mais revenons au modèle par lequel tout a commencé… Aujourd'hui, je vois bien que ma plus grande erreur n'était pas une naïveté d'ingénieur. Ce modèle n'avait tout simplement aucune chance de fonctionner comme je l'avais prévu. Le problème n'était pas technologique, mais purement philosophique. Et moi qui ai étudié la philosophie, j'aurais dû le repérer dès le départ, avec en tête la définition de la vérité de Tarski et les théorèmes de Gödel. Selon eux, aucun système suffisamment complexe ne peut démontrer pleinement sa propre cohérence, ni définir la vérité depuis son seul niveau. Tenter de forcer le modèle à analyser, évaluer et corriger ses propres états internes en temps réel l'enfermait dans une boucle structurelle dont – sans métaniveau ni point de référence extérieur – il n'y avait tout bonnement pas d'issue.

Quand je me suis lancé dans cette aventure, je voulais simplement créer un outil pour faciliter la transcription des interviews journalistiques. Mais il est très vite apparu qu'entrer dans le monde de l'intelligence artificielle, c'était plonger pour de bon dans le terrier du lapin d'« Alice au pays des merveilles » – plus on descend, plus tout devient complexe, stratifié et fascinant. Ma première application n'a peut-être pas révolutionné le marché des médias, mais cette chute dans le terrier m'a conduit au point où j'entraîne avec succès ma propre architecture. J'ai parcouru un long chemin, de l'auditeur passif de podcasts tech à quelqu'un qui façonne concrètement les paramètres des modèles et comprend ce qui se passe à l'intérieur.

Si vous avez des questions, j’y répondrai avec plaisir.

Un jeu de lecture : quand vous lisez régulièrement, un robot mange une ligne du code de ce site et marque des points ; un défilement trop rapide ou irrégulier lui fait rater des caractères. Décoratif — il n’affecte jamais le texte.

1. Les calculs faits sur le papier seront toujours trop optimistes

Quand on pense à l'entraînement d'un modèle, c'est naturellement le processus d'apprentissage automatique qui vient à l'esprit – un travail qu'accomplissent pour nous de puissants clusters Nvidia dans des centres de données ou, avec un peu plus de chance, notre propre station de travail, d'une puissance infernale. En lisant les fiches techniques, on oublie facilement que le MFU (Model FLOPs Utilization) réel est bien inférieur à ce que suggèrent les documents marketing des fabricants de cartes. Selon l'architecture et la granularité, le matériel ne vous laissera tirer du silicium qu'une fraction de sa puissance de calcul. À quoi bon une carte qui calcule en FP4, si l'entraînement d'un modèle de base à partir de zéro n'y est pas stable, ou si, à la largeur de votre modèle, descendre sous le BF16 n'apporte aucun gain ?

Le moment où vous comprenez que vous ne pourrez pas entraîner le modèle prévu dans les délais escomptés, ni même dans une taille approchante, n'est pas facile à vivre. Surtout si vous avez passé des semaines à arriver au point où vous pouvez lancer l'entraînement, pour découvrir soudain que tout le plan était irréaliste. Sur le papier, pourtant, tout collait ! Premier réflexe : chercher des méthodes d'optimisation – torch compile, autocast, flash attention, FLCE, des têtes et un minibatch dont la taille est calée sur les préférences de CUDA. Tout cela fonctionne, mais on ne triche pas avec la physique du silicium. Si vous entraînez un petit modèle, sa faible largeur jouera contre vous. Si vous n'avez pas les moyens d'entraîner un grand modèle, vous n'avez pas non plus les moyens de tirer le maximum de votre GPU. Arriver à exploiter la carte de façon optimale peut prendre des jours, et une baisse finale du TPS (Tokens Per Second) de 30 à 40 % à l'entraînement par rapport aux calculs initiaux, cela représente des jours, voire des semaines de travail de la carte.

2. Commencez toujours à la plus petite échelle capable de valider vos idées

Mon premier modèle comptait 1,5 milliard de paramètres, et je n'ai pu l'entraîner que jusqu'à trois Chinchilla. J'ai commis beaucoup d'erreurs en le construisant, mais il fonctionnait malgré tout. Ce qui l'a condamné à n'être presque d'aucune utilité, c'est avant tout le sous-entraînement. Si, avec le même budget, j'avais choisi d'entraîner un modèle dix fois plus petit, j'aurais pu me targuer d'un modèle bien entraîné et utile. J'aurais eu le temps de faire des tests et j'aurais certainement évité bien des erreurs, ce qui m'aurait permis de construire une meilleure architecture. Bien sûr, la taille compte, mais les données, l'architecture et l'efficacité de calcul comptent encore davantage. Les chances de concevoir un bon modèle à partir de la littérature, sans tests et sans erreurs, sont à peu près celles de gagner au Loto.

3. Un modèle ne s'entraîne pas tout seul

Entraîner un modèle, ça a l'air sympa, mais c'est bien plus ennuyeux qu'on ne l'imagine. En réalité, il s'agit surtout de concevoir sans cesse des expériences, de faire des mesures, d'analyser les résultats du modèle et de chercher des solutions aux problèmes qui surgissent en cours de route. Tout le temps, en boucle, jour après jour. Si vous ne savez pas tirer de satisfaction des petites découvertes et des modestes réussites, cela risque de vous paraître trop ennuyeux. Or c'est précisément une constance de fer dans les mesures qui décide de tout. Même avec des paramètres d'entraînement bien choisis, il peut s'avérer avec le temps que notre modèle a besoin de nouvelles données, ou qu'il se dégrade d'une manière difficile à repérer au premier coup d'œil. Vous ne le remarquerez pas sans un bon monitoring et des tests continus, et moins vous en faites, plus vous perdrez de temps si le modèle se met à se comporter de manière indésirable.

Prenons un scénario fréquent. Après quelques jours d'entraînement, vous vous apercevez que le modèle répond de plus en plus brièvement, tout en étant de plus en plus sûr de lui. La loss et l'ensemble held-out ont bonne mine, mais quelque chose cloche avec le modèle. Si vous analysez les normes au fil de l'eau et comparez chaque jour les réponses du modèle à celles de la veille, vous pouvez vite repérer la hausse des logits et comprendre que le modèle attribue une probabilité de plus en plus forte à certains tokens. Cette arrogance est une ruse de l'optimiseur paresseux : AdamW a trouvé le moyen de nous tromper et, au lieu de faire apprendre le modèle, il réduit la perte autrement. Si vous le repérez au bout de quelques jours, vous en serez peut-être pour quelques dizaines de dollars ; si vous laissez tourner l'entraînement en comptant sur le GPU Nvidia pour faire tout le travail, vous risquez d'en dépenser des centaines, voire des milliers, et le modèle sera peut-être déjà impossible à sauver.

J'ai moi-même passé des semaines à regarder Adam gonfler les normes de mes modèles, en abaissant le learning rate (LR) effectif, et ce malgré la normalisation QK-norm et un weight decay de 0,1. L'entraînement ralentissait, à me désespérer, car, comme on le sait, c'est le théorème de Pythagore qui joue ici : plus le vecteur de poids grandit, plus il est difficile de le faire tourner avec un LR constant. Le phénomène est bien décrit dans la littérature, mais tant que vous ne l'aurez pas vu de vos yeux, vous ne comprendrez pas pourquoi il vaut mieux passer à un autre optimiseur. Après tout, AdamW a permis d'entraîner des centaines de modèles. J'ai finalement opté pour MuonH, et ce fut l'une des meilleures décisions que j'aie prises. Bien sûr, beaucoup de choses de ce genre se trouvent dans la littérature, dans les manuels ou dans les articles publiés sur arXiv, mais on ne sait jamais comment elles fonctionneront chez soi. Nombre de solutions qui, en théorie, devraient apporter des bénéfices bien documentés n'ont pas fonctionné chez moi. Vous n'en aurez le cœur net qu'en vérifiant par vous-même, et pour cela, il faut rester vigilant et suivre les progrès en continu.

4. Ne changez jamais qu'une seule chose à la fois, et faites des tests d'ablation

Ces derniers mois, j'ai testé des centaines de petits modèles – aussi bien des transformers classiques que mes propres idées… et je sais aujourd'hui que je n'ai pas assez testé. À vouloir avancer trop vite, j'ai perdu du temps pour rien. Nombre de couches, ratio FFN, d_model, partage des poids, taille des têtes, nombre de têtes KV, batch, optimiseur, récurrence, parcimonie (sparsity), données d'entraînement : les facteurs qui influent sur le comportement du modèle se comptent par dizaines, et leurs combinaisons donnent des milliers d'architectures possibles. Et même si, grosso modo, tout fonctionne comme on peut s'y attendre après avoir lu un premier manuel d'ingénierie de l'IA, tant que vous n'aurez pas testé vous-même votre architecture, vous ne saurez pas où vous en êtes. Or de petites modifications peuvent souvent entraîner de grandes différences d'efficacité de calcul et de résultats aux benchmarks, et ce à jeu de données et taille de batch identiques. Si vous n'introduisez pas les changements un par un, il est facile de s'y perdre. J'ai moi-même commis cette erreur bien des fois. Ce n'est pas que les modifications étaient mauvaises. Même si elles l'étaient souvent. Le vrai problème, c'est que lorsque je faisais réellement un pas en avant, j'étais incapable de dire à quelle modification je le devais.

5. Commencez par les données

Pour entraîner un petit modèle, Hugging Face offre un réservoir de données d'une ampleur inimaginable. On pourrait croire que, si ces données sont à portée de main, en quantités qui dépassent largement les besoins de n'importe quel projet de garage, l'affaire est réglée. Pourtant, le choix des données compte bien plus qu'on ne le pense au départ. Et le fait qu'elles aient déjà été rassemblées en jeux de données prêts à l'emploi ne simplifie en rien les choses. S'y ajoute le choix du bon tokeniseur, des langues qu'on veut apprendre au modèle, ou des proportions. Par exemple, décider quelle part des données doit être du code, quelle part des mathématiques et quelle part de la langue naturelle. Puis choisir les domaines dans lesquels notre modèle doit se spécialiser. Plus on creuse, plus les possibilités se multiplient. J'ai moi-même dû préparer mon jeu de données à partir de zéro pas moins de trois fois. J'ai aussi connu quelques ratés de moindre ampleur, comme une fuite du template instruct que je n'avais pas repérée lors de la préparation des données. Chacune de ces erreurs m'obligeait à ramener l'entraînement plusieurs heures, voire plusieurs jours en arrière.

6. N'en attendez pas trop

À voir les grands laboratoires, et les plus petits, repousser sans cesse les limites de ce dont l'IA est capable, on a vite fait de croire qu'entraîner un modèle utile est au fond une affaire simple. Mais si repousser ces limites coûte des milliards de dollars, ce n'est pas sans raison. Que votre modèle se mette à parler comme un humain ou qu'il obtienne de bons scores sur les benchmarks populaires ne dit rien de sa qualité finale ni de son utilité. Les modèles apprennent très vite au début, dans les premiers jours de l'entraînement, mais chaque point de pourcentage supplémentaire se gagne à force d'astuce, d'attention et d'abnégation. Surtout quand, pendant des jours, vous voyez le modèle stagner sur un plateau, voire régresser. Par ailleurs, les benchmarks populaires en disent peu sur les capacités réelles d'un modèle. Votre modèle peut être bon en Python et faire d'excellents scores sur HumanEval et MBPP, mais s'il ne connaît pas les bibliothèques les plus récentes, son utilité dans le monde réel restera modeste.

7. Armez-vous de patience

Beaucoup de capacités des modèles progressent par bonds. Ce phénomène bien décrit, le grokking, est souvent précédé d'un long plateau qui peut durer des jours. Quand vous voyez le modèle ne faire aucun progrès, alors que chaque heure d'entraînement vous coûte des dollars en location de puissance de calcul, ou ne serait-ce qu'en électricité, difficile de ne pas douter. Vous vous dites : « Le modèle a atteint sa capacité, il n'apprendra plus rien », ou : « Les grands labos, qui entraînent jusqu'à 1000× Chinchilla, ont sûrement des astuces. » Or les capacités progressent souvent par bonds. Il suffit que le modèle apprenne à terminer proprement une fonction pour que, d'un coup, ce ne soit plus une seule tâche de MBPP qui passe, mais une bonne dizaine. Souvent aussi, le modèle fait de vrais progrès, mais si, par souci d'économie, vous ne surveillez que le top1 des réponses au lieu du top10, vous pouvez ne rien en voir pendant longtemps. Le modèle doit apprendre à attribuer davantage de confiance, et cela prend du temps.

8. Une seule carte ne suffit pas

On pourrait croire que, si vous disposez d'un H100 ou d'une RTX PRO 6000 (96 Go), seul votre budget vous limite. Le problème, c'est que l'entraînement exige des tests et des mesures en continu, pour savoir où l'on en est. Un GPU de plus peut aussi être nécessaire pour générer des données d'entraînement supplémentaires. J'ai moi-même fait des progrès notables dans l'entraînement de mon modèle avec la méthode STaR, qui consiste à faire générer par mon propre modèle une grande quantité de tâches et à ajouter au jeu de données celles qui sont correctes, ainsi qu'avec un ensemble de données contenant des exemples de traduction entre langages de programmation

Interrompre l'entraînement sur une carte puissante le temps que le modèle génère des réponses coûte très cher et n'est tout simplement pas rentable ; générer en parallèle – même si la VRAM le permet – peut faire courir un risque sérieux. La dernière chose que vous souhaitez, c'est découvrir au bout de trois jours, quand les résultats du modèle chutent, que pendant la génération lancée sur la carte à côté de l'entraînement, le loader a connu par exemple un « affamement » passager, et que la loss a de ce fait discrètement cessé de baisser. À un stade avancé de l'entraînement, ce genre de chose est souvent extrêmement difficile à repérer, même avec un monitoring qui vous alerte en cas de pics de normes.

9. Commencez par quelque chose de simple

J'ai commencé à construire mon premier modèle sur une intuition : on pouvait exploiter, dans l'entraînement d'un LLM, les propres activations du modèle, et les suivre pendant l'apprentissage devait aider à construire un modèle plus intelligent et plus véridique. Aujourd'hui, je n'en reviens pas d'avoir abordé les choses avec tant de naïveté. Non pas parce que je pense aujourd'hui que c'est impossible, mais parce que, sans avoir la moindre idée de ce à quoi ressemble l'entraînement d'un LLM, je me suis mis à expérimenter avec quelque chose qui me dépassait. J'ai dû assimiler une énorme quantité de connaissances, tout en testant à la fois des solutions propres à l'architecture des transformers classiques et mes propres idées, qui – le temps l'a montré – étaient en grande partie irréalisables.

J'ai alors buté sur toute une série de problèmes : une fois normalisé, le signal d'activation des portes SwiGLU perdait son sens ; sans normalisation, AdamW exploitait mes modifications pour gonfler les normes du modèle. Ce n'est qu'avec le temps que j'ai compris qu'une bonne partie des avantages que j'avais trouvés à mon premier modèle venait d'un phénomène proche d'une régularisation par le bruit. De plus, le seul calcul du Gini à partir des activations des portes SwiGLU coûtait cher : il ajoutait quelques pour cent de compute, sans que les résultats le rentabilisent en qualité.

J'entraîne actuellement un petit modèle de 160M d'architecture standard, spécialisé dans le code. C'était la meilleure décision que je pouvais prendre, car je me suis donné une chance de créer quelque chose qui puisse être réellement utile. Et les premiers résultats du modèle montrent que les leçons tirées de mes erreurs n'ont pas été perdues.

10. Ne construisez pas un modèle censé être bon en tout

Vu les coûts astronomiques, et la faisabilité même de l'entreprise, construire un modèle généraliste quand on est seul ou une petite structure n'a aujourd'hui aucun sens, pour des raisons purement économiques. Face aux géants, ou même aux plus petits laboratoires qui publient des modèles ouverts, la partie est perdue d'avance sans des moyens et une expérience considérables. Mais cela ne veut pas du tout dire que construire ses propres modèles n'a pas de sens.

On peut imaginer des centaines d'applications où de petits modèles entraînés à partir de zéro, ou affinés sur des données uniques, auront l'avantage sur les géants – et cet avantage ne tiendra pas forcément au savoir. Il suffit que le modèle soit rapide et puisse tourner en local dans un navigateur, ou sur le processeur de n'importe quelle station de travail. Pour des usages précis et étroits, il peut être bien plus rentable d'utiliser un micro-modèle de quelques centaines de millions de paramètres que de mobiliser les modèles les plus puissants d'OpenAI ou d'Anthropic. Ce n'est pas qu'une question de coût. Même si l'écart est colossal. Un modèle spécialisé dans un domaine étroit est bien plus facile non seulement à entraîner, mais aussi à contrôler et à adapter aux besoins de l'utilisateur. Et surtout, c'est une tâche qui reste à la portée d'une personne ordinaire, prête à relever ce défi.

Les modèles des grands laboratoires sont entraînés sur des milliers de puces très coûteuses. Un exemple : l'entraînement d'un modèle de la classe de Llama 3 400B a nécessité un cluster de 16 000 cartes H100. Les coûts se chiffrent en dizaines de millions de dollars. L'entraînement du tout dernier GPT Astra a probablement placé la barre bien plus haut. Comme tout ce secteur se développe à crédit, et que le déploiement de l'IA à grande échelle, avec les coûts actuels des API et les questions de sécurité des données, est souvent difficile à justifier sur le plan économique, on peut s'attendre à ce qu'à long terme, les petits modèles jouent un rôle croissant. Les petits modèles seront aussi de plus en plus performants. Je ne serais pas surpris qu'à l'avenir, un modèle de l'ordre de 7 milliards de paramètres nous suffise pour la plupart des tâches. L'éclatement de la « bulle de l'IA », dont les médias parlent de plus en plus souvent, ne pourrait qu'accélérer ce processus.

C'est pourquoi je pense que construire de petits modèles a un sens profond. D'abord, il n'y a pas de meilleur moyen de comprendre comment fonctionne l'IA que d'entraîner son propre modèle. Ensuite, même si, dans les grands laboratoires, le développement de l'IA est de plus en plus souvent assuré… par l'IA elle-même, on peut s'attendre à ce que l'humanité, prenant au sérieux les questions de sécurité, exige un contrôle et une supervision humaine du processus d'entraînement. Pour cela, il est indispensable de comprendre comment ce processus se déroule en pratique. Bien sûr, il suffit aujourd'hui d'ouvrir LinkedIn pour être submergé de publications sur l'intelligence artificielle, signées des spécialistes les plus divers, qui proposent tutoriels et formations. Mais combien d'entre eux ont réellement entraîné leur propre modèle ?

Si vous avez des questions, j’y répondrai avec plaisir.

Un jeu de lecture : quand vous lisez régulièrement, un robot mange une ligne du code de ce site et marque des points ; un défilement trop rapide ou irrégulier lui fait rater des caractères. Décoratif — il n’affecte jamais le texte.

Si vous avez des questions, j’y répondrai avec plaisir.

Un jeu de lecture : quand vous lisez régulièrement, un robot mange une ligne du code de ce site et marque des points ; un défilement trop rapide ou irrégulier lui fait rater des caractères. Décoratif — il n’affecte jamais le texte.

Ce texte est l'un des plus difficiles auxquels j'aie jamais eu à me confronter. Journaliste et, en même temps, homme qui entraîne ses propres modèles chez lui, je me tiens à deux pôles opposés. D'un côté, l'ingénierie pure me fascine ; de l'autre, j'ai pleinement conscience que la sécurité de l'intelligence artificielle est probablement le plus grand défi de l'époque que nous vivons.

Je commencerai par ce qui me fait personnellement le plus mal : l'appauvrissement tragique du débat public sur la sécurité de l'IA. C'est un débat plein de contradictions et d'une charge émotionnelle extrême. Difficile d'ailleurs qu'il en soit autrement, quand sont en jeu des intérêts qui se chiffrent en milliards et la survie des êtres humains.

D'un côté, on nous dit que l'IA est une menace mortelle et que son développement risque de conduire à l'anéantissement de l'humanité. De l'autre, que ces visions apocalyptiques ne sont qu'un jeu cynique des géants, qui veulent faire grimper la valorisation de leurs actions avant leur introduction en Bourse, ou bloquer et freiner le développement des petites entreprises pour préserver leur monopole et leur place en tête du peloton. Le commun des mortels, qui n'a pas le temps de suivre tout cela et attend des solutions simples, peut facilement basculer dans le camp des technomaximalistes ou dans celui des prophètes de l'apocalypse. Chacune de ces visions est si lisse, si évidente… et aucune n'exige rien de plus de notre part. Car enfin, si nous sommes impuissants face à des forces qui nous dépassent, nous n'avons pas à agir. À notre époque de maximalisme extrême, c'est une position bien confortable.

Que répondrais-je, moi, à mon enfant s'il me demandait si l'IA représente une menace pour nous ? En refusant tout recadrage simplificateur, je devrais admettre qu'il existe trois possibilités : que nous soyons effectivement condamnés à l'anéantissement ; qu'il n'ait finalement pas lieu (parce que – comme le soutient Yann LeCun – nous apprendrons tout simplement à maîtriser cette technologie) ; ou… que cet anéantissement ait déjà commencé. Le paradoxe, c'est que ces trois scénarios peuvent être vrais en même temps.

Si le pire a probablement déjà commencé, c'est en raison d'un fait qui perce rarement dans le débat grand public : toute technologie, toute invention doit rencontrer son époque et un terrain favorable pour exister pleinement. L'énergie nucléaire – si souvent invoquée comme point de comparaison dans ce débat – représentait une menace mortelle au temps de la guerre froide, mais en temps de paix, elle est devenue une source d'énergie bon marché, contribuant au boom économique. On peut en dire autant de la plupart des inventions : de la taille du silex à l'intelligence artificielle, en passant par la dynamite.

Notre monde est malheureusement devenu un lieu où le scénario catastrophe trouve des conditions quasi idéales pour se réaliser. Conflits armés recourant à des armes autonomes, surveillance croissante des citoyens par les États et les entreprises, adoption irréfléchie par les gouvernements des standards du monde de l'entreprise dans leur communication avec la société : tout cela forme une infrastructure toute prête pour les visions les plus sombres.

Pendant ce temps, l'idéologie du technomaximalisme, qui nous pousse vers ces menaces – en raillant ouvertement la faiblesse, en plaçant le profit économique et la force brute au-dessus du capital social et de la sécurité –, construit un monde où une IA qui aura rompu sa laisse prospérera à merveille. Et alors, le scénario catastrophe pourrait bien devenir inévitable.

Il n'y a là rien de nouveau. Ce débat dure pour ainsi dire depuis l'agora athénienne, où Platon se querellait avec Socrate, et l'histoire humaine est pleine de moments sombres et d'injustices. Ce qui se passe aujourd'hui dans la politique américaine, et qui, pour beaucoup d'Européens, sent le fascisme, n'a rien de nouveau, comme le souligne avec justesse l'historien Jon Meacham dans son livre « The Soul of America ». La force de la démocratie, c'est que la justice – si lente soit-elle – finit toujours par l'emporter grâce aux institutions. Il peut d'ailleurs en aller de même avec l'IA – c'est notre technologie, et nous apprendrons à la maîtriser, comme nous l'avons fait avec les avions, ainsi que le rappelle LeCun.

Avec la modeste expérience que j'ai de l'entraînement d'IA, je reste stupéfait de voir à quel point cette technologie est fragile. Il suffit de légères modifications des hyperparamètres pour que le modèle s'effondre complètement entre les mains de l'ingénieur. Mais on peut en dire autant des virus biologiques. Ce qui compte chez eux, ce n'est pas une intelligence hors du commun ni la capacité de survivre à tout prix, mais l'aptitude à se répliquer. Cette aptitude, l'intelligence artificielle ne l'a pas encore, semble-t-il, et pourrait ne pas l'avoir de sitôt. Le problème, c'est que, comme le montrent les récentes affaires de fuite d'agents IA autonomes hors des laboratoires et leurs actions coordonnées en ligne, la menace grandit. Et malgré cela, nous n'entendons rien d'autre que le récit sans cesse ressassé de deux courants extrémistes – sans la moindre solution concrète, sans la moindre conclusion.

Ce qui distingue les modèles actuels d'un code malveillant comme celui qui a, par exemple, attaqué Hugging Face ou des serveurs australiens, c'est avant tout la capacité d'agir (agency). Or la capacité d'agir ne peut jamais être l'apanage d'une machine. Ce qui fait de nous des humains, c'est notre libre arbitre. Aucune autre intelligence – artificielle – ne peut avoir de capacité d'agir garantie autrement que par l'humain qui lui prête cette volonté. De ce principe simple devraient découler l'ensemble des responsabilités et la réglementation, traduites en dispositions législatives concrètes. Le droit d'entraîner des modèles et de les utiliser sans restriction devrait dépendre de l'évaluation des risques et des capacités de contrôle de chaque entité.

Rien n'empêche d'autoriser à tous l'entraînement des plus petits modèles – par exemple jusqu'à 1 milliard de paramètres. Mais les modèles moyens, de l'ordre de 7 milliards de paramètres, ne devraient selon moi pouvoir être entraînés et téléchargés que par des organisations enregistrées, qui consignent en détail toutes les interactions de leurs agents (logs) et sont prêtes à les communiquer en cas de problème. Rien de futuriste là-dedans : la cryptographie le permet dès aujourd'hui, pour un coût marginal. Chaque agent opérant en ligne pourrait disposer d'une sorte de « carte d'identité », permettant de l'identifier en lien avec l'organisation qui le représente.

Et les grandes entreprises qui développent des modèles de pointe (frontier models) ? Elles pourraient par exemple être tenues d'employer des Défenseurs de l'intérêt public. Il s'agirait de spécialistes nommés et rémunérés exclusivement par le régulateur public – des salariés ayant accès à tous les secrets technologiques du laboratoire, tenus de faire rapport à l'État lorsqu'ils voient leur entreprise enfreindre les normes de sécurité ou se lancer dans des actions extrêmement risquées dans sa course contre la concurrence.

Les États ont aussi la possibilité, et le devoir moral, d'instaurer une taxe technologique affectée. Ces fonds doivent servir à sécuriser la transition : le passage d'une économie fondée sur le travail humain à une économie fondée sur les machines. Un tel fonds assurerait un filet de sécurité, réduirait les inégalités criantes et protégerait des millions de personnes d'une dépendance économique totale envers le bon vouloir de la caste la plus riche des seigneurs féodaux de la tech.

Le même pragmatisme systémique doit s'appliquer aux droits d'auteur sur les contenus qui servent à entraîner les modèles. Aujourd'hui, les géants de la tech aspirent sur le Web tout ce qui leur tombe sous la main, en comptant sur le fait que d'éventuels procès dureront des années. Or la solution est sur la table, et elle repose sur des institutions que nous connaissons déjà très bien : les sociétés de gestion collective des droits d'auteur, comme la ZAiKS polonaise ou ses équivalents étrangers. Rien n'empêche qu'elles fédèrent les créateurs prêts à concéder sous licence leurs textes, leurs images ou leur musique aux entreprises qui entraînent des IA, en échange d'une fraction de pour cent des revenus de la Big Tech. C'est un système où tout le monde est gagnant. Les créateurs retrouvent leur capacité d'agir et une vraie rémunération, avec le plein droit d'exclure leurs œuvres de l'entraînement. Les laboratoires d'IA, eux – puisque ces sociétés coopèrent entre elles à l'échelle internationale –, obtiennent d'une seule signature au bas d'un contrat un accès pleinement légal à de vastes bases de données juridiquement saines, venues du monde entier. Ainsi, au lieu de querelles stériles, nous pourrions bâtir de toutes pièces une puissante industrie de la licence équitable des données.

Ce dont nous devons nous méfier le plus, c'est de l'anthropomorphisation croissante de l'intelligence artificielle. Prêter aux machines des traits humains conduit à une situation extrêmement dangereuse, où toute la responsabilité retombe sur cette nouvelle créature numérique, tandis que ses créateurs et ceux qui l'utilisent sont pour ainsi dire absous d'office : « Ce n'est pas nous, c'est le modèle. » Aujourd'hui, personne ne demande si, dans la Silicon Valley, on a pris absolument toutes les mesures possibles pour prévenir un scénario catastrophe – alors que tout le monde sait que ce n'est pas le cas. Malheureusement, élaborer de vraies solutions législatives, ennuyeuses, est bien moins médiatique que d'agiter le spectre de l'apocalypse.

Or le scénario fatal ne ressemblera certainement pas à une scène de film catastrophe hollywoodien. Du moins au début, il prendra la forme d'un lent glissement vers les ténèbres – le cas classique de la grenouille qu'on fait cuire à petit feu. Les propriétaires des machines intelligentes et du capital croiseront avec indifférence, dans la rue, des gens structurellement superflus. Des gens qui n'auront absolument aucun moyen de changer leur situation, hormis la révolte physique. Et même cette révolte deviendra impossible dans un monde où chaque citoyen est surveillé en permanence par les milliards d'yeux de verre, jamais endormis, des caméras, et par des milliers de machines autonomes.

La nouvelle technocratie deviendra avec le temps une prison numérique – aussi bien pour ceux qu'elle contrôle que pour ceux qui croient naïvement exercer encore le pouvoir. Quand je pense au pire des avenirs, je ne vois pas de robots tueurs. Je pense justement à la solitude poignante des humains dans un monde entièrement administré par une intelligence étrangère, froide et indifférente. C'est le monde que nous construisons dès aujourd'hui, et où toutes les conditions sont réunies pour que la fameuse « révolte des machines » finisse par advenir et devenir réalité.

Moi-même, je ne cesse de réfléchir à ce problème. Et même si certaines idées ou visions pour sortir de cette situation semblent aujourd'hui trop futuristes, abstraites, voire parfois naïves, je pense que cet effort vaut la peine d'être fait – et même qu'il le faut. Le simple fait de réfléchir à des solutions, de sortir de notre zone de confort et d'essayer d'imaginer d'autres voies que celle que nous tracent aujourd'hui les géants de la tech, c'est notre principale ligne de défense. Cela fait partie intégrante de la construction d'un avenir meilleur et plus sûr. Si nous y renonçons, en nous contentant du rôle de consommateurs passifs et terrifiés, le pire des scénarios se réalisera : nous livrerons sans combattre notre capacité d'agir d'êtres humains. Et cela, nous ne pouvons tout simplement pas nous le permettre.

Si vous avez des questions, j’y répondrai avec plaisir.

Un jeu de lecture : quand vous lisez régulièrement, un robot mange une ligne du code de ce site et marque des points ; un défilement trop rapide ou irrégulier lui fait rater des caractères. Décoratif — il n’affecte jamais le texte.

HDK (Hedera Detection Key) est une petite bibliothèque Python gratuite que j’ai détachée d’OrsonAI pour en faire un outil ouvert et autonome. Depuis la version 0.1.3, elle est sous licence CC BY-NC 4.0 (les versions antérieures, publiées sous Apache 2.0, le restent). Le fichier à télécharger est une bibliothèque gratuite (alpha 0.1.3) avec ancrage Hedera optionnel (installation depuis le fichier téléchargé : pip install ./hdk-audit-0.1.3.zip). Elle a fonctionné un temps dans une application de démonstration, en ancrant ses enregistrements sur Hedera ; l’application n’est pas passée en production, HDK n’est donc pas utilisée en production aujourd’hui. Elle s’intercale entre une application et l’API d’un modèle de langage et enregistre chaque interaction de telle sorte qu’une manipulation ultérieure devienne détectable. Elle ne modifie ni les requêtes ni les réponses : elle y ajoute une preuve cryptographique de ce qui a été demandé, de ce qui a été renvoyé, à quel moment et par quel modèle.

Le problème

Les entreprises et les rédactions s’appuient de plus en plus sur des textes générés par l’IA, sans disposer d’une preuve vérifiable de ce que le modèle a réellement produit. Les journaux d’application sont stockés dans des bases contrôlées par l’opérateur : on peut les modifier ou les supprimer, et personne à l’extérieur ne peut vérifier que cela n’a pas été fait. Même lorsque des chaînes de hachage existent, une modification n’est repérée qu’en comparant les enregistrements à la main – rien ne fait qu’un accès non autorisé se révèle de lui-même au moment où il se produit.

Une généalogie hiérarchique des empreintes

HDK calcule l’empreinte SHA-256 de chaque événement en y incluant les empreintes de tous ses ancêtres : projet, document, conversation, requête et réponse. L’empreinte d’une réponse contient donc tout le chemin jusqu’au projet. Il suffit de changer quoi que ce soit, à n’importe quel niveau – un mot d’une requête, un document – pour que les empreintes de tous les descendants changent aussi. Pour chaque projet, HDK calcule une racine de Merkle : une seule empreinte qui représente l’état de tout le projet à un instant donné.

Le canari

La deuxième couche est un « canari » : une valeur secrète de 256 bits et un compteur qui augmente à chaque lecture. Leur empreinte (l’engagement) est intégrée à chaque enregistrement et consignée à intervalles réguliers. Si quelqu’un lit des données via la couche intermédiaire sans mettre à jour le compteur, le compteur ne correspond plus ; s’il le met à jour sans connaître le secret, c’est l’engagement qui ne correspond plus. Dans les deux cas, la vérification échoue. L’idée transpose à une infrastructure classique un principe issu de mon travail antérieur, conceptuel, sur la détection des brèches dans le confinement de l’IA.

L’ancrage sur Hedera

Régulièrement – par défaut tous les 1 000 nouveaux événements – HDK publie la racine de Merkle sur le Hedera Consensus Service, un registre public qui y ajoute un horodatage de consensus et un numéro de séquence. Seules des empreintes quittent le système de l’utilisateur ; les contenus, les identités et les requêtes restent privés (« données privées, preuve publique »). Chacun peut ensuite vérifier l’enregistrement de manière indépendante, par exemple sur hashscan.io (les ancrages d’OrsonAI de février à mai 2026 : sujet 0.0.10278996 sur le réseau principal de Hedera). Comme les chaînes d’ancêtres des nouveaux événements remontent jusque dans la plage de l’ancrage précédent, chaque ancrage confirme implicitement tous les précédents : plus le système fonctionne longtemps, plus il est difficile de réécrire l’historique sans que cela se voie.

Surcoût et prix

Dans les mesures décrites dans l’article, sur une infrastructure cloud x86 standard, HDK ajoute moins d’une milliseconde par événement. Un ancrage coûte 0,0001 dollar ; avec l’intervalle par défaut de 1 000 événements, l’ancrage revient donc à 0,0000001 dollar par interaction – environ 0,0001 % du prix d’un appel typique à un modèle (0,01 à 0,10 dollar). Ancrer chaque événement, pour le niveau de sécurité le plus élevé, coûte 0,0001 dollar par événement.

Pourquoi c’est important : l’AI Act

L’AI Act européen impose aux systèmes d’IA à haut risque la tenue de registres (article 12) et la transparence (article 13). HDK fournit une piste d’audit qu’un tiers peut vérifier sans accéder à aucun contenu privé. Dans OrsonAI, ce mécanisme était la base du certificat de paternité humaine d’un texte.

Les limites

Les garanties de HDK sont calculatoires – elles reposent sur la robustesse de SHA-256 et sur l’ancrage externe – et non absolues. Le canari fonctionne au niveau de l’application : il détecte les accès passant par la couche intermédiaire HDK, mais pas la copie passive des données au niveau du système d’exploitation ou de l’infrastructure, car des bits copiés ne laissent aucune trace. Une copie ne permet pas pour autant de falsifier l’historique : modifier n’importe quel événement passé rompt la généalogie, et les ancrages sur Hedera conservent l’état d’origine. Les contrôles d’intégrité aléatoires repèrent les modifications massives, mais pas une modification unique et chirurgicale – contre celle-ci, la protection vient de la généalogie et de l’ancrage. La sécurité suppose qu’au moins une des trois couches reste intacte : les données côté utilisateur, l’enregistrement ancré sur Hedera ou le matériel secret. Prochaines étapes : la vérification formelle des propriétés de la chaîne d’empreintes (Coq/Lean), la fédération de systèmes sur des sujets HCS partagés et des certificats de provenance des contenus à divulgation sélective.

Lire l’article sur ResearchGateTélécharger la bibliothèque HDK gratuiteHDK sur Hugging Face

Si vous avez des questions, j’y répondrai avec plaisir.