Discussion :

[jnspunk]

« En comparant le temps de cycle, le débit et la complexité des RP avec les RP avec tests, GitHub Copilot n'a ni aidé ni nui aux développeurs de l'échantillon, et n'a pas non plus augmenté la vitesse de codage. Bien que certaines de ces mesures soient statistiquement significatives, le changement réel n'a pas eu d'incidence sur les résultats techniques, par exemple le temps de cycle a diminué de 1,7 minute », indique le rapport d'Uplevel.

L'étude est complétement bidon, ca peut aussi vouloir dire que les participants ont levés le pied car ils avaient moins de travail à fournir grace à copilot.
D'ailleurs quiconque l'a déjà utilisé (github copilot) sait le temps que cela fait gagner rien qu'avec l'écriture de la documentation et des commentaires...

[calvaire]

L'étude est complétement bidon, ca peut aussi vouloir dire que les participants ont levés le pied car ils avaient moins de travail à fournir grace à copilot.
D'ailleurs quiconque l'a déjà utilisé (github copilot) sait le temps que cela fait gagner rien qu'avec l'écriture de la documentation et des commentaires...

je ne saurais l'expliquer, dans mon équipe, il y'a un gain de temps de mon coté, mais pour autant je ne constate pas une amélioration de la productivité ou de la qualité.
le nombre de bug et de tache Jira avec le status "finish" et similaire entre 2022, 2023 et 2024. a plus au moins 8% pres. Meme si chatgpt a permis d 'augmenter la productivité de 8% (ce qui reste a prouvé avec juste comme panel 1 projet celui ou je bosse, difficile d'en l'affirmer), 8% reste faible comme gain par rapport aux promesses des startups.

il serait intéressant sur developpez.com qu'on se partage les stats du nombre de tache jira finis et/ou des mr mergé sur 1 année, histoire de voir la tendance.

[Metal3d]

De mon côté je peux dire que la productivité a augmenté de 10 à 20% avec une IA de complétion. Je prends en compte le temp de dev et le temps de fix. On a moins de bugs et moins de tickets.

On a aussi testé Tabby en mode communautaire et pro. La productivité est moins impacté mais on n'avait pas les modèles adaptés selon moi.

Ce qui a compté, aussi, c'est le confort de dev. Les ingénieurs apprécient l'aide de l'IA, ça leur donne des idées ou carrément ça leur apprend des choses. Par contre il est nécessaire de bien préparé, surtout les jeunes, à vérifier ce qui est proposé.

[Stéphane le calme]

Bret Taylor invite à repenser le développement logiciel qui entre dans une « ère de pilotage automatique » avec l'IA,
il préconise de nouveaux systèmes de programmation, langages et méthodes de vérification pour garantir que les codes générés par l'IA restent robustes et sûrs

Le développement logiciel entre dans une « ère de pilotage automatique » avec les assistants de codage IA, mais le secteur doit se préparer à une autonomie totale, affirme Bret Taylor, Président du conseil d'administration d'OpenAI et ancien co-PDG de Salesforce. Faisant le parallèle avec les voitures autopilotées, il suggère que le rôle des ingénieurs logiciels évoluera, passant d'auteurs de code à opérateurs de machines génératrices de code. Taylor préconise de nouveaux systèmes de programmation, langages et méthodes de vérification pour garantir que le code généré par l'IA reste robuste et sécurisé.

L’intelligence artificielle (IA) redéfinit les contours de l’industrie technologique et Bret Taylor invite à une profonde réévaluation des approches traditionnelles de développement logiciel. Lors d’une récente intervention, Taylor a souligné que les avancées rapides de l’IA nécessitent une remise en question des méthodologies établies, mettant en lumière les opportunités et les défis associés à cette révolution.

L'évolution rapide des modèles de langage avancés et des assistants de codage, tels que Cursor, a inauguré ce que Bret Taylor appelle l'ère du « pilote automatique » en ingénierie logicielle. Ces outils augmentent la productivité des développeurs en facilitant la rédaction de code, tout en maintenant les environnements de programmation traditionnels conçus pour les humains, comme Visual Studio Code et des langages tels que Python. Cependant, cette approche nécessite encore une supervision humaine constante, comparable à garder les mains sur le volant.

Taylor envisage une transition vers une véritable ère autonome du développement logiciel, où le rôle des ingénieurs évoluerait de la création directe de code à l'exploitation de machines génératrices de code.

Il dresse d'ailleurs un parallèle avec les voitures autonomes :

« Lorsque vous montez à bord d'une Waymo à San Francisco, vous voyez un siège conducteur vide et un volant qui tourne essentiellement comme une forme de divertissement pour les passagers. Assis sur la banquette arrière, on ne peut s'empêcher de réfléchir aux changements radicaux que connaîtront les voitures au cours des prochaines décennies, à mesure que la conduite autonome se généralisera. Lorsque les voitures passeront du pilotage automatique à l'autonomie, il sera possible non seulement de réorganiser les sièges et d'enlever le volant, mais aussi de transformer notre relation avec les voitures, car le coût du covoiturage et du robotaxiage diminuera considérablement.

