Quasi quotidiennement, je vois des messages fortement moinssés, avec comme argument « c’est du vibe coding, donc c’est de la merde ».
Comme d'autres journaux récents, je souhaite alimenter votre réflexion.
Aimant bien comprendre les choses, et ayant quitté le monde du codage depuis fort longtemps, je me suis documenté (pas via une IA générative, il faut rester sérieux), fait quelques tests avec l’IA mise à disposition par mon entreprise. Je vais vous expliquer ce que j’ai compris, et si l’équation vibecoding = merde est toujours vraie
Tout d’abord, il faut que je vous parle rapidement de mon parcours avec le codage afin que vous compreniez mes biais.
J’ai appris le codage dans les années 80 (1980, faut il le préciser …), en assembleur.
J’ai ensuite appris le Pascal, et c’était une révolution pour moi. On pouvait coder en langage humain (if, then, else , ..) , et non plus en langage machine
Dans mon premier emploi, on codait du temps réel. 2 équipes s’affrontaient :
Les anciens, qui ne juraient que par l’assembleur (exécution plus rapide, moins gourmand en ressources, ..)
Les modernes qui programmaient en C (codage plus rapide, code sensiblement aussi performant que l’ASM, maintenable, ..)
Pour ma part, j’avais le choix des armes. J’ai codé en C, en intégrant des bouts d’assembleur (le meilleur des 2 mondes)
Puis je me suis éloigné du codage, me contentant de quelques scripts Python ou Bash pour me faciliter la vie. J’ai suivi de loin l'arrivée de nouveaux langages et le revival d'anciens(PASCAL, FORTRAN), puis l’arrivée de l’Orienté Objet ..
Chacun étant supposé remplacer définitivement les prédécesseurs, mais certains sont toujours là car ils répondent à un besoin (FORTRAN ..). Pour moi il n'y a pas de "meilleur langage", chaque langage est adapté à un besoin.
Et maintenant, c’est le vibe coding. C’est-à-dire décrire en langage courant ce que doit faire un logiciel, et laisser une IA générative s’occuper du code.
Ce que je retiens de tout ça, c'est que le code n'est pas une fin en soi. Ce n'est qu'un intermédiaire qui permet à un humain d'expliquer à une machine ce quelle doit faire.
Le plus important dans le projet, c'est ce qui se passe avant:
- clairement définir le besoin (et vérifier que quelqu'un ne l'a pas déjà fait)
- bien penser l'architecture globale
- intégrer la cyber sécu
Et ce qui se passe après:
- tests unitaires
- tests d'intégration
- crash test (par ex fuzing, test du singe)
Les "pisseurs de code", ça n'est pas nouveau, c'est juste que maintenant c'est une machine qui le fait.
Même quelqu'un qui serait un excellent codeur, mais néglige ces étapes, ferait aussi de la merde.
Donc avant de conclure instantanément vibecoding = merde, posez d'abord la question de ce qui s'est fait en amont et en aval., ça sera plus constructif.
Reference:
https://www.youtube.com/watch?v=AiytemqB_F0
# Mauvais problème
Posté par Colin Pitrat (site web personnel) . Évalué à 10 (+20/-5). Dernière modification le 07 octobre 2026 à 09:08.
Le problème ce n'est pas le vibe-coding, les problèmes ce sont:
- vibe-écrire son journal
- venir faire de la pub (plus ou moins déguisée) pour son projet vibe-codé dans un journal à l'intérêt limité
- contribuer à noyer les modérateurs et les utilisateurs (moins grâce aux modérateurs, les utilisateurs de RSS peuvent en témoigner) sous un déluge de vomi
Il y a toujours eu des journaux qui ne m'intéressaient pas. La différence c'est qu'en les regardant, je me disais "ça peut intéresser quelqu'un". Depuis peu il y a énormément de journaux (dont beaucoup supprimés rapidement par les modos) pour lesquels je me dis "ça n'intéressera personne".
Un indice que c'est du contenu de merde: bien souvent l'auteur(e) ne répond à aucun commentaire. Il/elle a coulé son bronze sur linuxfr puis a abandonné son compte.
EDIT: Je n'ai pas cliqué dessus, mais avec son lien YouTube, ce journal me semble aussi être une tentative de pub déguisée derrière un sujet maintes fois discutés dans des journaux et commentaires et d'un intérêt limité. Mais qui sait, peut-être l'auteur me répondra?
[^] # Re: Mauvais problème
Posté par piratebab2 . Évalué à 5 (+10/-6).
Merci pour ton commentaire argumenté. Je ne parle pas du contenus de journaux écrit par les LLM, je les déteste aussi, mais c'est un autre sujet.
L'idée de mon journal, c'est de ne pas faire le lien entre vibe coding et merde sans se poser un peu de questions.
En gros, est ce que c'est un logiciel qui tient la route, répond à un besoin, et est robuste, ou bien est ce juste une preuve de concept faite rapidement.
Dans ce 2eme cas, il faut que le concept soit innovant pour mériter un journal. Je trouve que les jugements sont trop souvent à l'emporte pièce, et videcoding = merde n'est pour moi pas un argument.
Le lien c'est une video du site underscore, que certains doivent connaître. Ils interviewent un chef d'entreprise de logiciel qui explique comment il a intégré l'IA dans ces process. C'est très pragmatique, et intéressera les codeurs. C'est une bonne vision de ce que leur métier est en train de devenir.
[^] # Re: Mauvais problème
Posté par fork_bomb . Évalué à 10 (+13/-0).
Est-ce que tu te poses beaucoup de questions quand tu reçois un mail te proposant une somme d'argent importante en échange de ton aide pour une transaction financière ? Sûrement, la première fois que tu en as reçu un, tu as lu un peu attentivement, voire si tu es particulièrement naïf tu as donné suite. Maintenant, tu supprimes sans réfléchir.
C'est exactement la même chose pour les journaux présentant des projets vibe-codés : on a regardé les premiers, constaté que le projet était éclaté au sol, que l'auteur ne répondait pas aux commentaires, etc. Désormais, et surtout qu'il y en a un volume important, ta réaction est beaucoup plus rapide.
Tu me diras qu'il y a des logiciels de bonne qualité parmi tous ceux-là, mais en fait c'est une question d'effort : le lecteur ne va pas se palucher des dizaines de journaux nazes dans l'espoir de trouver un truc bien.
# oui mais
Posté par passant·e . Évalué à 8 (+7/-1).
C'est un peut le but du journal. La personne prend la temps d'expliciter son problème et sa démarche.
T'as quand même remarqué que ce sont les personnes qui débarquent du contenu qu'ils n'ont pas produit eux-mêmes qui se font descendre en flèche?
C'est pas la même chose entre s'aider d'un outil pour produire son code et de venir en discuter ou demander à son outil de faire le programme et de publier un journal "sympa" pour faire sa promotion.
Dans le deuxième cas, le prompteur n'a AUCUNE valeur ajoutée et n'importe qui ayant envie de brûler des tokens peut avoir la même application en quelques minutes. De plus, il n'y a aucun intérêt à venir demander des retours sur le code source vu que c'est un blob qui va changer au prochain prompt.
Je trolle dès quand ça parle business, sécurité et sciences sociales
[^] # Re: oui mais
Posté par piratebab2 . Évalué à 1 (+1/-1).
Tout à fait d'accord avec toi. Mais ce que je veux dire, c'est que le problème n'est pas le vibe coding, mais tout le reste!
# Logiciel Libre
Posté par Krunch (courriel, site web personnel) . Évalué à 10 (+12/-4).
Il existe des excellent compilateurs C libres (au sens FSF et OSI). Si tu veux utiliser Grand Theft Autocomplete pour générer du code, ça passe par des services et/ou modèles privateurs qui, de plus, ingèrent des corpus de code libre en contrevenant à leur licence. De ce que je comprend il existe des modèles sois-disant libres mais environ personne ne les utilise pour cet usage et leur conformité avec les quatre libertés est douteuse.
Donc, dans le cadre d'un site web qui a pour objectif de promouvoir les Logiciels libres, il me semble bien légitime de rejeter ce genre d'outils.
Sans même parler des aspects environnementaux, économiques, sociaux et éthiques plus larges.
pertinent adj. Approprié : qui se rapporte exactement à ce dont il est question.
# Ce n'est pas ça
Posté par Julien Jorge (site web personnel) . Évalué à 10 (+14/-4).
Je trouve que tu vas un peu vite. Le moinsage en masse de ces derniers temps concerne surtout les journaux générés par LLM. Parce que nous ne voulons pas lire ce que vous n'avez pas écrit.
Et il s'avère que c'est un peu pareil avec le vibe coding, nous ne sommes pas intéressés par l'existence d'un logiciel que personne n'a écrit. Il y a quelques journaux qui s'en sortent, probablement parce que leur contenu va bien au delà de la superficialité du descriptif typiquement généré. Il y a d'un côté l'objet (le logiciel développé, quel que soit l'outil utilisé), et de l'autre côté le retour d'expérience (le contenu du journal). Les journaux sont principalement jugés sur leur contenu donc n'y mettez pas de la m
Et puis c'est fatiguant ce discours disant que le vibe code c'est le turfu et que ceux qui ne s'y mettent pas sont destinés à rester sur la touche, comme [insérer une analogie du siècle passé]. Nous vivons très bien sans vos outils qui résolvent des problèmes que nous n'avions pas et qui en plus introduisent de nouveaux problèmes. Tout allait très bien, merci, gardez vos trucs pour vous.
[^] # Re: Ce n'est pas ça
Posté par piratebab2 . Évalué à -10 (+4/-15).
Je te conseille de regarder la video d'underscore que j'ai mis en lien. C'est le retour d'expérience d'un développeur qui a intégré intelligemment l'IA dans ses équipes.
[^] # Re: Ce n'est pas ça
Posté par skeespin . Évalué à 3 (+4/-2).
Je moinsse ou plusse extrêmement rarement les journaux donc je ne me sens pas viser par ton journal mais j'avoue comprendre l'effet de saturation.
Comment tu veux qu'on fasse confiance à quelqu'un qui ne sait pas proprement écrire journal ( même aider avec une IA ) sur son efficience dans sa manière de coder avec une IA ?
Je suis sur que les auteurs de ses journaux n'ont pour la plupart même pas fait l'effort de simplement relire.
Ces journaux sont simplement des incivilités de personnes qui ont découvert un nouveau jouet (les smartphones avaient eu leurs lots auparavant).
[^] # Re: Ce n'est pas ça
Posté par Jérôme Flesch (site web personnel) . É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.
[^] # Re: Ce n'est pas ça
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 6 (+5/-1). Dernière modification le 07 octobre 2026 à 11:46.
Encore un autre commentaire pour dire encore et toujours la même chose, si ça ne ressemble pas à du spam ou au moins du forçage (à la N.B.…)
Bref, il n’est pas développeur (même si on essaie depuis des lustres de galvauder et dévoyer le mot), c’est un manageur qui nous explique que c’est « trop bien sa vie de “manager l’IA” » (on connaissait déjà le « bullshit job » mais on découvre son côté « slop », vive le progrès) ; et comme le disent les commentaires, son histoire manque tristement d’âme. Alors n’essaie pas de nous fourguer ta1 camelote car on frise déjà l’overdose.
L’insistance peut laisser croire que c’est toi le fameux « développeur » …ou alors tu touches des intérêts à nous forcer à voir ce truc ? ↩
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Ce n'est pas ça
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 10 (+11/-1).
Honnêtement, au point où on est, je ne sais pas ce qui est le plus pénible entre les journaux IAesque et ceux qui parlent de l'IA pour la défendre ou la descendre. Mais, clairement, en ce qui me concerne y'a overdose des deux.
Je n’ai aucun avis sur systemd
[^] # Re: Ce n'est pas ça
Posté par Faya . Évalué à 2 (+0/-0).
2 modos dans le fil, j'en profite : https://linuxfr.org/suivi/dissuader-les-journaux-slop
[^] # Re: Ce n'est pas ça
Posté par Benoit Sibaud (site web personnel) . Évalué à 6 (+4/-1).
Fait un journal pour dénoncer ces deux types de journaux ? Ou demande à un LLM de le faire peut-être ?
[^] # Re: Ce n'est pas ça
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 6 (+5/-2). Dernière modification le 07 octobre 2026 à 15:43.
Tu préfères pas qu’à la place j’écrive moi-même une dépêche pour la journée Ada Lovelace, que je finisse celles que j’ai en cours sur LibreOffice 26.8 (pas dans l’espace de rédaction) et sur le code avant l’Unicode ?
Mais bon, j’ai demandé à mon IA préférée, bien que canine, ce qu’elle en pense. Sa réponse est sans appel :
Je prends ça pour un « l’IA c’est nul sauf si c’est moi ». Le moi en question étant, bien entendu, chienGPT.
Je n’ai aucun avis sur systemd
[^] # Re: Ce n'est pas ça
Posté par Julien Jorge (site web personnel) . Évalué à 7 (+6/-1).
Allez, pour te faire plaisir j'ai cliqué sur le lien. Maintenant je sais qui est interviewé je vais plutôt passer mon chemin. J'ai eu l'occasion de l'entendre plusieurs fois dans des vidéos ces quinze dernières années et je n'ai jamais été convaincu par son discours et encore moins par son attitude, bien au contraire. Peut-être qu'il a changé depuis mais je ne ferai pas l'effort d'aller vérifier.
Comme dit dans d'autres commentaires, il ne s'agit pas d'un développeur, mais d'un manager. Et encore, ce n'est pas qu'un manager, c'est un CEO, le rôle le plus éloigné des aspects concrets du métier. Après, sa boîte a l'air de bien tourner, il fait sûrement bien son travail, et je n'ai pas de leçon a donner en termes de business, mais son avis sur le dev ne m'intéresse pas, c'est non pertinent.
Je suis d'ailleurs surpris que personne ne se soit donné la peine de nous informer de qui il s'agit. Tu donnes le lien YouTube sans précisions, en parlant d'un mystérieux développeur. Le titre de la vidéo ne donne pas d'info non plus sur l'interviewé, ni même le descriptif court. Il faut aller trois lignes avant la fin du descriptif long pour savoir qui donne son avis. Ajoute à ça que le partenaire de la vidéo fait son beurre en vendant des solutions GenAI, tout cela ne donne pas envie. Est-ce une tentative pour faire du référencement ?
[^] # Re: Ce n'est pas ça
Posté par Lutin . Évalué à 9 (+7/-0).
Le mec interviewé est un mythomane, en 10 minutes un développeur qui vient tout juste de découvrir les LLMs arrive à pondre un prompt qui lui génère 5 semaines de son boulot. Je me demande bien à quoi devait ressembler le travail de ce dev…
# Méthode de travail
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+9/-2).
Tu décris une méthode qui ressemble beaucoup au cycle en V traditionnel.
Il y a beaucoup de gens qui ne travaillent pas comme ça, mais avec des méthodes dites "agiles" ou ces étapes ne sont pas du tout découpées de la même façon.
En ce qui me concerne, l'écriture de code n'est pas seulement pour dire à la machine ce qu'elle doit faire. Il s'agit d'une méthode de formalisation des besoins exprimés. Cette formalisation dans un langage strict et structuré fait que on se rend compte, lors de l'écriture du code, qu'il y a des cas non prévus dans la spécification, voire des informations contradictoires. Cela permet aussi de se poser la question des bonnes structures de données à adopter pour faire le traitement de façon efficace.
Il y a donc constamment des allers-retours entre l'écriture du code et la rédaction de la spécification.
Je ne suis pas capable de faire ce travail en exprimant les choses en langage naturel (français ou anglais). Je ne pense pas que la personne qui rédige la spécification pourrait remplacer mon travail par l'utilisation d'un LLM. Je ne pense même pas qu'elle pourrait réduire mon travail: si une partie du code était générée par un LLM, ça me ferait d'autant plus de code à relire et à comprendre. Pour moi cela demande plus d'effort de lire et comprendre le code de quelqu'un d'autre, que d'écrire moi-même du code. De plus, le processus mis en place (écriture par une personne et relecture par une autre) est un moyen supplémentaire de détecter les divergences avec la spécification et les oublis. Lors de l'utilisation d'un LLM, c'est la première chose qui va sauter: le développeur ayant demandé au LLM de générer le code, ne l'a pas écrit, mais il l'a relu. Il va donc penser qu'une deuxième relecture n'est pas utile.
Il y a des cas où le code n'est pas critique, suffisamment simple, et où ça peut marcher. Mais dans ce cas, je ne vois pas l'intérêt d'en faire un journal sur linuxfr, car on apprendra rien de nouveau.
[^] # Re: Méthode de travail
Posté par piratebab2 . Évalué à 5 (+6/-2).
Ce que je décris de façon simpliste et probablement maladroite, c'est le "code driven by tests".
Je que je veux dire, c'est que la vrai valeur ajoutée, c'est la réflexion en amont, et les boucles de test.
Dans mon boulot, je gere des projets qui incluent du logiciel. Le codage représente une infime partie du travail. Le gros du boulot (et des couts), ce sont la spécification et les tests.
[^] # Re: Méthode de travail
Posté par Benoit Sibaud (site web personnel) . Évalué à 8 (+7/-2).
Avec une limite supplémentaire pour l'IA : avec un codeur (ie. supposé être une personne un minimum éthique et professionnelle) : lui demander une fonction addition de deux entiers positifs en ayant prévu un test nominal sur 1 et 3, des cas avec des entrées invalides et un cas de test de débordement d'entier ça devrait suffire. Avec un LLM, tu n'es pas l'abri que tous les tests soient ok mais que le code se limite à « exclure les cas problématiques et sinon renvoyer 4 » (dit autrement le LLM n'offre pas forcément un niveau d'éthique ou de professionnalisme, il remplit juste un ou des objectifs, et rien de plus).
[^] # Re: Méthode de travail
Posté par Nicolas Boulay (site web personnel) . Évalué à 0 (+2/-5).
Oui, c est le problème principale. Les agents règlent une partie du problème. Tu fais faire des revues selon la spec ou des normes, et tu reboucles.
J imagine que l etape suivante est d'ajouter les méthodes de l aeronautique : revue de test, traçabilité code souce <-> tests <-> spec, couverture de code, fuzzing,…
Sur un plan a 20€, cela part vite, mais cela marche de mieux en mieux.
"La première sécurité est la liberté"
[^] # Re: Méthode de travail
Posté par thoasm . Évalué à 5 (+3/-1).
En tout cas pour les maths, ça ne suffit pas : Navier-Stokes lost in translation: Why Lean verification of AI autoformalisation does not guarantee correct natural language proofs
Pour des raisons fondamentale, la formalisation de preuve en langage naturelle et ses ambiguïtés dépends de la résolution de problèmes indécidables en terme algorithmique, parfois …
[^] # Re: Méthode de travail
Posté par fearan . Évalué à 6 (+3/-0).
Pour avoir fait généré automatiquement des tests par IA, j'ai du les jeter :)
Ce générateur m'avait fait quasiment fait des test lignes à ligne vérifiant les appels via des mock.
Le tout dans l'ordre de la fonction…
j'ai du revoir un peu le prompt plus précisément sur ce que je voulais des tests.
Ce qu'il avait généré en premier lieu n'avait aucun intérêt si ce n'est casser à la premières mise à jour de code :)
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
# Le vrai problème c’est pas de pisser du code, mais les dégâts provoqués par l’outil « IA générative »
Posté par SpaceFox (site web personnel, Mastodon) . Évalué à 10 (+19/-11).
Les IA génératives ont des impacts négatifs très importants, tu en trouveras une liste assez complète ici : https://davidbeck.fr/blog/pourquoi-ia-non.html
Ainsi donc, utiliser l’IA générative, c’est :
Toutes les IA génératives généralistes grand public posent tous ces problèmes ; il n’en existe aucune qui en soit exempte.
Je sais, ce message ne fait pas plaisir, mais tout ça est très largement documenté. Donc : si vous acceptez de vibecoder des choses, alors vous acceptez aussi toutes ces externalités, et acceptez que le jeu en vaut la chandelle.
Vous gérez ça avec votre conscience ; mais pour moi : oui, le vibecoding, c’est de la merde.
Littératures de l’imaginaire, libres, pour tout le monde : https://renardspatial.com/ | La connaissance libre : https://zestedesavoir.com
# Le problème est en aval
Posté par Jérôme Flesch (site web personnel) . É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: Le problème est en aval
Posté par piratebab2 . Évalué à 0 (+4/-5).
Ca c'est un argument que j'aimerai voir plus souvent!
C'est cet argument qui devrait étre mis en avant, pas le vibe coding qui n'est qu'un outil qui peut être bien ou mal utilisé.
[^] # Re: Le problème est en aval
Posté par wilk (site web personnel, Mastodon) . Évalué à 10 (+10/-2).
Ben en fait non.
Non seulement le vol n'est pas un travail comme un autre mais si en plus il pose énormément de problèmes économiques, sociaux et environnementaux et bien il vaut mieux s'en passer, d'autant plus si on veut promouvoir les valeurs du libre.
[^] # Re: Le problème est en aval
Posté par syj . Évalué à 3 (+7/-5). Dernière modification le 07 octobre 2026 à 14:57.
Je suis passé dans mon équipe sur un développement piloté par les specs.
On a process très documenté qui guide le modèle du design à la livraison.
Il n'y a rien à y re-dire, çà marche, çà fournit un travail de meilleur qualité que la majorité des devs peuvent fournir.
le code est propre , testé de manière intelligente surtout si tu l'y contrains fort car ils ont tendance à rechigner comme beaucoup de développeurs.
Notre système est très contraint. Le LLM a au final très peu de marge de manœuvre, il est contraint par:
- la spécification( en Anglais dans un markdown)
- les attendus (en Gherkin + ou moins strict)
- le plan de développement établi (négocié avec le dev … négocié c'est le terme, je peux passer 1/2 journée sur un plan de dev)
- les règles de conception relatif à notre framework
- les tests qui valident les attendus à plusieurs niveaux (grain fin JUnit jusqu'au test d'intégration Playwright).
- les règles de code reviews (bonne pratique, contrôle de la duplication de code, vérifie que la bonne méthode est au bon endroit , mais aussi les failles sécurité type XXE , path-traversal, injection de script, le contrôle des sécurités utilisateurs, …)
- Contrôle la cohérence de la documentation utilisateur existant & les anciens specs qu'on appelle la doc froide.
Tous les éléments ci-dessus définissent le corpus de règle qui définissent ton application. Le modèle suit un workflow définit par des skills qui l'oblige à valider que chaque éléments de ce corpus est vérifié.
Au final pour moi, le développement est passé d'un langage Java/Typescript (de haut niveau) en langage naturel
Au final, çà reste du codes car on exprime des règles logiques qui définissent le logiciel, c'est nous qui spécifions l'architecture , les règles mais on ne code plus chaque fonction. C'est un peu comme utiliser une librairie pour faire un taff qu'on ne veut pas implémenter.
Concernant les LLM fermés, j'en utilise actuellement 2:
- Claude Opus pour taff. (J'utilise rarement Fable si j'ai besoin de quelques choses de mieux je réveille mon cerveau :-D )
- Mistral GLM 5.? pour le perso
Certes, GLM est moins bon que le Claude Opus actuel, mais ils n'ont que 6 mois de retard… çà va!(chez mistral, on n'a pas le dernier GLM). Pour moi, ce n'est pas un problème. Opus actuel est suffisant pour toutes les tâches. Dans 6 mois, les modèles Open-Weight seront au moins aussi performant et probablement plus performant en économie d'énergie car ils sont construit pour être plus efficient.
[^] # Re: Le problème est en aval
Posté par Jérôme Flesch (site web personnel) . É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.
[^] # Re: Le problème est en aval
Posté par syj . Évalué à 1 (+2/-2).
J'avais le même point de vue avant :-D
En fait, vu qu'ils ont un contexte énorme. Le modèle arrive à avoir une connaissance de la spec, de la doc & du code en même temps (et même voir plus parfois).
Et quand tu négocies les changements avec lui. Il va pointer tous les points qui deviennent contradictoire.
Dans le plan de dev, il pointera tous ces éléments et il ira les corriger pour que tout reste cohérent.
En soit, çà te prendrait énormément de temps de de faire çà à la main. Pour eux, c'est rapide.
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.
[^] # Re: Le problème est en aval
Posté par Jérôme Flesch (site web personnel) . É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 Nicolas Boulay (site web personnel) . Évalué à 1 (+1/-3).
Les agents font comme nous : des gros grep dans le code. Cela necessite beaucoup moins de token.
Toutes methodologies que l on impose a des humains peuvent l etre a des llm. Typiquement, tous les trucs que l on ne fait pas completement par manque de temps.
"La première sécurité est la liberté"
[^] # Re: Le problème est en aval
Posté par Nicolas Boulay (site web personnel) . Évalué à 2 (+2/-3).
Non l agilité, ce n est pas ça. Scrum qui est souvent confondu avec l agilité, utilise des user story qui contiennent deja toute la spec necessaire pour bosser.
"La première sécurité est la liberté"
[^] # Re: Le problème est en aval
Posté par Lutin . Évalué à 3 (+1/-0). Dernière modification le 08 octobre 2026 à 19:02.
Je pensais la même chose de l'agile, et c'est effectivement comme ça que c'est appliqué dans la plupart des boîtes.
Puis j'ai travaillé dans une boîte qui m'a fait repenser le principe.
Tout les tickets qui n'étaient pas suffisamment spécifiés n'entraient pas dans le sprint (c'était la version scrummvm de l'agile) et retournaient dans les mains du PO. Le principe était de laisser les managers en dehors du développement, et au lieu d'avoir 50.000 trucs urgent en même temps, l'équipe de développement promettait les avancements dans le dev avec une granularité de 2 semaines (durée du sprint).
Le PO et le scrum-master s'arrangeaient sur quelles épics, stories & cie entraient dans les sprints à venir.
Et c'était génial. Mais cette expérience fait clairement office d'exception.
Ma conclusion: l'agile, c'est super, ou c'est l'enfer, il n'y a pas d'entre deux, et 99% des boîtes prennent la version infernale.
[^] # Re: Le problème est en aval
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 5 (+2/-0). Dernière modification le 08 octobre 2026 à 23:52.
On trouve de tout dans les méthodes agiles.
Le principe de base est simple: ces méthodes sont adaptées quand ce n'est pas possible d'écrire une spécification complète dès le départ. Les besoins ne sont pas complètement identifiés, ou alors on sait déjà qu'on voudra étendre le projet plus tard ou qu'il va devoir évoluer pour d'autres raisons.
La mise en pratique est donc de démarrer assez rapidement le développement, et de réaliser la spécification au fur et à mesure, en présentant des versions du travail en cours et en s'en servant pour identifier ce qui ne marche pas, les points à améliorer, etc.
Ça ne dispense pas de faire de la documentation, bien au contraire. Tout au long du projet, l'architecture évolue, et mintenir des documents à jour coûte plus cher que de les écrire une bonne fois pour toutes au début.
Ensuite, on peut pousser ces méthodes beaucoup plus loin: puisque la spécification et l'architecture du code sont modifiaples tout au long du projet, la même idée peut s'appliquer à toute l'organisation du projet. On peut donc décider d'ajouter ou de supprimer des réunions récurrentes, d'attribuer un rôle spécifique à une personne (archiect, product owner, scrum master), choisir quand on fait des livraisons, etc.
La méthode scrum est le résultat auquel est arrivé une équipe oe développeurs après plusieurs années de pratique et d'expérimentation. Elle met en place tout un tas de choses plutôt oien pensées: oes sprints de durée courte avec un périmètre de travail fixé à l'avance, ce qui fait que les urgences peuvent être reportées au sprint suivant la plupart du temps. La séparation des rôles entre scrum master et product owner pour que l'un puisse rappeler les règles à l'autre s'il était tenté d'y faire une entorse. Le chiffrage des user stories en "points" qui ne sont pas directement une estimation de temps mais permettent tout de même d'équilibrer la charge des sprints.
Souvent, ce modèle est appliqué bêtement sans être compris. Il n'est pas forcément adapté à toutes les situations. Il faudrait donc l'adapter en pratiquant l'agile. Mans pour cela, il faut d'abord bien le comprendre, sans quoi, des modifications qui semblent anodines peuvent complètement déséquilibrer l'ensemble (et comme on est en entreprise, ce sera au profit du management et au détriment des gens qui font le travail).
[^] # Re: Le problème est en aval
Posté par Lutin . Évalué à 2 (+0/-0).
Dans l'expérience que je raconte, le projet était précisément spécifié. Cela c'est peut-être c'est peut-être pour ça que pour la méthode agile que j'en ai un bon souvenir.
[^] # Re: Le problème est en aval
Posté par BAud (site web personnel) . Évalué à 3 (+1/-0).
tu voulais dire ScummVM ou Scrum ? :D
mais oui, je rejoins un peu ton avis et plus celui de pulkomandy<
malencontreusement, en grande entreprise, tu rencontres peu souvent des équipes ayant compris l'articulation cycle en V / dév' agile lorsqu'il y en a besoin. Bon j'ai eu plus de chance que toi, j'ai plus du 70/30 (j'ai dû avoir du bol ou réussir à faire le grand écart malgré eux, mais bon quand t'as une équipe qui prétend faire de l'agile et qui te dit qu' « il n'y a pas de doc' », bin mieux vaut fuir ou avoir du temps pour expliquer et réussir à avancer :/)
[^] # Re: Le problème est en aval
Posté par Lutin . Évalué à 2 (+0/-0).
Scrum, j'ai mélangé les deux. Pour être honnête en me relisant ça m'a fait sourire alors j'ai laissé :D
[^] # Re: Le problème est en aval
Posté par barmic 🦦 . Évalué à 2 (+0/-0).
Si ça marche c’est bien, mais c’est une lecture très particulière du manifesto. Comment est déterminé "suffisamment spécifié" ? Qu’est-ce qui se passe si on se rend compte après le démarrage du sprint que ce n’est pas suffisamment spécifié. Ça donne quoi comme temps de cycle entre le moment où un utilisateur décrit un besoin et sa livraison ?
Dans les 12 principes du manifeste agile tu as :
Ce que tu semble décrire semble strict et chercher à minimiser les interactions PO / équipe de dev. Une manière plus classique de le dire est "les individus et leurs interactions plutôt que les processus et les outils".
Ça n’enlève au fait que ça marchait bien pour vous. C’est juste une version de l’agilité assez ténue.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le problème est en aval
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 4 (+1/-0).
La "definition of ready" fait partie de scrum, c'est assez bien expliqué ici par exemple: https://www.scrum.org/resources/blog/walking-through-definition-ready
En gros: tu as une "definition of done" pour savoir quand une user story est finie et prête à déployer en prod (avec toutes les phases de test, relecture, validation, etc que cela nécessite).
C'est une bonne idée de valider les choses au fil de la réalisation de l'US plutôt que tout à la fin (exemple avec la fabrication d'une voiture: tu fais des contrôle qualité tout le nong de la chaîne d'assemblage, pas une fois que toute la voiture est assemblée).
Du coup, logiquement, tu peux repousser une partie de cette validation avant même l'entrée de la user story dans un sprint pour sa réalisation. Tu peux t'assurer par exemple que toutes les infos nécessaires sont disponibles, que les grandes lignes de l'architecture à mettre en place sont définies, peut-être même une définition des scénarios de test qu'il faudra jouer.
Oui ça demande du temps de préparer tout ça. Mais d'un autre côté ça augmente la fiabilité du chiffrage et ça permet donc à l'équipe de s'engager avec une bonne confiance sur ce qu'elle va pouvoir réaliser dans un sprint.
Selon les projets, ça peut être nécessaire ou pas. Dans certains cas, l'incertitude sur le chiffrage n'est pas importante, et livrer une version avec un ou deux sprints de retard sur ce qui était annoncé ne pose aucun problème (juste les utilisateurs attendront un peu). Par contre si il y a des deadlines critiques (publier un jeu vidéo avant noel, mettre à jour un logiciel de compta avant l'entrée en application d'une loi, installer le code dans un satellite avant sa mise en orbite), tu as intérêt à être très fiable sur ce genre de choses, et là, avoir une bonne definition of ready va au moins permettre d'anticiper les problèmes.
Ça déPend aussi si les dévs de l'équipe sont autonomes pour concevoir l'architecture pendant la réalisation d'une user story, ou si tu as une équipe de débutants avec seulement quelques personnes capables de faire la conception d'architecture. Ou si ton PO est surbooké et risque de bloquer le développement si on a une question pour lui pendant la réalisation de la user story.
[^] # Re: Le problème est en aval
Posté par barmic 🦦 . Évalué à 1 (+1/-2).
En préambule encore une fois mon point n’est pas de dire comment des gens que je ne connais pas doivent travailler, mais plutôt de discuter autour de l’organisation de travail, en particulier autour de l’agilité. Dans mes commentaires "ce n’est pas de l’agile" ne veut pas dire que c’est un problème. Il n’y a pas de raison de corriger quelque chose qui fonctionne.
La DoR ne dit pas qu’il faut transnationaliser les intéractions. D’ailleurs une bonne partie de ce qu’on peut trouver dans un DoR n’est pas du fait des PO. Par exemple tu dis :
Certains ont identifié ça et on créé une pratique nommée les "3 Amigos", il s’agit de mettre ensemble un PO, un tech et un testeur pour pouvoir s’assurer que c’est prêt.
La gate n’est pas là pour renvoyer le PO à son travail, mais un moment d’intéraction entre des gens de casquettes différentes. Le commentaire semble présenter une méthode qui cloisonne et transactionnalise plutôt que d’ouvrir les équipes à interagir entre elles (en fait l’idée même que le PO ne fait pas parti de l’équipe est questionnable).
Tout à fait et je décris personnellement l’agilité comme des boules de feedback, mais du coup si tu segmente est-ce que c’est considéré comme un problème d’aller voir un PO en milieu de sprint ? Ou est-ce qu’il faut attendre la fin des 2 semaines pour avoir la démo et se rendre compte de si tout est bon. L’agilité est naît de l’idée que la spécification est un travail globalement impossible. Le découper le simplifie mais ne le rend pas simple et il est très difficile d’avoir le bon niveau de spécification (avoir suffisamment d’info et ne pas passer plus d’énergie que nécessaire dans des parties inutiles).
Ma take c’est que le chiffrage sert uniquement à faire discuter l’équipe de dev autour d’une tâche, mais que les valeurs absolues jour/homme ou je ne sais quoi sont plus néfastes qu’autre chose. La mesure de la vélocité aussi d’ailleurs.
Je n’ai jamais vu, entendu, vu décrit nulle part, quelqu’un expliquer que ceux qui contractualisent vraiment (directeur de projet dans les grandes ESN) doivent être en sprint planning. Ce que ça veut dire, c’est que les engagements sont pris ailleurs. Tu peut décider ce que tu veut en sprint planning la boite a déjà vendu la fonctionnalité à une date donnée par exemple. L’engagement ne sert qu’à une seule chose c’est de développer de la confiance, mais ce n’est pas le seul moyen d’y parvenir.
Embrasser l’incertitude plutôt que de tenter de la cacher est de mon avis et mon experience bien plus moteur de confiance que de contractualiser. Dans un autre contexte est-ce que tu préfère :
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll
[^] # Re: Le problème est en aval
Posté par wilk (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
On se retrouve donc avec les problèmes bien connus de dépendances qu'on ne maîtrise plus, ce qui entraînera une dépendance à vie sur les LLMs (qu'on ne maîtrise pas non plus) et ainsi de suite.
Concernant les librairies ont peut relativement estimer les coûts de maintenance à long terme même si une librairie doit être maintenue ou remplacée. Mais là, j'imagine qu'il y a un pari sur des coûts de token stables ?
[^] # Re: Le problème est en aval
Posté par syj . Évalué à 2 (+1/-0).
En fait, comme je le disais un peu plus haut les LLM Open-Weight comme GLM n'ont que 6 mois de retard vis-à-vis des LLM fermés.
Et ils sont déjà satisfaisant. Suffisant pas encore, mais dans 1 ans, ils le seront. J'en ai aucun doute.
C'est aussi pour çà que j'aime bien suivre les articles de Jérôme Flesch car potentiellement ce qu'il fait on sera obligé tous de le maitriser dans un an.
[^] # Re: Le problème est en aval
Posté par wilk (site web personnel, Mastodon) . Évalué à 7 (+5/-0).
Ca fait pas rêver dis donc.
Actuellement les seuls arguments sont la peur et l'obligation pour uniquement produire plus de code en quantité et non en qualité dont on n'a pour l'instant aucune demande voir une demande en baisse du fait de la crise que ça entraîne dans de nombreux domaines.
Le pari sur la rentabilité à moindre coût me semble extrêmement risqué surtout pour un besoin qui n'existe pas, non ?
[^] # Re: Le problème est en aval
Posté par syj . Évalué à 1 (+0/-0).
Je te conseille cette lecture : https://www.fnac.com/a1112977/Spencer-Johnson-Qui-a-pique-mon-fromage
[^] # Re: Le problème est en aval
Posté par wilk (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Merci pour ton conseil. Le mien serait de ne pas s'enfermer dans de nouvelle obligations et dépendances justement pour pouvoir s'adapter aux prochains changements.
Pour rester dans les conseils, 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. S'adapter n'est pas résister mais pas subir non plus. Tu as la lucidité d'y voir une obligation, cqfd.
Ce qui est pratique en informatique c'est que le terme de dépendance peut être pris dans tous les sens du terme !
[^] # Re: Le problème est en aval
Posté par Jérôme Flesch (site web personnel) . É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: Le problème est en aval
Posté par wilk (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
Olivier Hamant, De l'incohérence : Philosophie politique de la robustesse
Autant le côté incohérence ça m'a foutu une claque autant le côté robustesse du fait de la redondance, éviter les dépendances, l'enfermement etc c'est particulièrement concret pour nous.
Y a un côté philosophique et très pratique en même temps.
[^] # Re: Le problème est en aval
Posté par Jérôme Flesch (site web personnel) . Évalué à 3 (+1/-0).
Nickel, ça va me faire de la lecture, merci :-)
[^] # Re: Le problème est en aval
Posté par bbo . Évalué à 3 (+1/-0).
Une interview sur le sujet a été partagé ici même récemment !
En ce qui me concerne, cette interview a été une excellente introduction à la robustesse !
[^] # Re: Le problème est en aval
Posté par wilk (site web personnel, Mastodon) . Évalué à 6 (+4/-0).
D'après ce que tu décris et qui finalement pas changé c'est que la production de code n'est qu'une infime partie du boulot et je rajouterai même la plus facile et la plus agréable. La plus grande étant la conception puis la maintenance. D'autant plus pour une application métier.
Mais alors dans ce cas quel intérêt de se rajouter une telle dépendance et qui demande des compétences obscures (non déterministes) pour si peu j'ai envie de dire ?
Est-ce que réellement vous avez tant de mal à produire du code ?
[^] # Re: Le problème est en aval
Posté par syj . Évalué à -1 (+2/-4). Dernière modification le 08 octobre 2026 à 09:46.
En fait, je ne dirais pas que c'est non-déterministe.
A l'inverse, c'est même beaucoup plus déterministe que quand on demande à un junior ou un senior d'écrire un module sur laquelle on s'est mis d'accord sur l'architecture. Le LLM ira beaucoup plus vite , çà sera beaucoup plus propre.
Au final, le travail reste. c'est important de le préciser. Il est en amont. On travaille beaucoup plus sur le raffinement des besoins, de l'organisation, des attendus.
Mécaniquement, on passe aussi plus de temps à tester, à réceptionner les productions des autres , même de non-dev (équipe service) où il faut être vigilant.
Et là, ce n'est pas sur la qualité du code mais sur l'intégration fonctionnel qui peut avoir été bâclé.
On passe aussi beaucoup de temps à raffiner le process de production.
[^] # Re: Le problème est en aval
Posté par wilk (site web personnel, Mastodon) . Évalué à 6 (+5/-1).
Si je comprends bien le LLM vous sert à compenser ce qui était un manque de travail en amont, sur l'intégration et une mauvaise formation des juniors ou plutôt les mauvaises tâches attribuées aux juniors.
On reste donc dans l'idéologie de la technologie qui va résoudre les problèmes structurels.
Le problème avec cette approche est que même si elle résout une part du problème ponctuellement elle en rajoute d'autres. C'est une fuite en avant au lieu de résoudre le problème à la base.
[^] # Re: Le problème est en aval
Posté par syj . Évalué à 0 (+2/-3).
Tu interprètes mal mon propos car tu veux le voir sous un certains angles qui conforte ton point de vue.
Je partage juste ce que je constate. En prenant les choses juste sous un angle purement efficacité.
çà va plus vite, c'est mieux écrit même si c'était écrit par moi directement.
Un junior ou un senior, c'est comme LLM. il va interpréter les choses avec son contexte. Il va faire le travail et il y aura un écart.
D'ailleurs, c'est ce que j'ai toujours trouvé intéressant dans ce job justement ,c'est de cette écart que parfois émerge de bonnes idées.
Ma réponse était donc purement factuel en réagissant sur le côté déterministe ou non. Si tu veux quelques choses de déterministe.
Mon conseil est dans ton cas de le faire faire par un LLM.
Tu auras plus de chance d'avoir toujours le même résultat bien sûr si tu l'as beaucoup contraint.
[^] # Re: Le problème est en aval
Posté par wilk (site web personnel, Mastodon) . Évalué à 5 (+3/-0).
Je ne répondais pas sur le côté déterministe mais sur le fait que si on applique ce que tu décrit c'est à dire de soigner les spécifications et de faire coder par une personne compétente et bien le LLM n'aura plus grand intérêt.
On voit maintenant dans des projets libres des descriptifs pour Claude qui sont exactement ce qu'il fallait écrire comme doc pour les humains !
Le bon côté des LLMs sera finalement d'avoir fait comprendre l'importance de bien décrire les spécifications.
# Non
Posté par steph1978 . Évalué à 10 (+12/-3).
Non le vibecoding n'est pas la continuité de l'évolution des langages de programmation. Un LLM n'est pas un langage de programmation ou un compilateur.
Un compilateur est déterministe (la même entrée produit la même sortie) et il sort une erreur si le code en entrée est faux.
Un LLM n'est pas déterministe, il est probabiliste et il hallucine un résultat plutôt que de sortir une erreur.
Quand on programme en assembleur ou en langage de plus haut niveau, on commit l'entrée du compilateur (le code source), pas la sortie (le binaire).
Si le LLM génère le code à partir langage naturel, pourquoi on commit le code (sortie) et par le prompt (l'entrée) ?
C'est aussi et surtout un moyen d'encoder de la connaissance pour la passer d'un humain à un autre.
"Programs must be written for people to read, and only incidentally for machines to execute." Harold Abelson (MIT)
Ce n'est pas ce qui nous est présenté dans les contenus incriminés.
Linuxfr n'est pas un site de promotion de produits tech, cf le à propos.
[^] # Re: Non
Posté par Nicolas Boulay (site web personnel) . Évalué à 1 (+1/-3).
Il faut garder le prompt ! En general, tu as un fichier de descriprion de ton projet, un log pour garder les traces de action, des rapports de revue, des spec de features. Tu mets tout ça dans ton git pour plus tard.
"La première sécurité est la liberté"
[^] # Re: Non
Posté par Thomas (site web personnel) . Évalué à 5 (+4/-0).
voui.
dans toute cette histoire (specs, regles, skills, harness) on se demande pourquoi s'échiner à ne pas coder, alors que c'est plutôt sympa.
# Parle pour toi
Posté par Lutin . Évalué à 10 (+8/-0). Dernière modification le 07 octobre 2026 à 14:18.
Pour les gens qui sont passionnés par la programmation et l'algorithmie, si, c'est une fin en soi.
Une petite conférence avec plein de code qui ne sert à rien.
# Non
Posté par impromptux (site web personnel) . Évalué à 10 (+10/-1). Dernière modification le 07 octobre 2026 à 15:25.
Le problème des LLMs ne concerne pas seulement le code. Je ne pense pas que le passage de l'assembleur au C ait été à l'origine:
- d'impacts environnementaux gigantesques en eau et en consommation énergétique
- d'une augmentation des prix du matériel informatique
- d'un pillage généralisé de contenus protégés par le droit d'auteur
- de vagues de contenus produits sans supervision humaine
- d'emplois très dur psychologiquement pour des travailleurs précaires en Afrique
- d'une détérioration de la qualité du contenu disponible sur internet
- d'une pression continue sur les bénévoles de nombreux projets
etc.
Ce commentaire est sous licence CC0: faites-en ce que vous voulez tant que vous ne m'attribuez pas de fausses paroles.
[^] # Re: Non
Posté par BAud (site web personnel) . Évalué à 10 (+10/-1). Dernière modification le 07 octobre 2026 à 15:55.
en revanche, Java… ;-)
[^] # Re: Non
Posté par Tonton Th (site web personnel, Mastodon) . Évalué à 3 (+2/-1).
Nous attendons tous avec impatience la sortie de PierreTramoGPT !
[^] # Re: Non
Posté par Gil Cot ✔ (site web personnel, Mastodon) . Évalué à 3 (+1/-0).
Comme on nous dit que c’est un langage, dans la continuité de Pascal et Modula2, on attend plutôt le taptempo en langage Glaude/Gépéto/etc.
“It is seldom that liberty of any kind is lost all at once.” ― David Hume
[^] # Re: Non
Posté par Nicolas Boulay (site web personnel) . Évalué à -9 (+1/-13).
Tu n as jamais milié pour le partage ? Pour pirate bay ? Pour la licence global ?
Tu confonds avec les censeurs des RS.
Ou alors, c'est google qui est de plus en plus mauvais.
"La première sécurité est la liberté"
[^] # Re: Non
Posté par impromptux (site web personnel) . Évalué à 6 (+5/-0).
Non. Le droit d'auteur dans son objectif initial était prévu pour protéger les auteurs.
Ce n'est pas parce qu'il a été détourné qu'il est devenu néfaste.
La plupart des grandes licences libres se basent sur celui-ci. Sans le droit d'auteur, les auteurs ne pourraient pas vivre de leur plume sans le soutien de mécènes comme c'était le cas sous l'ancien régime. Sans le droit d'auteur, n'importe quelle entreprise pourrait réutiliser du code libre et tirer des bénéfices dessus sans ne rien devoir aux créateurs initiaux.
C'est ce qui est en train de se passer avec les grandes entreprises de l'IA justement et c'est scandaleux.
Non non. Il faut des gents pour trier ce qu'on donne pour l'entraînement aux LLMs et autres IA.
Ce commentaire est sous licence CC0: faites-en ce que vous voulez tant que vous ne m'attribuez pas de fausses paroles.
[^] # Re: Non
Posté par Nicolas Boulay (site web personnel) . Évalué à 2 (+0/-1).
lol.
Le droit d'auteur a été créé pour protégé les auteurs… des éditeurs, pas de leur lecteur.
C'est le cas avec le droit d'auteur puisque c'est un des effets du libre.
C'est fini ça. cf l'interview de Munsh au sénat.
"La première sécurité est la liberté"
[^] # Re: Non
Posté par bbo . Évalué à 6 (+4/-0).
C'est moche :-)
Ce qui n'est pas acceptable, c'est que ça fait des décennies que ces boites (notamment) luttent contre le partage sans conditions de la connaissance et de la culture. Et quand ça ne les arrangent pas, et bah on passe dessus.
Donc, aujourd'hui, la question est : on doit respecter ces règles de protection ou pas ?
Moi, je veux bien mais vu de ma fenêtre et sauf erreur de ma part, le téléchargement illégal n'est pas devenu légal. Donc, "eux" ils ont le droit mais pas moi ?
[^] # Re: Non
Posté par gUI (Mastodon) . Évalué à 5 (+2/-0).
Note que c'est pas les même boîtes. Disney ou Universal ne font pas dans le LLM par exemple. Par contre Google oui, et il n'a jamais eu rien à foutre du respect des droits d'auteur (à commencer par le tien bien évidemment). Ça reste donc à peu près cohérent.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Non
Posté par Nicolas Boulay (site web personnel) . Évalué à -2 (+0/-5).
Alors pour être précis, des boites se sont fait condamner pour piratage. Elle achètent donc les livres pour les scanner, et les détruisent justement pour éviter de créer un exemplaire de plus et violer le copyright.
La question est : est-ce que l'entrainement des llm est différent de lire un livre acheté ?
"La première sécurité est la liberté"
[^] # Re: Non
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
Est-ce au'on peut arrÊter de propager cette rumeur sans fondement?
Détruire une copie d'un ouvrage ne dispense pas du droit d'auteur. Le seul truc qui s'approcherait vaguement de cette idée, c'est le droit à la copie privée en france qui n'oblige en aucun cas à détruire l'original. Et le droit d'auteur s'applique à l'oeuvre indépendament de son support.
La rumeur vient d'une supposition d'un libraire allemand ayant levé l'alerte sur ces achats de livres par les entreprises d'IA. Il n'y connaît pas plus que nous en termes de droit d'auteur et en plus la citation n'a pas forcément été bien traduite à partir de la publication originale en allemand. Mais tout le monde la répète bêtement sans vérifier.
Les entreprises procèdent comme ça parce que c'est la solution la moins chère et la plus rapide pour scanner un livre. C'est tout.
Le droit d'auteur ils en ont rien à faire.
[^] # Re: Non
Posté par Nicolas Boulay (site web personnel) . Évalué à 0 (+0/-3). Dernière modification le 12 octobre 2026 à 10:25.
"Anthropic did was replace the print copies it had purchased for its central library with more convenient space-saving and searchable digital copies for its central library — without adding new copies, creating new works, or redistributing existing copies."
"On the facts here, that format change itself added no new copies, eased storage and enabled searchability, and was not done for purposes trenching upon the copyright owner‘s rightful interests — it was transformative."
"Anthropic already had purchased permanent library copies (print ones). It did not create new copies to share or sell outside."
C'est dans le jugement du proces contre open ai. https://app.midpage.ai/document/bartz-v-anthropic-pbc-1000443577770
Le fait de détruire la copie papier evite de creer une nouvelle copie qui est problematique devant le copyright. C'est explitement dit dans ce jugement.
C est bien sûr moins chère mais ce n'est pas la seule raison.
"La première sécurité est la liberté"
Envoyer un commentaire
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.