Le code à l'ère de l'IA

En 2025, j'écrivais l'article "Le vibecoding : c'est trop bien" explorant les impacts que ces nouvelles pratiques de développement pouvaient avoir sur notre quotidien de développeur.

Bientôt un an plus tard, il est désormais clair que ces outils ne sont plus des curiosités expérimentales : ils redessinent notre façon de coder, nos processus et, surtout, notre rapport au métier de développeur.

Et si notre rapport au métier change, une question s’impose alors : que devient un développeur quand écrire du code devient presque trivial ?

Pour répondre à cette question, il faut examiner comment l’IA transforme notre productivité, façonne nos architectures, exige un apprentissage nouveau et change notre manière d’aborder le code.

• La difficile question de la productivité
• La nécessité d'une bonne architecture
• Des choses à apprendre
• L'ego face au code
• Conclusion

La difficile question de la productivité

L'une des principales promesses de l'IA générative est celle de nous faire gagner du temps, la réponse pourrait paraître évidente face à tout ce code généré en quelques secondes sur nos écrans, mais qu'en est-il réellement ? Que disent les études, sondages et programmes de recherche ?

En 2025, l'étude "Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity" conclut que les développements s'appuyant sur l'IA prennent jusqu'à 19% de temps en plus pour finaliser une tâche.

Cette lenteur pourrait s'expliquée par des normes de qualité élevées, des exigences de process ou même par des outils IA ... insuffisamment utilisés pour en tirer pleinement parti !

Une mauvaise utilisation ou compréhension de l'IA pourrait donc devenir délétère, renforçant l'idée que ces outils sont loin d'être magiques et nécessitent un apprentissage nouveau.

Toujours en 2025, l'étude "The Effects of Generative AI on High-Skilled Work: Evidence from Three Field Experiments with Software Developers" menée chez Microsoft sur plus de 4800 développeurs indique quant à elle une augmentation de 26% des tâches réalisées par les développeurs assistés par IA.

Les développeurs plus expérimentés n'ont cependant pas montré d'augmentation significative de leur productivité, contrairement aux développeurs plus juniors qui ont vu leur nombre de tâches réalisées fortement augmenté, une conclusion en contradiction avec l'étude précédente.

Cette différence pourrait s'expliquer par la nature même des tâches effectuées : les développeurs juniors sont souvent confrontés à des tâches plus simples et plus facilement réalisables avec l'IA, l'écart observé serait donc davantage d'ordre organisationnel que technologique.

L'étude chez Microsoft se concentre également sur le nombre de tâches réalisées, délaissant l'aspect qualitatif du code produit : seul le taux de réussite de compilation fut monitoré, ce qui a du sens pour des langages de bas niveau, mais un angle mort pourrait exister sur l'aspect purement architectural, stylistique et maintenable du code.

Certaines études se concentrent également sur des langages très spécifiques, bien souvent Python, pouvant produire des attentes biaisées et non généralisables à l'ensemble de la profession.

Leurs résultats peuvent certainement se transposer à des langages de même nature, en revanche, ils deviennent beaucoup plus incertains dès que l’on s’éloigne de ces environnements pour aller vers des langages de plus bas niveau, où les contraintes et les modes de travail diffèrent profondément.

Surinterpréter un chiffre isolé est tentant mais potentiellement trompeur : le biais est visible mais son impact reste difficile à cerner.

En 2024, l'étude "Evaluating the Efficiency and Challenges of GitHub Copilot in Real-World Projects" a examiné comment les gains apportés par l'IA variaient selon les langages de programmation.

Elle a conclu que les langages de haut niveau offraient en moyenne des gains de vélocité plus importants, pouvant atteindre environ 50% pour JavaScript, tandis que les langages de bas niveau comme le C présentaient des gains plus modestes, autour de 33%.

Cette différence s'explique, d'après l'étude, par les attentes et les besoins différents ainsi qu'une richesse de documentation parfois plus abondante.

Les langages de haut niveau possèdent des structures bien établies et des modèles de codes répandus et bénéficient d'avantage des capacités de génération des IA. Les langages de bas niveau, quant à eux, nécessitent souvent des pratiques de code plus spécifiques et optimisées pour lesquelles les IA sont moins efficaces.

Au delà des langages utilisés, la typologie même des projets influence fortement les gains apportés par l’IA.

Depuis 2022, un programme de recherche mené par Stanford sur plus de 120'000 développeurs a montré que les tâches greenfield (dans le cadre d’un nouveau projet) bénéficiaient d’un gain de vélocité de 30 à 35%.

En revanche, les tâches réalisées sur des bases de code existantes et complexes (brownfield) affichaient des gains nettement plus faibles, de l’ordre de 5 à 10%.

En complément de ces études, certaines entreprises influentes réalisent également des sondages réguliers. Contrairement aux recherches empiriques, ces enquêtes déclaratives reflètent l’appréciation des développeurs plutôt que des mesures objectives de productivité.

De son côté, SonarQube publia début 2026 un sondage "State of Code Developer Survey Report" mené auprès de plus de 1000 développeurs.

