Du code et de l'IA

J'ai régulièrement des discussions sur l'usage de l'IA avec mes proches et mes collègues dans le domaine du développement informatique, et il est souvent compliqué de débattre du sujet tant il est complexe et interconnecté.

J'ai eu besoin de poser sur le papier mes pensées sur le sujet, à la fois pour remettre en question ou confirmer mes convictions, mais aussi parce que cela servira de support à partager, tant pour moi que pour ceux qui partagent mon point de vue. Sentez-vous donc libre de partager ce texte comme vous le souhaitez.

Ce texte peut être lu par des personnes non-tech sans problème majeur, hormis quelques passages un peu plus techniques.

Dans la suite, nous désignerons par “IA” les intelligences artificielles génératives, telles que celles utilisées par ChatGPT ou Claude, entre autres.

Productivité

La première raison qui est invoquée pour justifier l'usage de l'IA dans le développement informatique est la productivité. Ce n'est pas forcément évoqué sous ce terme, parfois “Je vais 2x plus vite” ou “On est obligés de l'utiliser sinon on va devenir obsolète”. Bien sûr que l'IA génère du code plus vite qu'un humain, mais est-ce que cela permet de délivrer du code plus vite ? Pour l'avoir utilisé sur des périodes prolongées, je n'ai pas observé de gain notable à long-terme, à qualité de code égale. Mais cela reste une observation personnelle, donc appuyons-nous sur des études à grande échelle.

Nous allons traiter cette section sous 2 prismes : le gain de temps et le coût.

Gain de temps

Concernant le gain de temps, quelques études sont récemment sorties, notamment celles de METR (= association à but non lucratif visant à évaluer les capacités des IA) qui a publié :

Si l'IA semble apporter un gain de temps à l'échelle d'une tâche, il me semble qu'il est important aussi de regarder l'impact à l'échelle de la livraison. Cette étude de FAROS est éclairante.

Elle confirme qu'il y a un gain de productivité à l'échelle de la tâche, de l'ordre de 33% par développeur, mais au détriment de la qualité du code. Le nombre d'incidents en production a triplé, le temps de relecture a doublé et le nombre de bugs a augmenté de 50%. Ces impacts sont observés quelque soit la maturité de l'adoption de l'IA ou l'adoption de bonnes pratiques de développement. Il n'y a donc pas de formule magique pour régler ces problèmes aujourd'hui.

Une mesure permettant de juger la qualité est le “code churn”, qui est le nombre de lignes de codes supprimées moins de 3 mois après être écrite. Cette mesure a été par plus de 8 (!) avec l'adoption de l'IA.

C'est ici qu'intervient le papier de Jellyfish et Harvard, qui en analysant plus de 700,000 codeurs parmi 700 companies, a conclu que les développeurs codent en moyenne 30% plus vite (on retrouve le même ordre de grandeur que les études précédentes) mais que cela n'a aucun impact statistiquement significatif sur la vitesse de livraison. Cela s'explique par le déplacement du temps de travail depuis le codage vers la relecture de la sortie de l'IA ainsi que la résolution de bugs.

En d'autres termes, on transforme du temps de codage en temps de relecture, sans gagner de temps au global. Sachant que cela ne prend pas en compte le prix que coûte l'usage de l'IA, particulièrement élevé chez les développeurs qui utilisent l'IA agentique (= IA capable d'effectuer des tâches complexes sans intervention humaine), dont la consommation de tokens (= unité d'utilisation des modèles d'IA, comme les watts pour l'électricite) est bien plus élevée.

Coût

