Utiliser l’IA ou non

 (antropia.studio)
5 points par GN⁺ 2025-10-01 | 2 commentaires | Partager sur WhatsApp
  • Une expérience a été menée pendant deux semaines pour créer une application uniquement avec un workflow de développement assisté par IA, mais le résultat s’est révélé moins satisfaisant qu’espéré
  • Une boucle définition des issues → implémentation par l’IA → revue de code → déploiement a été répétée avec une stack basée sur Claude Code et Remix
  • Mais la frustration a progressivement augmenté à cause d’un manque de contexte, de duplication de code non réutilisable, de ruptures de flux, d’hallucinations, et du problème lié à la loi de Pareto
  • Au bout de deux semaines, le développement centré sur l’IA a finalement été abandonné, avec un retour à la méthode classique, apportant davantage de satisfaction grâce au nettoyage du code et à l’amélioration de la qualité
  • Aujourd’hui, l’IA n’est plus utilisée que pour des usages limités comme la recherche, le rubber ducking, les snippets de code, les tests et la correction linguistique, sans projet d’élargir cet usage avant un changement technologique de fond

Aperçu de l’expérience

  • Une expérimentation de deux semaines de développement d’application a été menée en appliquant directement un workflow de développement autour des LLM (grands modèles de langage), très en vue récemment
  • En s’appuyant sur l’expérience d’une UI complexe de compte Facebook Ads, le développement d’un prototype adbrew, un outil simplifié de gestion publicitaire reposant uniquement sur l’API Facebook Ads, a été lancé
  • L’expérience a été menée avec l’objectif de vérifier le potentiel de l’IA et l’espoir qu’elle puisse résoudre un problème concret

Approche

  • Suivi de divers comptes liés à l’IA, étude de workflows, puis choix d’une stack technique en Remix/React Router v7
  • Après avoir souscrit à Claude Code, du temps a été consacré à la mise en place initiale : prompts, configuration des outils DX, définition des issues, etc.
  • Routine quotidienne
    • Définition des issues
    • Demande d’implémentation à l’IA
    • Ajustement des exigences avec l’IA
    • Revue détaillée du code généré
    • Commit/déploiement du code
    • Répétition du processus
    • Amélioration périodique des consignes et des fichiers de vérification automatique
  • Des efforts continus ont été faits pour aligner le flux de développement sur celui de l’IA

Problèmes fréquents

  1. Le contexte est toujours insuffisant
    • Même avec beaucoup de contexte fourni, l’IA ne demandait pas le retour nécessaire
    • L’IA avançait en faisant ses propres hypothèses, ce qui conduisait fréquemment à des implémentations erronées
  2. Réutilisabilité du code et maintenance impossibles
    • Faiblesses sur l’abstraction et la production de code réutilisable
    • Génération répétée de composants existants, augmentant la fatigue liée aux revues
    • Effet très limité des consignes intégrées
  3. Rupture du flux de travail
    • Le travail de l’IA nécessitait une surveillance continue
    • Difficile d’obtenir de véritables plages de concentration efficaces par issue, avec une baisse de productivité
  4. Phénomènes d’hallucination
    • Combinés à la complexité de l’API Facebook, à une documentation insuffisante et à un SDK mal typé, les fausses certitudes de l’IA ont accentué la confusion
    • L’IA a généré à plusieurs reprises des informations erronées sur divers frameworks et bibliothèques
  5. Aggravation de l’effet Pareto
    • L’IA pouvait faire rapidement 80 % du travail, mais les 20 % restants de finalisation et de correction demandaient 80 % des efforts
    • De nombreux défauts et bugs majeurs apparaissaient dans la gestion des exceptions ou les interactions entre fonctionnalités

Résultats et retour d’expérience

  • Après deux semaines, le code devenait de plus en plus désordonné et incontrôlable
  • La perte de plaisir dans le développement et les problèmes de qualité ont conduit à un retour au workflow traditionnel
  • En réorganisant ensuite le code manuellement, des éléments manqués lors des revues faites avec l’IA ont été découverts, permettant au final d’obtenir une base de code meilleure

