Mesurer l’« impact de l’IA » sur la productivité de développeurs open source expérimentés

• Une expérience contrôlée randomisée a été menée pour évaluer l’effet des outils d’IA du début 2025 sur la productivité réelle de développeurs open source
• Selon l’étude, l’utilisation d’outils d’IA allonge en moyenne de 19 % le temps nécessaire pour terminer une tâche
• Les développeurs s’attendaient à ce que l’IA les rende 24 % plus rapides, mais contrairement à leur ressenti, un ralentissement a été observé
• L’écart entre les capacités de l’IA observées dans les benchmarks et l’expérience quotidienne et ses effets réels ressort de façon très marquée
• L’étude souligne l’importance de comprendre précisément l’impact de l’IA sur la productivité et de recourir à des méthodes d’évaluation variées

---

Aperçu

• Cette étude a mené une expérience contrôlée randomisée (RCT) afin de vérifier l’impact des outils d’IA du début 2025 (Early-2025) sur la productivité de développeurs open source expérimentés
• Contrairement aux attentes, il a été constaté que les développeurs mettaient 19 % de temps en plus lorsqu’ils utilisaient des outils d’IA
• Ce résultat peut être interprété comme un exemple de mesure de l’impact réel de l’automatisation de la recherche par l’IA sur le développement logiciel
• Les auteurs indiquent vouloir s’appuyer sur cette méthodologie pour continuer à estimer les effets réels de l’accélération de la R&D en IA

Motivation de l’étude

• Les benchmarks de coding/agents existants ont pour limite de ne pas refléter suffisamment les situations de travail réelles
  • En raison de tests conçus en interne, de tâches isolées sans contexte ou encore d’un schéma de notation automatisé, ils peuvent surestimer les capacités de l’IA
  • À l’inverse, en l’absence d’intervention humaine adaptative, il est aussi possible de sous-estimer les performances réelles des modèles d’IA
• Pour compenser ces limites, l’étude mesure l’impact concret de l’IA en expérimentant ses effets sur la productivité réelle de développeurs open source

Méthode expérimentale

• 16 développeurs open source chevronnés ont été recrutés, et 246 issues réelles ont été sélectionnées dans de grands dépôts sur lesquels ils travaillaient depuis des années (en moyenne plus de 22 000 étoiles et plus d’1 million de lignes de code)
• Pour chaque issue, les participants ont été répartis aléatoirement dans un groupe avec IA autorisée ou avec IA interdite
• Lorsque l’IA était autorisée, les développeurs pouvaient utiliser librement Cursor Pro ainsi que les modèles les plus récents comme Claude 3.5/3.7 Sonnet ; lorsqu’elle était interdite, ils devaient travailler sans aide d’IA générative
• Les participants ont enregistré leur processus de résolution pour chaque issue (en moyenne 2 heures) et ont déclaré eux-mêmes le temps passé
• Les participants à l’expérience ont été rémunérés 150 dollars de l’heure

Principaux résultats

• Avec les outils d’IA, le temps de résolution des issues augmente en moyenne de 19 %
• Les développeurs s’attendaient à ce que l’IA augmente réellement leur productivité de 24 %, et même après l’expérience, ils ont encore déclaré ressentir un gain de vitesse de 20 %
• Cela met en évidence un fort décalage entre la perception et les performances réelles
• Afin d’éviter certains malentendus, l’étude n’apporte pas de preuve concernant les points suivants :
  • une généralisation selon laquelle l’IA ralentirait tous les développeurs ou l’ensemble du développement logiciel
  • une définition de l’effet de l’IA dans d’autres domaines ou d’autres contextes
  • l’affirmation que ce même résultat se maintiendra dans un futur proche
  • l’idée qu’il serait impossible d’optimiser les LLM existants et les techniques de prompt

Analyse des facteurs d’impact

• 20 facteurs susceptibles d’expliquer le ralentissement ont été analysés, et 5 d’entre eux ont été considérés comme ayant un effet réel
• Il a été confirmé que des variables majeures comme les conditions expérimentales, le modèle, la difficulté des issues ou la qualité des PR n’avaient pas d’effet significatif sur les résultats
• Le phénomène de ralentissement a été observé de manière cohérente dans divers sous-ensembles de données et avec différentes méthodes d’estimation
• Une analyse détaillée est disponible dans l’article scientifique original

Interprétation des résultats et discussion

Conflit entre les éléments de preuve et causes possibles

