Journal De développeur à orchestrateur, comment l'IA a changé ma vie

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
30
23
mar.
2026

Sommaire

Mon employeur est visionnaire

Et croyez bien que ça me fait mal à l'arrière train de l'admettre, parce qu'il y a quelques zélotes à l'égo sur-dimensionné que j'aurais bien voulu voir rabattre leur caquet. Mais bon, ce n'est pas de l'arrogance si ils ont raison?

Bref, ils ont mis le paquet. Ils ont compris que, comme lors de la révolution informatique et de la révolution internet, où il ne s'agissait pas juste de coller un ordinateur ou un navigateur devant les yeux de la secrétaire ou du patron mais de créer l'écosystème qui permette d'utiliser ces nouveaux outils au maximum de leur potentiel, il fallait un vrai département IA dédié (deux, en fait), et intégrer les nouveaux outils finement dans toutes les activités de la boite.

Ainsi, l'accès à ChatGPT ne fut que la toute première étape : on a ensuite eu un ChatGPT "sûr" (en fait, un simple NDA où il était permis d'envoyer des informations confidentielles au LLM. Ensuite, tout un tas d'outils que je trouve personnellement discutables, pour résumer des e-mails, ou même automatiquement générer et envoyer à son manager son petit résumé de la semaine, à partir des e-mails, des commits, et des tickets (ce que je trouve être une hérésie, mais on peut lancer le débat).

L'autre aspect à noter et que la philosophie Devops et Infra-as-code est très développée chez nous, ce qui veut dire que la plupart des changements courants (déploiement de services, espace disque, logiciels installés sur la machine…) se contrôlent à travers des dépôts Git. Tout est mûr pour que la machine prenne le pouvoir.

La première révélation

Finalement, ce sont 2 nouveaux produits qui ont tout changé: d'une part ce bon vieux Claude CLI en ligne de commande, et d'autre part, un accès à Claude via une GUI Web. Mais pas les versions brut de décoffrage, non - On parle de versions adaptées, intégrées avec les dépôt de code, les logs de prod, les APIs ActiveDirectory, et tout le toutim, le tout correctement référencé par des MCP et des Skills, et avec les bons niveaux d'isolation pour éviter les accidents.

C'était il y a quelques mois - Un collègue me fait remarquer que nous n'avons plus Notepad++ depuis la migration d'OS. Ayant vu une démonstration du Claude Web juste avant, je me suis lancé, sans trop y croire. "Salut lapin, ajoute Notepad++ sur le Puppet de l'équipe". Après avoir mouliné 2 minutes, il me sort la pull request. Je ne lui ai pas dit quelle était mon équipe. Je ne lui ai pas donné le nom du paquet. Je ne lui ai pas dit où était le dépôt Puppet. Là où j'aurais galéré à trouver l'info et certainement fait plusieurs typos, il s'est débrouillé dans son coin. À partir de ce moment, je n'ai plus touché un Gitops manuellement. Je lui dit ce que je veux, il se débrouille, et il écrit du bien meilleur Yaml que moi.

La deuxième révélation

Quelques semaines plus tard, toute l'équipe doit se rendre à l'évidence : Claude écrit du meilleur C++ que nous. Alors oui, il ne part pas de zéro : on a déjà une belle base de code bien propre, cohérente et bien testée. Mais Claude se montre infatigable : il écrit des services entiers, il refactore ou implémente des petites fonctionnalités mineures qui étaient au fond de la pile - Mais il est tellement rapide et autonome que c'est un faible coût pour moi de le lancer sur le sujet et de voir ce qu'il fait. Si c'est du n'importe quoi, je n'ai perdu que 5 minutes.

Notre approche est la suivante : tout d'abord, on utilise le Claude Web, on lui demande de ne pas écrire de code, mais juste une spec. Il part alors dans la base de code principale, les Gitops, les tickets, la documentation, et écrit une spec. Je la revois en détail, j'itère, jusqu´a ce que je sois content. Ensuite, je donne la spec à manger à Claude CLI, qui implémente. Quand il a fini, je fais une revue de code, je lui dit quoi changer, si c'est quelque chose d'un peu fondamental je lui demande d'éditer les documents de style ou de bonnes pratiques qu'il utilise comme base.

Notre approche du développement a complètement changé: puisqu'on a des Claude autonomes, plutôt que de travailler sur une fonctionnalité à la fois, je lance 2, 3 ou 4 choses en même temps - J'ai mis en place quelques macros Emacs pour avoir mon éditeur favori qui intègre une session entière avec la ligne de commande, Git, et l'éditeur de texte, j'ai un bureau virtuel par tâche sur laquelle je travaille, et je passe de l'une à l'autre, je vérifie, je relance, je relis une spec, je vérifie des tests unitaires - Comme une sorte de tech lead fou qui aurait un nombre illimité de développeurs brillants mais un peu bornés à son service.

La troisième révélation

La conséquence de ce changement, c'est que le code va vite, mais pas le reste : il me faut encore revoir les changements que mes collègues ont vibe codé, et eux les miens. Il faut tester, il faut déployer, et nos mise en prod hebdomadaires prennent de l'embonpoint et deviennent plus risquées.

L'IA, c'est comme la violence, si ça ne résout pas ton problème, c'est que tu n'en a pas mis assez. J'ai donc demandé à Claude de créer un document de test, avec des trous à remplir et les requêtes et systèmes à utiliser. Ensuite, chaque semaine, je lui donne le document à mouliner, ça tourne pendant 10 minutes, et il me sort tous les tests de régression, corrélés aux tickets qui sortent, aux logs, et ainsi de suite, le tout justifié et simple à vérifier. Ça ne fait pas tout, mais c'est un fort gain de temps.

La part sombre

Bien sûr, ce n'est pas gratuit - Et le management a l'intention de faire un retour sur investissement conséquent. L'on parle de 5X, 10X, 50X même, et nos chefs ont été explicites sur les améliorations de productivité qu'ils comptent tirer de l'IA. Pour l'instant, il s'agit de faire beaucoup plus avec les même ressources. Mais je me doute bien que le jour où il faudra faire moins, beaucoup perdront leur emploi.

De mon côté, mes douleurs aux bras, aux poignets et aux mains, disparues depuis longtemps grâce au Typematrix, reviennent. Avant, je pouvais taper du code pendant des heures, presque sans toucher la souris, et je devais fréquemment ralentir pour réfléchir à mon algo ou aller lire une doc. Maintenant, l'on passe d'une tâche à une autre tout le temps, on écrit un peu de texte à toute berzingue sans trop se préoccuper des fautes ou des typos, et on utilise la souris tout le temps. J'ai tenté de mettre en place autant de raccourcis clavier que possible, et j'ai investi dans une souris verticale - On verra si ça aide.

Conclusion

