Posté par raphj (site web personnel) .
Évalué à 10 (+13/-0).
Dernière modification le 10 février 2026 à 13:04.
"Si vous vous n'y mettez pas, vous serez viré·e".
Parce qu'apparemment, le monde de l’IA a besoin de persuader en balançant cette même sauce tous les jours depuis au moins 6 mois.
Pour l'instant, mon "vélo à pignon fixe" ne crame pas trop la planète, et on sait en fait le produire sans brûler du cash et ne fait pas planer des risques économiques démesurés sur le monde. Personne n'a vampirisé et aliéné le web entier pour le produire. Et c'est même pas sûr qu'il avance moins vite que "le jetpack propulsé aux bazookas", en tout cas il avance dans la bonne direction. Et je continue à m'entrainer à pédaler bien. D'ailleurs je peux aussi faire du FOMO dans l'autre sens, saurez vous toujours pédaler quand il y en aura besoin ?
On verra quand ça deviendra indispensable, et quand ce sera clair que c'est plus efficace avec que sans, si ça le devient un jour. Peut-être qu'à ce moment là, ces articles voulant nous persuader que ça vaut le coup seront moins nombreux.
Six mois, c'est trop court pour évaluer l'impact. Que se passera-t-il sur 15 ans ?
Pour rappel, on ne peut pas entraîner un modèle d'IA avec des données issues d'un autre modèle d'IA (ou le même) : c'est la voie royale vers le surapprentissage, et ça vaut pour absolument toute technique qui vise à prédire une donnée à partir d'une autre donnée (les modèles d'IA ne sont qu'un cas particulier de modèle prédictif, et c'est d'ailleurs pour ça qu'on parle de modèle d'IA).
Donc il faut des données non issues de l'IA. Maintenant, tu prends un junior d'aujourd'hui, tu lui files un agent IA et tu le regardes pisser du code pendant 15 ans. Au bout de 15 ans, tu as toujours un junior, qui n'a pas appris grand chose, parce que l'IA faisait à sa place. Le senior est parti à la retraite. Le junior est obligé de faire confiance à l'IA. Entre en scène le surapprentissage puisque tout le code (ou une proportion suffisamment élevée) est alors produit par IA. Effondrement de la qualité de l'ajustement des modèles, carence en programmeurs capables de prendre le relais, fin de l'avancée technologique.
Comment tu contres ça ? 2 solutions :
Tu maintiens une proportion suffisante d'humains dans la boucle et tu les formes ;
Tu étiquettes le code généré par IA pour qu'il ne soit pas réinjecté dans un modèle. Variante : tu vends du code généré par humain pour entraîner des modèles
Le problème de la solution 1, c'est que l'externalité négative est partagée : la dégradation des modèles touche tout le monde, et tu as toujours intérêt, individuellement, à être le passager clandestin. Donc la solution 1 n'est pas un équilibre de Nash, il y aura toujours un intérêt à être tricheur : soit, si on est au milieu des non-tricheurs, parce qu'on économise de l'argent, soit, si les autres trichent, parce qu'autant économiser de l'argent quand même vu que le modèle va de toute façon se dégrader.
Quant à étiqueter le code fait par des humains, il va évidemment y avoir une surenchère à l'étiquetage insincère, vue la charge que font peser les crawlers d'IA sur les forges logicielles. L'option de payer pour le code généré par humain n'est citée que dans un but d'exhaustivité, elle est irréalisable : rien n'empêchera techniquement de générer du code par IA et de le revendre à une boîte d'IA, voire pire, de générer du code à la con, sans s'intéresser à ce qu'il fait ni vérifier qu'il le fait bien, juste pour la revente.
Donc bon. L'IA est une mode, qui passera pour une des raisons suivantes :
Aucune boîte n'a encore trouvé de modèle économique viable mais elles ont toutes des coûts faramineux ;
La qualité d'un modèle est une fonction logarithmique du nombre de neurones (et de la quantité de données injectée : on rappelle qu'un modèle doit toujours avoir plus de données que de paramètres), donc des coûts pour l'entraîner et le faire tourner (matériel et énergie compris), ce qui signifie des coûts exponentiels pour une qualité en croissance linéaire ;
Les modèles sont voués à se dégrader avec le temps pour la raison évoquée plus haut.
La question est donc : quand l'IA s'effondrera-t-elle, et qui emportera-t-elle dans sa chute ? Dans l'intervalle, n'organisez pas votre dépendance.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
(…) et si vous ne me croyez pas, attendez six mois.
Pas la peine pour me remetre un peu sur react + typescript j'ai utilisé l'agent de l'IDE, j'ai obtenu super rapidement un truc fonctionnel, il corrigeait via les remarques que je lui faisais; avec les tests unitaires. Bon il a pris quelques présupposé que je n'ai pas précisé, et ça allait pas avec le reste mais bon passons.
Parlons plutôt code, et non fonctionnalité, performance et maintenance, placer des pièces façon tetris simplifié sur une grille via correspondance de tag, avec tag idéal et rotation possible; comme les pièce sont simple y'a que horizontal ou vertical à tester…
Ben j'ai eu une passe avec la position idéal, une passe avec une position non idéale, puis encore 2 fois avec les rotations…
mais c'est pas tout, comme il doit ensuite placer aléatoirement sur les postions candidates, après avoir fait les 4 passe, il en refait 2 pour savoir s'il doit rotationner ou pas… (et au passage on peut perdre la position idéale…)
La solution simple consistait à faire une passe droit, une passe rotationé, avec un scoring et garder les meilleurs score pour la position aléatoire avec mémorisation de la rotation si nécessaire, mais l'IA, à décidé de faire 6 passe, au lieu de 2…
Toujours sur le même projet il me fait des composant graphique beaucoup trop gros, lors de demande de refactoring pour séparer, il a tendance à créer des truc que dans le temps on appelait plats de spaghetti innommable…
Si je l'avais laisser continuer sans regarder sous le capot, le code serait devenu extrêmement difficile a faire évoluer par un humain, et il serait devenu impossible à un llm de de faire évoluer en utilisant des ressource raisonnables.
Bref tu vas pas faire une grosse application avec juste un llm; c'est un superbe outil pour facilité l'écriture de code, mais si tu ne suis pas de près ce qu'il fait tu va accumuler de la 'dette technique' à une vitesse hallucinante.
Je ne dis pas qu'il sert à rien, il est très efficace pour faire des modifications, te proposer des choix architecturaux, ou corriger ton code.
Pour info je lui ai demandé plusieurs fois de faire une revue du code, les base étaient solide, évolutive… bref que des qualités, et il ne s'est pas du tout inquiété des boilerplate accumulées.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
Bref tu vas pas faire une grosse application avec juste un llm; c'est un superbe outil pour facilité l'écriture de code, mais si tu ne suis pas de près ce qu'il fait tu va accumuler de la 'dette technique' à une vitesse hallucinante.
Ce qui me gène c'est qu'aujourd'hui les boites s'en foutent. Elles veulent juste du code qui marche pour hier.
il ne s'est pas du tout inquiété des boilerplate accumulées.
Ben non, et les dirigerants s'en foutent. Ils espèrent que l'IA saura corriger ce code plus tard ….
ça parle toujours d'écrire plus de code, plus vite.
Comme le dit Cory Doctorrow, c'est comme se vanter d'avoir créé "l'avion le plus lourd du monde". C'est prendre le problème à l'envers.
Mon travail ce n'est pas d'écrire du code. Le code est un outil. C'est lui qui me permet de formaliser ce qu'un ordinateur doit faire, de façon précise et non ambiguë. Le travail d'écriture du code me force à réfléchir aux choses dans les moindres détails, et à mettre en évidence les choses qui sont incohérentes ou pas claire dans ce qu'on m'a demandé de faire.
C'est cette étape que l'utilisation des LLM pour générer du code essaie de supprimer. Donnons directement les spécifications en langage naturel, ambiguës, incomplètes, contradictoires, à l'ordinateur. Il saura bien se débrouiller avec. Et en plus, il ne dit jamais "non, c'est n'importe quoi, ça marchera pas" comme un développeur ronchon.
La question qu'il faut se poser, c'est plutôt si votre travail était d'écrire du code pour des problèmes qui étaient déjà résolus. Peut être que votre application est juste un clone de celle de votre concurrent. Peut-être que vous êtes juste développeur et que l'architecte du projet vous a déjà tout parfaitement spécifié et qu'il n'y a plus aucune question lors de l'écriture du code. Auquel cas, effectivement, peut-être que c'est entièrement automatisable. Mais votre métier devait déjà être terriblement ennuyeux avant l'arrivée des LLM, non?
C'est comme vouloir être milliardaire pour être milliardaire. Ça n'a pas de sens. Ce qui importe ce n'est pas la quantité d'argent que l'on peut posséder, c'est ce qu'on peut faire avec.
C'est, en effet, la même logique. On confond l'outil (ici le code, là l'argent) avec le but recherché (ici obtenir que l’ordinateur accomplisse une tâche définie, là pouvoir payer pour des actions et des objectifs précis).
Ce sont les limites de la comparaison, quoique. En effet, on aimerait bien que les gens qui codent des applications pourries de surveillance par exemple, fassent autre chose, je sais pas moi, développer des applications à caractère médical pour la compensation de handicaps.
C'est intéressant, ce que tu dis sur le fait d'écrire le plus possible de code.
Ce week-end, j'ai écrit un script pour configurer un bouton de souris dans Hyprland. Comme ça devait réagir à un clic de souris, j'avais une contrainte de performance : le code devait être exécuté en moins de 16 ms (une frame sur un écran à 60 FPS).
Donc mon but n'était pas d'écrire le plus de code possible : c'était d'écrire le moins de code possible, pour économiser un maximum de temps, et d'optimiser le code en fonction des caractéristiques connues des données passées en entrée.
Autre anecdote : un jour, je me retrouve dans un jury d'oral de M1. Un des étudiants nous présente un mémoire de stage dépourvu de tout intérêt, où je m'emmerde très vite. Aucun résultat intéressant, et d'ailleurs aucun résultat tout court. Une de ses diapos nous présente un immense tableau de données brutes, plusieurs dizaines de colonnes, plusieurs centaines de lignes (mais pas le début du commencement d'une analyse pertinente). Arrive le moment des questions du jury :
- Peux-tu nous remettre la diapo du tableur Excel, s'il-te-plaît ? (l'étudiant s'exécute)
- Bien, maintenant, viens à ma hauteur. (l'étudiant descend de l'estrade, traverse la salle, se positionne à côté de moi)
- Qu'est-ce que tu arrives à lire ?
- Ah ouais, je vois le problème…
- Que suis-je censé comprendre de ce tableau illisible ?
- Ben… Que j'ai beaucoup travaillé, j'ai récolté énormément de données !
- Tu as beaucoup travaillé, mais tu n'as rien produit. Ça s'appelle du gâchis.
(pour la petite histoire, comme il n'était même pas le pire étudiant du master, je lui ai quand même mis la moyenne. Et j'ai conseillé à mes propres étudiants de fuir ce master)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
# Encore du FOMO
Posté par raphj (site web personnel) . Évalué à 10 (+13/-0). Dernière modification le 10 février 2026 à 13:04.
"Si vous vous n'y mettez pas, vous serez viré·e".
Parce qu'apparemment, le monde de l’IA a besoin de persuader en balançant cette même sauce tous les jours depuis au moins 6 mois.
Pour l'instant, mon "vélo à pignon fixe" ne crame pas trop la planète, et on sait en fait le produire sans brûler du cash et ne fait pas planer des risques économiques démesurés sur le monde. Personne n'a vampirisé et aliéné le web entier pour le produire. Et c'est même pas sûr qu'il avance moins vite que "le jetpack propulsé aux bazookas", en tout cas il avance dans la bonne direction. Et je continue à m'entrainer à pédaler bien. D'ailleurs je peux aussi faire du FOMO dans l'autre sens, saurez vous toujours pédaler quand il y en aura besoin ?
On verra quand ça deviendra indispensable, et quand ce sera clair que c'est plus efficace avec que sans, si ça le devient un jour. Peut-être qu'à ce moment là, ces articles voulant nous persuader que ça vaut le coup seront moins nombreux.
[^] # Re: Encore du FOMO
Posté par dovik (site web personnel) . Évalué à 8 (+6/-0).
Je cite l'article :
[^] # Re: Encore du FOMO
Posté par Liorel . Évalué à 10 (+19/-0).
Six mois, c'est trop court pour évaluer l'impact. Que se passera-t-il sur 15 ans ?
Pour rappel, on ne peut pas entraîner un modèle d'IA avec des données issues d'un autre modèle d'IA (ou le même) : c'est la voie royale vers le surapprentissage, et ça vaut pour absolument toute technique qui vise à prédire une donnée à partir d'une autre donnée (les modèles d'IA ne sont qu'un cas particulier de modèle prédictif, et c'est d'ailleurs pour ça qu'on parle de modèle d'IA).
Donc il faut des données non issues de l'IA. Maintenant, tu prends un junior d'aujourd'hui, tu lui files un agent IA et tu le regardes pisser du code pendant 15 ans. Au bout de 15 ans, tu as toujours un junior, qui n'a pas appris grand chose, parce que l'IA faisait à sa place. Le senior est parti à la retraite. Le junior est obligé de faire confiance à l'IA. Entre en scène le surapprentissage puisque tout le code (ou une proportion suffisamment élevée) est alors produit par IA. Effondrement de la qualité de l'ajustement des modèles, carence en programmeurs capables de prendre le relais, fin de l'avancée technologique.
Comment tu contres ça ? 2 solutions :
Le problème de la solution 1, c'est que l'externalité négative est partagée : la dégradation des modèles touche tout le monde, et tu as toujours intérêt, individuellement, à être le passager clandestin. Donc la solution 1 n'est pas un équilibre de Nash, il y aura toujours un intérêt à être tricheur : soit, si on est au milieu des non-tricheurs, parce qu'on économise de l'argent, soit, si les autres trichent, parce qu'autant économiser de l'argent quand même vu que le modèle va de toute façon se dégrader.
Quant à étiqueter le code fait par des humains, il va évidemment y avoir une surenchère à l'étiquetage insincère, vue la charge que font peser les crawlers d'IA sur les forges logicielles. L'option de payer pour le code généré par humain n'est citée que dans un but d'exhaustivité, elle est irréalisable : rien n'empêchera techniquement de générer du code par IA et de le revendre à une boîte d'IA, voire pire, de générer du code à la con, sans s'intéresser à ce qu'il fait ni vérifier qu'il le fait bien, juste pour la revente.
Donc bon. L'IA est une mode, qui passera pour une des raisons suivantes :
La question est donc : quand l'IA s'effondrera-t-elle, et qui emportera-t-elle dans sa chute ? Dans l'intervalle, n'organisez pas votre dépendance.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Encore du FOMO
Posté par Thomas (site web personnel) . Évalué à 2 (+1/-0).
Je plussoie moultement.
[^] # Re: Encore du FOMO
Posté par fearan . Évalué à 7 (+4/-0).
Pas la peine pour me remetre un peu sur react + typescript j'ai utilisé l'agent de l'IDE, j'ai obtenu super rapidement un truc fonctionnel, il corrigeait via les remarques que je lui faisais; avec les tests unitaires. Bon il a pris quelques présupposé que je n'ai pas précisé, et ça allait pas avec le reste mais bon passons.
Parlons plutôt code, et non fonctionnalité, performance et maintenance, placer des pièces façon tetris simplifié sur une grille via correspondance de tag, avec tag idéal et rotation possible; comme les pièce sont simple y'a que horizontal ou vertical à tester…
Ben j'ai eu une passe avec la position idéal, une passe avec une position non idéale, puis encore 2 fois avec les rotations…
mais c'est pas tout, comme il doit ensuite placer aléatoirement sur les postions candidates, après avoir fait les 4 passe, il en refait 2 pour savoir s'il doit rotationner ou pas… (et au passage on peut perdre la position idéale…)
La solution simple consistait à faire une passe droit, une passe rotationé, avec un scoring et garder les meilleurs score pour la position aléatoire avec mémorisation de la rotation si nécessaire, mais l'IA, à décidé de faire 6 passe, au lieu de 2…
Toujours sur le même projet il me fait des composant graphique beaucoup trop gros, lors de demande de refactoring pour séparer, il a tendance à créer des truc que dans le temps on appelait plats de spaghetti innommable…
Si je l'avais laisser continuer sans regarder sous le capot, le code serait devenu extrêmement difficile a faire évoluer par un humain, et il serait devenu impossible à un llm de de faire évoluer en utilisant des ressource raisonnables.
Bref tu vas pas faire une grosse application avec juste un llm; c'est un superbe outil pour facilité l'écriture de code, mais si tu ne suis pas de près ce qu'il fait tu va accumuler de la 'dette technique' à une vitesse hallucinante.
Je ne dis pas qu'il sert à rien, il est très efficace pour faire des modifications, te proposer des choix architecturaux, ou corriger ton code.
Pour info je lui ai demandé plusieurs fois de faire une revue du code, les base étaient solide, évolutive… bref que des qualités, et il ne s'est pas du tout inquiété des boilerplate accumulées.
Il ne faut pas décorner les boeufs avant d'avoir semé le vent
[^] # Re: Encore du FOMO
Posté par totof2000 . Évalué à 3 (+1/-0).
Ce qui me gène c'est qu'aujourd'hui les boites s'en foutent. Elles veulent juste du code qui marche pour hier.
Ben non, et les dirigerants s'en foutent. Ils espèrent que l'IA saura corriger ce code plus tard ….
[^] # Re: Encore du FOMO
Posté par totof2000 . Évalué à 7 (+5/-0).
Un autre article me disait la même chose il y a 6 mois.
[^] # Re: Encore du FOMO
Posté par pulkomandy (site web personnel, Mastodon) . Évalué à 10 (+14/-0).
ça parle toujours d'écrire plus de code, plus vite.
Comme le dit Cory Doctorrow, c'est comme se vanter d'avoir créé "l'avion le plus lourd du monde". C'est prendre le problème à l'envers.
Mon travail ce n'est pas d'écrire du code. Le code est un outil. C'est lui qui me permet de formaliser ce qu'un ordinateur doit faire, de façon précise et non ambiguë. Le travail d'écriture du code me force à réfléchir aux choses dans les moindres détails, et à mettre en évidence les choses qui sont incohérentes ou pas claire dans ce qu'on m'a demandé de faire.
C'est cette étape que l'utilisation des LLM pour générer du code essaie de supprimer. Donnons directement les spécifications en langage naturel, ambiguës, incomplètes, contradictoires, à l'ordinateur. Il saura bien se débrouiller avec. Et en plus, il ne dit jamais "non, c'est n'importe quoi, ça marchera pas" comme un développeur ronchon.
La question qu'il faut se poser, c'est plutôt si votre travail était d'écrire du code pour des problèmes qui étaient déjà résolus. Peut être que votre application est juste un clone de celle de votre concurrent. Peut-être que vous êtes juste développeur et que l'architecte du projet vous a déjà tout parfaitement spécifié et qu'il n'y a plus aucune question lors de l'écriture du code. Auquel cas, effectivement, peut-être que c'est entièrement automatisable. Mais votre métier devait déjà être terriblement ennuyeux avant l'arrivée des LLM, non?
[^] # Re: Encore du FOMO
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 8 (+5/-0).
C'est comme vouloir être milliardaire pour être milliardaire. Ça n'a pas de sens. Ce qui importe ce n'est pas la quantité d'argent que l'on peut posséder, c'est ce qu'on peut faire avec.
C'est, en effet, la même logique. On confond l'outil (ici le code, là l'argent) avec le but recherché (ici obtenir que l’ordinateur accomplisse une tâche définie, là pouvoir payer pour des actions et des objectifs précis).
Je n’ai aucun avis sur systemd
[^] # Re: Encore du FOMO
Posté par Liorel . Évalué à 6 (+5/-1).
Quitte à choisir, je préfèrerais que Vincent Bolloré, Peter Thiel ou Mark Andreessen se contentent de posséder et pas de faire des choses avec leur argent.
Ça, ce sont les sources. Le mouton que tu veux est dedans.
[^] # Re: Encore du FOMO
Posté par Ysabeau 🧶 (site web personnel, Mastodon) . Évalué à 5 (+2/-0).
Ce sont les limites de la comparaison, quoique. En effet, on aimerait bien que les gens qui codent des applications pourries de surveillance par exemple, fassent autre chose, je sais pas moi, développer des applications à caractère médical pour la compensation de handicaps.
Je n’ai aucun avis sur systemd
[^] # Re: Encore du FOMO
Posté par lolop (site web personnel) . Évalué à 5 (+3/-0).
S'il pouvaient se contenter de posséder moins (et de redistribuer plus vers les salariés de leurs entreprises par exemple).
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: Encore du FOMO
Posté par Liorel . Évalué à 10 (+11/-1).
C'est intéressant, ce que tu dis sur le fait d'écrire le plus possible de code.
Ce week-end, j'ai écrit un script pour configurer un bouton de souris dans Hyprland. Comme ça devait réagir à un clic de souris, j'avais une contrainte de performance : le code devait être exécuté en moins de 16 ms (une frame sur un écran à 60 FPS).
Donc mon but n'était pas d'écrire le plus de code possible : c'était d'écrire le moins de code possible, pour économiser un maximum de temps, et d'optimiser le code en fonction des caractéristiques connues des données passées en entrée.
Autre anecdote : un jour, je me retrouve dans un jury d'oral de M1. Un des étudiants nous présente un mémoire de stage dépourvu de tout intérêt, où je m'emmerde très vite. Aucun résultat intéressant, et d'ailleurs aucun résultat tout court. Une de ses diapos nous présente un immense tableau de données brutes, plusieurs dizaines de colonnes, plusieurs centaines de lignes (mais pas le début du commencement d'une analyse pertinente). Arrive le moment des questions du jury :
- Peux-tu nous remettre la diapo du tableur Excel, s'il-te-plaît ? (l'étudiant s'exécute)
- Bien, maintenant, viens à ma hauteur. (l'étudiant descend de l'estrade, traverse la salle, se positionne à côté de moi)
- Qu'est-ce que tu arrives à lire ?
- Ah ouais, je vois le problème…
- Que suis-je censé comprendre de ce tableau illisible ?
- Ben… Que j'ai beaucoup travaillé, j'ai récolté énormément de données !
- Tu as beaucoup travaillé, mais tu n'as rien produit. Ça s'appelle du gâchis.
(pour la petite histoire, comme il n'était même pas le pire étudiant du master, je lui ai quand même mis la moyenne. Et j'ai conseillé à mes propres étudiants de fuir ce master)
Ça, ce sont les sources. Le mouton que tu veux est dedans.
# En VO et commentaires
Posté par fero14041 . Évalué à 7 (+6/-0).
"We mourn our craft", abondamment discuté sur HackerNews.
J'aurais p'têt traduit ça moins littéralement, par exemple:
"Nous faisons le deuil de notre savoir-faire", non?
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.