« Avec l'avènement des grands modèles de langage, il est clair que nous sommes déjà entrés dans l'ère du pilotage automatique du génie logiciel. Les assistants de codage comme Cursor aident les programmeurs individuels à devenir beaucoup plus productifs, mais en grande partie dans le cadre d'environnements de programmation optimisés pour les humains : des éditeurs de texte optimisés pour les humains comme Visual Studio Code et des langages de programmation optimisés pour les humains comme Python, tous présentés sous forme de complétion de code de sorte que le programmeur informatique doit garder la main sur le volant tout le temps.

« Malgré le rythme de l'innovation dans les assistants de codage, il semble qu'il nous manque encore certaines des idées fondamentales qui pourraient faire du développement de logiciels véritablement autonomes une réalité. À quoi ressemblera le génie logiciel à l'ère de l'autonomie, lorsque nous nous serons débarrassés du proverbial siège du conducteur et du volant ? »

Une transformation qui soulève des questions fondamentales, selon lui

L'urgence de ces réflexions est accentuée par l'augmentation massive de la production logicielle, souvent accompagnée de vulnérabilités et de failles de sécurité similaires à celles du passé, mais avec moins de supervision et de maintenabilité. L'IA offre une opportunité unique de créer des logiciels non seulement plus nombreux, mais aussi plus robustes.

Taylor appelle ainsi l'industrie à adopter une ambition renouvelée pour concevoir cette ère autonome de l'ingénierie logicielle. Il encourage les professionnels travaillant sur ces problématiques à partager leurs projets, afin de s'inspirer mutuellement et de façonner ensemble l'avenir du développement logiciel.

« Dans l'ère autonome du génie logiciel, le rôle de l'ingénieur logiciel passera probablement de celui d'auteur de code informatique à celui d'opérateur d'une machine génératrice de code. Quel est le système de programmation informatique conçu nativement pour ce flux de travail ?

« Si la génération de code n'est plus un facteur limitant, quels types de langages de programmation devrions-nous construire ?

« Si un ordinateur génère la plupart des codes, comment faire en sorte qu'il soit facile pour un ingénieur logiciel de vérifier qu'il fait bien ce qu'il veut ? Quel est le rôle de la conception des langages de programmation (par exemple, ce que Rust a fait pour la sécurité de la mémoire) ? Quel est le rôle de la vérification formelle ? Quel est le rôle des tests, du CI/CD et des flux de développement ?

« Aujourd'hui, le principal bureau d'un ingénieur logiciel est son éditeur. Quel est le contrôle de mission d'un ingénieur logiciel à l'ère du développement autonome ?

« Non seulement répondre à ces questions sera amusant et aura un impact, mais je dirais que nous devons y répondre rapidement. Dans cette ère du pilotage automatique, nous augmentons considérablement la quantité de logiciels dans le monde, mais ces nouveaux logiciels semblent contenir les mêmes failles et vulnérabilités de sécurité que le code que nous écrivions auparavant, mais avec moins de surveillance et de facilité de maintenance.

« Avec l'IA, nous avons la possibilité non seulement de créer plus de logiciels, mais aussi de les rendre nettement plus robustes. Pouvons-nous créer un nouveau système d'ingénierie logicielle qui nous permette non seulement d'être plus productifs, mais aussi de produire moins de bogues et de vulnérabilités en matière de sécurité ? Pourquoi tous les programmes ne seraient-ils pas vérifiables et ne fonctionneraient-ils pas de manière incroyablement efficace si l'IA fait tout le travail ? Combien de logiciels dangereux dans le monde pourront être réécrits lorsque nous disposerons d'un tel système ?

« En tant qu'industrie, je pense que nous devrions être plus ambitieux et concevoir activement l'ère autonome de l'ingénierie logicielle. Si vous travaillez sur ce type de problèmes, j'aimerais en savoir plus et m'inspirer de votre projet ».

Le code généré par l'IA pourrait augmenter la charge de travail des développeurs et accroître les risques

Nous sommes encore loin, bien loin de ce monde imaginé par Bret Taylor. L'IA est censée faciliter le travail des développeurs, mais selon Harness, le code généré par l'IA pourrait en réalité tripler leur charge de travail dans l'année à venir.

L'augmentation du volume de code généré par les outils d'intelligence artificielle pose un défi majeur en termes de sécurité et de gestion des vulnérabilités. Bien que l'automatisation et la génération de code puissent considérablement accélérer le processus de développement, elles introduisent également de nouveaux risques. Si les tests et les mesures de sécurité ne sont pas rigoureusement appliqués à chaque étape du cycle de vie du développement logiciel, il devient presque inévitable que des failles passent inaperçues et soient déployées en production.

La rapidité avec laquelle le code est produit grâce à l'IA peut surpasser la capacité des développeurs à effectuer des tests approfondis et à assurer la sécurité de chaque ligne de code. Sans une infrastructure solide pour la détection et la correction des failles, les erreurs et les vulnérabilités peuvent s'accumuler, augmentant le risque d'exploits et de temps d'arrêt coûteux. La complexité accrue et la vitesse du développement exigent des outils de tests automatisés et des processus de sécurité intégrés pour compenser les limitations humaines.

Cette dépendance accrue aux outils d'IA pour la génération de code peut entraîner une réduction de la vigilance humaine, où les développeurs pourraient faire excessivement confiance aux suggestions de l'IA sans une vérification rigoureuse. Cette approche peut devenir dangereuse, car même les systèmes d'IA avancés peuvent générer du code défectueux ou vulnérable. Une approche équilibrée, combinant l'efficacité de l'IA avec une supervision humaine minutieuse, est essentielle pour garantir la qualité et la sécurité du code.