Manière actuelle d’utiliser l’IA

  • Moteur de recherche puissant : efficace pour explorer des informations complexes et obtenir des réponses adaptées au contexte, avec possibilité de revenir rapidement aux méthodes classiques en cas d’échec
  • Rubber ducking (brainstorming d’idées) : particulièrement utile pour proposer des alternatives, élargir le champ d’exploration et renforcer la recherche de mots-clés liés
  • Assistant de snippets de code : réduction de la fatigue de développement via l’automatisation de la création de fonctions utilitaires répétitives
  • Aide au code de test : usage de l’IA pour découvrir de nouveaux scénarios de test
  • Travaux liés au langage : utile pour l’édition de texte, comme les messages de commit, les issues ou les PR
    • Récemment, une inversion s’est produite : au lieu que l’IA rédige, le développeur écrit et l’IA relit

Conclusion et perspectives

  • L’usage de l’IA se poursuit pour l’assistance dans les tâches quotidiennes, mais une extension vers une délégation de l’ensemble du processus de développement est, à ce stade, envisagée négativement
  • Des efforts sont en cours pour privilégier les LLM locaux et garder le contrôle des données
  • L’attention reste portée sur de possibles évolutions technologiques futures, mais, à ce stade, l’intention est de maintenir un usage limité de l’IA

À lire aussi

2 commentaires

 
shakespeares 2025-10-06

C’est un inconvénient que je ressens très souvent quand je travaille sur des tâches complexes.
Perte de plaisir + code en désordre..
J’ai vraiment souvent l’impression que ce n’est pas très adapté à autre chose que le refactoring de code et l’usage pour générer des idées.
 