• L’écart entre les scores de benchmarks IA, les retours de cas d’usage et les résultats expérimentaux réels apparaît nettement
• Les benchmarks mesurent les capacités de l’IA principalement sur des problèmes étroits pouvant être évalués automatiquement
  • SWE-Bench : PR open source fondées sur des tests, RE-Bench : problèmes évaluables de manière algorithmique
• Dans la RCT réelle, sur des tâches complexes et réalistes prenant de 20 minutes à 4 heures, les humains se sont au contraire révélés plus lents
• En parallèle, dans l’industrie ou dans les communautés, il existe de nombreux retours qualitatifs selon lesquels l’IA est très utile sur des tâches longues

Cadre d’interprétation

• Chacune de ces approches a la particularité de mesurer différemment la “capacité réelle”
• Approche par cas :
  • problème de sous-estimation dans la RCT : il peut exister des spécificités propres à notre configuration expérimentale
  • possibilité de surestimation dans les benchmarks/retours de cas : décalage avec la résolution réelle et fiabilité limitée des données auto-déclarées
  • il est possible que les trois approches ne correspondent bien qu’à certaines sous-catégories de problèmes réels
• L’écart entre les différentes sources et le niveau réel de capacité peut s’interpréter comme relevant d’erreurs ou biais de mesure (rouge) et de différences de périmètre de mesure (bleu)

Autres enseignements de l’expérience

• Les résultats de la RCT peuvent ne pas s’appliquer à des environnements où l’on échantillonne les résultats de l’IA des centaines ou des milliers de fois
• Il est possible qu’un gain d’efficacité n’apparaisse qu’après des dizaines à des centaines d’heures d’usage d’outils d’IA comme Cursor
• Dans des environnements avec du code de haute qualité et de nombreuses exigences implicites (documentation, tests, formatage, etc.), les capacités de l’IA peuvent être limitées
• Les benchmarks ont un périmètre de problème étroit et reflètent mal la difficulté du travail réel
• Les retours qualitatifs de ressenti peuvent être moins fiables en raison d’effets de surestimation et d’auto-illusion

• Aucune méthode d’évaluation unique n’étant parfaite, il est nécessaire de les utiliser de manière complémentaire

Perspectives

• Cette méthodologie sera continuellement améliorée afin de suivre quantitativement l’ampleur réelle des changements de productivité induits par les outils d’IA chez les développeurs
• Si les outils d’IA augmentent fortement l’efficacité des développeurs sur le terrain, cela pourrait aussi s’accompagner de risques tels qu’une accélération brutale de l’ensemble de la R&D en IA, des échecs de supervision ou une concentration du pouvoir
• Le développement de cadres d’évaluation adaptés aux environnements réels sera très important pour l’évolution future de l’IA et pour l’ensemble de l’industrie

[odlwlkiime]

150 dollars de l’heure ? Rien qu’à partir de là, le contrôle des variables part en vrille, mdr hahaha

[GN⁺]

Avis Hacker News