Les gains directs, c’est à dire ce que les développeurs ressentent au quotidien, montrent une hausse de productivité d’environ 35%. Concrètement, cela signifie davantage de tâches terminées dans le même laps de temps.

La quasi-totalité des sondés (82%) déclare également coder plus vite, un gain qui se concentre surtout sur les tâches à plus faible valeur ajoutée pour près de 75% des répondants.

À l’inverse, presque tous les répondants (96%) indiquent ne pas accorder une confiance aveugle au code généré et 38% affirment même passer davantage de temps à relire du code produit par une IA que du code écrit par des humains … sans toutefois que ce temps soit réellement mesuré.

Ainsi, l’IA semble accélérer l’écriture du code tout en déplaçant l’effort vers sa validation : le temps gagné à produire devient du temps investi à vérifier, sans qu’il soit pour autant possible d’en évaluer précisément l’ampleur.

Toutes ces études et sondages offrent des indications intéressantes, parfois contradictoires, mais restent trop limitées pour trancher la question de la productivité, sans doute parce que celle ci est trop réductrice et mal posée.

Comme nous venons de le voir, la productivité se heurte à une multitude de facteurs et de conditions particulières : le niveau des développeurs, la maturité de l’équipe, la qualité de l’architecture existante, l’environnement technique, les langages utilisés, la nature des problématiques fonctionnelles rencontrées, la pression business, la dette technique accumulée ...

Chacun de ces facteurs modifie profondément l’impact de l’IA rendant toute conclusion générale fragile : affirmer que l'IA accélère ou ralentit le développement relève donc d’une simplification abusive.

Si certains projets peuvent indéniablement bénéficier d’un gain tangible d’autres nécessitent au contraire une intervention humaine plus soutenue.

L’IA n’est donc pas un outil magique : elle exige des développeurs une réelle compétence, acquise par la pratique, pour identifier les situations où elle apporte véritablement de la valeur.

La nécessité d'une bonne architecture

Nous venons de voir que l’IA peut, dans bien des circonstances, accélérer l’écriture du code : mais plus la vitesse augmente et plus le risque de chaos se multiplie.

Sans architecture claire et pensée, chaque génération de code devient une source potentielle de bugs, de dépendances problématiques et d'entropie.

L’entropie est inévitable, qu’il s’agisse de code écrit à la main ou généré automatiquement : notre métier a toujours consisté à contenir ce chaos, de poser des limites et d’imposer des règles.

Par chaos, je ne parle pas seulement de quelques bugs isolés car l’entropie est profondément structurelle.

Elle se manifeste par des dépendances instables et circulaires, des responsabilités mal définies, des zones du code où un changement mineur peut provoquer une avalanche de régressions ailleurs et inattendues.

Ces dépendances génèrent parfois des cycles qui grossissent sans cesse : de quelques dizaines de fichiers à plusieurs centaines, avec des dépendances qui se multiplient et se propagent rigidifiant le systeme.

Représentation de cycles dans une visualisation en graph des dépendances

Ce phénomène illustre parfaitement ce que l’IA pourrait involontairement amplifier si elle était utilisée sans cadre : produire du code plus vite ne fait que nourrir le chaos existant.

L’architecture logicielle n’est donc pas négociable, c’est elle qui nous permet de canaliser le code produit par l’IA et de retrouver confiance dans ce que nous déléguons à la machine.

Pour illustrer ce point, prenons un exemple concret et réel : une application d'analyse de code composée de plusieurs composants ayant chacun ses propres responsabilités.

Chaque composant déclare ses propres contrats : ce qu'il peut exporter, ce qu'il doit garantir, des frontières strictes définies avec soin pour limiter la propagation du changement.

Grâce à ces limites claires, j'ai pu me servir de l'IA pour générer un nouveau connecteur au sein du composant Reporting, je savais que, tant que la génération respectait les contrats que j'avais définis, l'architecture globale et la stabilité de l'application seraient préservées.

Chaque modification resterait circonscrite : pas de propagation imprévue, pas de shotgun surgery, le code pouvait changer, évoluer ... mais les règles que j'avais préalablement posées agissaient ici comme un filet de sécurité me permettant de garder le contrôle et la compréhension de l'application.

C’est précisément dans cette situation que l’architecture devient un garde fou essentiel : elle rend possible la délégation à l’IA sans perdre le contrôle du système.

La vraie valeur du développeur ne réside pas dans la vitesse de production, mais dans sa capacité à endiguer l’entropie, à contenir le chaos et à maintenir la cohésion du système ... et cette compétence ne fera que devenir plus cruciale à mesure que l’IA accélère l’écriture du code.

Des choses à apprendre

Si l'IA et le vibe coding s'installent durablement dans notre quotidien, alors une évidence s'impose : il va falloir apprendre à s'en servir correctement.

Il ne s’agit pas d’apprendre un énième framework ou langage mais de découvrir une nouvelle façon de travailler, dans un écosystème doté de ses propres règles et pratiques ... et qui bouscule frontalement nos habitudes et nos certitudes.