L'étude de Jellyfish que l'on peut voir ici mesure également la quantité de tokens utilisés par développeur ainsi que le gain de temps associé (à l'échelle du développeur donc, pas du logiciel) et démontre que le rapport entre le gain de temps et le nombre de tokens est exponentiel.

Par exemple entre le développeur médian, qui consomme 7M de tokens par PR (= unité de livraison du code) et les développeur les plus productifs, qui consomment 69M de tokens par PR, la consommation de tokens est multipliée par 10 pour aller 2x plus vite. Entre les développeurs les moins productifs, qui utilisent seulement 74K tokens (soit quasiment rien) par PR et le développeur médian, qui utilise 7M de token par PR, la consommation de tokens est multipliée par 100 pour aller 1,3x plus vite. En d'autres termes, plus on utilise l'IA, moins le ratio accélération/coût est avantageux.

L'article mentionne un montant de 691$ (= 600€) par mois pour les plus gros utilisateurs d'IA. Cela correspond à environ 15% de son salaire brut moyen (en France). Quant au développeur médian et ses 51$ (= 45€) par mois pour aller 30% plus vite à la tâche, cela correspond à environ 1,2% de son salaire.

Dans tous les cas, comme nous avons vu que le gain de temps à la tâche ne se répercute pas sur la vitesse de livraison, il s'agit seulement d'un coût financier supplémentaire.

Sécurité

Une autre facette peu débattue des IA est la faille de sécurité qu'elle représente, à la fois pour les entreprises et les individus.

Vous avez peut-être entendu parler des infiltrations de requête (ou “prompt injection” en anglais), il s'agit d'une attaque consistant à introduire du texte dans les instructions d'une IA afin de l'amener à effectuer des actions malicieuses. La plupart des IA ayant aujourd'hui accès à Internet, alors le web tout entier devient une surface d'attaque.

Il y a des cas d'entreprises perdant des centaines de milliers d'euros à cause de ces attaques. D'après cet article, environ 2,3 milliards d'euros de perte directe sont liés à des attaques par infiltration de requête, avec un coût moyen de 340 000 euros par attaque, et cela ne concerne que les incidents déclarés.

Il a été démontré qu'il est impossible pour une IA de distinguer les instructions “injectées” des instructions de l'utilisateur. Et il s'agit d'une limitation absolue au niveau du modèle (en tout cas pour les IA génératives dont on parle ici, donc une solution n'arrivera pas “un jour”). On peut réduire le risque, mais quand on parle de sécurité, même si on évite 99% des attaques, ce n'est absolument pas suffisant. Aujourd'hui, aucune défense n'est 100% efficace.

Le seul moyen est donc de vérifier manuellement chaque action que prend l'IA, mais cela est très fastidieux, et à force de répétition on finit par cliquer par automatisme, ce qui rend la vérification de moins en moins efficace. Cela s'appelle la “fatigue d'approbation”, théorisé dans le papier de Google et vérifié empiriquement par l'étude de ScaleX, qui démontre que 1/3 des attaques passent à travers une vérification humaine.

L'impact environnemental

Mais le coût de l'IA n'est pas seulement financier et sécuritaire, il est aussi écologique.

Impact carbone

Reprenons les résultats précédents. Le prix des tokens étant à peu près proportionnel à la consommation électrique du token, on peut déduire l'impact carbone directement depuis le coût. Comme la plupart des développeurs IA utilisent Claude Sonnet pour coder, nous allons nous baser sur son coût carbone (450 gCO²e/kWh issu de Know Your Compute et 75.5 Wh/$ issu de ce blog soit environ 33g CO²e/$). Donc notre gros utilisateur produira environ 21kg de CO²e/mois soit environ 250 kg de CO²e/an. C'est l'équivalent de 1/8 de l'objectif carbone individuel annuel pour 2050. Quant à notre ami le développeur médian, il produira environ 1,7 kg CO²e/mois soit 20kg CO²e/ an. Cela correspond à 1% de l'objectif carbone.

Attention, il s'agit d'un ordre de grandeur, mais cela donne une idée générale de l'ampleur de l'impact carbone lié à l'usage d'une IA.

Impact eau

Contrairement aux idées reçues, l'impact eau de l'IA n'est pas seulement lié au refroidissement des centres de données mais au refroidissement des centrales électriques comme expliqué ici.

Ainsi les chiffres souvent relayés ne concernent que le refroidissement direct (scope 1) du centre de données, alors que la consommation d'eau correspondant à l'électricité consommée (scope 2) par le centre de données compte pour 75% du total de l'impact eau.

Dans de nombreux endroits, l'installation d'un centre de données rentre en conflit d'usage direct avec l'usage agricole ou domestique de l'eau.

Impact sur la biodiversité

L'IA a évidemment un impact sur la biodiversité, mais il est nettement plus difficile à chiffrer que le carbone ou l'eau. Il me paraît en tout cas important de préciser que ces impacts existent.

Il est généralement admis qu'environ 20% de l'empreinte d'un centre de données est liée à sa fabrication, qui demande de grandes quantités de métaux rares. La production de ces derniers pollue les sols et les nappes phréatiques, généralement dans des pays pauvres.

Considérations éthiques

Le logiciel libre

Dans le domaine du codage, les IA se sont entraînées sur des milliers de lignes de codes disponibles publiquement en ligne, majoritairement issues de projet open-source (= code accessible librement). Jusque là, on peut trouver ça injuste mais rien d'illégal. Par contre ces IA permettent désormais de recréer de zéro des packages (= briques logicielles) ou des fonctionnalités plutôt que de recourir à l'open source (et donc d'y contribuer).

À long terme cela revient à épuiser la ressource même qui a permis à l'IA de s'entraîner et aussi celle sur laquelle repose notre propre code : quasiment tous les projets informatiques du monde (y compris des projets qui ne sont pas open-source) reposent sur du code open-source.

Désapprentissage

Il est démontré que l'IA réduit la compréhension qu'ont les développeurs de leur propre code. En faisant générer son code, on pratique ce que l'on appelle de la “délégation cognitive”, c'est à dire qu'on confie une tâche cognitive à un système externe. D'après cet article on crée des développeurs qui comprennent moins bien leur code, qui ne sont plus capables de coder sans IA et qui sont donc moins capables d'évaluer le code généré par une IA : c'est la triple peine.

De la même manière que l'on fragilise l'écosystème open source en utilisant l'IA, on fragilise également la ressource en main d'oeuvre en incitant les développeurs juniors et confirmés à utiliser l'IA plutôt que de progresser et d'apprendre.

Santé mentale

Comme conclu précédemment, l'IA permet de produire du code plus vite, ce qui crée une attente que la livraison aille aussi plus vite. Mais nous avons vu que ce n'est pas ce qu'il se passe en réalité : la productivité horaire des développeurs concernant la livraison de fonctionnalités n'a pas augmenté significativement. Mais comme il est attendu que la livraison aille logiquement plus vite, alors les développeurs travaillent plus, pensant que le problème est de leur côté, comme illustré par cet article qui montre que les développeurs utilisant l'IA vont terminer 27% de PR en plus (ce qui ne veut pas dire que la livraison va 27% plus vite) mais travaillent 20% plus longtemps que les autres.

Les entreprises d'IA

La plupart des entreprises d'IA américaines, Google, OpenAI et Meta en tête, ont passé des contrats avec ICE, la police de l'immigration américaine, qui expulse violemment des travailleurs du territoire américain (je vous laisse faire vos recherches) et a largement financé la campagne de Trump.

Quant à Anthropic, qui fait figure de “bon élève” en appelant à réguler l'IA, il joue sur les peurs des gens en faisant croire à l'arrivée imminente d'une IA super-intelligente, ce qui n'est que pur marketing car: 1) Il est peu probable qu'une quelconque superintelligence émerge en apprenant plus de mots à une machine à prédire des mots. 2) Cette rhétorique du “Attention on crée un produit si puissant qu'il peut détruire l'humanité, mais on veut pas le faire parce qu'on est gentils mais on a quand même des produits un peu moins puissant que vous pouvez acheter” est évidemment très profitable à Anthropic.

Le français Mistral semble être exempt de ces critiques mais cela ne règle pas les autres problèmes évoqués plus haut.

Autres considérations

Notre métier

D'après moi le métier de développeur se fait en 3 étapes : spécifier, coder, délivrer, et on recommence ces étapes en cas de bug. Ces 3 étapes sont un tout incompressible, si l'on réduit une de ces étapes les autres vont mécaniquement prendre plus de temps, de sorte à ce que le temps total ne sera pas affecté. Si l'on réalise n'importe laquelle de ces étapes avec une IA, notre compréhension s'en retrouvera affectée et cela se répercutera sur les étapes suivantes.

Code is cheap ?

Un argument que je vois souvent évoqué est que le code en lui même ne vaut plus rien et que seule la spécification compte. Cela me semble faux, la spécification est surtout là pour réduire au maximum l'écart entre le besoin et l'implémentation, mais à la fin le code est la spécification la plus précise qui soit, puisqu'il est littéralement la description de ce que l'ordinateur fait.

Lorsque vous générez du code avec une IA, vous spécifiez dans un language naturel (donc moins précis que du code) et vous extrapolez tout cela à travers une IA qui répondra souvent au besoin exprimé mais rarement au besoin réel. Vous allez donc devoir comprendre le code, générer à nouveau ou corriger à la main, tout en ayant une connaissance superficielle du code et en laissant probablement passer des erreurs invisibles (qui sont de + en + difficiles à détecter à mesure que les IA s'améliorent et que les développeurs ne sont plus capables de juger la qualité du code)

Je suis aussi personnellement convaincu que comprendre profondément une base de code est un atout essentiel dans le métier de développeur, cela permet de prendre de meilleures décisions, d'éviter de réinventer des choses existantes, de diagnostiquer + rapidement les bugs et de savoir quand il est judicieux de refactoriser.

Le mot de la fin

Mon avis est que l'IA ne doit être adoptée que lorsqu'elle permet d'augmenter la qualité du code et non pas la quantité de code. Utilisée par exemple comme outil de relecture, elle permet de repérer des erreurs ou des typos, et éviter aux collègues de devoir le faire et ainsi faire gagner du temps aux autres sur la relecture. Utilisé comme outil de recherche, elle permet d'approfondir certaines notions ou d'acquérir de nouvelles connaissances, qui font de nous de meilleurs développeurs.

Plus généralement, l'IA est utile lorsqu'il est possible d'évaluer la qualité de sa production sans aucune hésitation. Prenons l'exemple de l'extraction documentaire (c'est une partie de ce que nous faisons à mon boulot), il est extrêmement aisé de dire si l'IA a extrait correctement les informations d'un document : soit c'est juste soit c'est faux.

Quant à un bout de code, sa qualité est très difficile à juger, même pour un humain. La qualité d'un code se juge dans le contexte d'une application, en interaction avec les utilisateurs et le serveur sur lequel il tourne et du nombre de bugs qui émergent en production. Parfois même, la qualité d'un code se juge par son absence : un bon développeur refusera parfois de coder une fonctionnalité, ce que la plupart des IA ne fera pas puisque les entreprises les entrainent à être sycophantique (= tout le temps d'accord) pour maximiser l'engagement des utilisateurs, y compris celui des développeurs.

Je ne suis pas contre tous les usages de l'IA. Oui c'est une technologie impressionnante, qui a des usages utiles. Non, elle ne va pas détruire l'humanité ni remplacer tous les métiers intellectuels du monde car elle n'en est pas capable.