• Commentaire de Simon Willison :
  L’article complet contient beaucoup de détails absents du résumé lien vers l’article
  À mon avis, il existe une courbe d’apprentissage bien plus abrupte que ce que les gens imaginent pour obtenir un vrai gain de productivité avec des outils d’IA basés sur les LLM
  Cette étude portait sur 16 personnes ayant des niveaux d’expérience variés avec les outils d’IA, et 56 % utilisaient Cursor pour la première fois ; c’était essentiellement une étude sur Cursor
  Chaque participant a traité environ 15 issues au total, et pour chaque issue, l’usage de l’IA était autorisé ou non de façon aléatoire
  Autrement dit, chaque développeur a travaillé sur un mélange de tâches avec IA autorisée et non autorisée
  Seul un quart des participants a vu ses performances s’améliorer, tandis que les trois quarts ont régressé
  Parmi les plus gros utilisateurs de l’IA, on trouvait surtout des personnes ayant utilisé Cursor plus de 50 heures
  Les chercheurs eux-mêmes reconnaissent que les développeurs ayant une expérience suffisante de Cursor ont vu leurs performances s’améliorer
  Mon intuition, c’est que cet article montre surtout qu’en raison de la forte courbe d’apprentissage du développement collaboratif avec l’IA, l’intégrer immédiatement dans un workflow existant en conditions réelles peut au contraire dégrader les performances

  • On entend souvent à propos des LLM : « c’est juste que tu ne sais pas bien t’en servir », mais ça ressemble à une excuse qui rejette trop la responsabilité sur l’utilisateur
    Pour la plupart des produits technologiques, si l’utilisateur n’en perçoit pas la valeur, j’estime que c’est la conception du produit qui est en cause ; je me demande pourquoi ce raisonnement ne s’applique pas à l’IA

  • Merci Simon, et merci d’avoir lu l’article aussi attentivement — je suis fan des projets OS et je voulais souligner quelques points importants
    1) Certaines études précédentes montrent des gains de performance même avec peu d’expérience de l’outil, donc la théorie de la « courbe d’apprentissage abrupte » n’explique pas à elle seule l’ensemble des résultats ici
    2) Avant l’étude, plus de 90 % des participants avaient déjà une expérience des prompts LLM, et le prompting était considéré comme la compétence principale. L’idée dominante était que si l’on maîtrise VSCode, Cursor s’apprend facilement
    3) Si tout le monde était déjà habitué à l’IA, ils pouvaient au contraire être moins bons sans IA (au moins, ça me parle), ce qui réduit justement un effet d’optique où l’IA semblerait meilleure qu’elle ne l’est
    4) Les informations sur l’expérience ont été partagées à l’avance avec les experts en prévision, et malgré cela, les prévisionnistes ont largement surestimé les gains de productivité attendus
    5) Il est possible qu’il existe réellement une compétence de long terme qui n’apparaît qu’après des centaines d’heures d’usage ; cette étude ne permet pas vraiment de trancher ce point
    Comme l’article donne un résultat surprenant, il est facile pour les lecteurs d’isoler un seul facteur et de conclure « c’est à cause de ça ! »
    En réalité, les causes peuvent être multiples (au moins 5, et jusqu’à 9 ne peuvent pas être exclues ; voir le tableau page 11)
    Une implication vraiment importante : le niveau de satisfaction auto-déclaré par les développeurs était très éloigné de la réalité, indépendamment du type d’outil utilisé
    Pour mesurer la productivité, il faut absolument des données réelles de terrain (voir la section C.2.7 de l’article : « utilisation inférieure à la moyenne des outils d’IA », qui en parle en détail)

  • On peut interpréter cela comme : malgré une expérience des LLM chez 75 % des participants, l’usage de l’IA les a en fait ralentis. Une lecture possible est que la courbe d’apprentissage des LLM est très abrupte ; une autre est que l’efficacité réelle actuelle des LLM comme assistants de programmation est surestimée. Les gens se trompent systématiquement dans leurs prédictions de performance

  • Même lorsqu’on devient bon avec les LLM, il est possible de moins bien comprendre le code qu’on écrit soi-même
    Le développeur maîtrise de mieux en mieux le code avec le temps, alors que le LLM peut au contraire devenir moins pertinent
    On peut générer du code rapidement avec un LLM, mais si l’on n’y prête pas suffisamment attention, on n’accumule pas de vraie maîtrise du code
    Au début, le développement paraît fluide et rapide, mais en coulisses la compréhension reste faible ; et comme le LLM, utile au départ, cesse ensuite de vraiment s’améliorer, on finit un jour avec un code chaotique que ni le LLM ni l’utilisateur ne peuvent encore maîtriser
    Je pense qu’il faut résister à cette tentation, gérer le LLM de façon tenace pour qu’il produise un code plus propre, et étudier soi-même le code. Il faut un effort volontaire de compréhension

  • On voit bien que certains gagnent en productivité avec les outils d’IA, et d’autres non
    Mon hypothèse, c’est que les personnes capables de lire rapidement de longs textes ou du code ont un avantage considérable
    La capacité à repérer vite les suggestions inutiles et à itérer jusqu’à obtenir une bonne réponse est très importante
    Cette capacité de lecture rapide est corrélée à l’expérience, mais on trouve parfois aussi des juniors étonnamment rapides sur ce point
    Les personnes très douées pour la recherche peuvent aussi être avantagées avec les LLM ; cela semble relever de la même logique que l’aptitude à bien googler

