---
title: "Mes débuts"
author: "Jakub Ćwirlej"
id: how-i-started
language: fr
url: "https://jakubcwirlej.com/fr/articles/how-i-started.md"
page: "https://jakubcwirlej.com/fr/ai-dev/"
translations:
  pl: "https://jakubcwirlej.com/pl/articles/how-i-started.md"
  en: "https://jakubcwirlej.com/articles/how-i-started.md"
  nl: "https://jakubcwirlej.com/nl/articles/how-i-started.md"
updated: 2026-10-14
words: 1635
summary: "L'auteur raconte comment la création d'OrsonAI, un ensemble d'outils d'IA pour son propre travail de journaliste, l'a mené du vibe coding à la recherche sur les hallucinations des modèles de langage, puis à l'entraînement de ses propres modèles. Il décrit l'accueil froid réservé à l'application par la profession, ses études des activations des portes SwiGLU et l'échec de son premier modèle bâti sur sa propre architecture. Aujourd'hui, il entraîne EUGEN 160M, un petit modèle spécialisé dans le code que l'on peut essayer dans un terminal sur le site."
summary_type: editorial
---

# Mes débuts

Jakub Ćwirlej · langue du texte: FR · 1635 mots

## Résumé (éditorial)

L'auteur raconte comment la création d'OrsonAI, un ensemble d'outils d'IA pour son propre travail de journaliste, l'a mené du vibe coding à la recherche sur les hallucinations des modèles de langage, puis à l'entraînement de ses propres modèles. Il décrit l'accueil froid réservé à l'application par la profession, ses études des activations des portes SwiGLU et l'échec de son premier modèle bâti sur sa propre architecture. Aujourd'hui, il entraîne EUGEN 160M, un petit modèle spécialisé dans le code que l'on peut essayer dans un terminal sur le site.

## Points clés (éditorial)

- OrsonAI proposait la transcription d'interviews en direct, un mode d'édition pour consulter un chatbot sur des passages choisis et des certificats d'origine humaine enregistrés sur le registre public Hedera Hashgraph.
- Il décrit désormais les signaux GSI qu'il a trouvés comme des signaux proxy de la connaissance plutôt que comme une « conscience épistémique » du modèle, et a observé que la confabulation est en grande partie un processus en deux temps.
- Les progrès d'EUGEN 160M reposent sur un suivi étroit, des données d'entraînement ciblées, des données synthétiques STaR et LEMA et des exemples de traduction de Python vers C++, Java et Rust.
- Avec l'aide d'un agent d'IA de programmation, il a construit son propre kernel Triton pour entraîner un modèle sparse : dans un modèle d'environ 300 M de paramètres, la variante sparse s'est entraînée 1,23× plus vite que la dense, et les optimisations suivantes du kernel ont relevé le débit de 36 % de plus.
- Il attribue l'échec de son premier modèle à un problème philosophique, en citant la définition de la vérité de Tarski et les théorèmes de Gödel.

## Texte intégral (les mots de l'auteur)

…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 HDK](https://jakubcwirlej.com/fr/articles/hdk-tech.md)
- [Vous pouvez télécharger ici la bibliothèque HDK gratuite](https://jakubcwirlej.com/files/hdk/hdk-audit-0.1.3.zip)
- [HDK sur Hugging Face](https://huggingface.co/JakCwi/hdk-audit)

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.

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](https://www.researchgate.net/publication/397730862)

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](https://jakubcwirlej.com/fr/ai-dev/#terminal)

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 ici](https://jakubcwirlej.com/files/eugen-sparse.zip)
- [Le kernel sur Hugging Face](https://huggingface.co/JakCwi/eugen-sparse)

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.

---

Jakub Ćwirlej — Journaliste qui construit avec l'IA · sur le site: https://jakubcwirlej.com/fr/ai-dev/
Contexte complet: https://jakubcwirlej.com/context/fr.md · https://jakubcwirlej.com/llms.txt