Que l'on déplore ou que l'on se réjouisse de ces changements, ils sont là pour durer. Le chat est sorti du sac, comme disent nos amis d'outre-Manche, c'est la nouvelle manière de travailler, il faudra s'y faire. Steve Yegge, un développeur et blogueur influent, en a parlé dans un article récent : vibe coder, c'est épuisant (après, peut-être qu'il se fait vieux). De mon côté, je me suis pris au jeu - Je me sens insatisfait quand je n'ai pas un ou deux Claude qui moulinent en arrière plan. Mais je continue à coder un peu à la main à la maison, j'installe des LLM en local chez moi pour bidouiller et évaluer les technologies. Quelque part, c'est passionnant. Mais c'est aussi terrifiant.

  • # Pendant ce temps

    Posté par  (site web personnel) . Évalué à 10 (+35/-0).

    La pression est forte au boulot pour que nous utilisions Claude. Bien sûr un tel outil doit être évalué rigoureusement avant d'être déployé, après tout on lui donnera quasiment les clés du dev. C'est pour cela que nous avons organisé diverses expérimentations afin que les collègues pré-acquis à la cause puissent expliquer comment l'utiliser. J'insiste, il ne s'agit pas de voir si c'est une bonne idée ni même de chercher les limites de l'outil, mais directement de trouver des Bonnes Pratiques™.

    Intrigués par les retours, tout à fait identiques à ce qu'on lit partout (c'est mieux que ce que j'aurais fait ! Ça m'a fait gagner, heu… allez je vais dire 60% tiens, 60% du temps de dev !), j'ai aussi expérimenté dans ce que j'espère être une évaluation rigoureuse. Car si on me proposait un prestataire pas cher avec la promesse qu'il sache tout faire, aucun doute que ça activerait l'alarme charlatanisme.

    J'ai donc pris notre dépôt de code et j'ai demandé à Claude d'écrire l'implémentation optimisée en AVX2 d'une fonction du logiciel. Pour le contexte on a dans le dépôt plein de fonctions du genre foo_avx2 pour la perf et leurs équivalentes en C++ foo_c pour référence. On a un micro-benchmark qui évalue les deux, et on a une suite de tests qui vérifie que les deux sortent les mêmes résultats pour les mêmes entrées. Ma démarche d'expérimentation est la suivante : je supprime le corps de foo_avx2 et je demande à Claude de l'implémenter avec comme consigne de la rendre aussi performante que possible en termes de temps d'exécution. Je lui mets à disposition le benchmark et la suite de test, comme ça il peut s'évaluer lui-même.

    Et effectivement il s'est débrouillé pour sortir une fonction valide ! Elle n'est que 50% à 300% plus lente que notre implémentation. Après de nombreuses itérations, des heures à être sur son dos en le guidant pour améliorer tel ou tel cas, il a pu produire quelque chose d'équivalent en perf.

    Alors évidemment on m'a dit que je n'y croyais pas assez fort et que j'aurais du utiliser Opus 4.6 en max reasoning. J'ai donc refais l'expérience sur une autre fonction en mettant tous les curseurs à 11. Effectivement il a réfléchit très fort et a produit encore plus vite une implémentation 50% plus lente que la nôtre. J'ai à nouveau itéré jusqu'à aligner les perfs avec notre implémentation sans jamais réussir à l'égaler.

    Dans les deux cas j'ai ensuite fait une revue du code. Le première fonction est implémentée de manière acceptable sans plus, la seconde est dégueux. Du code dégueux et plus lent, c'est ce qu'a produit Claude.

    Et là je me sens seul. Je vois mes confrères grisés par l'expérience, jurant que je devrais essayer c'est trop bon, aveuglés par l'amour tels des ados épris dans une relation interdite, mais chacun de mes essais est un flop. Aucune montée d'adrénaline, les niveaux d'endorphine au plus bas, je me retrouve face à un énorme étron dans le code tandis que derrière moi toute l'industrie, euphorique, s'égosille : « Mange ! Mange ! ».

    On nous rabâche le fait que l'on doit own la sortie de Claude mais pour moi ça ne fait aucun doute que personne ne saura ce qu'il se passe dans nos logiciels. Jamais une revue de code ne nous donnera une connaissance autre que superficielle et je suis convaincu que ce qui a été écrit par Claude sera maintenu par Claude. Qu'il sera responsable des corrections de bugs et sans doute aussi des revues.

    Les uns et les autres clament que Claude produit du code meilleur que ce qu'ils auraient produit et moi je me demande, si le résultat est effectivement mieux que ce qu'ils auraient fait, c'est donc au delà de leurs capacités. Dès lors, sont-ils aptes à juger du résultat ? Par exemple, je ne sais pas jongler. N'importe qui pouvant attraper deux fois deux balles fait déjà mieux que ce que j'aurais fait. À quoi ça rime si je l'impose à tous les cirques du monde parce qu'il fait mieux que ce que j'aurais fait ? Faut-il laisser les décisions aux plus incompétents ?

    Cette semaine je ferai un autre essai plus orienté fonctionnel en demandant à Claude d'implémenter un algo que j'ai moi-même précédemment implémenté. La démarche sera la même, il partira du commit précédant mes modifs, et je lui décrirai le besoin. Il n'aura plus qu'à l'implémenter. Moi il m'a fallu 4 heures de travail effectif (7 à l'horloge murale) pour aller de zéro à la la validation complète de la suite de test. J'aimerais bien le voir faire mieux, genre plus rapide pour la même qualité de code. Ça m'aiderait à comprendre mes confrères.

    • [^] # Re: Pendant ce temps

      Posté par  . Évalué à 7 (+5/-0).

      Je serai intéressé pour que publies la suite de tes expérimentations.

    • [^] # Re: Pendant ce temps

      Posté par  . Évalué à 10 (+7/-0).

      De mes expérimentations, j'ai le même constat, générateur de code ne vois pas de problème a refaire 2, 3, 4, 5, 6 fois la même chose, ni ne fait de recherche préliminaire pour savoir si ce qu'il fait à déjà été mis dans ta base de code.

      On arrive (très) rapidement à quelque chose de fonctionnel, et à première vue, (mes premières relectures), on ne voit pas le problème, le code est propre, clair lisible, jusqu'au moment ou faut faire évoluer, ou que le truc a raté un cas à la marge (pourtant y'a tous les tests)

      Et là c'est le drame on ne lit plus sa sortie, on la comprends, on voit qu'il fait plusieurs passes sur un tableau alors qu'une seule suffit, on voit qu'il a ajouté des présupposé de nulle part…

      Alors quand on s'en rends compte tôt c'est pas grave, le plus gênant c'est si on laisse ces duplication perdurer, qu'on en corrige certaines et pas les autres, et à la fin le refactoring deviens un tel sac de nœuds que le llm lâchera l'affaire; ou plutôt va consommer les tokens jusqu'à plus soif, sans arriver à une solution.

      Alors oui le problème de performance, plusieurs fois la même tâche avec juste un booléen qui change, j'ai déjà eu des collègues qui le font, la duplication de code / fonctionnalité, aussi, mais là je parle d'une seule évolution réclamée.

      Cette semaine je ferai un autre essai plus orienté fonctionnel en demandant à Claude d'implémenter un algo que j'ai moi-même précédemment implémenté. La démarche sera la même, il partira du commit précédant mes modifs, et je lui décrirai le besoin. Il n'aura plus qu'à l'implémenter. Moi il m'a fallu 4 heures de travail effectif (7 à l'horloge murale) pour aller de zéro à la la validation complète de la suite de test. J'aimerais bien le voir faire mieux, genre plus rapide pour la même qualité de code. Ça m'aiderait à comprendre mes confrères.

      ça c'est plus dans ses cordes ;) Tu peux aussi t'en servir pour relire ton code et faire des propositions, lui faire faire de petites évolution que tu relieras intégralement, ou simplement t'en servir comme google y'a 10-15 ans :)

      Il ne faut pas décorner les boeufs avant d'avoir semé le vent

    • [^] # Re: Pendant ce temps

      Posté par  . Évalué à 10 (+18/-0).

      Je crois que l'IA est plutôt douée pour les tâches de niveau moyen. Ecrire un yaml? Ok. Pondre une fonction C qui va trier un tableau, ça va. Ecrire la doc d'un commit, oué, ça sait faire. Quand tu lui demandes d'améliorer un code que tu as optimisé avec amour pendant des heures, bah l'IA te sors un truc dégueulasse. Un truc un peu niche -> echec assuré. L'IA c'est du niveau moyen plus.

      Je vais avoir une position extrêmement agressive : j'ai l'impression que les personnes qui sont le plus fascinées par l'IA sont des mauvais devs. Ils sont incapables de faire un truc propre, l'IA sort un machin vaguement moyen, ils disent que c'est génial, qu'ils n'auraient jamais pu faire mieux, plus vite, plus propre. Moi, ça m'inquiète.

      D'un autre côté, je trouve aussi que c'est une bonne jauge : Par exemple, je trouve que l'IA écrit des très très bons scripts shells, très propre, et rapidement. Ca m'a permis de comprendre que je suis une buse complète en bash :D Il y a encore quelques domaines ou je trouve que l'IA est vraiment mauvaise, ça me rassure

      • [^] # Un pas de côté

        Posté par  . Évalué à 9 (+7/-0).

        j'ai l'impression que les personnes qui sont le plus fascinées par l'IA sont des mauvais devs

        Dans un tout autre domaine, j'ai la même impression.

        J'ai tenté de faire faire à chatGPT (pas testé avec les autres IAgen) des documents pédagogiques pour des élèves, de lui demander des des analyses didactiques, des propositions de progressions, etc.

        Bin c'est nul.

        Ça ressemble à quelque chose, ce n'est pas foncièrement faux (avec de gros pains de temps en temps quand même) et c'est plutôt bien écrit. Mais c'est plat, sans originalité, ça ne tiens pas du tout compte des résultats de recherches en sciences de l'éduc', alors même qu'il les connait puisqu'il est capable de les citer ou de les expliquer avec des prompts ciblés.

        J'ai pu participer cette année à la formation des M2 MEEF (futurs profs l'an prochain, ayant peu ou pas enseigné « en responsabilité ») : quand ils ont une ressource ou une séance à produire et qu'il le font avec sérieux (sans chatGPT ;-) ) ils font tout de suite mieux

        Alors oui je suis bluffé par le code informatique produit, mais je fais clairement parti des mauvais programmeurs !

      • [^] # Re: Pendant ce temps

        Posté par  . Évalué à 3 (+1/-0).

        L'optimisation ça concerne des langages bas-niveau (je pense que C++ est le meilleur exemple). Quand tu es dev JS/python, même compétent, je pense que tu as moins de levier pour l'optimisation. L'intérêt de ses langages c'est essentiellement la clarté / simplicité du code pour effectuer une tâche donnée

        • [^] # Re: Pendant ce temps

          Posté par  . Évalué à 9 (+7/-1).

          Quand tu es dev JS/python, même compétent, je pense que tu as moins de levier pour l'optimisation.

          L'optimisation c'est pas que économiser un cycle sur une boucle for, ça c'est le truc de fin quand t'es limite où que ton but c'est la performance.

          L'optimisation c'est aussi ne pas
          * refetcher des ressources que t'as déjà en local,
          * c'est pas reparser 15 fois ton json,
          * c'est ne pas effectuer une deep copy à coup de JSON.parse(JSON.stringify(obj))
          * c'est ne pas faire history4 = clone(history3); history3=clone(history2); history2=clone(history1); history1=clone(state)

          Et je précise que les history étaient des json clonés par la méthode précédente (et c'était pas mon code, ni une génération à moi)

          En javascript y'a structuredClone pour faire des deep copy.

          en optimisé (ou simplement pas de conneries)
          history4=history3; histroy3=history2; history2=history1; history1=structuredClone(state);

          Je parle même pas du fait qu'avant cette version moche le state était un json sringifié, que le truc en question allait chercher des éléments dans le state, et comme il le faisait plusieurs fois pour un même passage il le parsait plusieurs fois…

          Bref pour résumer, il y'a plusieurs optimisation, et la première, la plus importante, celle qui fait que ton truc à des performance correcte, c'est au plus haut niveau que ça se fait, c'est éviter de faire des calculs inutiles (t'auras beau les optimiser a fond au niveau assembleur, ce sera toujours des calculs qui prennent du temps pour rien); c'est le choix de tes algorithmes et façon de traiter les données, je choix du type de donnée (map, set, tableau…); typiquement si t'as des tableau que t'accède toujours aux éléments à coup de tab.filter( t => t.id === val) la map ou l'objet js peut être plus pertinent.

          L'intérêt de sces langages c'est essentiellement la clarté / simplicité du code pour effectuer une tâche donnée

          Je te montrerais bien des codes js pour effectuer une tâche donnée, la simplicité est absente, et la clarté est aux oubliettes.

          Il ne faut pas décorner les boeufs avant d'avoir semé le vent

          • [^] # Re: Pendant ce temps

            Posté par  (site web personnel) . Évalué à 7 (+5/-0).

            en optimisé (ou simplement pas de conneries)
            history4=history3; histroy3=history2; history2=history1; history1=structuredClone(state);

            et la déclaration des variables à la volée te permet de bénéficier de histroy3 silencieusement. Et une définition de history4 potentiellement foireuse.

      • [^] # Re: Pendant ce temps

        Posté par  . Évalué à 3 (+3/-2). Dernière modification le 23 mars 2026 à 14:08.

        Je vais avoir une position extrêmement agressive : j'ai l'impression que les personnes qui sont le plus fascinées par l'IA sont des mauvais devs

        Non.

        Donald Knuth. Eric Raymond. antirez.

        Pas vraiment des mauvais devs.

        • [^] # Re: Pendant ce temps

          Posté par  . Évalué à 10 (+9/-1).

          Pas des mauvais dev mais des geeks qui aiment bien s'émerveiller sur tout et n'importe quoi et qui se fichent bien de savoir qui va maintenir le résultat de ses quelques expérimentations.
          On a eu la même chose en Go avec les goroutines. C'était tellement amusant qu'on les utilisait partout pour tout et n'importe quoi tellement s'était amusant. Et par la suite on s'est rendu compte que c'était quand même souvent bien coton à maintenir et l'utilisation est redevenue plus rationnelle. Idem pour les micro-services, pour les serverless, on adore fait joujou comme si on était Google et puis finalement quand on a une application à maintenir dans la durée on en revient à ce qu'on connait et qui a fait ses preuves.

          • [^] # Re: Pendant ce temps

            Posté par  . Évalué à 3 (+2/-1).

            Les deux dernières personnes ont maintenu des logiciels à un niveau d’exigence (de par l’ampleur de leur déploiement) que je pense aucun d’entre nous ne peut prétendre. Je pense que ni toi ni moi n’avons de leçon à leur donner sur le poids de la maintenance applicative. Et Eric Raymond ne fait pas que s’émerveiller, il explique ouvertement que la plupart du code qu’il publie est maintenant écrit par l’IA (sévèrement tenue en laisse, justement parce qu’il considère important de garder des très hautes exigences en termes d’architecture, justement pour ces raisons de maintenabilité).

            Et de fait, à ma connaissance, aucun des deux ne s’est émerveillé par le serverless et les microservices.

      • [^] # Re: Pendant ce temps

        Posté par  (site web personnel) . Évalué à 5 (+2/-0).

        Je crois que l'IA est plutôt douée pour les tâches de niveau moyen

        En fait, par la nature du fonctionnement des modèles, les LLMs sont efficaces pour les problèmes déjà résolus plusieurs fois ailleurs.

        J'ai un programme en rust qui me file un ics pour ce que j'appelle la "meeting chaos period", ce moment de l'année où les réunions bougent dans mon calendrier à cause de la date de changement d'heure qui différe entre l'Europe (ou je suis) et les USA (ou mes collègues sont). Quand je fait un meeting, il bouge quand je bouge, quand c'est mon chef en Californie, ça bouge quand il bouge. Du coup, y a des conflits de partout. Par curiosité, j'ai choisi utilisé Crush en branchant le logiciel sur Gemini de Google il y a ~8 mois, et j'ai demandé via l'interface de faire une revue de code.

        Le modèle a correctement noté que j'ai mal écrit une balise, que je devais mettre des tests parce que j'ai laissé ça en "TODO". J'ai laissé le modèle écrire des tests, mais j'ai du les refaire de 0 car relativement non idiomatique. Puis j'ai eu comme remarque que je pouvais utiliser une constante, mais le code généré a mis un clone() gratuit que j'ai du retirer. Le modèle a aussi correctement remonté que mes tests n'étaient pas suffisant, vu que j'avais mis un commentaire sur le fait que ça ne soit pas forcément 1h de décalage (et en effet, il y a parfois 2h et parfois 30 minutes). Du coup, j'ai continué à chercher tout les edges cases possibles, et c'est pour ça que j'ai 2 fois plus de tests que de code sur le fichier principal.

        J'ai aussi eu comme suggestion d'ajouter ce patch:

        --- a/src/timezone_pair.rs