• Cela rappelle la règle des 80/20 : l’outil résout 80 % du travail en 20 % du temps, puis les 20 % restants consomment 80 % du temps
  On a toujours l’impression d’être « presque arrivé », ce qui favorise facilement le biais des coûts irrécupérables
  La méthode que j’ai essayée récemment consiste à utiliser l’IA non comme « solutionneur », mais comme « réducteur de friction »
  Je programme moi-même, et je ne demande à l’IA que des choses mineures comme un bout de syntaxe oublié, afin d’aller plus vite
  Je regarde presque jamais les propositions complètes de code ; j’écris toujours en réfléchissant moi-même, pour éviter une baisse de compréhension et de compétence

  • Avant, c’était plutôt une logique anti-Pareto : 80 % du travail demandaient 80 % de l’effort, puis les 20 % restants en demandaient encore 80 %
    Je suis d’accord avec l’usage de l’IA pour ne résoudre que les « petits obstacles »
    Hier encore, je galérais avec une ConcurrentOperationsException en traitant une List via la Java stream API
    J’essayais d’écrire la méthode moi-même sans y arriver, puis j’ai demandé à l’IA une « méthode de transformation de liste thread-safe », et elle m’a indiqué qu’une méthode intégrée existait déjà dans cette API
    L’IA est excellente pour ce genre de petits problèmes divers — lorsqu’ils sont complexes, mais bien définis

  • C’est particulièrement utile comme une version plus puissante de Stack Overflow, quand je sais à peu près ce que je veux faire mais pas comment l’adapter concrètement à mon environnement, et c’est aussi utile pour le debugging ou le rubber ducking

  • Le fait de « passer 80 % du temps sur les 20 % finaux » correspondait déjà à mon expérience avant l’arrivée de l’IA. Réduire seulement le temps du démarrage est déjà précieux. La meilleure formule que j’ai entendue de quelqu’un d’expérimenté à propos de l’IA, c’est : « 90 % de mes compétences sont devenues sans valeur, et les 10 % restants sont devenus mille fois plus importants ». C’est exagéré, mais j’aime bien l’idée de fond

  • L’illusion du « c’est presque fini » peut au contraire faire perdre du temps. L’IA est particulièrement douée pour donner l’impression d’être utile, donc il faut un niveau élevé d’esprit critique pour déterminer s’il y a un vrai gain de productivité

  • C’est particulièrement utile lorsqu’on ajoute des fonctionnalités à une codebase existante, par exemple pour « ajouter foo en plus des paramètres de recherche existants » ou « retirer le code lié à x »

• Pour les utilisateurs HN, je suis l’auteur de l’article — je fréquente HN depuis longtemps, et je réponds autant que possible aujourd’hui aux questions et retours dans les commentaires. Si vous manquez de temps, je recommande plutôt le billet de blog de présentation ou le thread de présentation sur x.com que l’article complet

  • La méthodologie de l’article et la manière dont vous échangez ici sont très professionnelles et impressionnantes ; c’est une excellente étude

  • Je pense que c’est l’une des meilleures études : elle présente les résultats honnêtement, sans clickbait, et elle est très facile à lire

  • Avez-vous examiné si les tickets traités par l’IA étaient réellement du type qui convient bien à l’IA ? Dire « essaie de traiter ce ticket avec l’IA » est réaliste, mais peut aussi être inefficace. Utilisée sur les bons cas, l’IA peut vraiment aider, mais elle produit souvent l’effet inverse. Si les participants avaient suffisamment d’expérience de l’IA, ils auraient pu faire cette distinction, mais ce n’est pas très clair à la lecture de l’article

  • Je me demande s’il serait possible de publier le jeu de données brut anonymisé, ou au moins d’ajouter dans l’article les durées absolues par développeur. J’aimerais savoir si les participants ayant beaucoup d’expérience avec Cursor étaient réellement plus rapides que les autres, ou s’ils étaient simplement plus lents au départ et ont davantage bénéficié de l’IA. Je suis ravi de voir une évaluation expérimentale vraiment solide, qui prend même en compte l’effet Hawthorne

  • (Je n’ai pas lu l’article, seulement le post.) Je me demande si la fatigue subjective a été mesurée comme indicateur pouvant expliquer pourquoi l’on croit à tort que l’IA est plus rapide. Depuis que je suis passé de développeur à manager, quand mon cerveau est fatigué, l’IA me paraît plus confortable