Avec Microsoft Copilot les développeurs ont constaté une augmentation de 41 % des bogues

un rapport révèle un décalage entre les dirigeants qui sont pressés à adopter les outils de codage IA et les développeurs qui sont plus prudents à l'égard de l'IA. Le rapport montre que les directeurs techniques et les RSSI sont cinq fois plus nombreux que les développeurs à penser que les outils de codage IA ne présentent aucun risque et deux fois plus nombreux que les développeurs à penser qu'ils sont "extrêmement prêts" à adopter des outils de codage IA.

Dans l'ensemble, le rapport constate que la sécurité du code généré par l'IA n'est pas une préoccupation majeure pour la majorité des organisations interrogées. Près des deux tiers (63,3 %) des personnes interrogées considèrent que la sécurité est excellente ou bonne, et seulement 5,9 % la considèrent comme mauvaise.

Un autre rapport d'Uplevel suggère que les outils de développement actuels basés sur la GenAI n'ont pas tendance à améliorer l'efficacité du codage et peuvent même augmenter le taux de bogues. Après la mise en œuvre de Microsoft Copilot, les développeurs ont constaté une augmentation de 41 % des bogues.

Alors que l'IA est souvent présentée comme la solution à toutes sortes de tâches, il semble qu'elle n'améliore pas toujours les choses lorsqu'il s'agit de développer des logiciels. L'étude, menée par Uplevel Data Labs, la branche d'Uplevel spécialisée dans la science des données, a porté sur un échantillon de 800 développeurs de logiciels appartenant à de grandes équipes d'ingénieurs et dont les organisations avaient adopté GitHub Copilot de Microsoft, un assistant de codage et un outil de développement basé sur la GenAI.

