on trouve en ce moment des livres sur la robustesse qui montrent le piège de l'efficacité (terme que tu as employé) à tout prix qui empêche de au contraire de s'adapter aux changements.
Tu en as un en particulier à conseiller ? (si possible dans un format qui se lance bien aux visages d'autres personnes ^^)
Je ne sais pas si ton commentaire est ironique ou pas, donc, dans le doute, je me permets d'y répondre sérieusement :
D'après Kaplan et al., augmenter l'intelligence d'un LLM suit la loi des puissances. Ça se voit d'ailleurs sur les benchmarks : il leur faut maintenant des mois entiers d’entraînement et des datacenters gigantesques pour entraîner leurs modèles. Tout ça pour finalement gratter quelques points de pourcentage dans les benchmarks.
Il est donc tout à fait possible qu'on soit déjà proche du potentiel maximum des LLM qu'on peut avoir, de façon raisonnablement écologique en tout cas (oui, bon, hein, je sais … 🫤). Autant dire qu'à ce stade, poursuivre la course à la taille et l'intelligence des modèles me semble écologiquement aberrant, mais c'est visiblement le chemin choisi par tous les participants … 🙁
Le contexte énorme, c'est 1 million de tokens actuellement. Sur un projet sain, même très gros, c'est effectivement très large. Mais perso, j'attends de voir le résultat sur un très gros projet après dix ans de vibe-coding par une grosse équipe de dev.
PS : Mistral propose le modèle GLM en plus de leur modèle maison. Actuellement, c'est le meilleur qu'ils m'offrent dans leur abonnement.
Ah, pour le coup, j'ai appris quelque-chose, merci :-)
C'est un argument que je vois souvent chez les vibe-codeurs : il faut spécifier au maximum, pour ne pas laisser de chance au LLM de planter.
Ça m'amuse beaucoup, parce que personnellement, j'ai un souvenir du passage à Agile : l'idée m'avait semblé être de réduire les spécifications au minimum, de les faire à la volée, et d'itérer le plus possible à la place (corrigez-moi si je me trompe). Pour cause, spécifier correctement est très coûteux en temps, souvent plus que de coder directement, et les spécifications sont toujours fausses, tôt ou tard. Le logiciel, lui, est fait pour être modifié vite (quand c'est bien fait). Du coup, l'approche Agile m'a toujours semblé pertinente (et très souvent mal appliquée). Et là, j'ai l'impression d'un beau retour en arrière. De plus, on reboucle sur ce que je disais avant : pour moi, les LLMs sont bons pour le dev initial, et très mauvais pour les évolutions.
Mais eh, allez-y, utilisez une technique dont les conséquences sont encore mal connues, et vibe-codez autant que vous voulez ! On verra bien quels projets et quelles entreprises seront encore vivants dans 10 ans :-)
posez d'abord la question de ce qui s'est fait en amont et en aval., ça sera plus constructif.
Et c'est tout le problème du vibe-coding : ce qui sort en aval. Il y a une perte complète de la maîtrise du résultat. Tu crois le maîtriser parce que le logiciel semble faire ce qu'il est censé faire, mais tu ne peux pas en avoir une certitude suffisante.
Tu prends l'exemple du passage de l'assembleur au C, et c'est un très mauvais parallèle. En compilant, le compilateur C prend en fait très peu de libertés par rapport au code écrit en C par le développeur. Et il y a des compilateurs C modernes qui sont opensources, régulièrement audités et relus, dans lesquels le niveau de confiance est donc excellent. Le développeur peut donc argumenter avoir le contrôle sur ce qui est généré par le compilateur.
Avec le vibe-coding, tu utilises forcément un LLM fermé (peut-être openweight, mais sûrement pas opensource). La sortie est exponentiellement plus longue que ce que tu lui donnes en entrée et elle contient donc forcément de l'improvisation. Et surtout, les LLM sont non-déterministes ! Ils ne te sortiront jamais deux fois le même code !
Donc, à moins de relire tout le code, c'est impossible de n'avoir ne serait-ce qu'une idée de ce qu'il y a dans le code. Sauf que je reste convaincu que c'est impossible : trop de volume de code, trop de ralentissements, pas assez de dopamine.
Pour un expert logiciel, la maîtrise du résultat est vitale : faire un programme qui fonctionne bien n'est que ~10% du travail d'un expert logiciel. Et pour cause, si c'était le seul et unique but, n'importe quel stagiaire suffit. Le gros du travail d'un expert logiciel, c'est de faire un logiciel qui sera encore fonctionnel, utilisé et activement maintenu dans 10 ans (maintenu sans rendre fou les confrères, j'entends). Il faut garder à l'esprit que la réécriture d'un logiciel est toujours l'aveu d'un échec, même quand on vibe-code.
Or on n'a clairement pas encore assez de recul sur le vibe-coding pour dire si c'est une solution qui tient la route sur plus de 10 ans. D'ailleurs, mes expérimentations m'en font fortement douter : de ce que j'en ai vu, les IA sont très fortes pour du one-shot prompt, mais, actuellement, elles sont franchement nulles quand il s'agit de gérer les évolutions toutes seules.
Ensuite, avec des LLM fermés, si le vibe-coding devient la pratique la plus courante partout, ça ouvrira des possibilités malhonnêtes mais très tentantes aux créateurs de LLM : plus tard, qu'est-ce qui empêcherait Anthropic (par exemple) d'entrainer ses LLM à repérer quand son utilisateur vibe-code, et à cacher de subtiles backdoor dans le code ?
Je me souviens quand un de mes collègues m'a expliqué que Claude lui mettait parfois des commentaires # Generated by Claude dans le code ou des Co-Authored-By: Claude dans ses messages de commit. Je suis encore sidéré que cette pratique n'ait pas déclenché automatiquement un boycott de Anthropic, et une interdiction massive du vibe-coding en entreprise.
À noter que les tests automatisés sont totalement hors-sujet, puisque si tu vibe-code, logiquement, ces tests seront le premier truc que tu vas vibe-coder.
Tu parles de bien penser la sécurité, mais trop souvent, une faille de sécurité, c'est juste trois lignes de code mal-écrites (« oh zut, un @require_login a été oublié sur une route »). Le vibe-coding t'expose totalement sur ce point.
Quant à l'architecture logicielle, ça ne résout que partiellement le problème. Avec le temps, si le code de chaque composant est devenu un gros tas de spaghettis, ce n'est pas ton architecture logicielle qui te sauvera.
Pour en revenir spécifiquement aux posts sur LinuxFr : je sais me servir des LLM. Je n'ai pas besoin de quelqu'un d'autre pour prompter Claude et copier-coller le résultat sur Github et LinuxFr. J'attends de l'originalité dans les dépêches et les journaux.
Est-ce qu'on n'est pas juste en train de faire tout un foin d'un non-problème ?
Tel que je vois ça, les IA sont juste un nouveau type d'outils. Ces outils peuvent faire plein de choses bien, et plein de choses mal. Ce qui fait la distinction entre les deux, comme pour tous les outils, c'est leurs utilisateurs et les façons dont ils les utilisent. On peut faire l'analogie avec un couteau à beurre : je peux tuer quelqu'un avec un couteau à beurre, pourtant l'idée ne viendrait à personne de bannir les couteaux à beurre.
À ce stade, je ne vois même pas l'intérêt de déclarer si une IA a été utilisée pour quoi que ce soit. À la place du développeur de rsync, je ne l'aurais juste pas dit.
Avant l'arrivée de l'IA, il y a très longtemps, en programmation classique, il a fallu plusieurs décennies pour déterminer les bonnes pratiques. Aujourd'hui encore, elles sont redébattues, ad vitam æternam, parce qu'il y a toujours quelqu'un pour ne pas être d'accord. Mais il y a des bonnes pratiques désormais fortement établies et ancrées dans les habitudes. Maintenant, avec l'arrivée de l'IA, j'ai l'impression qu'on a tout un tas de nouvelles façons de travailler qui s'offrent à nous, certaines bonnes, certaines mauvaises. Et comme pour la programmation classique, il va falloir faire le tri. Et ça, ça va demander beaucoup de temps et d'expérimentations.
Laissons la qualité et la maintenabilité du travail parler d'elles-mêmes. Les projets qui seront encore vivants dans 10 ans serviront alors de base pour les bonnes pratiques.
Si vous trouvez votre niveau de français trop mauvais, (…)
Pour le coup, on peut aussi se faire relire par un LLM. Entre ça et Grammalecte, je ne suis pas sûr qu'il y ait de différences notables sur le résultat final. Et avec le LLM, on peut discuter les tournures de phrase.
Exemple: j'avais un doute sur la compréhensibilité de ma phrase "Personnellement, je reste adepte de l'idée d'utiliser les LLM comme assistants plutôt que comme exécutants". Un LLM m'a confirmé qu'elle était claire. Mais la formulation initiale était un peu plus lourde, et l'outil m'a suggéré une formulation plus simple.
Qwen 3.8 27b est spécialisé programmation. Gemma4 31b est plus généraliste. Du coup, lui, il voit le défaut du poignard :
Le poignard et l'arbre : Le poignard semble "flotter" ou être fusionné de manière irréaliste avec le papier et l'écorce de l'arbre. Il n'y a pas d'ombre portée cohérente ni d'interaction physique réelle (comme un enfoncement dans le bois).
Le texte du parchemin : Le texte est totalement illisible. Ce ne sont pas des lettres réelles, mais des formes qui imitent l'apparence d'une écriture ancienne (du "faux texte" typique des IA), ce qui rend le document sans signification.
La main et le doigt : Si vous regardez attentivement le doigt levé de l'homme, sa morphologie est étrange et la jonction avec la main manque de naturel.
L'élément d'interface : Il y a une superposition d'interface utilisateur (le texte "Faites glisser vers le haut…" et une vignette vidéo) qui ne fait pas partie de la scène, ce qui indique qu'il s'agit d'une capture d'écran d'une application ou d'un outil de recherche.
Incohérence visuelle : Le contraste entre le réalisme du visage de l'homme et l'aspect "dessiné" ou artificiel du parchemin et du couteau crée un effet de montage maladroit.
Par contre, pour les pentagones, Gemma 4 31b a essayé d'utiliser mon générateur d'image pour ça. Or ce n'est évidemment pas le bon outil : c'est fait pour faire prototyper de l'art, pas de la géométrie. Sur ce coup-là, Qwen 3.8 27b est plus pertinent : en bon programmeur, il pense tout de suite à écrire un programme. Et le résultat est là. Par contre, ça lui a pris looooonnnnngtemps, et, selon comment on voit ça, il a triché :-). Il a fait pas mal de recherches sur Internet, et il est tombé sur le Tiling Viewer de Jaap Scherphuis (en Java). Il s'en est ouvertement inspiré, et a fait un script en Python et matplotlib basé sur ses mêmes algorithmes :
Cela signifie-t-il qu’on peut utiliser un modèle qui nécessite davantage que 16GB de RAM, mais n’est pas dense et donc se contenterait quand même de mes 16GB ?
Attention à la confusion entre VRAM (la RAM de la carte graphique) et la RAM (la RAM du CPU) !
Si tu veux effectivement dire que tu n'as que 16 Go de RAM (et, je suppose, encore moins de VRAM), tu vas avoir du mal à faire tourner quoique ce soit de correct (dense ou non). Tu vas être restreint aux très petits LLM (denses) qui sont bêtes comme des caillous.
Si tu voulais dire que tu as 16 Go de VRAM (et, je suppose, assez de RAM), alors oui : les modèles "pas denses", ce sont les MoE (Mixture-of-Experts). Et ils permettent justement ça.
Avec l'option --cpu-moe, les éléments du MoE qui sont systématiquement sollicités à chaque token sont gérés par la carte graphique et sont mis en VRAM. Les autres (les experts) sont gérés par le CPU et sont en RAM classique. Et en terme d'occupation mémoire, les experts représentent la plus grosse partie d'un modèle MoE. Mais comme un seul expert est sollicité à chaque token (simplification), ils sont plus rapides à traiter, et le CPU seul peut s'en occuper.
Grâce à ça, avec tes 16 Go de VRAM, si tu as assez de RAM, tu peux faire tourner un MoE comme qwen 3.6 35b par exemple sans problème, même si il occupe plus de 20 Go de RAM/VRAM.
(Initialement, avec les MoE, je pensais que la vitesse de génération était OK, mais que la vitesse de preremplissage allait pêcher quand même ; d'où mon corrigendum : en fait, le préremplissage peut être optimisé et arriver à un niveau tout à fait satisfaisant).
Concernant le piège que tu évoques sur les documents et le RAG, est ce que tu as essayé l'option "Full Context" ?
Raahhh, mais évidemment qu'il y avait une option planquée pour ça … 😭
Pour ceux qui, comme moi, galère ou ont galéré, il faut :
joindre le fichier à la conversation
cliquer sur le fichier (avant d'envoyer un message au LLM !)
en haut à droite, basculer l'interrupteur "Utilisation de la récupération ciblée", qui doit alors devenir "Utilisation du document entier" (et oui, le texte décris l'état actuel, et non pas ce qui va être activé quand vous activez l'interrupteur …).
Pour le coup, merci du tuyau ! Tu viens de m'enlever une belle épine du pied 🙂.
Chers gentils modérateurs, serait-il possible de retirer ce malheureux bout de phrase de mon journal s'il vous plaît : « et que vous ne pouvez pas changer ce comportement » ? 🥺
Pour un usage assez modeste — aide ponctuelle sur du code, relecture, LaTeX ou analyse de documents — vaut-il mieux privilégier un petit modèle entièrement contenu dans la VRAM, ou les 32 Go de RAM rendent-ils raisonnable l’utilisation d’un modèle plus ambitieux débordant sur le CPU ?
Tout d'abord, les vitesses des LLM dépendent bien plus de la quantité de VRAM que de la quantité de RAM : Si 99% du modèle est en VRAM, ça tournera bien. Si 99% du modèle est en RAM, ça sera très lent. Par exemple, vous pouvez avoir 1 To de la meilleure RAM DDR5 possible, si vous n'avez pas de VRAM du tout, vous ne ferez jamais tourner raisonnablement de LLM plus gros que du 10b (un peu plus de 10Go de RAM en q8).
Ensuite, il n'y a vraiment pas de réponse binaire à cette question :
La taille du modèle définit grosso-modo son niveau d'intelligence (j'hyper-simplifie ici ; l'architecture du modèle et ses données d’entraînement jouent aussi pas mal). Pour les taches indiquées, tous les modèles ont leur limite. Même Fable 5 a ses limites et va échouer parfois sur ces tâches. Mais plus le modèle est petit, plus il échouera. C'est à chacun de déterminer ce qu'il considère acceptable. Pour ma part, je suis à l'aise avec Qwen 3.6 27b. D'autres se contenteront peut-être d'un modèle un peu plus petit et plus bête. D'autres voudront absolument un modèle plus grand et plus intelligent.
Il en va de même avec la vitesse. Certaines personnes seront OK avec le fait d'attendre 5 min que le préremplissage se fasse pour reprendre leur session, et d'autres non. Certaines personnes seront OK avec un LLM qui mâche ses mots à 15 tokens/s, et d'autres s’impatienteront.
Il n'y a malheureusement pas de règle magique pour savoir à l'avance quoi utiliser. C'est vraiment à chacun d'essayer, voir ce qu'il peut faire tourner, et voir si ça lui convient.
Plus sérieusement, les LLM me ramènent au temps où une compilation complète d'un projet durait souvent longtemps. Ce temps où j'allais parfois discuter à la machine à café "le temps que la machine finisse" 🙂
j'y ai appris l'existence de Qwen 3.6 MTP… C'est le prochain que je teste.
Alors, ça vaut le coup de l'essayer. Mais je ne veux pas non plus te donner de faux espoirs.
MTP, c'est vraiment quitte ou double. Sur certaines configurations (logiciel, matériel, en fonction du LLM, etc.), ça détériore salement les performances, et sur d'autres, ça double la vitesse de génération des tokens ¯\_(ツ)_/¯. Dans tous les cas, ça n'améliore pas la vitesse de préremplissage.
Si un gentil modo passe par là, serait-il possible de corriger le lien "poules mouillées" ? Le bon lien est https://www.youtube.com/watch?v=tM4044bh4FU (j'ai visiblement réussi à faire une typo: le B est en majuscule au lieu d'être en minuscule).
Ça dépend. Seule, effectivement, elle ne t'apportera rien. Si tu peux la mettre en plus de ta Titan XP, tu arrives à 24Go de VRAM. Et 24Go de VRAM, ça t'ouvres par exemple la porte de Qwen 3.6 27b (dense) en q4_k_xl avec une taille de contexte décente (128K de mémoire).
--ubatch-size, passé de 512 (défaut) à 1536. Gain mesuré : +91% sur le prefill de Qwen3.6, un peu moins pour Gemma 4 26B A4B.
De mon coté, l'expérience montre que ça joue en effet beaucoup pour la Intel B60. Les Nvidia, nettement moins. La AMD, je n'ai pas pu tester.
Perso, jusqu'à présent, ça me sert surtout à faire les vieux nettoyages de code que j'ai longtemps laissés traîner. Je les ai laissés traîner parce-qu'il s'agit en général de faire des changements sur des éléments utilisés un peu partout dans le code.
Un exemple que je peux donner (hors boulot donc) : Sur mon projet perso Paperwork, j'ai environ 300 plugins. Ces plugins dérivent tous d'une même classe abstraite. Je voulais, de longue date, faire une modification dans un des contrats de cette classe abstraite, impactant donc les 300 plugins. Malheureusement, ça impliquait plus qu'un simple rechercher&remplacer. Comme il s'agissait de rendre les choses plus strictes, il fallait même corriger des erreurs qui étaient passées inaperçues jusque là. À l'époque, j'ai fini par le faire … à la main. Ça m'a pris plus de 2 semaines en temps libre. Et bien sûr, j'ai réalisé à la toute fin que j'aurais pu jeter un LLM sur le problème. J'ai fait le test pour savoir : en moins de 2h, un LLM (devstrall-small 2 de mémoire) m'avait réglé 95% du problème.
Pareillement, au boulot, je m'en sers aussi pour éliminer de la vieille dette technique bien pénible.
À coté de ça, je m'en sers aussi pour relire mes changements (soit pour du code perso, soit en pro, avant de l'envoyer en pull request aux collègues). Une sorte d'analyse statique++ avec laquelle je peux discuter en somme.
Quand je pense aux milliards engloutis, niveau retour sur investissement, j'espère que vous planchez sur un truc de maboul !
Alors moi, je ne planche sur rien du tout. Mais les chat bots sont une vieille fascination que je me traîne depuis mon adolescence. Autant te dire que je m'amuse beaucoup trop là ^^.
Toujours me concernant, on est d'ailleurs bien d'accord que les investissements sont complètement délirants par rapport à ce que l'outil à offrir. Ma conviction est qu'on nage dans un délire mondial complet : L'outil a fait un énorme effet "wow" en arrivant. Les investisseurs n'y comprennent visiblement. Et les boys de la Silicon Valley vendent continuellement un rêve sans avoir aucune certitude de pouvoir le réaliser : celle d'une IA qui n'hallucine jamais et qui ne fait jamais d'erreur, ou tellement rarement que ça devient négligeable.
De plus, je suis prêt à parier qu'il y a maintenant tellement d'argent sur la table qu'ils jouent tous au même jeu de cons : le premier qui crache ouvertement la pilule concernant les limitations des LLMs va faire s'effondrer ce château de cartes à plusieurs billions de dollars/euros et va foutre tout le monde dans la merde. Donc tout le monde continue comme si c'était la solution à tous les problèmes de l'Humanité.
D'autant que malgré mes recherches assistées par IA, je n'ai pas trouvé de homelabeur qui pousse de petits agents jusqu'au vibe-sysadmin, ou vibe-coding.
Même si je méfis du vibe-coding comme de la peste, je crois que je vais prendre cepassagepersonnellement … 🙂
Connais tu une communauté qui travaille sur le sujet ??
Sur le sujet de l'utilisation des LLMs sur les configurations à faible VRAM (≤16gb) ? Ou sur les très petits modèles (≤10b) ?
En fait, dans les deux cas, pas vraiment. Les petits modèles sont très limités, et ont donc peu d'utilisations possibles. Et faire tourner sérieusement des LLM plus gros sur des configurations à faible VRAM implique de faire du débordement CPU+RAM. Et le débordement, c'est vicieux : Au premier abord, ça semble donner des résultats utilisables. Mais ce que beaucoup ratent, c'est que ces résultats s'effondrent vite en utilisation réelle avec l'augmentation du contexte. Je pense détailler cette dernière problématique dans un prochain journal.
[^] # Re: Le problème est en aval
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Le vibe coding, linuxfr, et moi. Évalué à 3 (+1/-0).
Nickel, ça va me faire de la lecture, merci :-)
[^] # Re: Le problème est en aval
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Le vibe coding, linuxfr, et moi. Évalué à 3 (+1/-0). Dernière modification le 09 octobre 2026 à 13:33.
Tu en as un en particulier à conseiller ? (si possible dans un format qui se lance bien aux visages d'autres personnes ^^)
[^] # Re: Juste un outil
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Debian, IA, vibe coding & rsync : la croisée des chemins ?. Évalué à 4 (+3/-1). Dernière modification le 07 octobre 2026 à 16:07.
Je ne sais pas si ton commentaire est ironique ou pas, donc, dans le doute, je me permets d'y répondre sérieusement :
D'après Kaplan et al., augmenter l'intelligence d'un LLM suit la loi des puissances. Ça se voit d'ailleurs sur les benchmarks : il leur faut maintenant des mois entiers d’entraînement et des datacenters gigantesques pour entraîner leurs modèles. Tout ça pour finalement gratter quelques points de pourcentage dans les benchmarks.
Il est donc tout à fait possible qu'on soit déjà proche du potentiel maximum des LLM qu'on peut avoir, de façon raisonnablement écologique en tout cas (oui, bon, hein, je sais … 🫤). Autant dire qu'à ce stade, poursuivre la course à la taille et l'intelligence des modèles me semble écologiquement aberrant, mais c'est visiblement le chemin choisi par tous les participants … 🙁
[^] # Re: Le problème est en aval
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Le vibe coding, linuxfr, et moi. Évalué à 5 (+3/-0).
Le contexte énorme, c'est 1 million de tokens actuellement. Sur un projet sain, même très gros, c'est effectivement très large. Mais perso, j'attends de voir le résultat sur un très gros projet après dix ans de vibe-coding par une grosse équipe de dev.
Ah, pour le coup, j'ai appris quelque-chose, merci :-)
[^] # Re: Le problème est en aval
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Le vibe coding, linuxfr, et moi. Évalué à 10 (+11/-2). Dernière modification le 07 octobre 2026 à 15:18.
C'est un argument que je vois souvent chez les vibe-codeurs : il faut spécifier au maximum, pour ne pas laisser de chance au LLM de planter.
Ça m'amuse beaucoup, parce que personnellement, j'ai un souvenir du passage à Agile : l'idée m'avait semblé être de réduire les spécifications au minimum, de les faire à la volée, et d'itérer le plus possible à la place (corrigez-moi si je me trompe). Pour cause, spécifier correctement est très coûteux en temps, souvent plus que de coder directement, et les spécifications sont toujours fausses, tôt ou tard. Le logiciel, lui, est fait pour être modifié vite (quand c'est bien fait). Du coup, l'approche Agile m'a toujours semblé pertinente (et très souvent mal appliquée). Et là, j'ai l'impression d'un beau retour en arrière. De plus, on reboucle sur ce que je disais avant : pour moi, les LLMs sont bons pour le dev initial, et très mauvais pour les évolutions.
Mais eh, allez-y, utilisez une technique dont les conséquences sont encore mal connues, et vibe-codez autant que vous voulez ! On verra bien quels projets et quelles entreprises seront encore vivants dans 10 ans :-)
PS: GLM et Mistral n'ont rien à voir.
# Le problème est en aval
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Le vibe coding, linuxfr, et moi. Évalué à 10 (+11/-1). Dernière modification le 07 octobre 2026 à 12:08.
Et c'est tout le problème du vibe-coding : ce qui sort en aval. Il y a une perte complète de la maîtrise du résultat. Tu crois le maîtriser parce que le logiciel semble faire ce qu'il est censé faire, mais tu ne peux pas en avoir une certitude suffisante.
Tu prends l'exemple du passage de l'assembleur au C, et c'est un très mauvais parallèle. En compilant, le compilateur C prend en fait très peu de libertés par rapport au code écrit en C par le développeur. Et il y a des compilateurs C modernes qui sont opensources, régulièrement audités et relus, dans lesquels le niveau de confiance est donc excellent. Le développeur peut donc argumenter avoir le contrôle sur ce qui est généré par le compilateur.
Avec le vibe-coding, tu utilises forcément un LLM fermé (peut-être openweight, mais sûrement pas opensource). La sortie est exponentiellement plus longue que ce que tu lui donnes en entrée et elle contient donc forcément de l'improvisation. Et surtout, les LLM sont non-déterministes ! Ils ne te sortiront jamais deux fois le même code !
Donc, à moins de relire tout le code, c'est impossible de n'avoir ne serait-ce qu'une idée de ce qu'il y a dans le code. Sauf que je reste convaincu que c'est impossible : trop de volume de code, trop de ralentissements, pas assez de dopamine.
Pour un expert logiciel, la maîtrise du résultat est vitale : faire un programme qui fonctionne bien n'est que ~10% du travail d'un expert logiciel. Et pour cause, si c'était le seul et unique but, n'importe quel stagiaire suffit. Le gros du travail d'un expert logiciel, c'est de faire un logiciel qui sera encore fonctionnel, utilisé et activement maintenu dans 10 ans (maintenu sans rendre fou les confrères, j'entends). Il faut garder à l'esprit que la réécriture d'un logiciel est toujours l'aveu d'un échec, même quand on vibe-code.
Or on n'a clairement pas encore assez de recul sur le vibe-coding pour dire si c'est une solution qui tient la route sur plus de 10 ans. D'ailleurs, mes expérimentations m'en font fortement douter : de ce que j'en ai vu, les IA sont très fortes pour du one-shot prompt, mais, actuellement, elles sont franchement nulles quand il s'agit de gérer les évolutions toutes seules.
Ensuite, avec des LLM fermés, si le vibe-coding devient la pratique la plus courante partout, ça ouvrira des possibilités malhonnêtes mais très tentantes aux créateurs de LLM : plus tard, qu'est-ce qui empêcherait Anthropic (par exemple) d'entrainer ses LLM à repérer quand son utilisateur vibe-code, et à cacher de subtiles backdoor dans le code ?
Je me souviens quand un de mes collègues m'a expliqué que Claude lui mettait parfois des commentaires
# Generated by Claudedans le code ou desCo-Authored-By: Claudedans ses messages de commit. Je suis encore sidéré que cette pratique n'ait pas déclenché automatiquement un boycott de Anthropic, et une interdiction massive du vibe-coding en entreprise.À noter que les tests automatisés sont totalement hors-sujet, puisque si tu vibe-code, logiquement, ces tests seront le premier truc que tu vas vibe-coder.
Tu parles de bien penser la sécurité, mais trop souvent, une faille de sécurité, c'est juste trois lignes de code mal-écrites (« oh zut, un @require_login a été oublié sur une route »). Le vibe-coding t'expose totalement sur ce point.
Quant à l'architecture logicielle, ça ne résout que partiellement le problème. Avec le temps, si le code de chaque composant est devenu un gros tas de spaghettis, ce n'est pas ton architecture logicielle qui te sauvera.
Pour en revenir spécifiquement aux posts sur LinuxFr : je sais me servir des LLM. Je n'ai pas besoin de quelqu'un d'autre pour prompter Claude et copier-coller le résultat sur Github et LinuxFr. J'attends de l'originalité dans les dépêches et les journaux.
[^] # Re: Ce n'est pas ça
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Le vibe coding, linuxfr, et moi. Évalué à 10 (+14/-2). Dernière modification le 07 octobre 2026 à 11:25.
Il n'est pas développeur. Il est PDG, et un des pires : ceux qui micromanagent en disant à leurs ingénieurs comment faire leur travail.
# Juste un outil
Posté par Jérôme Flesch (site web personnel) . En réponse à la dépêche Debian, IA, vibe coding & rsync : la croisée des chemins ?. Évalué à -2 (+15/-19). Dernière modification le 04 octobre 2026 à 14:49.
Est-ce qu'on n'est pas juste en train de faire tout un foin d'un non-problème ?
Tel que je vois ça, les IA sont juste un nouveau type d'outils. Ces outils peuvent faire plein de choses bien, et plein de choses mal. Ce qui fait la distinction entre les deux, comme pour tous les outils, c'est leurs utilisateurs et les façons dont ils les utilisent. On peut faire l'analogie avec un couteau à beurre : je peux tuer quelqu'un avec un couteau à beurre, pourtant l'idée ne viendrait à personne de bannir les couteaux à beurre.
À ce stade, je ne vois même pas l'intérêt de déclarer si une IA a été utilisée pour quoi que ce soit. À la place du développeur de rsync, je ne l'aurais juste pas dit.
Avant l'arrivée de l'IA, il y a très longtemps, en programmation classique, il a fallu plusieurs décennies pour déterminer les bonnes pratiques. Aujourd'hui encore, elles sont redébattues, ad vitam æternam, parce qu'il y a toujours quelqu'un pour ne pas être d'accord. Mais il y a des bonnes pratiques désormais fortement établies et ancrées dans les habitudes. Maintenant, avec l'arrivée de l'IA, j'ai l'impression qu'on a tout un tas de nouvelles façons de travailler qui s'offrent à nous, certaines bonnes, certaines mauvaises. Et comme pour la programmation classique, il va falloir faire le tri. Et ça, ça va demander beaucoup de temps et d'expérimentations.
Laissons la qualité et la maintenabilité du travail parler d'elles-mêmes. Les projets qui seront encore vivants dans 10 ans serviront alors de base pour les bonnes pratiques.
[^] # Re: Comme quoi, ils sont conscients du souci
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Dis, journal, comment on demande à un LLM de faire de la pub pour un projet ?. Évalué à 3 (+2/-1).
Pour le coup, on peut aussi se faire relire par un LLM. Entre ça et Grammalecte, je ne suis pas sûr qu'il y ait de différences notables sur le résultat final. Et avec le LLM, on peut discuter les tournures de phrase.
Personnellement, je reste adepte de l'idée d'utiliser les LLM comme assistants plutôt que comme exécutants. D'expérience, les LLM MoE sont suffisants pour ça, et sont auto-hébergeables sans nécessiter de matériel hors de prix.
Exemple: j'avais un doute sur la compréhensibilité de ma phrase "Personnellement, je reste adepte de l'idée d'utiliser les LLM comme assistants plutôt que comme exécutants". Un LLM m'a confirmé qu'elle était claire. Mais la formulation initiale était un peu plus lourde, et l'outil m'a suggéré une formulation plus simple.
[^] # Re: Demandez à votre IA de prédilection si elle voit ce qui cloche dans cette image
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Pourquoi tout le monde en parle ?. Évalué à 10 (+11/-0). Dernière modification le 24 septembre 2026 à 08:29.
Qwen 3.8 27b est spécialisé programmation. Gemma4 31b est plus généraliste. Du coup, lui, il voit le défaut du poignard :
Par contre, pour les pentagones, Gemma 4 31b a essayé d'utiliser mon générateur d'image pour ça. Or ce n'est évidemment pas le bon outil : c'est fait pour faire prototyper de l'art, pas de la géométrie. Sur ce coup-là, Qwen 3.8 27b est plus pertinent : en bon programmeur, il pense tout de suite à écrire un programme. Et le résultat est là. Par contre, ça lui a pris looooonnnnngtemps, et, selon comment on voit ça, il a triché :-). Il a fait pas mal de recherches sur Internet, et il est tombé sur le Tiling Viewer de Jaap Scherphuis (en Java). Il s'en est ouvertement inspiré, et a fait un script en Python et matplotlib basé sur ses mêmes algorithmes :
Le script
(tous ces tests ont été fait via Open WebUI)
[^] # Re: Dense ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Interfaces utilisateur. Évalué à 3 (+1/-0).
Perso, j'utilise
nvtop(sudo nécessaire avec les cartes Intel et AMD pour voir la VRAM consommée).[^] # Re: Dense ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Interfaces utilisateur. Évalué à 4 (+2/-0). Dernière modification le 20 septembre 2026 à 16:51.
Attention à la confusion entre VRAM (la RAM de la carte graphique) et la RAM (la RAM du CPU) !
Si tu veux effectivement dire que tu n'as que 16 Go de RAM (et, je suppose, encore moins de VRAM), tu vas avoir du mal à faire tourner quoique ce soit de correct (dense ou non). Tu vas être restreint aux très petits LLM (denses) qui sont bêtes comme des caillous.
Si tu voulais dire que tu as 16 Go de VRAM (et, je suppose, assez de RAM), alors oui : les modèles "pas denses", ce sont les MoE (Mixture-of-Experts). Et ils permettent justement ça.
Avec l'option
--cpu-moe, les éléments du MoE qui sont systématiquement sollicités à chaque token sont gérés par la carte graphique et sont mis en VRAM. Les autres (les experts) sont gérés par le CPU et sont en RAM classique. Et en terme d'occupation mémoire, les experts représentent la plus grosse partie d'un modèle MoE. Mais comme un seul expert est sollicité à chaque token (simplification), ils sont plus rapides à traiter, et le CPU seul peut s'en occuper.Grâce à ça, avec tes 16 Go de VRAM, si tu as assez de RAM, tu peux faire tourner un MoE comme qwen 3.6 35b par exemple sans problème, même si il occupe plus de 20 Go de RAM/VRAM.
Voir:
(Initialement, avec les MoE, je pensais que la vitesse de génération était OK, mais que la vitesse de preremplissage allait pêcher quand même ; d'où mon corrigendum : en fait, le préremplissage peut être optimisé et arriver à un niveau tout à fait satisfaisant).
[^] # Re: Frustration
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Interfaces utilisateur. Évalué à 2 (+0/-0). Dernière modification le 06 septembre 2026 à 10:35.
En fait, je pense que c'est une frustration assez courante.
Sauf erreur de ma part, ceux qui veulent utiliser sérieusement l'IA générative passent généralement rapidement d'un simple chat à ComfyUI.
# Coquilles
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Corrigendum : Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks. Évalué à 5 (+3/-0). Dernière modification le 28 août 2026 à 18:20.
Je voulais préciser « peut aider avec la vitesse de prédicition » …
Et ici, le « nombre de cœurs de votre CPU ».
Gentils modos, s'il vous plaît ? 🥺🙏
(en plus, je vous jure que je me relis encore et encore avant de poster …)
# Corrigendum !
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks. Évalué à 2 (+0/-0).
Petit journal supplémentaire pour corriger une belle boulette que j'ai fait ici : https://linuxfr.org/users/jflesch/journaux/corrigendum-auto-heberger-ses-llm-ia-debordement-cpu-ram-mixture-of-experts-et-benchmarks
[^] # Re: Option "Full Context" pour les documents ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Interfaces utilisateur. Évalué à 5 (+3/-0). Dernière modification le 18 août 2026 à 18:31.
Raahhh, mais évidemment qu'il y avait une option planquée pour ça … 😭
Pour ceux qui, comme moi, galère ou ont galéré, il faut :
Pour le coup, merci du tuyau ! Tu viens de m'enlever une belle épine du pied 🙂.
Chers gentils modérateurs, serait-il possible de retirer ce malheureux bout de phrase de mon journal s'il vous plaît : « et que vous ne pouvez pas changer ce comportement » ? 🥺
[^] # Re: Passer de 16 à 32 Go : un vrai gain, mais jusqu’où ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks. Évalué à 3 (+1/-0). Dernière modification le 06 août 2026 à 00:33.
Tout d'abord, les vitesses des LLM dépendent bien plus de la quantité de VRAM que de la quantité de RAM : Si 99% du modèle est en VRAM, ça tournera bien. Si 99% du modèle est en RAM, ça sera très lent. Par exemple, vous pouvez avoir 1 To de la meilleure RAM DDR5 possible, si vous n'avez pas de VRAM du tout, vous ne ferez jamais tourner raisonnablement de LLM plus gros que du 10b (un peu plus de 10Go de RAM en q8).
Ensuite, il n'y a vraiment pas de réponse binaire à cette question :
La taille du modèle définit grosso-modo son niveau d'intelligence (j'hyper-simplifie ici ; l'architecture du modèle et ses données d’entraînement jouent aussi pas mal). Pour les taches indiquées, tous les modèles ont leur limite. Même Fable 5 a ses limites et va échouer parfois sur ces tâches. Mais plus le modèle est petit, plus il échouera. C'est à chacun de déterminer ce qu'il considère acceptable. Pour ma part, je suis à l'aise avec Qwen 3.6 27b. D'autres se contenteront peut-être d'un modèle un peu plus petit et plus bête. D'autres voudront absolument un modèle plus grand et plus intelligent.
Il en va de même avec la vitesse. Certaines personnes seront OK avec le fait d'attendre 5 min que le préremplissage se fasse pour reprendre leur session, et d'autres non. Certaines personnes seront OK avec un LLM qui mâche ses mots à 15 tokens/s, et d'autres s’impatienteront.
Il n'y a malheureusement pas de règle magique pour savoir à l'avance quoi utiliser. C'est vraiment à chacun d'essayer, voir ce qu'il peut faire tourner, et voir si ça lui convient.
[^] # Re: Tant de mots
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Ma découverte de l'IA, et de sa mise en exploitation personnelle.. Évalué à 4 (+2/-0). Dernière modification le 04 août 2026 à 16:36.
Pschut, caftes pas nos secrets ! 😁
Plus sérieusement, les LLM me ramènent au temps où une compilation complète d'un projet durait souvent longtemps. Ce temps où j'allais parfois discuter à la machine à café "le temps que la machine finisse" 🙂
[^] # Re: très éclairant
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks. Évalué à 2 (+0/-0).
Alors, ça vaut le coup de l'essayer. Mais je ne veux pas non plus te donner de faux espoirs.
MTP, c'est vraiment quitte ou double. Sur certaines configurations (logiciel, matériel, en fonction du LLM, etc.), ça détériore salement les performances, et sur d'autres, ça double la vitesse de génération des tokens ¯\_(ツ)_/¯. Dans tous les cas, ça n'améliore pas la vitesse de préremplissage.
# Typo dans le lien "poules mouillées"
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks. Évalué à 2 (+0/-0).
Si un gentil modo passe par là, serait-il possible de corriger le lien "poules mouillées" ? Le bon lien est https://www.youtube.com/watch?v=tM4044bh4FU (j'ai visiblement réussi à faire une typo: le B est en majuscule au lieu d'être en minuscule).
Merci d'avance :-)
[^] # Re: très éclairant
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks. Évalué à 2 (+0/-0).
Ça dépend. Seule, effectivement, elle ne t'apportera rien. Si tu peux la mettre en plus de ta Titan XP, tu arrives à 24Go de VRAM. Et 24Go de VRAM, ça t'ouvres par exemple la porte de Qwen 3.6 27b (dense) en q4_k_xl avec une taille de contexte décente (128K de mémoire).
De mon coté, l'expérience montre que ça joue en effet beaucoup pour la Intel B60. Les Nvidia, nettement moins. La AMD, je n'ai pas pu tester.
[^] # Re: Ça vous sert à quoi au quotidien ?
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses LLM (IA) : Débordement CPU+RAM, Mixture-of-Experts et Benchmarks. Évalué à 10 (+13/-0). Dernière modification le 03 août 2026 à 18:27.
Perso, jusqu'à présent, ça me sert surtout à faire les vieux nettoyages de code que j'ai longtemps laissés traîner. Je les ai laissés traîner parce-qu'il s'agit en général de faire des changements sur des éléments utilisés un peu partout dans le code.
Un exemple que je peux donner (hors boulot donc) : Sur mon projet perso Paperwork, j'ai environ 300 plugins. Ces plugins dérivent tous d'une même classe abstraite. Je voulais, de longue date, faire une modification dans un des contrats de cette classe abstraite, impactant donc les 300 plugins. Malheureusement, ça impliquait plus qu'un simple rechercher&remplacer. Comme il s'agissait de rendre les choses plus strictes, il fallait même corriger des erreurs qui étaient passées inaperçues jusque là. À l'époque, j'ai fini par le faire … à la main. Ça m'a pris plus de 2 semaines en temps libre. Et bien sûr, j'ai réalisé à la toute fin que j'aurais pu jeter un LLM sur le problème. J'ai fait le test pour savoir : en moins de 2h, un LLM (devstrall-small 2 de mémoire) m'avait réglé 95% du problème.
Pareillement, au boulot, je m'en sers aussi pour éliminer de la vieille dette technique bien pénible.
À coté de ça, je m'en sers aussi pour relire mes changements (soit pour du code perso, soit en pro, avant de l'envoyer en pull request aux collègues). Une sorte d'analyse statique++ avec laquelle je peux discuter en somme.
Alors moi, je ne planche sur rien du tout. Mais les chat bots sont une vieille fascination que je me traîne depuis mon adolescence. Autant te dire que je m'amuse beaucoup trop là ^^.
Toujours me concernant, on est d'ailleurs bien d'accord que les investissements sont complètement délirants par rapport à ce que l'outil à offrir. Ma conviction est qu'on nage dans un délire mondial complet : L'outil a fait un énorme effet "wow" en arrivant. Les investisseurs n'y comprennent visiblement. Et les boys de la Silicon Valley vendent continuellement un rêve sans avoir aucune certitude de pouvoir le réaliser : celle d'une IA qui n'hallucine jamais et qui ne fait jamais d'erreur, ou tellement rarement que ça devient négligeable.
De plus, je suis prêt à parier qu'il y a maintenant tellement d'argent sur la table qu'ils jouent tous au même jeu de cons : le premier qui crache ouvertement la pilule concernant les limitations des LLMs va faire s'effondrer ce château de cartes à plusieurs billions de dollars/euros et va foutre tout le monde dans la merde. Donc tout le monde continue comme si c'était la solution à tous les problèmes de l'Humanité.
# Vexant
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Ma découverte de l'IA, et de sa mise en exploitation personnelle.. Évalué à 10 (+12/-0). Dernière modification le 03 août 2026 à 13:25.
Même si je méfis du vibe-coding comme de la peste, je crois que je vais prendre ce passage personnellement … 🙂
[^] # Re: Petite config
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 2.
Je ne connais pas de communauté dédiée à ces sujets. La plus proche que je connaisse est le sub-reddit /r/localllama.
[^] # Re: Petite config
Posté par Jérôme Flesch (site web personnel) . En réponse au journal Auto-héberger ses IA : Matériel et optimisation de l'inférence. Évalué à 3. Dernière modification le 14 juillet 2026 à 09:33.
Sur le sujet de l'utilisation des LLMs sur les configurations à faible VRAM (≤16gb) ? Ou sur les très petits modèles (≤10b) ?
En fait, dans les deux cas, pas vraiment. Les petits modèles sont très limités, et ont donc peu d'utilisations possibles. Et faire tourner sérieusement des LLM plus gros sur des configurations à faible VRAM implique de faire du débordement CPU+RAM. Et le débordement, c'est vicieux : Au premier abord, ça semble donner des résultats utilisables. Mais ce que beaucoup ratent, c'est que ces résultats s'effondrent vite en utilisation réelle avec l'augmentation du contexte. Je pense détailler cette dernière problématique dans un prochain journal.