• Le résultat de cette étude, en particulier le fait que « les développeurs s’attendaient à ce que l’IA les rende 24 % plus rapides, mais même après avoir été ralentis en réalité, ils croyaient encore avoir gagné 20 % de vitesse », est extrêmement intéressant. Pourquoi un écart aussi spectaculaire entre réalité et perception ? Je me demande si le cerveau ne confond pas parfois l’“effort mental” avec l’expérience subjective du temps

  • Je n’ai aucune preuve, mais j’ai une pensée inquiétante : et si l’interaction avec l’IA pendant le codage stimulait le cerveau un peu comme une boucle dopaminergique des réseaux sociaux, même à un degré différent ? L’IA propose sans cesse des réponses, ce qui pourrait donner au cerveau l’impression de recevoir une évaluation positive, et pousser ainsi les développeurs à juger l’IA plus favorablement qu’elle ne le mérite réellement. Si cela allait jusqu’à créer une forme d’addiction, cela ne conduirait-il pas à surestimer ses effets réels sur la productivité ?

  • Ce phénomène peut aussi être le résultat d’une vaste campagne de marché qui pousse beaucoup de gens à croire que les outils d’IA sont meilleurs qu’ils ne le sont en réalité. Les groupes d’experts économiques et ML recoupent en partie les intérêts des entreprises d’IA, et les dirigeants reprennent cela au pied de la lettre en promettant de grands résultats. Cela finit par relever le niveau d’attente général, y compris chez les développeurs expérimentés. C’est difficile à prouver empiriquement, mais cela pourrait expliquer pourquoi l’illusion collective autour de la productivité de l’IA s’est autant diffusée

  • Je me demande si beaucoup d’enthousiastes de l’IA dans les commentaires HN ne tombent pas eux aussi dans ce piège. Tant qu’on ne mesure pas vraiment ses propres performances, il reste douteux que l’IA améliore réellement sa productivité

  • Il m’arrive parfois de vivre exactement l’inverse. Aujourd’hui, j’ai essayé de générer le code d’une app de démonstration avec Claude code ; à regarder, c’était impressionnant et presque science-fictionnel, mais au bout de 15 minutes j’avais l’esprit embrumé et je m’ennuyais

• Quand on lit que « les développeurs espéraient être 24 % plus rapides avec l’IA, et ont cru être 20 % plus rapides alors qu’ils avaient en réalité ralenti », j’ai l’impression qu’il y a ici deux problèmes
  Le premier, c’est qu’il est difficile pour une même personne de comparer correctement le temps pris avec et sans IA dans un contexte identique
  Le second, c’est qu’on peut facilement mesurer l’efficacité de l’IA avec des indicateurs superficiels comme le délai d’ouverture ou de merge d’une PR, alors qu’en pratique l’introduction de l’IA déplace davantage de temps vers le refactoring, les tests et la résolution des problèmes en aval
  Il est facile de croire que « la PR a été ouverte plus vite » signifie que l’IA est plus rapide, tout en négligeant l’augmentation du travail ultérieur

  • Il est vraiment difficile de mesurer l’effet d’une technologie ou d’une pratique donnée sur la productivité. Tirer des conclusions à partir de simples témoignages est dangereux, car tout le monde peut facilement tomber dans l’auto-illusion. L’étude elle-même reconnaît ses limites, donc il faut garder une grande marge d’erreur en tête dans toute discussion sur la productivité. L’IA est la technologie la plus étrange que j’aie vue de toute ma vie ; tenter de déduire des causalités à partir de cas isolés ou de benchmarks douteux, c’est presque de la divination

  • L’article n’a pas observé de baisse de qualité des PR entre les situations avec IA et sans IA. La plupart des participants connaissaient bien les standards de leur dépôt et n’étaient pas du genre à « soumettre à l’arrache pour ouvrir une PR ». Le temps médian de revue intermédiaire des PR dans l’étude était d’environ 1 minute. Comme vous le dites, la répartition du temps change complètement. Voir la page 10 de l’article pour la distribution du temps avec et sans IA : avec l’IA, le temps de codage baisse, mais le temps d’interaction avec l’IA augmente, ce qui compense le gain. Pour des tâches simples de moins de 5 minutes, il valait peut-être mieux ne pas utiliser de LLM du tout

  • Concernant l’idée qu’il serait impossible de connaître précisément « la différence de temps pour une même personne dans le même contexte, avec ou sans IA », le protocole expérimental isole justement l’effet du groupe IA et du groupe non-IA via l’assignation aléatoire. Les différences liées à l’individu, au contexte ou à l’environnement sont compensées par la randomisation. Tant que l’échantillon et la taille d’effet sont suffisants, on peut en extraire des différences statistiquement significatives

  • La Figure 21 montre que le temps de mise en œuvre initiale lui-même (jusqu’à la PR) a augmenté, et même si le temps après review a aussi augmenté, l’impact global ne semble pas majeur. Comme on le voit dans la Figure 18, le temps de codage effectif diminue, mais le temps gagné est compensé par la rédaction des prompts, l’attente des résultats et la revue des sorties. Pour les tâches simples de moins de 5 minutes, il aurait même pu être préférable de ne pas utiliser les LLM

