Mon père avait les yeux qui brillaient quand il a branché son premier 286. Un processeur à 6 MHz, 256 Ko de RAM, un disque dur de 20 Mo. Ridicule sur le papier. Mais pour lui, c'était la machine à tout faire. Du BASIC, du traitement de texte, des jeux en 16 couleurs. Il savait que c'était limité. Et pourtant, l'excitation était réelle : « Je peux faire des choses qu'une calculatrice ne fera jamais. »
Cette même excitation, je l'ai ressentie quarante ans plus tard. Pas devant un ordinateur, mais devant un modèle d'intelligence artificielle de 2,6 Go qui tourne sur mon propre PC. Les LLM locaux, c'est le 286 de notre génération. Limités, oui. Mais capables de choses que personne n'imaginait possibles il y a deux ans.
Dans cet article, je vous raconte comment je suis passé d'un premier modèle qui échouait dans 44 % des cas à 15 fonctionnalités IA qui tournent silencieusement en arrière-plan pendant que je code. Le tout pour 0 € et 2,6 Go de mémoire.
Avant de continuer de lire la suite de l'article, je vous invite à vous inscrire à ma newsletter, pour connaître en avant première les futurs sujets traités chaque semaine.
L'ère du bricolage : Ollama et les LLM de maison
Ollama, c'est le logiciel qui permet de faire tourner des modèles d'intelligence artificielle directement sur votre machine. Pas de compte cloud, pas d'abonnement, pas de données qui partent sur un serveur à l'autre bout du monde. Vous tapez ollama pull qwen3:4b dans votre terminal, et trois minutes plus tard, vous avez un modèle de langage qui tourne chez vous.
Le parallèle avec les premiers PC n'est pas qu'esthétique. En 1981, IBM lance son PC avec une architecture ouverte. N'importe qui peut fabriquer des clones compatibles. Résultat : une explosion de constructeurs, de logiciels, de bidouilles. Aujourd'hui, Ollama fait pareil avec l'IA. Des centaines de modèles open source, une communauté de créateurs qui publient des variantes optimisées, et la liberté de tout casser sans conséquence.
Pourquoi local plutôt que le cloud ? Ce n'est pas une question de puissance. ChatGPT, Claude, Gemini sont évidemment plus puissants. C'est une question de philosophie. Le bricoleur veut comprendre comment ça marche. Il veut modifier, tester, adapter à son workflow. Et surtout, il veut que son code reste sur sa machine.
En 2026, 42 % des développeurs exécutent des LLM en local. Et 85 % utilisent des outils IA pour coder, selon le rapport JetBrains 2025. L'IA locale n'est plus une curiosité de geek. C'est un outil de travail.
Mais comme pour le 286, tout ne marche pas du premier coup.
Le premier échec : qwen3:4b et ses boucles de réflexion
J'ai commencé avec qwen3:4b. Un modèle de quatre milliards de paramètres, développé par Alibaba (Qwen). Installation facile : une commande, quelques minutes de téléchargement, et c'est prêt. Sur le papier, c'est prometteur : le modèle est récent, bien noté, et conçu pour les tâches de développement.
En pratique, c'est une autre histoire.
Le problème fondamental de qwen3:4b, c'est qu'il « pense » trop. Littéralement. Avant chaque réponse, le modèle génère un bloc de réflexion interne (des tokens <think>...</think>) qui consomme son budget de réponse. Imaginez un collègue très intelligent qui réfléchit dix minutes avant de dire un mot. Brillant, mais inutilisable en équipe.
Les chiffres de mes tests sont sans appel :
| Tâche | Taux de réussite | Temps moyen |
|---|---|---|
| Messages de commit | 0 % | 69 secondes |
| Revue de code | 33 % | 75 secondes |
| Scoring qualité | 0 % | 26 secondes |
| Traduction commentaires | 50 % | 58 secondes |
| Résumé de texte | 100 % | 26 secondes |
Score global : 56 % de réussite. Et quand ça échoue, c'est spectaculaire. Sur les messages de commit, le modèle entre dans une boucle de réflexion infinie : il raisonne, raisonne, raisonne... et ne produit jamais de réponse. 100 % de son budget de tokens part en réflexion interne. Zéro output utile.
J'ai aussi testé le Qwen3-Reranker-0.6B, un modèle de reclassement de 600 millions de paramètres. Résultat : il affiche !!!!!!!!!! au lieu de scores de pertinence. Pas un bug de configuration : Ollama ne supporte tout simplement pas ce type de modèle (cross-encoder). La leçon est claire : le bon modèle au bon endroit.
J'aurais pu abandonner. J'aurais pu me dire que les LLM locaux, c'est bien pour faire joujou, mais pas pour du vrai travail.
C'est là qu'un contributeur de la communauté a changé la donne.
La perle rare : qwen3-nothink:4b
Sur Ollama Hub, un utilisateur nommé hoangquan456 a publié une variante de qwen3:4b avec un changement simple mais radical : le mode « thinking » est désactivé au niveau du template du modèle. Pas via un paramètre d'API (qui ne marche pas de manière fiable), mais directement dans la configuration du modèle.
Le nom : hoangquan456/qwen3-nothink:4b.
Le résultat m'a coupé le souffle :
| Aspect | qwen3:4b | nothink:4b |
|---|---|---|
| Taux de réussite global | 56 % | 91 % |
| Messages de commit | 0 % | 100 % |
| Revue de code | 33 % | 100 % |
| Traduction | 50 % | 100 % |
| Vitesse moyenne | 25-75 secondes | 0,3-4 secondes |
| Tokens utilisés (commit) | 2 625 / 3 000 | 14 / 3 000 |
| Taille sur disque | 3,3 Go | 2,6 Go |
C'est le même modèle. Les mêmes quatre milliards de paramètres. La même architecture. Mais sans la couche de « réflexion » qui sabotait tout.
Le moment où j'ai vu un message de commit généré en 0,9 seconde — au lieu de 69 secondes — c'est le moment « 286 ». La même excitation que mon père. Pas parce que c'est parfait, mais parce que ça marche. Et ça marche sur ma machine.
C'est l'esprit du 286 : on ne lui demandait pas de faire tourner Photoshop. On lui demandait de faire du traitement de texte, et il le faisait brillamment.
15 fonctionnalités IA pour 2,6 Go
Le vrai pouvoir d'un petit modèle, ce n'est pas ce qu'il fait tout seul. C'est ce qu'on construit autour.
Aujourd'hui, nothink:4b alimente 15 automatisations dans mon environnement de développement. Tout tourne sur un GPU de 6 Go (RTX 3050 Laptop), en parallèle avec un modèle d'embeddings pour la recherche sémantique. Coût total : 0 €.
Quand j'écris du code :
- Détection automatique de bugs et de failles de sécurité dans mes modifications
- Vérification des conventions de nommage (camelCase, snake_case selon le langage)
- Détection de code dupliqué par analyse sémantique
Quand je commite :
- Suggestion de message de commit au format conventionnel (fix:, feat:, refactor:)
- Suggestion de nom de branche cohérent
- Résumé automatique des gros changements (quand le diff touche plus de cinq fichiers)
Quand je débugue :
- Explication des erreurs en langage clair (fini les messages TypeScript cryptiques)
- Catégorisation automatique de la priorité des TODOs (P0 à P3)
En tâche de fond :
- Score qualité pour le système de mémoire (RAG)
- Documentation automatique des nouvelles fonctions (JSDoc)
- Génération de changelog depuis les commits
L'optimisation du système a aussi été spectaculaire. Avant la migration, chaque modification de fichier déclenchait 12,6 secondes de traitement bloquant. Après : 0,3 seconde. Une réduction de 97 %.
Comment ? En convertissant les traitements synchrones (bloquants) en asynchrones (en arrière-plan), en fusionnant des hooks redondants, et en réduisant les budgets de tokens maintenant que le modèle n'en gaspille plus 99 % en réflexion interne.
Les limites honnêtes
Ce serait malhonnête de ne pas parler des limites.
nothink:4b, c'est quatre milliards de paramètres. Ce n'est pas GPT-4, ce n'est pas Claude Opus, ce n'est pas Gemini. Le scoring qualité n'est pas parfait : le modèle donne un score de 3/5 au mot « hello » alors qu'il devrait donner 1. Le raisonnement multi-étapes complexe dépasse ses capacités. L'analyse de sécurité approfondie reste le domaine des grands modèles.
Sans GPU, c'est utilisable mais lent : cinq à trente secondes par requête sur CPU. Avec un GPU même modeste (6 Go de VRAM), la plupart des tâches passent sous la seconde.
Le positionnement est clair : c'est un assistant, pas un architecte. Il fait le travail répétitif — les revues de code routinières, les messages de commit, la traduction de commentaires — pour que le développeur se concentre sur la réflexion et les décisions d'architecture.
Comme le 286 : on ne lui demandait pas de faire tourner Photoshop. On lui demandait de faire du traitement de texte, et il le faisait brillamment.
Conclusion
Mon père faisait du BASIC sur son 286. Moi, je fais de la revue de code avec un LLM de 2,6 Go. Les machines ont changé, mais l'excitation est la même : celle du bricoleur qui découvre ce que sa machine peut faire, avec ses limites et ses promesses.
L'enseignement principal : un petit modèle bien configuré vaut mieux qu'un gros modèle mal utilisé. J'ai perdu des heures avec qwen3:4b (le modèle « penseur ») avant de trouver la variante communautaire qui a tout débloqué. La technologie ne suffit pas. C'est la configuration, le choix du bon outil pour le bon usage, qui fait la différence.
L'IA locale n'est pas une version dégradée de l'IA cloud. C'est un outil différent, pour un usage différent. Privé, gratuit, personnalisable, et étonnamment capable quand on prend le temps de le configurer.
Si vous n'avez jamais essayé Ollama, commencez par là. Un ollama pull hoangquan456/qwen3-nothink:4b et vous comprendrez ce que je veux dire.
La prochaine étape ? Quand ces modèles locaux communiqueront avec les modèles cloud de manière sécurisée (Ollama travaille avec Stanford sur un projet appelé Secure Minions). Le 286 avait fini par se connecter à Internet. Ces modèles feront pareil.
Qui suis je ?
Je suis Mathieu GRENIER, CTO d'Easystrat une startup de Montpellier, en France. Je manage une équipe d'une dizaine d'ingénieurs (Graphistes, IA, frontend, backend, devOps, AWS) en remote depuis le Japon.
J'ai aussi mon activité de freelance, où je conseille des entrepreneurs dans leurs projets d'application.
Avec mon expérience personnelle de plus de 15 ans en ESN, j'ai pu travailler pour un large panel d'entreprises de différentes tailles. Ma compréhension des problèmes métiers est une de mes grandes forces et permet à mes clients de pouvoir se projeter plus facilement.
L'essentiel de mon travail consiste à canaliser l'énergie des entrepreneurs sur l'essence même de leur projet.
La technologie, les méthodes, le management sont le cœur de mes compétences.
Vous pouvez me faire confiance sur ces points là.
Si vous voulez me parler d'un de vos projets, n'hésitez pas à m'envoyer un email avec vos disponibilités à : contact@mathieugrenier.fr
Je donnes aussi des formations via Youmind (organisme de formation agréé qualiopi)
Tous les articles de ce blog sont écrits par moi, même si je peux m'aider de l'IA pour illustrer mes propos. Mais jamais je ne fournis d'articles 100 % IA.
Mon 286 à moi, c'est Ollama : quand un modèle de 2,6 Go transforme votre quotidien de développeur