+++ b/src/timezone_pair.rs
@@ -19,34 +19,25 @@
 pub fn parse_tz(paths: Vec<&str>) -> Option<TimezonePair> {
-    let mut prefix = String::from(""); 
-    let mut res = Vec::new();
-
     // make sure we do not do a loop if the result is obviously
     // wrong (small protection against DoS)
     // 6 is the maximum for 2 TZs
-    if paths.len() > 6 {
+    if paths.len() > 6 || paths.is_empty() {
         return None;
     }

-    for item in paths {
-        prefix.push_str(item);
-        match prefix.parse() {
-            Ok(tz) => {
-                res.push(tz);
-                prefix.clear();
-            }
-            Err(_) => prefix.push('/'),
+    // Iterate through all possible split points from 1 to paths.len() - 1
+    for i in 1..paths.len() {
+        let s1 = paths[0..i].join(\"/\");
+        let s2 = paths[i..].join(\"/\");
+
+        // If both parts parse as valid timezones, we've found our pair.
+        if let (Ok(tz1), Ok(tz2)) = (s1.parse(), s2.parse()) {
+            return Some(TimezonePair::new(tz1, tz2));
         }
     }

-    if res.len() == 2 || prefix.is_empty() {
-        Some(TimezonePair::new(res[0], res[1]))
-    } else {
-        None
-    }
+    None
 }

 impl TimezonePair {

        Le code marche (de ce que je sache), mais je l'ai refusé parce que ça m'a semblé moins idiomatique que le mien, que le code avait l'air plus subtile et avec une complexité plus dure à évaluer (mon algo fait un nombre linéaire d'appel à Tz::parse() dépendant de la taille de la chaîne sauf erreur de ma part, la ou le code proposé fait du 2n). Et je pense consomme un peu plus de mémoire (vu qu'il y a plus d'allocations de chaîne via s1 et s2).

        En pratique, on s'en fout car la fonction est appelé 1 fois par jour (y a un cache), que n vaut au plus 6, mais j'aime bien ne pas avoir du code rust qui ressemble trop à du code C quand je peux éviter.

        Le LLM a aussi réussi à se planter dans un diff (eg, un diff syntaxiquement incorrect), et a ne pas noter qu'une constante est utilisé en dehors du code rust (BUILDTIME dans les templates askama).

        Ce que je retient avec mon échantillon de 1 revue, c'est que le LLM, outil de matching avant tout, a correctement noté des trucs subtils, mais classiques. Remplacer un "// TODO add test" avec une réponse "faut faire des tests", c'est une revue courante. Mettre header au lieu de head, je suis sans doute pas le premier à faire l'erreur. Remplacer une chaine par une constante en Rust, c'est aussi une optim de base qu'on doit voir dans plein de revue.

        Et hélas, refaire un algo qui marche sans raison, c'est aussi une réponse courante dans des revues de code.

        Je ne dit pas que ça sert à rien, j'ai améliorer mon code grâce à ça mais si la seule raison de ma productivité est d'avoir face à moi une machine reloue, je sais pas si c'est si bien que ça.

        Toujours dans un cas qui va dans mon sens, j'ai aussi fait une seconde tentative, toujours via Gemini, toujours sur les calendriers, mais avec de la génération de code. J'ai voulu automatisé le fait de copier les jours fériés qui concernent mon équipe (8 pays) sur le calendrier d'équipe pour aider notre administratrice. Google Calendar est scriptable via une API, on peut lancer du javascript chez Google avec la gestion des clés et tout coté serveur, donc ç'est pas mal. Mais ayant déjà du faire ça par le passé, la documentation de Google est franchement pas terrible (et traduite automatiquement, avec un coté bizarre à la lecture).

        Donc je me suis dit que le LLM de Google doit sans doute bien connaître l'API Google et peut me sortir un script d'exemple que je peux adapter, quelque chose qui prends un ics d'un coté pour le mettre vers le calendrier sans trop de souci. L'idée était de comparer et copier les nouveaux événements pour ceux qui peuvent changer dans l'année (le cas typique, c'est le ramadan, mais je doute pas que Trump invente aussi un nouveau jour férié à un moment), ou quand quelqu'un arrive dans l'équipe depuis un pays non couvert dans l'année. Pour le moment, c'est une copie manuelle en décembre, mais un truc dynamique serait mieux.

        Il n'y a rien d'innovant, c'est juste lire 2 ics via http, faire une boucle pour comparer et envoyer la différence via une API. Et en effet, j'ai eu mon script en 30 secondes, ce qui me va parce que j'ai pas envie de faire du js si je peux l'éviter.

        Le seul probléme, le modèle a généré du code utilisant une fonction sans dire d’où elle vient, mais après recherche pas des apis Google (et qui ne marche pas). Alors bien sur, les hallucinations, ç'est documenté, mais la ou c'est intéressant, que je pense que celle ci est causé par le fait qu'il y a assez peu de code JS sur le web qui concerne le scripting de Google Workspace, et peu de code sur les calendriers en javascript en général, mais juste assez pour avoir une réponse en utilisant une lib non spécifié. Malheureusement, j'ai pas gardé le résultat.

        Donc oui, la ou les modèles font du bon boulot, c'est quand ce que tu dois faire a déjà été fait 100 fois et que le code est publique. Quand tu tapes dans les trucs un peu "nouveau" et un peu cracra que ça soit du point de vue des libs à utiliser, ou du domaine, ça semble commencer à partir un peu en vrille plus facilement.

        Pour moi, ça montre surtout que le métier de dev, c'est assez souvent refaire la roue, et c'est pour ça qu'une technologie qui est une forme de recherche statistique de code marche tellement bien dans les cas ou ç'est finalement un peu toujours la même chose.

        • [^] # Re: Pendant ce temps

          Posté par  . Évalué à 6 (+4/-0).

          Donc oui, la ou les modèles font du bon boulot, c'est quand ce que tu dois faire a déjà été fait 100 fois et que le code est publique. Quand tu tapes dans les trucs un peu "nouveau" et un peu cracra que ça soit du point de vue des libs à utiliser, ou du domaine, ça semble commencer à partir un peu en vrille plus facilement.

          Je comprends mieux pourquoi je n'obtient quasiment jamais de résultats probant pour les quelques fois où j'ai essayé. J'essaye uniquement quand je butte sur un problème difficile à résoudre ou une recherche de doc que je n'ai pas pu trouver facilement et de fait je ne tombe que sur des aberrations.

    • [^] # Re: Pendant ce temps

      Posté par  (site web personnel) . Évalué à 10 (+11/-0).

      Comme il a été écris en commentaire, l'IA n'est actuellement pas prêt à remplacer un dev, un dev compétent s'entend (au sens des frères Dreyfus sur l'acquisition des compétences). Par contre, il remplace apparemment aisément un stagiaire.

      Des retours que j'ai, effectivement, il faut interagir avec lui comme s'il s'agissait d'un stagiaire : lui expliciter le boulot à faire, être toujours derrière lui et à lui faire des retours fréquents, le corriger, etc. Bref, il est bien adapté pour des tâches petites, précises et spécifiques. Bref, tu passes de développeur à manageur d'une petite équipe de stagiaires (d'agents IA au-dessus d'un LLM) ; pour certains, ça plaît de faire du micro-management, pour d'autres …

      Un jour, j'ai lu sur Mastodon la question d'un geek (je crois que c'est @sebsauvage) aux dev jouissant de l'utilisation de l'IA s'ils avaient vue leur rémunération augmenter à la mesure du gain de productivité qu'ils apportaient avec leur l'utilisation de l'IA. Bref, à qui profite vraiment, actuellement, l'utilisation d'agents IA ?

      • [^] # Re: Pendant ce temps

        Posté par  (site web personnel, Mastodon) . Évalué à 10 (+15/-0).

        Alors j'aime beaucoup encadrer des stagiaires. Pourtant, je sais d'avance que le code produit ne va pas être utilisable, qu'il va falloir repasser 15 fois sur les relectures. Je sais que ça va me prendre 5 fois plus de temps que de faire les choses moi-même. Par contre, si ça fonctionne bien, à la fin du stage, j'ai un collègue qui est monté en compétence, et qui est opérationnel pour commencer à prendre part au développement du projet.

        "Encadrer" des LLM, qui ne peuvent jamais apprendre ce qu'on leur explique, et devoir répéter, répéter, et encore répéter? Et en plus, savoir qu'on travaille moins vite que si on faisait les choses soi même, c'est l'enfer. Pourquoi des gens s'infligent-ils ça?

        • [^] # Re: Pendant ce temps

          Posté par  . Évalué à 3 (+3/-1).

          C'est à cela que servent les 'steering document' des systèmes de génération de code d'IA, bref des 'prefixes de prompt' en pratique qui lui donnent les règles à suivre à chaque fois.

          C'est ce que je j'utilises pour lui dire de toujours génerer un plan et me le montrer avant d'implémenter, de toujours écrire des tests qui couvrent les different aspects, de ne jamais choisir un hack comme solution mais une approche architecturalement propre, etc…

          C'est pas 100% suffisant, mais cela aide beaucoup à éviter de revoir les mêmes problèmes à chaque fois.

          Et ensuite, avec les améliorations de la qualité des LLMs à chaque version, il y de moins en moins besoin de se taper la tête contre les murs.

      • [^] # Re: Pendant ce temps

        Posté par  . Évalué à 10 (+20/-0).

        Par contre, il remplace apparemment aisément un stagiaire.

        Sauf que le stagiaire n'est, normalement, pas là pour remplacer le dev. mais pour apprendre. Si on le remplace par Claude, quand le stagiaire va-t-il apprendre ?

      • [^] # Re: Pendant ce temps

        Posté par  (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 23 mars 2026 à 11:44.

        Bref, il est bien adapté pour des tâches petites, précises et spécifiques.

        je rejoins ton point de vue mais ce n'est pas comme ça qu'il est "vendu" : il est censé "tout" faire (les docs', les tests, la non-rég', les API, le code) — ce n'est pas moi qui le dit, ce sont les zélotes hein :p — là où pour les commits je suis dubitatif, encore plus pour les déploiements qui vont emballer la machine… (et la consommation de tokens).

        Tant qu'il y a des points de contrôle effectifs, ça peut permettre d'avoir une couverture de tests plus complètes que ce que tu aurais fait.

        Tant que personne n'est prêt à maintenir le code généré par un LLM, ça risque d'être no go ;-) (déjà que maintenir le code d'un autre c'est pas toujours la panacée… au moins, tu peux lui demander ce qu'il aurait amélioré, s'il s'en rappelle :D).

        • [^] # Re: Pendant ce temps

          Posté par  . Évalué à 3 (+2/-0).

          Je confirme, c'est très adapté pour des taches précises et "générique" et aussi pour pas mal de petits trucs:
          - éviter le syndrome de la page / l'algo blanc : On lui jette ce que l'on a en tête, ca le structure, et ensuite on affine notre réflexion. Cela remplace avantageusement le canard en plastique, par un machin qui te répond et qui peut sourcer
          - ca évite d'écrire du code que tu sais jetable et d'y passer trop de temps. En ce moment, je "m'amuse" a devoir parser des sorties d'outils hétérogènes pour récupérer certaines info. C'est du PoC, pour mesurer quels outils répondent le mieux à mon besoin. Il me généré ca en vitesse et sans trop d'erreur, ca reste du code maitrisable qui m'évite d'avoir à tapper un truc pseudo répétif mais pas tout à fait
          - ca génere des tests cases a la volée assez rapidement. Tu lui donnes tes définitions de fonction, ta spec (ou RFC), il va te pondre bcp de tests. Ca se relis facilement, et ca va bcp plus vite.
          - Tu lui donnes un code que tu maitrises et tu lui demande son avis. Il eput se retrouver pertinent à proposer quelques amélioration. Ne pas hésiter à le passer en mode "insultant" avec un prompt qui lui demande de te faire une analyse d'expert pour torpiller l'architecture. Sinon, il va être trop gentil et avoir tendance à montrer ce qui marche

          Bref, l'outil est plutôt bon, il faut juste savoir l'utiliser et quand ne pas le faire. Mais le plus gros risque étant de voir :
          - Potentiellement moins de nouveaux qui codent "sans" ou qui comprenne ce qu'il font.
          - A déléguer les taches "facile" et peu valorisante, on réduit les inputs pour fomer des nouveaux entrant

    • [^] # Re: Pendant ce temps

      Posté par  (site web personnel, Mastodon) . Évalué à 10 (+27/-0).

      Les uns et les autres clament que Claude produit du code meilleur que ce qu'ils auraient produit et moi je me demande, si le résultat est effectivement mieux que ce qu'ils auraient fait, c'est donc au delà de leurs capacités. Dès lors, sont-ils aptes à juger du résultat ? Par exemple, je ne sais pas jongler. N'importe qui pouvant attraper deux fois deux balles fait déjà mieux que ce que j'aurais fait. À quoi ça rime si je l'impose à tous les cirques du monde parce qu'il fait mieux que ce que j'aurais fait ? Faut-il laisser les décisions aux plus incompétents ?

      En fait tu touches là le cœur du problème. Une bonne majorité des gens sont incompétents, ou plutôt, pas très compétents (c'est à dire qu'ils sont suffisamment compétents pour faire quelque chose de médiocre, mais qui marche, par contre ça va pas beaucoup plus loin). Et le problème est qu'il est très dur de bien vivre en société si on doit se retrouver à expliquer cela. Ce qui fait que cela ne rentre jamais vraiment en argument dans ce genre de discussion (même si c'est en fait un argument très fort). Enfin je suppose que tu vas pas te mettre à expliquer à tes collègues qu'ils sont incompétents et c'est donc pour cela qu'ils voient pas le problème… enfin du moins en supposant que tu veuilles continuer en bonne entente dans cette entreprise. 😅

      Le problème des gens peu compétents pour ce genre d'évaluation est double: le premier est évident, c'est qu'ils ne voient pas le problème (parce qu'évidemment, ils ne savent pas faire mieux); le second est encore plus pervers et encore plus dur à sortir en argument. Quand on est peu compétent, le travail est laborieux et pénible et on saute sur toute bonne occasion de pouvoir éteindre son cerveau. On veut passer une journée pépère au boulot, rentrer chez soi et oublier.

      Cela fait donc beaucoup écho à ce que tu dis ensuite:

      Jamais une revue de code ne nous donnera une connaissance autre que superficielle et je suis convaincu que ce qui a été écrit par Claude sera maintenu par Claude. Qu'il sera responsable des corrections de bugs et sans doute aussi des revues.

      En effet, l'un des arguments que les fanatiques de l'IA sortent souvent, c'est que comme ils sont compétents (🤣), ben ils reliront le code, le comprendront, le "own" (ahah elle est bonne celle-là, ce genre d'anglicisme me rappelle l'époque où je bossais en entreprise), comme tu dis… Mais qu'ils auront gagné énormément de temps, car ils n'auront que la revue de code à faire. Et là on sent bien que ces gens ne comprennent rien à la revue de code, ne la comprennent pas, et ne l'ont sûrement jamais bien faite de leur vie.

      Une bonne partie des revues de code prennent plus de temps que si on avait tout écrit de zéro soi-même! Une bonne revue, c'est chiant, c'est pénible, c'est parfois plus éreintant à comprendre que si on écrit le code, car dans le second cas, on doit juste essayer de comprendre le code originel et son intention, alors que dans le premier cas, on doit comprendre également le nouveau code, aussi son intention, et pourquoi le développeur a choisi de corriger le bug à cet endroit précis du code (spoiler: l'endroit de la correction est souvent faux pour les débutants qui adorent corriger les symptômes plutôt que les causes d'un bug! Ce qui ne fait que rendre le code moins bons et le bug réapparaîtrait plus tard; une bonne partie de mes revues de code ont pour conclusion: "là tu es en train de prendre en compte un cas qui est censé être impossible, c'est à dire que si vraiment ta condition retourne TRUE, ça veut dire que le processus est dans un état invalide; s'il te plaît recherche comment en est-on arrivé là, et corrige la source du problème pour que ça ne puisse plus arriver").

      Pourquoi on fait des revues de code, alors? D'une, c'est pour former les "nouvelles recrues" (dans le logiciel libre, la variante, ce serait pour espérer que le contributeur reste dans le coin et fasse plus de patchs; donc on le forme dans cet espoir), pour que justement la personne devienne compétente et qu'on n'ait plus trop à passer de temps en revue de code dans le futur. Également cela peut être pour avoir une seconde vision sur un problème complexe (avec l'IA, parler donc de revue de code est une aberration, puisqu'il n'y a au final qu'une seule vision! Celle du développeur qui fait la revue!). Et bien sûr, éviter des problèmes passés inaperçus au premier développeur. Mais en réalité, à un moment donné, on veut tous essayer de s'alléger la tâche, donc à un moment donné, on fait moins gaffe à la revue, et on devient paresseux le jour où on considère que le développeur dont on fait la revue de code est devenu meilleur, et qu'il peut donc gagner un brin d'indépendance. Notons qu'on ne considère pas forcément qu'il est vraiment au top niveau, mais au moins qu'il fera moins d'erreurs de débutants. Dans ces conditions, on va toujours faire une revue de code pour voir s'il n'y a quand même pas de grosses erreurs flagrantes, mais la revue sera plus superficielle, et peut-être même qu'on verra quelques petites imperfections mineures mais qu'on les laissera passer (si elles sont globalement inconséquentes) ou bien qu'on se dira que le patch n'est pas idéal mais pas non plus complètement faux, et on laissera passer encore, en se disant que cette personne doit aussi apprendre. On se permet soi-même un petit peu de paresse dans notre tâche de revue. Et c'est seulement là où la revue est rapide. Mais parce qu'on a sciemment laissé passer du code non-idéal (ou qu'on l'a fait, mais pas sciemment, dans le cas des moins compétents).

      Le truc, c'est aussi qu'on veut pas passer tout son temps à faire des revues de code. C'est chiant, c'est long, c'est compliqué (autant, voire plus, que l'écriture du code, car contrairement à ce que semblent penser les mauvais développeurs, il faut aussi comprendre le code pour en faire la revue! On refait donc tout le même travail qu'est censé avoir fait le développeur initial!), et ça ne nous laisse pas de temps pour écrire notre code à nous!

      Donc à chaque fois que je lis les fans de l'IA sortir que comme on fait juste la revue de code, ben au final, on peut se l'approprier et on gagne beaucoup de temps, ben la chose que ça me fait comprendre, c'est que ces gens étaient effectivement des développeurs incompétents s'ils pensent ainsi. Parce que ça veut dire qu'ils ne comprennent pas ce qu'est une bonne revue de code et n'en ont jamais fait une (bonne) eux-même de leur vie. Ce sont des gens qui sont probablement directement passé à l'étape "revue paresseuse" sans jamais avoir fait l'étape "revue en profondeur et avec compréhension complète du code" qu'ils auraient dû faire d'abord (et que je fais personnellement pour tout nouveau contributeur, et pas juste pour une ou 2 revues mais en général pour au moins une dizaine de revues pendant quelques mois, voire quelques dizaines de revues — cela dépend du contributeur et de sa capacité d'apprentissage —; et ce qui prend un temps fou).

      Maintenant, c'est d'autant plus chiant car il est bien connu que ces développeurs incompétents, ce seront ceux qui finiront aux postes à responsabilité en contexte d'entreprise, ceux qui feront donc des décisions du genre "on va tous utiliser de l'IA, et c'est maintenant un outil obligatoire de l'entreprise".

      J'ai bien vécu cela aussi en entreprise, par exemple avec le jeune dont la principale compétence est "sort de polytechnique", propulsé directement à un rôle managérial, ce qui signifie en vrai que le gars est incompétent et est juste là pour "changer les choses" (on sait pas quoi, ni pourquoi, mais faut changer). J'ai une histoire comme cela où on parle de changer notre outil de suivi de bug, ce qui est une bonne idée. C'est l'outil qu'on va utiliser tous les jours, alors je demande à mon boss de présenter quelque chose, je monte un bugzilla (à l'époque, c'était le top, bien avant tous les forges modernes à la Gitlab) sur un serveur, avec des modifs pour s'adapter à l'entreprise, pour faire une démo live. Le gars de son côté a préparé ses "slides" pour présenter Jira. Il ne faisait que copier-coller des points marketing de l'entreprise qui fait Jira (Atlassian). Il n'a pas montré une seule fois le logiciel, qui s'est avéré être une usine à gaz sans nom. Mais bon "il vient de Polytechnique", il n'y a même pas eu de discussion, sa proposition a gagné avant même de la présenter (c'est à peine si les "décideurs" ont regardé ma démo). Vous comprenez, "il vient de Polytechnique".

      Dans une autre entreprise, une startup cette fois, on était peu, mais ils ont réussi à choisir le pire des développeurs de l'équipe (mais le plus blabla-teur) pour en faire un manager. Celui qui faisait du mauvais code, qui arrêtait pas en plus de dire du mal des patrons lorsqu'on prenait une bière, mais qui une fois manager est devenu le pire des managers, toxique au possible.

      Et le problème, c'est que ce sont ces personnes qui prendront les décisions. Personnellement je suis heureux de ne plus être en entreprise, et ce que je dis souvent, c'est que dans le contexte actuel, je doute d'autant plus que je veuille y retourner un jour.

      Donc oui, l'IA, c'est un nouvel apogée de la médiocrité (mais je fais confiance aux humains qui ont su prouver dans leur histoire exceller en la matière et en repousser les limites encore et encore).

      Et c'est le cas dans tous les contextes d'usage de l'IA d'ailleurs. Les mêmes problèmes de faible qualité, paresse, etc. s'appliquent. Par exemple, un bon traducteur a besoin de laisser libre cours à son imagination. S'il part d'une traduction médiocre pré-mâchée par un LLM, c'est comme un carcan dans lequel on nous demande de travailler et dont il faut se dépêtrer. Au mieux, cela fera une traduction tout juste "OK", avec énormément plus de travail que si la personne avait tout traduit de zéro. Au pire, le traducteur va devenir paresseux et va faire le minimum syndical (comme dans le cas de la revue de code paresseuse) et on se retrouvera avec une trad médiocre, voire carrément mauvaise.

      Ce sera aussi le cas pour l'écriture de texte, ou bien la création d'images, voire multimédia de manière générale.

      Et c'est aussi pourquoi il est important que les gens qui comprennent le problème pour leur champ d'activité ne le laisse pas passer là où ils sont moins compétents. On lit encore bien trop souvent des "L'IA, c'est horrible pour le code, mais ça marche super bien pour créer des illustrations" (signé: un développeur qui n'a jamais dessiné depuis la maternelle), ou encore "L'IA tue l'industrie du dessin, mais c'est cool pour faire des programmes pour quelqu'un pas développeur pour un sou!" (signé: un illustrateur quelconque qui veut s'essayer aux jeux vidéos) ou encore "L'IA ne remplacera jamais les acteurs, mais on comprend tout à fait l'usage pour les métiers techniques!" (je reçois des emails d'appel au secours d'organismes de gestion de droits ces derniers mois à ce sujet — ils s'égosillent sur le remplacement des acteurs par des "acteurs IA" —, parce que j'ai un gros passif dans le monde du cinéma/télé), etc. On peut le faire avec toutes les variantes et combinaisons.

      J'avais fait un commentaire à ce sujet sur un article qui se plaignait des livres écrits par IA et l'illustrait… par une image générée: https://linuxfr.org/users/vendrediouletrollsauvage/liens/ces-livres-ecrits-par-ia-vendus-sur-amazon-recit-alarmiste-d-une-mere#comment-2003847

      Quand ils sont venus simuler la création graphique, je n'ai rien dit, je ne savais pas peindre;
      Quand ils sont venus simuler la création littéraire, je n'ai rien dit, j'écris vraiment mal;
      Quand ils sont venus simuler la création de code, je n'ai rien dit, je ne développe pas;
      Quand le monde fut rempli de merde générée, on s'était déjà tous tirés dans les pattes et plus personne ne travaillait ensemble.
      La médiocrité a gagné.

      Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

      • [^] # Re: Pendant ce temps

        Posté par  (site web personnel) . Évalué à 6 (+4/-0).

        sans remettre en cause la compétence de ceux qui choisissent l'IA, j'aurais plutôt tendance à leur demander s'ils sont prêts à maintenir ce que leur a produit l'IA (avec un taux d'engagement supérieur à 60% :D), cela permet mieux d'identifier les limites que eux y mettent.

        Et oui, selon ses appétences, j'ai tout de même l'impression que le jugement sur l'IA est par rapport à ce que l'on n'aurait pas fait de soi-même : la doc', les tests, le code pour certains, les trucs un peu répétitifs dans le code, autant faire faire les revues par l'IA aussi (mais dans ce cas avoir les bonnes pratiques correctement exprimées :D)

      • [^] # Re: Pendant ce temps

        Posté par  (site web personnel) . Évalué à 9 (+7/-0).

        Quand on est peu compétent, le travail est laborieux et pénible et on saute sur toute bonne occasion de pouvoir éteindre son cerveau. On veut passer une journée pépère au boulot, rentrer chez soi et oublier.

        Pas besoin d'être peu compétent pour ça /o\

      • [^] # Re: Pendant ce temps

        Posté par  . Évalué à 5 (+3/-0).

        Quand ils sont venus simuler la création graphique, je n'ai rien dit, je ne savais pas peindre;
        Quand ils sont venus simuler la création littéraire, je n'ai rien dit, j'écris vraiment mal;
        Quand ils sont venus simuler la création de code, je n'ai rien dit, je ne développe pas;
        Quand le monde fut rempli de merde générée, on s'était déjà tous tirés dans les pattes et plus personne ne travaillait ensemble.
        La médiocrité a gagné.

        J'aime beaucoup !

        Merci pour ce retour et cette analyse.

        Comme beaucoup je suis tiraillé entre l'intérêt que je porte à ces outils assez "magiques" il faut bien le dire et tout ce que ça m'inspire d'horreur sur le plan sociétale et écologique.
        J'ai quand même creusé le sujet, j'ai passé un diplôme d' "Expert IA" (à Polytechnique Bordeaux d'ailleurs :D) pour comprendre un peu plus comment fonctionne ces systèmes.
        Je commence à les utiliser et j'en vois tout de même des avantages indéniables dans la pratique du développement informatique (mon domaine), mais je n'ai pas encore fait le pas de l'intégrer totalement à ma base de code.

        Je rejoins ton avis sur la relecture de code, c'est long, c'est fastidieux. Souvent, on finit par ne pas faire toutes nos remarques quand elles portent sur des aspects "minimes". Parfois, j'abandonne même sur l'aspect architectural quand ce n'est pas moi qui gère le projet. Mais si je devais laisser une IA faire, je crois que ça serait le massacre.

        Perso les LLM m'aident beaucoup pour débroussailler un projet, une nouvelle techno, trouver comment écrire tel truc sur des technos que je ne vais pas devoir maîtriser par la suite ou quand ce n'est pas mon coeur de métier et que je n'ai pas le temps ou tout simplement l'envie de monter en compétence dessus.

        Dans ce cas d'usage c'est une sorte de stackoverflow survitaminé et ça fonctionne vraiment bien !

        C'est aussi très pratique pour rédiger une implémentation d'une fonction dont le domaine est bien circonscrit, que des tests peuvent facilement s'écrire etc. ça fonctionne aussi du tonnerre. Et pour une nouvelle implémentation, la relecture est plus simple justement car on part d'une page blanche, la logique est plus aisée à appréhender.

        Mais je vois quand même que souvent les LLMs écrivent des choses bizarres parfois : genre avec des variables qui ne sont jamais utilisées, pas mal de répétitions, ils oublient aussi très facilement un contexte surtout s'il est détaillé etc.

        Je sais que ce genre de problématique à tendance à réduire avec le temps, mais quand même, je ne crois pas qu'on soit encore à un niveau ou une IA peut comprendre l'intégralité d'une base de code et proposer des modifications de manière cohérente avec l'ensemble.

        Peut-être que je me trompe ?

        Je n'ai aussi jamais utiliser d'outil comme Cursor ou Copilot, mais j'ai des retours très positifs. Je reste encore assez méfiant (notamment sur les aspects non techniques liés aux GAFAM) cependant.

        L'autre jour il y'avait un article d'une personne qui est rédactrice marketing indépendante et elle disait que maintenant 95% de ses clients lui demande de reprendre des textes générés par IA.

        Ce phénomène risque d'arriver dans la tech, avec des boîtes qui vont engager en urgence des gens "compétents" pour corriger des problèmes de trucs live codé rapidement et livrés en production sans plus de vérification. C'est déjà en train d'arriver chez Amazon, Microsoft et tout. Ils s'étaient enflammé en interne sur l'usage de l'IA, pour beaucoup ils font machine arrière ou mette des règles plus strictes pour encadrer son usage.

        Le gain de productivité ne serait qu'illusoire…

        En tout cas, la où je trouve que ça excelle, c'est pour l'analyse de document. Des outils comme NotebookLM sont vraiment impressionnant et permette d'appréhender des documents volumineux, complexes (genre des normes) ou d'un autre niveau intellectuel (genre des articles scientifique dans un domaine peu maîtrisé) avec une aisance folle. Sérieux, si je devais garder un truc de toute l'IA générative, ça serait ça. Pouvoir discuter autour d'une base documentaire. C'est un énorme bon dans l'exploration de la connaissance je trouve.

      • [^] # Re: Pendant ce temps

        Posté par  . Évalué à 2 (+0/-0). Dernière modification le 24 mars 2026 à 00:43.

        là tu es en train de prendre en compte un cas qui est censé être impossible

        Il y a pas trop longtemps, j'ai laissé passer un truc pendant une revue, car on m'avait convaincu qu'il était "cas impossible" (par fatigue, par empathie, je ne sais plus). Deux jours plus tard, bim! dans la tronche le cas impossible :D. Je m'en suis un peu voulu de m'être laissé convaincre.

        Je dis pas qu'il faut aller vers du if(1==1) avant chaque instruction, mais vérifier les entrées quand ça vient d'un truc un peu lointain/compliqué, ça peut quand même sauver les meubles ;).

        • [^] # Re: Pendant ce temps

          Posté par  (site web personnel, Mastodon) . Évalué à 7 (+4/-0).

          ça peut quand même sauver les meubles ;).

          En fait ça dépend vraiment de ce que tu cherches: un logiciel sans bug, ou un logiciel qui a "l'air" de fonctionner (mais en fait est tout cassé).

          Quand on dit "cas impossible" ici, cela veut bien entendu dire "théoriquement" et non pas dans les faits, clairement (puisqu'il est arrivé cette première fois). Donc le "dans la tronche le cas impossible" ne prouve donc absolument rien, sinon le fait que tes collègues ont possiblement raison et qu'il y a un autre bout de code créant ce cas "impossible".
          La réponse à cela doit donc être de corriger ce code qui a généré cet état impossible, afin qu'il représente cette théorie. Le problème de la correction a posteriori (c'est à dire quand il est déjà arrivé) du cas impossible, c'est qu'on ne fait que cacher le problème, un peu l'équivalent de mettre la poussière sous le tapis.

          Deux jours plus tard, bim! dans la tronche le cas impossible :D. Je m'en suis un peu voulu de m'être laissé convaincre.

          Alors je connais pas ton cas particulier. Peut-être est-ce un autre cas, et qu'en fait ce n'était simplement pas réellement un cas qui devait être impossible dans la théorie. Ce qui n'est alors pas ce dont on parle ici.

          Mais si on suppose que ça l'était, alors je suis désolé, mais tes collègues avaient raison et le fait que ça se reproduise 2 jours plus tard… ne fait que leur donner encore plus raison! 😛 La dernière chose que tu voudrais vouloir est de cacher cet état impossible des choses. Si ça se produit vraiment régulièrement, tu veux comprendre pourquoi et c'est ça que tu veux corriger. Et tu veux laisser les conséquences de ce problème bien visibles jusqu'au moment où tu as corrigé cela, comme un marqueur du problème (par exemple, si le problème est très complexe et tu n'es pas certain de ta correction, tu vérifies si d'autres gens continuent de rapporter le problème; si à un moment donné, plus personne ne le rapporte, tu peux supposer que la correction est bonne).

          Je dis pas qu'il faut aller vers du if(1==1) avant chaque instruction, mais vérifier les entrées quand ça vient d'un truc un peu lointain/compliqué, ça peut quand même sauver les meubles ;).

          C'est justement pour cela que les assert() ont été créés. Tu vérifies l'état de ton processus (le contenu des variables, l'état d'un objet, etc.) tel qu'il est censé être au début d'une fonction (ou parfois même au milieu, après être passé par certains traitements).

          Alors assert, c'est un peu violent, tu vas me dire. Et tu aurais raison. Néanmoins les processus de développement ont évolué depuis qu'on en fait! Dans GIMP, nous avons des fonctions du même genre qui ne plantent pas immédiatement le processus. À la place, ça va générer des WARNINGs ou CRITICALs, et parfois aussi retourner immédiatement de certaines fonctions (surtout quand on sait que sinon, on planterait, genre parce qu'on ferait une division par zéro, ou qu'on va déréférencer un pointeur NULL, etc.). Donc le processus est toujours dans un état instable, mais on se donne une chance de retrouver un état stable, probablement avec un truc qui va mal (ou pas) se passer, mais avec un peu de chance, quelque chose de pas trop grave.

          Par contre, la grosse différence, c'est qu'on aura eu notre CRITICAL. Et c'est là où on va pouvoir se mettre à débugguer. Ce CRITICAL va bien sûr se logguer dans le terminal, mais surtout j'ai implémenté une fenêtre de Debug qui s'ouvre automatiquement en popup et produit une backtrace du code qui a produit ce CRITICAL. Et cette fenêtre suggère aux gens de soumettre un rapport de bug avec ces informations. Ce qui en retour nous permet de trouver l'origine du CRITICAL puis de dialoguer avec la personne ("Vous rappelez-vous ce que vous faisiez?") pour essayer de trouver l'origine du bug (note que parfois, la trace se suffit à elle-même, bien sûr! Mais je parle du cas dont il est question où la trace serait plutôt un symptôme que la cause du problème).

          Avant que j'arrive chez GIMP, on avait pas cette fenêtre de Debug donc on n'obtenait jamais des rapports pour ces bugs un peu "cachés" (car les gens ne regardent pas le terminal pour un logiciel graphique en général!), on avait rarement des traces de debug (sauf quand le rapporteur était aussi développeur) et notre indice principal était les procédures de reproduction (ce qui reste très important, mais maintenant, c'est pas notre seul indice et dans beaucoup de cas, on arrive même à faire sans).

          Le développement a évolué, et de nos jours, il existe donc des moyens d'éviter des plantages intempestifs sans pour autant cacher les problèmes. Alors as-tu vraiment sauvé les meubles si tu t'es contenté d'un if qui a silencieusement corrigé une variable fausse (ou quelque chose du genre)? Rien n'est moins sûr (et encore une fois, je connais pas ton cas précis).

          Je sais qu'on a régulièrement des cas comme cela dans GIMP où certains développeurs plus junior vont faire des corrections de conséquences; mais cela reste des développeurs de confiance à qui j'ai donné les clés (ils font du bon travail globalement, même si parfois aussi quelques erreurs). Et à cause de cela, le même bug se reproduit, mais ailleurs. Et ils refont globalement la même "correction" dans cet "ailleurs". Plusieurs fois.

          Puis j'arrive à un moment, je regarde le problème, et corrige la vraie source du bug (qui peut être dans un endroit totalement différent du code). Puis on retire tous les "sparadraps" du reste du code qui n'avaient été rien d'autre que des cache-misères tentant de maladroitement cacher un vrai bug ailleurs.

          Au final, on peut considérer donc que cacher ce cas impossible ne fait que créer plus de travail. Notamment car il devient alors plus compliqué de diagnostiquer un problème. Le pire cas est même quand on arrive à vraiment bien cacher le problème en fait, si bien qu'il ne ressort plus de manière évidente ailleurs, mais à la place apparaît alors comme un problème dorénavant bien plus subtil dans un processus qui a l'air de fonctionner mais qui produit un résultat légèrement erroné. Et personne ne comprend pourquoi. Mais qu'est-ce qui se passe? Bah voilà! C'était le développeur débutant qui a caché un méchant bug l'autre jour (et d'après lui, il a bien fait! Ben oui, avant le processus plantait complètement; et maintenant non; c'est mieux, non?), sauf que maintenant à la place, on a un résultat faux, mais suffisamment subtilement pour que beaucoup ne s'en rendent pas compte (donc on le découvrira des mois après) et que quand on le voit enfin, on va chercher des jours et des jours pour le problème.

          Alors as-tu vraiment sauvé les meubles? La question reste ouverte! 😜

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

          • [^] # Re: Pendant ce temps

            Posté par  . Évalué à 3 (+1/-0).

            Hello, merci pour cette réponse détaillée.

            Je ne me souviens pas du cas exact, mais c'était, je crois, un cas où un processus (en shell) lisait le résultat d'un autre processus (en python je crois), et le renvoyait à un troisième (dans puppet). Les valeurs qu'on pouvait avoir étaient simples : true ou false, sous forme de chaîne dans le shell, converties en booléens dans puppet. Mais à un moment, on a eu ni true ni false, mais undef (le fameux). Et là, le programme ne passe pas par là ou il devrait. Bref, un truc de débutant. Mais on m'a convaincu que seules deux valeurs pouvaient arriver pour un booléen, je fus faible.

            On a en effet corrigé le programme d'origine pour qu'il ne puisse plus retourner que true ou false pour de vrai. Involontairement, on a utilisé ta méthode je crois :D.

      • [^] # Re: Pendant ce temps

        Posté par  (site web personnel, Mastodon) . Évalué à 5 (+3/-0).

        Donc oui, l'IA, c'est un nouvel apogée de la médiocrité

        Comment j'aurais trop aimé pouvoir pertinenter deux fois !

      • [^] # Re: Pendant ce temps

        Posté par  . Évalué à 3 (+3/-2). Dernière modification le 24 mars 2026 à 14:01.

        Je te trouve bien tranché dans tes opinions, dans un domaine qui évolue très vite, et qui est de base extrêmement flou.

        "Soit l’IA est un outil qui fascine les incompétents, soit l’IA et un outil qui peut aider les compétents" (et je me suis très fortement décidé sur le premier cas).

        "Soit l’IA est un générateur de bullshit convainquant, soit l’IA est réellement capable de faire du travail de fond" (et je me suis très fortement décidé sur le premier cas).

        Comme j’ai dit ailleurs dans le fil, il y a clairement des développeurs dont la compétence n’est pas à mettre en doute qui arrivent à tirer profit de l’IA. Il y a évidemment des développeurs compétents qui ne veulent pas ou n’arrivent pas à tirer profit de l’IA (dont tu sembles faire partie, je nommerai également Drew DeVault). Il y a même des développeurs incompétents qui arrivent à tirer profit de l’IA (c’est plus compliqué, mais c’est possible, il faut juste rester à la hauteur de ses ambitions). Et évidemment beaucoup d’incompétents qui se tirent une balle dans le pied en acceptant aveuglement tout ce que l’IA balance et se retrouvent au mieux avec une solution inmaintenable, au pire avec quelque chose de déployé "dans le cloud" qui coûte trois reins qui a plus de failles de sécurité qu’un Windows ME non patché.

        Je ne comprend réellement pas ce qui justifie ta position "non, l’IA ne fait que fasciner les incompétents".

        Le point générateur de bullshit convainquant vs capable de faire du travail de fond est éclairant. La réponse est clairement "les deux mon capitaine". Rien que dans les liens que je mentionne dans les "nouvelles sur l’IA de mars 2025" :

        Générateur de bullshit :

        Travail de fond :

        Et c’est tout les mois la même chose : The Good, The Bad and The Ugly. Avoir une opinion tranchée dans un sens ou dans l’autre (l’IA ne fait que du bon travail ou l’IA ne fait que du travail médiocre) est clairement, à ce stade, une erreur.

        Maintenant j’aimerai parler un peu de prendre du recul. Ce que j’ai l’impression que personne n’est capable de faire, comme si le passé n’existait pas, qu’on vivait dans un présent perpétuel déraciné, à la 1984.

        Le recul, c’est que si tu dis en 2021, "en 2026 on a des IA assez avancées pour faire du travail de fond en mathématiques, sécurité informatique, programmation, mais avec toutefois des résultats assez inégaux…"

        1. Tu seras pris pour un malade, un fou furieux à enfermer. Par moi le premier.
        2. De manière évidente et très claire tout le monde te dira que l’information choquante, importante dans cette phrase, est la partie avant le "mais", pas la partie après le "mais".

        Je ne comprend pas pourquoi, aujourd’hui, on tient tant à se concentrer sur la partie après le "mais". Je pense que la réponse serait quelque chose comme "je suis fatigué de toute cette hype, on voit bien que l’outil est survendu", et encore une fois, j’ai envie de dire, il faut prendre du recul. Je laisse la parole à Andrej Karpathy :

        The majority of the ruff ruff is people who look at the current point and people who look at the current slope.

        Ce que je mettrai en ces termes : se concentrer sur les limitations actuelles est une erreur :

        • Épistémologique, si on essentialise et éternalise ces limitations, plutôt que de les considérer telles qu’elles sont réellement : les limitations actuelles. Tu es cash sur incompétents vs compétents, ce que j’apprécie, alors permet moi d’être cash. Tu es un être humain. Doué de raison et d’un cerveau. Tu as le droit et en un sens le devoir de les utiliser pour extrapoler au mieux de tes capacités intellectuelles les tendances, de te projeter dans l’avenir. "Oui mais qui formera les juniors de demain" est une très bonne question, mais qui j’ai l’impression sous-tend une certaine présupposition que l’IA n’aura pas évolué dans ses capacités dans 10 ans, ce à quoi je me contenterai de dire "WTF ? Pourquoi ? Sur quoi se base cette croyance ?". As-tu vu, remarqué le rythme d’évolution ?

        • Instrumentale : 1. un outil imparfait aujourd’hui peut quand même être d’une grande aide, et apprendre à travailler avec (et ses imperfections) un gain important et 2. l’outil imparfait d’aujourd’hui permet de se familiariser avec l’outil moins imparfait qui sera là demain

    • [^] # Re: Pendant ce temps

      Posté par  . Évalué à 2 (+2/-0).

      J'ai personnellement la même expérience avec Claude. Et clairement je rejoins un commentaire plus bas, il y a une nette corrélation (et une causalité évidente) entre l'adoration de l'IA et son niveau de compétence.

      Mais ma réponse à ce message est surtout pour exprimer ma surprise de savoir qu'il existe encore des boîtes dans lesquelles ce genre d'optimisation arcanique en AVX2 (tu précises pas si c'est à l'aide du compilateur, d'intrinsics ou directement via de l'assembleur (inlined ou lié)) est considéré comme utile et accepté d'être réalisé. Cool de savoir que ça existe encore.

  • # dépendance

    Posté par  (Mastodon) . Évalué à 10 (+9/-0).

    Merci pour ce retour très intéressant et positif sur la partie technique.

    Vu que l'on est sur Linuxfr je me pose la question de la dépendance à des outils stratégiques non libre ? et états-uniens.

    • [^] # Re: dépendance

      Posté par  (site web personnel) . Évalué à 2 (+1/-1). Dernière modification le 23 mars 2026 à 09:57.

      C'est évident que c'est un gros problème.

      Tout juste en cette période où les organismes européen commencent timidement à se dire que bon, Google et Microsoft aux US, ce serait peut-être bien d'éviter.

      J'espère que nos boites européennes de l'open source et du libre ne vont pas forcer leurs employé·es à utiliser ces outils.

      • [^] # Re: dépendance

        Posté par  . Évalué à 4 (+2/-0).

        Sans compter les coûts économiques et environnementaux qui vont vite nous rattraper et faire tomber la mayonnaise.

    • [^] # Re: dépendance

      Posté par  (site web personnel) . Évalué à 5 (+3/-0). Dernière modification le 24 mars 2026 à 09:08.

      Personnellement, je suis un maniaque de l'opensource et de l'hébergement perso, et c'est probablement la question qui m'embête le plus.

      Surtout que les développeurs de LLM maintiennent (volontairement ?) une forte confusion entre LLMs opensources et openweights. Les LLMs vraiment opensources sont en fait très rares. Les LLMs openweights sont eux extrêmement nombreux.

      Mais même en s'autorisant l'utilisation de LLMs openweights non-opensources, ce n'est pas simple.

      En IA, actuellement, tout est surtout question de puissance de calcul. J'ai deux Nvidia RTX 2000 ADA 16go. Mais même avec 32go de VRAM, et je peine à trouver des modèles qui tournent sur mon matériel et qui tiennent la route. Et ironiquement, mes cartes valent 50% plus chères que quand je les avais achetées.

      Avec opencode, le seul LLM openweight que j'ai trouvé qui tienne à peu prêt la route en terme de résultats est devstral-small-2:24b-instruct-2512-q8_0 (fait par notre chère boite Mistral, cocorico !). Mais soit j'utilise un petit contexte, et opencode passe son temps à recompacter le contexte (leeennnt), soit le modèle et son contexte débordent de mes cartes graphiques et font travailler le CPU+RAM (leeennnt). Du coup, quoique je fasse, c'est lent.

      À ces problèmes, on peut rajouter Nvidia, qui vient d'arrêter le support de ses cartes graphiques Pascal dans ses pilotes. Or, en terme de capacité de calculs, ces cartes sont encore parfaitement utilisables pour de l'inférence (obsolescence programmée ?).

      Et dans tous les cas, on est très très loin des résultats actuels d'un Claude Opus 4.6 :-(

  • # fun fact

    Posté par  . Évalué à 10 (+10/-0).

    Et pourtant, Claude - car j'espère que Anthropic utilise son produit - ne sait toujours pas compter :

    • aller sur https://claude.com/pricing#api => opus 4.6 à 5$/MT in, 25$/MT out
    • cliquer sur "Save 50% with batch processing" => opus 4.6 à 3$/MT, 15$/MT out

    y a déjà un petit soucis, d'arrondi peut être

    • cliquer sur "Save 50% with batch processing" pour enlever l'option => opus 4.6 à 6$/MT in, 30$/MT out

    oupsi!

    Et c'est la page prix, sûrement la deuxième page que tout visiteur va voir, pas une page au fin fond du site.

    La bonne nouvelle pour eux, c'est qu'ils auront moins de problème d'arrondis quand ils afficheront les vrais prix, que réclameront les investisseurs : >10x.

    En attendant la première dose est (quasi) gratuite.

    • [^] # Re: fun fact

      Posté par  . Évalué à 4 (+2/-0). Dernière modification le 23 mars 2026 à 15:40.

      Génial ! Par curiosité, je suis allé voir et le javascript est lisible :

              // Function to update prices within this section only
        function updatePrices(showDiscount) {
          priceElements.forEach(element => {
            const fullPrice = parseFloat(element.dataset.value);
            if (!isNaN(fullPrice)) {
              // Add updating class for animation
              element.classList.add('updating');
              // Update price after short delay for smooth transition
              setTimeout(() => {
                const newPrice = showDiscount ? fullPrice / 2 : fullPrice;
                element.textContent = formatPrice(newPrice);
                // Remove updating class
                element.classList.remove('updating');
              }, 150);
            }
          });
          // notify location-based-pricing (or any other script) that prices changed
          setTimeout(() => {
            document.dispatchEvent(new CustomEvent("batch-prices-updated"));
          }, 160);
        }

      Ce n'est pas cette fonction qui est en cause puisque la division est correcte et les prix sont correctement affichés pendant un court moment. Le problème n'est pas beaucoup plus loin… C'est 160 ms plus tard, lors de l'évènement, on vient appeler la fonction applyRate() qui casse la division.

      • [^] # Re: fun fact

        Posté par  (Mastodon) . Évalué à 3 (+0/-0).

        Ce n'est pas cette fonction qui est en cause puisque la division est correcte

        On dirait qu'elle s'applique sur un type entier et que du coup 5÷2… répond 3 !

        J'ai pas lu le JS mais c'est ce qu'il semble à observer le comportement de la page.

        En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

        • [^] # Re: fun fact

          Posté par  . Évalué à 3 (+1/-0).

          Nope

          qjs > fullPrice = 5;
5
qjs > fullPrice / 2
2.5

          Mais @nico4nicolas, quand on triture un peu le switch, on voit apparaître subrepticement 2.50 et ensuite c'est remplacé par 3. Donc je pense que ça n'est pas dans cette fonction. Mais je ne mettrai pas le nez du code JS de LLM pour savoir où.

          Cela dit pour 3.5B$ - oui parce que c'est devenu l'unité de base du capital - je veux bien aller debugger du JS pour Anthropic, car je suis vénal.

  • # Et dans quelques années....

    Posté par  . Évalué à 10 (+8/-0).

    … tu risques d'avoir perdu pas mal de maîtrise

    • [^] # Re: Et dans quelques années....

      Posté par  . Évalué à 3 (+7/-7).

      C'est pas plutôt qu'il aura changé de métier, ce qui en soi est un peu la logique du truc?

      Prends par exemple l'arrivée des calculatrices. Tu étais ingénieur, et tu passais une proportion non-négligeable de ton temps à faire des calculs à la main, éventuellement avec des conversions log pour transformer les multiplications et les additions.

      Quelques années plus tard, est-ce que tu auras perdu de la maitrise? Très probablement, tu iras moins vite pour faire les divisions et les additions à la main, éventuellement tu ne sauras plus refaire des calculs que tu faisais en routine avant (extraire des racines carrées, par exemple). Pire, les jeunes recrutés ne sauront même plus faire. Et tu croiseras des vieux croutons qui te diront "mais comment feras-tu le jour où tu n'auras plus ces machines sous la main"? C'est vrai, le jour où tu n'auras pas de calculatrice sous la main, tu seras bien embêté pour calculer à la main une racine carrée, et tu seras bien moins efficace pour faire 25 divisions sans te tromper. Tout ça est parfaitement juste.

      Mais en réalité, cette situation n'arrivera jamais. Pire, elle sera de moins en moins à même d'arriver, puisque cette histoire particulière nous montre qu'il nous arrive de moins en moins souvent de devoir réaliser nous-mêmes une opération (à la main, à la calculatrice, etc), parce que les opérations sont de plus en plus abstraites et imbriquées dans des algorithmes "tout faits", disponibles via des dépendances ou des bibliothèques; et qu'en parallèle, nous avons de plus en plus de calculatrices disponibles partout autour de nous (trucphones, tablettes, assistants vocaux…). Nous avons donc perdu une compétence devenue inutile, mais c'est sans conséquence.

      Je trouve que la question qui est intéressante, c'est celle de l'utilité de l'apprentissage, pour le développement de notre cerveau et pour notre adaptabilité. Actuellement, les enfants apprennent toujours à faire des multiplications à la main, avant de confier ces tâches à des machines. Mais ils n'apprennent plus l'utilisation des tables de log ni l'extraction de racines carrées. Qu'est-ce qu'on est prêts à abandonner totalement à la technologie, et quels sont les savoirs fondamentaux qu'on souhaite garder? On a collectivement "désappris" à faire du feu avec des cailloux, à atteler un cheval, à parler latin, à écrire avec une plume, à filer la laine, à broder, à s'orienter aux étoiles… Il faut forcément faire des choix. Là, tu sembles partir du principe qu'il est évident que perdre la faculté de coder soi-même serait une sorte de chose négative à plus ou moins long terme, mais rien n'est moins sûr.

      • [^] # Re: Et dans quelques années....

        Posté par  (site web personnel) . Évalué à 10 (+12/-0).

        Prends par exemple l'arrivée des calculatrices. Tu étais ingénieur, et tu passais une proportion non-négligeable de ton temps à faire des calculs à la main, éventuellement avec des conversions log pour transformer les multiplications et les additions.

        Je comprendrai jamais cette comparaison. Il y a une galaxie entre comparer un calcul à la main et à la calculatrice contre écrire du code et le générer hein.

        À la rigueur, je veux bien que tu compares du code écrit sans auto complétion, sans couleur, sans warnings et sans debugger avec un boulanger qui pétrit sa pate à la main vs au pétrin électrique.

        La calculatrice elle invente rien. L'IA elle invente beaucoup et parfois des conneries. En plus, la calculatrice n'émet pas des giga tonnes de CO2 par an à chaque calcul.

        AI is a mental disorder

      • [^] # Re: Et dans quelques années....

        Posté par  . Évalué à 10 (+11/-0). Dernière modification le 23 mars 2026 à 20:09.

        Quelques années plus tard, est-ce que tu auras perdu de la maitrise? Très probablement

        On ne perd pas que la maîtrise, on perd aussi du plaisir. Enfin peut-être pas tout le monde mais ce qui est décrit dans le précédent lien est réel de mon côté : c'est tout simplement moins gratifiant de récupérer/tester le travail du LLM. Le patron de Replit a dit qu'être développeur serait un handicap dans le futur et peut-être qu'il a raison (enfin il a un intérêt évident à affirmer ce genre de trucs vu qu'il vend une solution de "vibe coding")… Je suis dev, j'aime coder, et ça perd de son intérêt si c'est la machine qui le fait à ma place. Surtout si il ne nous reste que la revue de code, la partie la plus chiante. Quand je pense à mes (trop nombreux) side-projects, je suis carrément moins excité en m'imaginant guider un LLM que quand je pense aux solutions techniques que JE pourrais mettre en place. Faut avoir une mentalité de Startupper Linkedin pour prendre son pied avec ces trucs. Ce qui ne retire rien à leurs capacités, au contraire. Plus ils sont bons, plus le job deviendra chiant.

        Amjad Masad, CEO de Replit : “Not having coding experience is becoming an advantage, because coders get lost in the details. Product people — people who are focused on solving a problem, on making money — they’re going to be focused on marketing, they’re going to be focused on user interface, they’re going to be focused on all the right things.”

        • [^] # Re: Et dans quelques années....

          Posté par  (site web personnel, Mastodon) . Évalué à 10 (+11/-0).

          Wow. Cette citation est tellement symptomatique du problème (aucune idée de ce qu'est "Replit" et j'ai même pas envie de chercher; clairement encore un "produit" vide et sans âme).

          En gros, le gars dit "le problème des développeurs, c'est qu'ils essaient de faire les choses bien et un bon logiciel" (traduction par mes soins du discours "bullshit marketing"! Même pas besoin d'IA pour traduire les marketeux, je suis trop fort!). Mais c'est bien sûr! Quelle idée de vouloir faire bien!

          Alors que le "marketing", clairement ça rentre dans "all the right things". On peut reformuler cela par: les "product people", ils se concentrent sur le fric, le blé, le flouze, l'oseille, le pognon… Toutes les trucs importants quoi! 🤦

          Le fait que ces gens sont maintenant totalement décomplexés pour sortir de genre de citations débiles et qu'il y a forcément des gens dans ce monde qui lisent cela en hochant de la tête "mais c'est bien sûr", ça me chagrine bien sur l'état de notre société.

          Film d'animation libre en CC by-sa/Art Libre, fait avec GIMP et autre logiciels libres: ZeMarmot [ http://film.zemarmot.net ]

  • # Mes premiers pas

    Posté par  (Mastodon) . Évalué à 10 (+12/-0).

    Je commence à peine à jouer avec Claude Code (entendre : lui laisser les clés du camion et le regarder coder/tester) et je suis rapidement tombé dans un très gros piège : il code vite, plutôt bien, mais la quantité de code qu'il te refile à relire est gigantesque.

    Au début (je le fais travailler par jalons avec un ensemble de fonctionnalités nouvelles à chaque fois) tu te disciplines, tu relis ce qu'il fait, tu lui demandes de modifier.

    Mais quand il met 5mn à pondre le code, tests compris, et que toi tu pars sur 20-30mn de relecture et de modifs, c'est dur de se persuader que c'est productif. Pas dans le sens où j'aurais tout écris en 30mn moi-même, pas du tout, mais ce rapport complètement déséquilibré entre le codage et la relecture, bin… on n'est pas habitués.

    Et à la fin, je le laissais tout faire, résultat j'ai pris des milliers de lignes de code (qui marchent plutôt bien, aucun soucis là dessus) sans finalement les relire.

    Alors dans mon cas où c'est hors taff et justement à titre d'évaluation du vibe coding et je m'amuse avec un projet que j'avais en tête depuis des lustres, c'est rigolo à constater, mais j'ai peur que sur des cas plus sérieux la situation soit la même : même avec la meilleure volonté du monde, au bout d'un moment, tu vas plus relire, plus "critiquer" et bouffer à grande vitesse la quantité gigantesque de code produit.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

  • # Quand on parle de ces IA génératives, je me demande...

    Posté par  . Évalué à 9 (+7/-0).

    À quels besoins ces quantités de code, images, textes, videos, etc. produites en quantités exponentielles vont-elles répondre ? Comment cela va-t-il améliorer nos vies ?

  • # code review fatigue

    Posté par  (Mastodon) . Évalué à 10 (+13/-0). Dernière modification le 23 mars 2026 à 17:35.

    Les LLM c'est fascinant, ça brosse les gens dans le sens du poil parce que ça les aide à se sentir comme un boss. Tu donnes des ordres, les agents s'exécutent sans rechigner. J'assimile ça à de la masturbation mentale pour une population frustrée de son statut de salarié qui ne se rend pas compte qu'elle est en train de scier la branche sur laquelle elle est assise.

    Derrière la posture naïve je fais des revues de code, donc tout va bien, on sait pourtant ce qui se passe au final.

    Les projets ont des deadlines, les parties prenantes s'impatientent pour la sortie de telle ou telle fonctionnalitées, avance-rapide vers quelques mois/années plus tard, de la même manière que du code est parfois mal torché parce que fait rapidement, les revues de codes seront de moins en moins appronfondies. On entend déjà parler d'équipes qui multiplient les agents avec des modèles différents avec l'idée que que ce soient des agents LLM qui fassent les revues de code. Claude code, Gemini écris les tests et GPT review. On se plaint de l'enshittification, que pour charger un simple article de journal on télécharge des tonnes pour afficher trois fois rien et qu'il faille des gigas de mémoires pour faire des trucs qu'on faisait avant avec un pentium 100Mhz et 32MB de mémoire, ça ne va pas s'améliorer.

    Bientôt le dev qui s'était glaussé sur linuxfr d'être devenu orchestrateur va aussi disparaitre puisqu'on demandera directement un agent de trier les tickets, décider des prioritées et déléguer aux autres agents. Des architectes, pourquoi faire si on a un agent? Pareil pour la gestion des coûts. Chouette, les projets vont se multiplier, tout le monde va devenir product owner!

    La seule chose que je ne suis pas sûr c'est si les dev vont vraiment disparaître, ou si dans quelques années on va les appeler à la rescousse pour nettoyer la merde en espérant qu'ils se rappellent comment ils s'appellent.

    • [^] # Re: code review fatigue

      Posté par  . Évalué à 7 (+5/-0).

      J'assimile ça à de la masturbation mentale

      Je crains malheureusement que les personnes que tu désignes ne soient pas toutes consentantes.

      Je pense plutôt que la plupart sont victimes des stratégies de management : fantasme de la productivité 10x, sélection de profiles "AI compatibles".

  • # Comme j'aurais aimé naître dans les années soixante

    Posté par  (site web personnel, Mastodon) . Évalué à 10 (+14/-0).

    On est tous atteint que l'on veuille ou non par cette omniprésence de l'IA générative. Je ne pense pas que ton employeur soit visionnaire car il n'est de loin pas le seul à avoir pris cette direction qui, d'après ce qu'on dit aujourd'hui, est là seule bonne direction pour survivre face à la concurrence.

    Ce que je constate maintenant c'est une grande naïveté, de la stupidité, de la maladresse et tout ce que j'oublie…

    Je suspecte, chez nous, des fuites de clefs API chez Anthropic et OpenAI à cause de l'utilisation naïve de ces applications comme Copilot, Claude Code, Warp et autre chenis (terme suisse) du genre, outils non-libres qui exploitent des services non-libres chez qui on sait. Je tente néanmoins d'alerter sur ce point mais je doute de cette prise de conscience dans toute l'entreprise. "Il faut se détacher des ricains.." oui oui c'est ça.. bla bla bla…

    Je constate déjà de la perte de maîtrise quand il y a une panne chez Antropic, avec des collègues qui "attendent" sur la page de statut que tout redevienne en ordre. Pathétique…

    Je vois de la flemmardise à demander à confirmer tout le temps à Copilot qu'il à le droit de faire ceci ou cela en lui activant l'auto-approve (YOLO mode). Ahahah (je ris jaune).. non mais sérieux.

    Je vois des boucles d'écriture de spécifications à parler comme un con avec un programme (l'IA ici) pour soit disant de plus jamais écrire de code sois même (AI first hype). Déjà les OS qui disent "Bonjour" quand il se lance ça me casse les c*******, là c'est le fond du bac.

    Je vois des idioties comme demander à Copilot d'effacer un fichier plutôt que de faire un rm (pardon, del il y a encore tant de monde sous Windaube). J'aime imaginer toute la machinerie qui se passe, du prompt envoyé chez Antropic pour se faire inférer dans des modèles surdimensionné (dans un joli datacenter écolo.. ahah.. uhm) avec un retour par chez nous pour enfin, effacer le fichier. N'est-ce pas beau le progrès ? La killing feature.

    Je suis rassuré quand je vois des fautes d'orthographes. Ouf, un humain m'a écrit un mail. Ah je respire un peu d'air.

    Je sent que l'on me met toujours plus de pression pour que je rentre dans ce moule qui n'a absolument pas une forme adaptée pour moi et mes principes. J'essaie de rappeler qu'il n'y aura jamais de conscience émergente à une grosse fonction binaire et impure (une IA si vous ne me suivez plus) et que tout ceci ce n'est que de l'illusion d'intelligence qui devient de plus en plus crédible et qui rend con. "Oh, je parle à mon mari qui est décédé à travers une app sur mon smartphone" (c'est une citation hein…).

    Je rappel qu'on n'est pas souverain de tous les outils. On a bien une infrastructure pour faire de l'IA chez nous pour certains service (96GB VRAM, cool). Mais face à Claude c'est compliqué à rivaliser.

    Alors oui, j'utilise aussi de l'IA. Je l'utilise comme un super manuel, un prof. J'essaie d'apprendre et de progresser par son biais. Quand elle fait mieux que moi, je veux qu'elle m'explique pourquoi car sinon je ne progresse pas. J'ai aussi fait de la m***** avec et j'ai finis par détruire la plupart des comptes que j'avais chez les gros fournisseurs IA.

    Finalement c'est une question fondamentale. A quoi sert cette vie si ce n'est que pour augmenter la productivité d'une entreprise pour faire de l'argent à tout prix. Est-ce bien ce que l'on souhaite ? Juste travailler pour le salaire et vite tout boucler une fois que les heures sont faites ? Ce n'est pas ce que je veux. J'aime écrire du code, j'aime faire de la recherche et du développement, j'aime faire des erreurs dans mes développement et en sortir meilleur après. Ce que je sais aussi c'est que je déteste depuis toujours l'humanisation des machines. Je déteste les robots qui ressemblent à des humains, que ce soit physiquement ou simplement comme outil en ligne de prompt. Alors oui, ces LLMs sont très performants, mais je m'en fiche qu'il fasse de meilleur requêtes SQL que moi, où qu'ils pondent du code Rust que je ne comprend pas et qui fonctionne. Il y a toujours eu meilleur que moi avant et sans IA. Mais ici quand il le fait, alors il doit m'expliquer ce que je n'ai pas compris. Alors je suis à contre courant, alors je perd trop de temps, alors je deviens de moins en moins productif. Et pourtant j'ai pas mal d'expérience depuis au moins un bon quart de siècle. Mais ça.. combien de temps ça aura du poids ?

    Alors à quoi tout ça peut bien servir ? Juste à de grosses entreprises à faire du pognon, non ? Mais m**** à la fin. J'écris des outils pour les gens, mais ces gens sont eux même en train d'être remplacés par des IA (ah oui parce qu'il ne faut plus rédiger de mail pour répondre aux clients qui sont encore humains, il faut tout passer ça dans une IA; moi je trouve ça insultant et bien triste). Alors on écrit gentiment mais sûrement de plus en plus d'outils pour les IA. Et surtout on utilise des IA pour faire les outils pour les IA. Mais tout ceci c'est de la m****; ce qui compte ce sont les gens, les humains. On est censé répondre à des vrais besoins humains. J'en ai rien à faire des besoins des IAs.

    Alors je résiste à l'AI first. Avec cette attitude je vais peut être perdre mon job, mais finalement c'est peut être pas plus mal ? Je ferai autre chose de ma vie, quelque chose qui a du sens pour moi et les vrais personnes, et je continuerais à programmer pour mon propre plaisir car c'est aussi mon hobby.

    Mais attendez, aujourd'hui "vous" jouez aux orchestrateurs et aux rédacteurs assistés de spécifications. Mais dans pas longtemps on aura plus besoin de vous pour le faire. Tout ça semble bien éphémère.

    Bon sang, comme j'aurais aimé naître dans les années soixante (pour l'essor de l'informatique).

  • # La revue de texte chez les traducteurs

    Posté par  . Évalué à 5 (+3/-0).

    https://www.mediapart.fr/journal/economie-et-social/230326/les-traducteurs-d-arte-denoncent-la-destruction-de-leur-metier-par-l-ia

    cantonnant les traducteurs à un fastidieux travail de « post-édition », payé moitié moins.

  • # Zoologie intéressante

    Posté par  (site web personnel) . Évalué à 3 (+2/-0).

    Commentaires très intéressants.

    J'observe que les devs moules ici présentes sont mitigées sur l'utilité réelle de ces satanés agents. Nous avons 18-24 mois de recul et les avis restent partagés. Attendons de voir l'évolution du legacy vide codé ?

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.