• J’aimerais comparer le contenu des PR selon les workflows. Copilot me propose souvent plus de code que ce que j’écrirais moi-même, avec beaucoup de vérifications inutiles, de répétitions, ou davantage de lignes sans vraie abstraction. Mon hypothèse personnelle, c’est que voir le LLM produire autant de code déforme notre perception du temps nécessaire pour résoudre le problème

• La vraie difficulté quand on utilise un LLM sur une grosse codebase, c’est de décrire précisément le travail à faire. Il arrive souvent que le simple fait d’expliquer un problème au milieu d’innombrables interactions du code prenne plus de temps que de le traiter soi-même à la main ; à l’inverse, pour générer du boilerplate sur un projet neuf, les LLM semblent particulièrement bien adaptés

  • J’ai exactement la même expérience. Comme le disait Knuth, l’essence du code ne réside pas uniquement dans le code lui-même, mais aussi dans la tête du développeur. À moins de transmettre tout le contexte au LLM avec précision, on ne peut pas lui verser d’un coup des années de concepts et de stratégies accumulés

• Rien que pour recruter les développeurs participants, ils ont dépensé 300 x 246 = environ 73K, et pourtant l’article n’est ni publié dans une revue, ni évalué par les pairs. Le document paraît bien présenté et pas spécialement généré par IA, mais je me demande comment un tel financement a été possible

  • Le plus gros soutien financier venait de The Audacious Project, comme on peut le voir dans l’annonce officielle ; le site précise aussi dans une note de bas de page qu’ils n’avaient reçu aucune rémunération d’entreprises d’IA pour des évaluations jusqu’en avril 2025

  • Les entreprises publient souvent ce genre de « white papers ». C’est un mélange de rapport technique, de recommandation politique et de document promotionnel

  • Je ne pense pas qu’il faille accorder tant d’importance au seul fait qu’un article soit ou non dans une revue ou évalué par les pairs. En science, ce qui compte n’est pas qui publie, mais la reproductibilité et la répétition des résultats. Comme l’a montré la crise de la réplication en psychologie, être publié dans une revue ne garantit pas la fiabilité

  • Dans la plupart des pays, la recherche bénéficie de financements publics ; les États-Unis soutenaient davantage cela autrefois, mais ces aides ont été fortement réduites récemment

  • D’après la page de présentation de la fondation, ils semblent recevoir des financements de diverses sources, notamment d’entreprises d’IA et de gouvernements

• Dans les projets OSS de loisir, l’IA est plutôt un obstacle. La génération de code ou le scaffolding n’est pas vraiment mon inquiétude ; ce qui compte davantage, c’est la revue de code et la gestion de la communauté. Les possibilités concrètes des outils d’IA sont clairement limitées. Pourtant, quelqu’un a branché un outil de revue de code par IA sur une de mes PR ouvertes, et même sur une PR de 30 lignes il a craché deux pages de résumé avec des emojis et des puces bien rangées. Cela ajoute du bruit inutile, si bien que je perds désormais davantage de temps de maintenance à supprimer ou masquer ce genre de commentaires

• Une fois la courbe d’apprentissage franchie, on devient plus rapide (ou, comme quelqu’un l’a dit, « jusqu’à oublier comment travailler sans IA »), mais ce qu’il faudrait vraiment mesurer, c’est… le temps qu’il faut à 3 heures du matin quand PagerDuty se déclenche pour déboguer ce code. Et je me demande aussi quelle est la qualité à long terme de ce code. Depuis longtemps, j’améliore la structure du code en remontant la logique métier dans des dossiers partagés, en faisant remonter les chaînes d’appel pour simplifier les API en aval, en séparant logique/API/affichage, en renforçant l’encapsulation, etc. (avec par exemple l’injection de dépendances pour réduire le couplage). Le code généré par IA donnera-t-il à long terme une meilleure qualité, portabilité ou extensibilité ? Ou bien va-t-on accumuler progressivement du code médiocre jusqu’à former une décharge emmêlée, et finir par consacrer la moitié du temps à corriger des bugs ?