GN⁺ 2025-10-01
Avis Hacker News

  • J’ai récemment passé plus d’une heure à essayer d’obtenir de ChatGPT une commande rsync très simple, mais il continuait à fournir des paramètres qui ne fonctionnaient pas avec la version de rsync présente sur mon Mac. Environ la moitié de l’échec venait du fait qu’il s’enfonçait dans un dépannage absurde, et l’autre moitié du fait qu’il prétendait avoir « réalisé » son erreur tout en donnant encore une mauvaise réponse liée à une autre version. Je lui ai demandé de vérifier les paramètres pour qu’ils correspondent à ma version, mais il n’a clairement pas réussi à le faire. En réalité, seul, j’aurais réglé ça en cinq minutes, mais j’ai continué à regarder cette technologie fascinante me faire perdre mon temps. Je ne suis pas développeur professionnel, mais je me demande si ce genre d’expérience est aussi courant chez les développeurs. Peut-être qu’on évite ce problème quand on code avec des versions logicielles proches du principal jeu d’entraînement des LLM, et je me demande aussi s’il existe un moyen de l’éviter via le prompt. Pour l’instant, j’ai du mal à voir en quoi les LLM font réellement gagner du temps sur des tâches de code ; à cause de leur caractère bizarre, j’ai plutôt l’impression qu’ils en font perdre davantage.

    • Même quand je demande à un LLM de vérifier les paramètres adaptés à ma version, il ne le fait pas correctement. J’aimerais avoir l’avis de spécialistes de l’IA là-dessus. J’ai souvent ce genre d’expérience moi aussi. Au final, un LLM ne comprend pas vraiment ce qu’on lui dit ; mathématiquement, on peut même expliquer pourquoi. Cela dit, on dirait aussi que des techniques comme les transformers ou d’autres astuces ont été ajoutées pour des tâches un peu moins embarrassantes que compter les lettres. Je me demande si quelque chose m’échappe.

    • Ce genre d’expérience est très courant chez les développeurs aussi. Certains diront peut-être « ça ne m’est jamais arrivé », mais ce sont de très rares exceptions, et la plupart des gens se plaignent de choses similaires. Vous avez aussi demandé si on pouvait éviter ce problème avec un prompt ; si l’information n’est pas dans les données d’entraînement, cela ne sert à rien. Dans beaucoup de langages, les LLM sont vraiment médiocres. Pour les outils CLI, même si on indique au LLM qu’on est sur macOS ou sur une version BSD, il donne souvent quand même des flags GNU. Surtout que rsync a récemment changé sur macOS, donc il y a peu d’informations en ligne ; voir ce lien article sur le remplacement de rsync. Et l’idée même que les LLM vont faire gagner du temps en programmation, c’est déjà le best case. À l’inverse, il arrive aussi très souvent qu’on fasse trop confiance au code généré par LLM et qu’on le committe, ce qui introduit des bugs ou des failles de sécurité. Références : blog ai-coding-slowdown et article arXiv

    • Pour la question de savoir si un prompt permet d’éviter ce problème, je ne sais pas trop, mais dans Claude Code on peut exécuter directement des commandes. Autrement dit, au lieu de laisser le LLM tout imaginer, il suffit d’ajouter au contexte la vraie sortie de commandes comme ! man rsync ou ! rsync --help.

    • Je me demande pourquoi utiliser un LLM quand on cherche simplement le manuel d’un outil précis.

    • Concernant le fait d’avoir passé plus d’une heure à essayer d’obtenir une simple commande rsync avec ChatGPT : j’essaierais plusieurs fois en ajoutant suffisamment d’informations sur l’environnement et les messages d’erreur, puis, si ça ne marche toujours pas, je testerais d’autres modèles comme Claude ou Gemini. Si après un nombre d’essais prédéfini ça ne se résout pas, alors il sera difficile d’obtenir de l’aide du LLM, donc autant arrêter et chercher l’information via les méthodes classiques, comme les manuels ou les forums : ce sera bien plus rapide. En général, essayer 10 à 20 minutes avant de passer à autre chose est une limite réaliste. Il y a des problèmes que les LLM ne résolvent tout simplement pas, même après de longues tentatives ; ils tournent juste en rond.

  • J’ai moi aussi souvent ce genre d’expérience. L’IA est vraiment utile quand je lui fais faire des tâches que je sais déjà faire moi-même. Si je peux décrire le problème avec assez de précision pour qu’un LLM le comprenne, il produit des résultats corrects, et je peux vérifier immédiatement si le code généré correspond à ce que je veux. Si je lui confie quelque chose que je ne connais pas du tout, ça devient au contraire plus compliqué.

    • Je trouve que cet article (à part le titre) a une vision assez équilibrée. Le mode « confiez tout aux LLM ! » est bourré de problèmes ; en revanche, leur déléguer du code répétitif qui fait gagner du temps ou une partie du code de test, c’est plutôt pas mal. Mais évidemment, avec un titre banal du genre « l’IA marche parfois, et parfois non », impossible de faire des vues.

    • L’IA ressemble plus à un stagiaire qu’à un prestataire externe.

  • Je me reconnais énormément dans l’idée que « le contexte ne suffit pas ». Même si on fournit énormément d’éléments, l’IA ne demande pas de retour et part le plus souvent sur ses propres suppositions jusqu’à échouer. Ça me rappelle une scène d’une série télé où quelqu’un formule un vœu à un génie et discute comme un avocat pour vérifier minutieusement toutes les conditions. Parler à un LLM donne un peu la même impression.

    • L’IA ressemble à ce collègue extrêmement intelligent qui ne dit jamais ce qu’il pense. On a l’impression qu’il pourrait tout faire, mais il est incapable de travailler en équipe, et une phrase comme « je ne comprends pas ce que tu veux ici, peux-tu m’expliquer un peu plus ? » ne sort jamais d’une IA.

    • (Je crois voir de quelle scène TV vous parlez.) Dans cette scène, tout finit par bien se passer, mais j’ai l’impression qu’un LLM ne ressent absolument aucun besoin de respecter sa « promesse ». Le génie, lui, ressemble plutôt à une IA classique de science-fiction, corsetée par des règles et des contraintes. Un LLM, c’est tout autre chose.

  • Je n’aime pas trop le vibe coding, c’est-à-dire communiquer avec l’IA plutôt que coder réellement. En revanche, ce que j’ai surtout changé, c’est que je structure davantage le processus de développement dès le départ. J’écris d’abord un fichier de spécification, puis je demande au LLM de découper, à partir de la base de code et d’informations en ligne, les points à clarifier dans les exigences et les étapes d’implémentation sous forme de checklist pas à pas. Je ne passe à la session suivante qu’une fois chaque étape terminée, afin d’augmenter progressivement le niveau de finition. Et si la conversation avec l’IA devient fatigante, moi ou un membre de l’équipe pouvons toujours implémenter directement selon la spec, donc c’est une utilisation assez flexible.

  • J’ai récemment introduit le AI coding sur un projet. Je ne sais pas exactement ce que recouvre vibe coding, mais l’approche que j’ai choisie est une interaction itérative et détendue. J’ai utilisé Gemini AI Studio et j’ai été très satisfait du résultat, au point de documenter tout le processus et de le publier en open source. Ça a donné un vrai boost à ma productivité. Le point le plus frustrant, c’est que l’IA parle de manière excessivement polie. À mon avis, l’IA offre le meilleur ROI quand le résultat attendu est clair et qu’il faut comparer des options au cours du processus. Je l’ai utilisée pour tous les livrables du projet (code cœur, cas de test, scripts de build, documentation, application d’exemple, utilitaires). L’historique complet des échanges de développement est disponible ici, et le code source du projet ici.

  • J’utilise l’IA d’une manière assez proche. Attendre d’elle des abstractions révolutionnaires, c’est en demander trop. En revanche, elle fonctionne bien sur des chemins tout à fait ordinaires, déjà parcourus par des milliers de développeurs. En ce sens, cela ressemble à un moteur de recherche extrêmement puissant.

    • Je pense que ChatGPT est en fait le moteur de recherche que Google aurait dû construire lui-même. À mon avis, Google a retardé cela parce qu’il ne voulait pas perturber son activité existante.

  • Ma façon préférée de faire consiste à demander au LLM une première solution ou un exemple de code, puis à reprendre moi-même sans continuer à affiner les prompts. À la fin, si besoin, je lui fais relire mon code. Le plus grand avantage, c’est d’éviter la boucle d’affinage des prompts. Cette boucle est vraiment pénible, prend énormément de temps, et à long terme elle peut même réduire l’efficacité du travail.

  • Le fait que l’IA avance sans feedback ni questions de clarification est vraiment frustrant.

  • Je rapporte l’avis de mon équipe : « Pour l’instant, on n’utilise l’IA que jusque-là, et si la technologie évolue de manière fondamentale, on réévaluera la situation. » Je me demande jusqu’où les LLM pourront aller au-delà de ça. Je pense qu’ils sont déjà très utiles quand on sait bien les exploiter.

    • Je ne comprends pas le doute sur la capacité des LLM à faire davantage. J’ai plusieurs nouvelles idées par jour pour améliorer les outils fondés sur les LLM, et la plupart relèvent d’un simple travail d’ingénierie, au point que je pourrais tout construire moi-même si je le voulais. Même si Dieu empêchait réellement d’entraîner de nouveaux modèles LLM, je suis convaincu qu’on pourrait encore obtenir pendant des décennies des gains de productivité multipliés par plusieurs dizaines. Avec de bons processus de développement logiciel et de QA, de simples améliorations d’agentic wrappers ou de pipelines suffiraient à provoquer une forte progression.

  • Utiliser l’IA pour améliorer les Facebook Ads, c’est un peu comme les breakers dans la série Dark Tower.