L'étude révèle que les développeurs utilisant Copilot n'ont pas constaté d'augmentation de la vitesse de codage. En termes de temps de cycle des demandes d'extraction (PR) (le temps nécessaire pour fusionner le code dans un dépôt) et de débit des PR (le nombre de demandes d'extraction fusionnées), Copilot n'a ni aidé ni nui aux développeurs.

Après la mise en œuvre de Copilot, les développeurs ont constaté une augmentation de 41 % des bogues dans les demandes d'extraction, ce qui suggère que l'outil peut avoir un impact sur la qualité du code. L'étude suggère également que l'utilisation de Copilot n'a qu'un effet limité sur le temps que les développeurs consacrent au travail en dehors des heures de travail. Ce temps a diminué de 17 % pour ceux qui ont accès à Copilot, mais surtout de 28 % pour un groupe de contrôle composé de ceux qui n'y ont pas accès.

Joe Levy, PDG d'Uplevel déclare : « Les équipes d'ingénieurs d'aujourd'hui cherchent à allouer leur temps au travail de plus grande valeur, à réaliser ce travail aussi efficacement que possible, et à le faire sans s'épuiser. Elles s'appuient sur les données pour prendre des décisions, et pour l'instant, les données ne montrent pas de gains appréciables dans ces domaines spécifiques grâce à l'IA générative ».

Il ajoute : « Mais l'innovation évolue rapidement, et nous ne suggérons pas aux développeurs d'ignorer les outils basés sur l'IA générative tels que Copilot, Gemini ou CodeWhisperer. Ces outils sont tous nouveaux, il y a une courbe d'apprentissage et la plupart des équipes doivent encore trouver les cas d'utilisation les plus efficaces pour améliorer la productivité. Nous continuerons à observer ces informations au fur et à mesure que l'adoption de la GenAI continuera à croître, et nous recommandons à tous ceux qui investissent dans des outils GenAI de faire de même ».

Source : Bret Taylor

Et vous ?

Que pensez-vous de l'argumentation de Bret Taylor ? Partagez-vous son avis (ses constats, ses projections et ses solutions) ? Dans quelle mesure ?

En vous penchant sur ses capacités actuelles, pensez-vous que l'IA puisse prendre le pas sur les développeurs ?

Quels nouveaux paradigmes de programmation pourraient émerger si la génération de code devient entièrement automatisée ?

Comment garantir que le code généré par des machines corresponde précisément aux intentions des développeurs ?

Si le rôle des ingénieurs évolue de créateurs de code à superviseurs de machines, quelles compétences devront-ils développer ?

Les nouveaux outils autonomes risquent-ils de marginaliser les développeurs juniors ou non spécialisés ?

Les environnements autonomes peuvent-ils réellement réduire les vulnérabilités logicielles, ou risquent-ils d’en introduire de nouvelles ?

[Mathis Lucas]

Morgan Stanley déclare que son outil d'IA a traité 9 millions de lignes de code hérité cette année et a permis d'économiser 280 000 heures de travail pour les développeurs
bien que des défis restent à relever

La modernisation du code hérité est l'une des tâches les plus difficiles de l'ingénierie logicielle. Les ingénieurs doivent faire face à plusieurs défis qui nécessitent des investissements colossaux en matière de coûts et de temps. Mais Morgan Stanley affirme que l'IA permet de réduire la complexité de cette tâche. Morgan Stanley a rapporté que son outil d'IA interne a traité 9 millions de lignes de code ancien cette année, ce qui a permis à ses ingénieurs d'économiser 280 000 heures de travail. Toutefois, la banque affirme que plusieurs défis restent à relever, car les outils d'IA actuels ne sont pas fiables pour les tâches de codage.

Les banques et de nombreuses autres organisations à travers le monde s'appuient encore sur des systèmes hérités écrits dans de vieux langages comme le COBOL ou le Perl. La plupart cherchent aujourd'hui à réécrire leurs anciens logiciels dans des langages modernes, comme Python ou Java, car ils sont plus efficaces, maintenables et utilisés par les développeurs actuels. Face à ce défi, Morgan Stanley a mis au point un outil d'IA interne appelé DevGen.AI.

Morgan Stanley a présenté DevGen.AI en janvier. L'outil, qui tire parti des modèles GPT d'OpenAI, traduit le code des anciens langages, tels que Perl (publié en 1987), en anglais simple, que les développeurs peuvent ensuite utiliser comme base pour réécrire le code dans des langages plus récents tels que Python. Mike Pizzi, responsable mondial de la technologie et des opérations chez Morgan Stanley, a laissé entendre qu'il s'agit d'une approche efficace.

Selon lui, au cours des cinq mois qui ont suivi son lancement, DevGen.AI a traité 9 millions de lignes de code, permettant aux 15 000 développeurs de l'entreprise d'économiser 280 000 heures de travail. « L'élimination d'une telle quantité de travail fastidieux est un événement majeur », a écrit un critique.

Développement et fonctionnement de programme DevGen.AI

La modernisation des logiciels hérités a toujours été un véritable casse-tête pour les organisations, qui disposent parfois d'un code datant de plusieurs dizaines d'années, susceptible d'affaiblir la sécurité et de ralentir l'adoption de nouvelles technologies. Par exemple, il devient difficile de trouver des développeurs qui savent encore coder en COBOL, un langage qui a fêté ses 60 ans 2019. Bien que les anciens systèmes sont fiables, ils sont coûteux à entretenir.

Selon les entreprises d'IA, la modernisation des logiciels hérités est l'un des cas d'utilisation les plus adaptés aux assistants d'IA de codage. Mais les outils d'IA existant souffrent de nombreuses lacunes qui frustrent les ingénieurs. Selon Mike Pizzi, Morgan Stanley a choisi de construire son propre logiciel d'IA en interne parce que les entreprises technologiques n'avaient pas de solutions qui pouvaient répondre aux spécifications exactes de Morgan Stanley.

Les outils commerciaux manquaient d'expertise pour déchiffrer les anciens langages de codage, en particulier ceux qui sont spécifiques à une entreprise. Ces outils commerciaux sont excellents pour écrire des codes nouveaux et modernes. Cependant, Mike Pizzi a expliqué qu'ils n'ont pas nécessairement autant d'expertise dans les langages de programmation moins populaires ou plus anciens, ou dans ceux qui sont adaptés à une organisation donnée.

C'est un domaine sur lequel travaillent de nombreuses entreprises technologiques, mais pour l'instant, leurs offres n'ont pas la flexibilité dont les entreprises ont besoin. C'est pourquoi Morgan Stanley a choisi de ne pas attendre. Nous avons constaté que le fait de le construire nous-mêmes nous donnait certaines capacités que nous ne voyons pas vraiment dans certains produits commerciaux. Les outils disponibles sur le marché pourraient encore évoluer pour offrir ces capacités, mais nous avons vu l'opportunité de prendre de l'avance.

Morgan Stanley a formé son outil sur sa propre base de code, y compris sur des langages qui ne sont plus, ou n'ont jamais été, d'usage courant. Plutôt que de traduire automatiquement le code ancien en code moderne, DevGen.AI convertit le code hérité en spécifications en anglais clair. Ces descriptions facilitent la compréhension du fonctionnement du code existant et permettent aux ingénieurs de le réécrire efficacement dans des langages modernes.

Aujourd'hui, les quelque 15 000 développeurs de Morgan Stanley, répartis dans le monde entier, peuvent utiliser l'outil pour toute une série de tâches, notamment la traduction du code existant en spécifications en langage naturel (l'anglais simple), l'isolation de sections du code existant pour les enquêtes réglementaires et autres demandes, et même la traduction complète de sections plus petites du code hérité en code écrit dans un langage moderne.

Des défis restent à relever et la technologie doit encore mûrir

Comme souligné plus haut, DevGen.AI a été entraîné spécifiquement sur le code interne de Morgan Stanley, y compris des langages personnalisés peu répandus, ce qui le rend plus efficace que les outils commerciaux génériques. Il est conçu pour la traduction du code existant en spécifications en anglais simple. Bien qu'il puisse théoriquement traduire du code ancien en code moderne, l'outil ne garantit pas une optimisation complète du nouveau code.

En d'autres termes, DevGen.AI peut réécrire un code Perl en code Python, mais il ne saurait pas nécessairement comment l'écrire en tant que code efficace tirant parti de toutes les capacités de Python. « Et c'est l'une des principales raisons pour lesquelles les humains restent dans la boucle », a déclaré Mike Pizzi.

Selon lui, c'est en traduisant les codes existants en spécifications anglaises, c'est-à-dire en dressant une carte de ce que fait le code, que le logiciel s'avère vraiment efficace. C'est quelque chose qu'un nombre de plus en plus restreint de développeurs, formés à des langages anciens ou spécifiques, sait faire. Selon Mike Pizzi, avec ces spécifications, n'importe quel développeur peut écrire l'ancien code comme un nouveau code dans un langage moderne.

Mike Pizzi a ajouté que plusieurs défis restent à relever et que la technologie doit encore mûrir. Morgan Stanley maintient les programmeurs humains impliqués dans le processus de traduction des codes anciens ou hérités vers de nouveaux langages. Selon Mike Pizzi, Morgan Stanley ne réduirait pas ses effectifs d'ingénieurs logiciels en raison de l'outil d'IA, bien qu'il ait licencié 2 000 de ses 80 000 employés au cours du mois de mars de cette année.

Morgan Stanley a lancé plusieurs applications d'IA pour ses employés, dont une qui les aide à résumer des réunions vidéo et une autre qui leur permet de trouver rapidement des informations à partir du corpus de recherche de l'entreprise. L'année dernière, Ted Pick, PDG de Morgan Stanley, a déclaré aux investisseurs que les outils d'IA pourraient permettre aux employés d'économiser jusqu'à 15 heures par semaine et qu'ils pourraient changer la donne.

Les dirigeants imposent les outils d'IA malgré leurs limites

L'initiative de Morgan Stanley illustre comment l'IA peut être intégrée de manière stratégique pour résoudre des problèmes complexes tels que la modernisation de la base de code des systèmes hérités. Elle souligne également l'importance de solutions personnalisées pour répondre aux besoins spécifiques des entreprises, en particulier lorsque les outils standards du marché ne suffisent pas. Mais l'approche contraste avec le reste de l'industrie technologique.

Des témoignages d'employés anonymes de Microsoft indiquent que, dans certaines équipes, des solutions techniques efficaces sont écartées au profit de solutions basées sur l'IA, même si ces dernières sont moins performantes. Un ingénieur de Microsoft a rapporté que des algorithmes efficaces étaient parfois délaissés au profit de modèles d'IA, simplement pour suivre la tendance, malgré des performances inférieures et des coûts plus élevés.

Les dossiers de l'État de Washington examinés par Bloomberg ont révélé que « plus de 40 % des personnes licenciées par Microsoft dans l'État en mai travaillaient dans le domaine du développement de logiciels ». Les ingénieurs restants semblent dépassés, frustrés ou stressés par l'intégration rapide et parfois chaotique de GitHub Copilot dans les flux de travail. Ce qui se traduit par un taux de bogue élevé et une augmentation de la charge de travail.

Chez Amazon, l'IA transforme le codage informatique en « un travail à la chaîne ». Les ingénieurs logiciels d'Amazon rapportent que leur travail devient plus mécanique, moins intellectuellement stimulant et davantage axé sur la rapidité d'exécution que sur la qualité ou la réflexion.

Source : Mike Pizzi, responsable mondial de la technologie et des opérations chez Morgan Stanley

Et vous ?

Quel est votre avis sur le sujet ?
Que pensez-vous du fonctionnement de l'outil DevGen.AI de Morgan Stanley ?
L'outil traduit le code ancien en spécifications en anglais plutôt que dans un langage moderne. Qu'en pensez-vous ?

Voir aussi

Les ingénieurs de Microsoft contraints de creuser leurs propres tombes avec l'IA. Ils sont sous pression pour concevoir et adopter des outils capables d'automatiser leurs tâches, ils sont ensuite licenciés

L'IA transforme le rôle des développeurs : leur travail devient plus mécanique, moins intellectuellement stimulant et davantage axé sur la rapidité d'exécution que sur la qualité ou la réflexion

L'IA pourrait déjà réduire le nombre d'emplois de débutant dans la technologie. L'embauche de jeunes diplômés a chuté de 25 % en 2024 et 37 % des employeurs préfèrent embaucher une IA pour les tâches banales

[djuju]

Morgan Stanley a rapporté que son outil d'IA interne a traité 9 millions de lignes de code ancien cette année, ce qui a permis à ses ingénieurs d'économiser 280 000 heures de travail. [...] les outils d'IA actuels ne sont pas fiables pour tâches de codage

Effectivement, pour l'instant ce n'est pas vraiment fiable. Alors sur les 280000h, combien sont économisées et combien doivent être compté en dette technique ?

[shenron666]

Les chiffres, on leur fait dire ce que l'on veut

[Axel Mattauch]

[...] Plutôt que de traduire automatiquement le code ancien en code moderne, DevGen.AI convertit le code hérité en spécifications en anglais clair. Ces descriptions facilitent la compréhension du fonctionnement du code existant et permettent aux ingénieurs de le réécrire efficacement dans des langages modernes.

Si DevGen.AI sait effectivement faire ça, je pense que c'est louable.
Peut-être y compris pour convertir des codes moins anciens en spécifications en anglais clair ?

J'ai quand même quelques doutes, d'autant que les programmes écrits en code ancien (sic) étaient écrits pour des machines de technologie ancienne, et le code écrit avait une certaine propension a mettre en œuvre des astuces.

Et, même avec des spécifications en langage clair, la transcription -comme l'écriture from scratch- n'est pas chose aisée.

Le plus incompréhensible est qu'il soit possible de pérorer:

DevGen.AI a traité 9 millions de lignes de code, permettant aux 15 000 développeurs de l'entreprise d'économiser 280 000 heures de travail.

L'estimation ne se base-t-elle pas sur le préjugé de type marketing, que la transcription de COBOL, PERL,PL/1,PL/M, ALGOL et consorts en spécification en langue anglaise fait gagner x% de temps au recodage?

Cela reste a voir, donc; mais si c'est avéré, la démarche est intéressante.

[Stéphane le calme]

La taxe invisible de la productivité d'un code d'IA « presque correct » : 84% des développeurs utilisent l'IA... mais 46% ne lui font pas confiance,
selon une enquête

Les développeurs sont plus nombreux que jamais à utiliser des outils d'IA pour assister et générer du code. Alors que l'adoption de l'IA par les entreprises s'accélère, les nouvelles données d'une enquête auprès des développeurs révèlent un point critique : la dette technique croissante créée par les outils d'IA qui génèrent des solutions « presque correctes », sapant potentiellement les gains de productivité qu'ils promettent de fournir. Selon l'enquête, 84 % des développeurs utilisent des outils d'IA, mais 46 % d'entre eux ne font pas confiance aux résultats.

En quelques années, les assistants IA comme GitHub Copilot, ChatGPT, CodeWhisperer ou Tabnine sont devenus des partenaires quasi permanents dans l’environnement de développement. D’après le Stack Overflow Developer Survey 2025, plus de 84 % des développeurs déclarent utiliser ou envisager d’utiliser une IA générative dans leur travail quotidien. Il y a un an, ce chiffre s’élevait à 76 %, et seulement 55 % en 2023.

L’enthousiasme initial repose sur une promesse forte : automatiser les tâches répétitives, réduire le temps d’écriture, accélérer l’apprentissage de nouveaux langages, et même générer des solutions à des problèmes complexes en quelques secondes. Et en effet, dans bien des cas, ces IA tiennent parole – du moins en apparence.

Mais sous la surface, une réalité plus complexe émerge. L’outil qui semblait libérateur s’accompagne d’une charge mentale croissante, de frustrations insidieuses et, surtout, d’une taxe invisible sur la productivité.

L'enquête annuelle de Stack Overflow auprès des développeurs est l'un des plus importants rapports de ce type au cours d'une année donnée. En 2024, le rapport a révélé que les développeurs ne craignaient pas que l'IA ne supprime leurs emplois. De manière quelque peu ironique, Stack Overflow a d'abord subi l'impact négatif de la croissance de l'IA générique, avec une baisse du trafic et des licenciements en conséquence en 2023.

L'enquête menée en 2025 auprès de plus de 49 000 développeurs dans 177 pays révèle un paradoxe troublant dans l'adoption de l'IA par les entreprises. L'utilisation de l'IA continue de progresser - 84 % des développeurs utilisent ou prévoient d'utiliser des outils d'IA, contre 76 % en 2024. Pourtant, la confiance dans ces outils s'est effondrée.

La face cachée du code « presque juste » : quand l’IA nous ralentit

Une confiance en chute libre

Alors que l’adoption explose, la confiance, elle, s’effondre. En 2025, seulement 33 % des développeurs déclarent faire confiance à la précision du code généré par l’IA, contre 43 % en 2024. La confiance dans l'IA est passée de 77 % en 2023 à 72 % en 2024 et à seulement 60 % cette année. Plus frappant encore, 46 % disent explicitement ne pas lui faire confiance, soit une augmentation de 15 points en un an. Les développeurs expérimentés sont les plus sceptiques. Parmi ceux qui ont plus de 10 ans d’expérience, à peine 2,5 % expriment une « forte confiance » dans les outils IA. Cette fracture générationnelle illustre un paradoxe : plus on est compétent, plus on identifie les limites de l’IA.

Le vrai problème : le « code presque juste »

Ce que redoutent les développeurs, ce n’est pas que l’IA se trompe, c’est plutôt qu’elle fasse illusion. Le code généré est souvent syntaxiquement correct, logique en surface, mais fondamentalement erroné. Il compile, passe les tests superficiels, mais introduit des bugs subtils, des failles de sécurité ou des erreurs conceptuelles.

D'ailleurs, l'enquête révèle que :

• 66 % des développeurs rapportent que le code généré semble bon mais contient des erreurs.
• 45 % passent plus de temps à déboguer du code généré par l’IA qu’ils ne l’auraient fait en codant eux-mêmes.

Autrement dit : l’IA génère du travail invisible. Elle économise du temps en surface, mais en ajoute en profondeur.

Un coût opérationnel souvent ignoré

Une perte de temps masquée

Dans la course à la rapidité, certains développeurs insèrent directement du code IA dans les bases sans vérification approfondie. Résultat ? Une accumulation de dette technique, qui se paie plus tard, au prix fort : bugs en production, maintenance plus coûteuse, réécriture de modules entiers.

Les projets gagnent en vitesse initiale mais perdent en robustesse structurelle.

Des erreurs de sécurité critiques

Une étude récente de Veracode a montré que près de 45 % des suggestions de code IA contiennent des failles de sécurité exploitables : injections SQL, cross-site scripting, erreurs d’authentification…

Pour les entreprises manipulant des données sensibles, le code généré sans surveillance représente un risque juridique majeur.

Une surcharge cognitive

Les développeurs doivent désormais relire, comprendre, corriger un code qu’ils n’ont pas écrit. Cette posture « passive-agressive » crée un inconfort cognitif : il est plus difficile de déboguer un code généré que de le produire soi-même.

C’est là la véritable taxe de productivité : une IA qui semble aider mais exige un surinvestissement intellectuel permanent.

La majorité des développeurs évitent les agents et préfèrent des outils plus simples

Alors que les LLM sont la norme, les agents d'IA ne sont pas encore très répandus. Une majorité - 52 % des développeurs - déclare ne pas utiliser d'agents ou s'en tenir à des outils plus simples, et 38 % n'ont pas l'intention d'essayer des agents d'IA dans un avenir proche.

Mais parmi ceux qui les utilisent, les gains de productivité sont évidents : 69 % déclarent que les agents d'intelligence artificielle ont amélioré leur flux de travail, 70 % indiquent qu'ils ont réduit le temps consacré à des tâches spécifiques. Un bémol toutefois : seuls 17 % estiment que les agents d'IA ont amélioré la collaboration au sein de l'équipe, ce qui en fait l'impact le moins bien noté.

Le « Vibe Coding » existe désormais, mais n'est pas (encore) une pratique sérieuse

Oui, les développeurs expérimentent le « vibe coding », en demandant à un LLM de générer des applications ou des composants entiers. Mais ne vous attendez pas encore à ce que cela se retrouve dans votre répertoire de production : 77 % des développeurs déclarent que le vibe coding ne fait pas partie de leur flux de travail professionnel.

Au lieu de cela, l'interaction humaine domine toujours la boîte à outils de résolution de problèmes du développeur : 84 % d'entre eux utilisent Stack Overflow, 67 % GitHub, 61 % YouTube et, cerise sur le gâteau, 35 % des développeurs se tournent vers Stack Overflow en cas d'échec d'un code généré par l'IA. Ainsi, bien que l'IA soit un assistant tape-à-l'œil, la sagesse de la communauté des développeurs, issue de la foule, continue de faire la loi.

« Avec tous les investissements et l'attention portée à l'IA, je m'attendais à ce que la confiance augmente au fur et à mesure »

Pour Prashanth Chandrasekar, PDG, Stack Overflow : « Le manque de confiance croissant dans les outils d'IA nous est apparu comme le point clé de l'enquête de cette année, en particulier compte tenu du rythme accéléré de la croissance et de l'adoption de ces outils d'IA. L'IA est un outil puissant, mais elle présente des risques importants de désinformation ou peut manquer de complexité ou de pertinence ».

« L'un des résultats les plus surprenants a été un changement significatif dans les préférences des développeurs pour l'IA par rapport aux années précédentes, alors que la plupart des développeurs utilisent l'IA, ils l'aiment moins et lui font moins confiance cette année », a déclaré Erin Yepis, analyste principal pour les études de marché et les insights chez Stack Overflow. « Cette réponse est surprenante, car avec tous les investissements et l'attention portée à l'IA dans les actualités technologiques, je m'attendais à ce que la confiance augmente au fur et à mesure que la technologie s'améliorait. »

Pourquoi persiste-t-on à l’utiliser ?

Malgré ces constats, l’IA reste utilisée massivement. Pourquoi ?

Tout d'abord, parce qu’elle reste utile… pour les tâches simples. Les développeurs reconnaissent que l’IA est excellente pour :

• Générer du boilerplate
• Créer des tests unitaires
• Écrire des scripts simples
• Résoudre des erreurs de syntaxe

Mais moins de 30 % estiment qu’elle est capable de gérer des problèmes complexes ou critiques.

Du côté des débutants, les juniors y trouvent un tuteur omniprésent. L’IA leur permet de progresser rapidement, d’apprendre en testant. Mais cette dépendance peut créer un effet pervers : une perte de compétences analytiques et une tendance à survalider des solutions incorrectes.

Il faut aussi compter sur les profils moins techniques : l'IA impressionne les managers. L’IA permet de produire « quelque chose » rapidement, ce qui peut tromper sur la qualité réelle. Cela génère un effet de productivité trompeur, très apprécié des décideurs pressés. Pourtant, la réalité du terrain finit souvent par contredire l’illusion d’efficacité.

Conclusion

Le principal problème mis en évidence par l'enquête est la lutte de 66 % des développeurs contre les solutions IA qui sont « presque bonnes » mais manquent finalement la cible. Ce phénomène a un impact direct sur la productivité. La plupart des développeurs qui utilisent l'IA se retrouvent à passer plus de temps à corriger le code généré qu'à le concevoir eux-mêmes. L'enquête révèle d'ailleurs que 45 % des développeurs estiment que le débogage du code généré par l'IA prend plus de temps que sa rédaction à partir de zéro.

Ce travail de correction et de débogage représente une « taxe de productivité » cachée. Au lieu de libérer du temps pour des tâches plus complexes et créatives, l'IA génère un travail supplémentaire de vérification et de révision. Ce cycle de « génération-correction » peut non seulement annuler les gains de vitesse initiaux, mais aussi introduire de la frustration et une charge cognitive accrue pour le développeur.

Malgré cette méfiance et ces défis, il est important de noter que le sentiment général à l'égard de l'IA reste majoritairement positif (60 %). De nombreux développeurs (36 %) l'utilisent comme un outil de développement personnel, pour apprendre de nouvelles technologies ou perfectionner leurs compétences.

Si l'IA est devenue un outil incontournable pour la majorité des développeurs, il est crucial de reconnaître et de corriger le problème du code « presque bon ». Les outils d'IA doivent évoluer pour devenir non seulement plus rapides, mais aussi plus fiables. Pour les développeurs, cela signifie qu'il faut intégrer l'IA avec discernement, en l'utilisant comme un assistant puissant tout en restant vigilant et critique face à ses propositions. Le véritable potentiel de productivité de l'IA ne sera libéré que lorsque la confiance dans ses résultats aura rattrapé l'adoption explosive de la technologie.

Source : résultats de l'enquête

Et vous ?

Trouvez-vous cette enquête crédible ou pertinente ? Si vous utilisez une IA dans un contexte professionnel, faites-vous confiance au résultat ou le vérifiez-vous systématiquement ?

Comment les développeurs peuvent-ils mieux intégrer les outils d'IA dans leurs flux de travail pour minimiser la « taxe de productivité » du code « presque bon » ?

Quelles nouvelles fonctionnalités les outils d'IA devraient-ils développer pour gagner la confiance des développeurs et réduire le besoin de débogage manuel ?

Au-delà du code, comment le manque de confiance dans l'IA pourrait-il impacter d'autres aspects du développement logiciel, comme la conception de systèmes ou la documentation ?

À long terme, est-ce que cette méfiance envers l'IA pourrait freiner l'adoption de technologies d'automatisation plus avancées ou, au contraire, pousser à la création de systèmes plus fiables ?

Comment les entreprises peuvent-elles mesurer l'impact réel de l'IA sur la productivité de leurs équipes, en tenant compte du temps passé à corriger les erreurs et non seulement du temps gagné ?

[Matthieu Vergne]

« L'un des résultats les plus surprenants a été un changement significatif dans les préférences des développeurs pour l'IA par rapport aux années précédentes, alors que la plupart des développeurs utilisent l'IA, ils l'aiment moins et lui font moins confiance cette année », a déclaré Erin Yepis, analyste principal pour les études de marché et les insights chez Stack Overflow. « Cette réponse est surprenante, car avec tous les investissements et l'attention portée à l'IA dans les actualités technologiques, je m'attendais à ce que la confiance augmente au fur et à mesure que la technologie s'améliorait. »

Ceux qui comprennent comment fonctionne l'IA ne devraient pas trouver cela surprenant. Les investissements, qui améliorent la technologie, et l'attention portée à l'IA, qui lui fait de la publicité, expliquent l'augmentation de son utilisation, pas de la confiance. La confiance vient avec les résultats obtenus lors de son utilisation. Or, à force de l'utiliser, les dévs se rendent comptent des limites de la techno, notamment le fait que cela reste un générateur de texte statistique, voué à générer des illusions à un moment ou à un autre.

Les probabilités de génération d'illusions peuvent être réduites significativement en améliorant l'apprentissage et le contexte, mais jamais tomber à zéro. C'est une limite intrinsèque des LLM. Et comme on leur ajoute des outils dont les résultats passent à nouveau par le LLM afin d'être formatés, même les résultats d'outils fiables sont assujettis au risque d'être déformés par le LLM.

Pour passer le cap des illusions, il faudra passer le cap du LLM. Soit en le rendant secondaire, permettant à un outil fiable de fournir son résultat sans déformation, soit en utilisant des technos (futures) qui n'ont pas ce problème à la place ou en complément du LLM.

C'est un outil utile, donc tout le monde s'y met, c'est normal de voir l'utilisation continuer d'augmenter. Et ça finira dans la boîte à outil requise du dév, donc on va probablement atteindre les ~95% d'utilisation (juste quelques % qui ne pourront pas l'utiliser dans des contextes très spécifiques, ou ni les LLM en ligne ni ceux qui tournent localement ne sont utilisables, pour qurelques raisons que ce soit). Par contre, tant qu'on reste sur cette techno, je ne serait pas surpris d'atteindre les 60-70% de dévs qui ne lui font pas confiance.

On en aura toujours une partie qui lui fera confiance, aveuglément ou par défaut. Soit des juniors, soit ces dévs qui restent incompétents toute leur vie car n'ayant aucun intérêt à s'améliorer. Ceux-là même qui sont 100% remplaçables par l'IA (remplacement qui pourrait les faire sortir du marché du dév, et donc augmenter au delà de 60-70%).

Et je suis convaincu que rien ne chamboulera ça tant qu'on n'aura pas une nouvelle techno que le LLM pour venir régler ce problème d'illusion.

[Axel Mattauch]

Ceux qui comprennent comment fonctionne l'IA ne devraient pas trouver cela surprenant.
[...]

Pour passer le cap des illusions, il faudra passer le cap du LLM. Soit en le rendant secondaire, permettant à un outil fiable de fournir son résultat sans déformation, soit en utilisant des technos (futures) qui n'ont pas ce problème à la place ou en complément du LLM.

[...]

Et je suis convaincu que rien ne chamboulera ça tant qu'on n'aura pas une nouvelle techno que le LLM pour venir régler ce problème d'illusion.

N'étant ni dev pro, ni initié sérieusement à la techno IA, je ne peux me prononcer doctement.
L'article de Stéphane me parle, et ton commentaire [Matthieu] me paraît tout à fait pertinent.

Eu égard aux caractéristiques du support IA (rapidité, étendue du référentiel, fiabilité incertaine), je me demande si l'IA ne saurait pas jouer magnifiquement et efficacement le rôle du candide. En effet les tests faits par les dev sont biaisés -certes pertinents et ciblés- mais dans le design de produits, confier des tests au candide, s'avère souvent un moyen efficace pour mettre en lumière des anomalies non détectées par le processus normal.