Ces dernières années nous avons vu débarquer tout un ensemble de nouveaux concepts : MCP, agents, skills, guidelines, contextes … Ces concepts ne sont pas innés et il est tout à fait normal de s’y sentir perdu ou dépassé, d’autant que la cadence effrénée des nouveautés peut intimider.

Ce malaise n’est pas uniquement technique : il touche aussi à notre rapport au métier de développeur et à la maîtrise que nous pensions avoir acquise.

Cette dernière décennie, nous nous sommes peut être sentis intouchables, nos langages évoluaient mais la pratique du développement restait peu ou prou la même, confortant l’idée que notre savoir faire était stable, durable et presque immuable.

L’arrivée de l’IA est un rappel brutal à la réalité : nos métiers ne sont pas figés dans le marbre, et cette fois, ce ne sont pas seulement nos outils qui évoluent mais notre position elle même.

Refuser d’apprendre, ou minimiser ces changements au nom de l’expérience ou de l’ego revient à prendre le risque que le monde continue d’avancer … sans nous.

L'ego face au code

S’il existe aujourd’hui un frein majeur à une adoption de l’IA et du vibe coding, il n’est ni technique, ni économique, ni même éthique, il est profondément humain : notre ego de développeur.

Une partie des débats actuels autour de l’IA générative dans l'ingénierie souffre d’un problème fondamental : une vision morale et binaire.

L’IA serait "bonne" ou "mauvaise”, "fiable" ou “dangereuse”, “utile” ou “toxique” ... cette lecture, par ailleurs curieusement anthropomorphique, me semble profondement erronée.

L’IA n’a aucune intention particulière, elle ne cherche ni à bien faire ni à mal faire, elle optimise simplement une réponse à partir d’un contexte donné. Toute interprétation supplementaire relève exclusivement d'une projection de notre part.

Dans ce contexte, l’ego du code devient un frein majeur à l’adoption saine de ces outils, l’attachement émotionnel à “son” code, à son style, à sa manière d’écrire rend toute délégation suspecte ... presque vécue comme une dépossession.

Nous aimons penser que notre valeur réside dans le code que nous écrivons : dans notre style, dans nos patterns, dans ces micro décisions que nous avons accumulées au fil des années et qui constituent notre “signature”.

Quand une machine produit en quelques secondes ce que nous mettions des heures à écrire, ce n’est pas seulement notre productivité qui est remise en question mais également notre identité professionnelle.

Il en découle une injonction devenue quasiment omniprésente sur les réseaux sociaux : “il faut garder le contrôle sur le code”, “Il faut comprendre chaque ligne” ... mais ces affirmations sont trompeuses car elles reposent sur des illusions.

Le contrôle absolu sur le code est un mythe que nous avons déjà abandonné depuis longtemps : compilateurs, frameworks, runtimes, ORMs, garbage collectors, moteurs de templates ... sont tout autant d’exemples de responsabilités que nous avons confiées à la machine ou au code écrit par d’autres.

Nous n’avons jamais réellement contrôlé l’intégralité de ce que nous exécutons en production ... et c'est d'ailleurs ce que nous recherchons avec un langage de haut niveau comme PHP, se libérer des détails de bas niveau pour se concentrer sur la logique métier.

L’ego du code nous pousse à confondre responsabilité et paternité : être responsable d’un système ne signifie pas avoir tout écrit sois même !

Refuser cette distinction, c’est se condamner à lutter contre un mouvement de fond avec des arguments moraux alors que le sujet est profondement structurel. L'IA n'a pas besoin de notre validation pour écrire du code ... elle n'a pas besoin de notre fierté non plus.

En revanche, elle a cruellement besoin de cadres, de limites, de règles explicites et c’est précisément là que le développeur reste indispensable.

Abandonner l’ego du code ne signifie pas renoncer à l’exigence, ni à la qualité, ni à la rigueur, cela signifie accepter que notre valeur ne se mesure plus à la quantité de code produit, ni même à sa forme, mais à notre capacité à penser des systèmes cohérents, à poser des contraintes intelligentes et à assumer les conséquences des choix faits.

Conclusion

Un an plus tôt, je voyais le vibe coding et la génération par IA comme un moyen d'accélérer la production du développement, aujourd’hui, je réalise que cette accélération ne se cantonnait pas au code ... mais au métier lui même.

L'IA n'a pas simplement changé notre vitesse d'exécution, elle a déplacé la nature de notre travail : nous écrivons moins mais nous décidons davantage.

Pendant des années, la compétence d'un développeur s'évaluait à sa capacité à transformer une idée en code, désormais, le code est abondant, presque trivial.

Ce qui devient rare, ce n’est pas le code, mais la structure, le discernement et les limites que nous savons poser au système.

L'IA ne remplace pas le développeur, elle nous force simplement à abandonner un simple rôle d'artisan pour devenir celui d'un architecte.

Le véritable changement se trouve probablement ici : le métier ne disparaît pas, il perd simplement son illusion la plus confortable, celle que notre valeur se trouvait dans ce que nous écrivions.

« Problem solving, system thinking, product awareness, and structural competence have always been more important than coding; and those skills are more important than ever »
— Robert C. Martin

Mathieu De Gracia

Lead & Software Architect • nublar.dev