Je demande parfois « Tu fais quoi avec l’IA ? ». L’in­gé­nie­rie logi­cielle c’est bien plus que taper du code mais je vais ici me concen­trer sur la géné­ra­tion de code.

Le niveau 0 c’est celui qui ne cherche pas à utili­ser l’IA mais qui ne fait pas la chasse non plus. Surprise, à ce niveau on l’uti­lise proba­ble­ment à plusieurs endroits sans le savoir, mais ça reste anec­do­tique.

C’est celui qui ne veut pas en entendre parler et qui fait atten­tion à exclure tout ce qui est lié à l’IA, c’est plutôt le niveau –1¹.

---

Note: Ne sautez pas les étapes. On a besoin de maitri­ser une étape avant de pouvoir passer à la suivante avec succès. Si vous allez trop vite, vous risquez de simple­ment faire n’im­porte quoi.

Pensez aussi à toute votre chaîne. Si votre version­ne­ment, votre inté­gra­tion conti­nue, vos pratiques de revue, votre archi­tec­ture ou vos tests ne sont pas au niveau, ou si globa­le­ment les bonnes pratiques de déve­lop­pe­ment logi­ciel modernes ne sont là, vous risquez de démul­ti­plier le bordel : Garbage in, garbage out.

1. L’usage de surface

L’usage de surface c’est si vous avez confi­guré copi­lot ou un système simi­laire dans votre IDE. Il y a de la complé­tion auto­ma­tique un peu intel­li­gente sur une ou plusieurs lignes.

Honnê­te­ment, si vous n’avez pas une aver­sion forte à l’IA, foncez.

C’est l’étape qui va juste vous appor­ter un peu de confort gratuit sans rien chan­ger à votre métier. Les modèles liés sont des tout petits modèles pour que ça tourne rapi­de­ment, donc il n’y a pas vrai­ment d’enjeu éner­gé­tique non plus.

La première marche est de commen­cer à utili­ser l’in­ter­face de chat pour poser des ques­tions sur un méca­nisme que vous ne connais­sez pas, ou pour comprendre le fonc­tion­ne­ment d’un code qui n’est pas le vôtre.

La seconde marche est l’uti­li­sa­tion des inter­faces de chat pour faire de la géné­ra­tion. Au départ on se contente des sque­lettes géné­riques initiaux qu’on modi­fiera ensuite. Assez vite on tente des modi­fi­ca­tions contex­tuelles locales ou de la revue de code, pour voir.

Ne vous atten­dez à rien d’ex­cep­tion­nel. C’est juste un outil de plus qui peut aider. Pensez à bien gérer votre version­ne­ment, avec des commit avant et après le passage de l’IA, pour annu­ler tout faci­le­ment.

Si vous en êtes là, tentez les fonc­tions de debug de Cursor. Vous allez voir la machine faire des hypo­thèses, monter du moni­to­ring, et itérer jusqu’à trou­ver et corri­ger la source du problème (avec votre aide). Ça ne fonc­tionne pas à tous les coups mais c’est une bonne aide en première inten­tion.

2. Approche tech­nique

Le premier palier inté­res­sant c’est celui là. L’in­ter­face de chat sert à géné­rer le cœur du code. L’idée c’est de commen­cer à plus géné­rer de code qu’en écrire.

Les premières fois on reste sur une approche tech­nique. C’est vous qui deman­dez expli­ci­te­ment quelle fonc­tion, quel fichier, quelle archi­tec­ture.

Cette étape peut être frus­trante, parce qu’on a l’im­pres­sion de prendre un bébé par la main et perdre du temps à tout expliquer ce qu’on pour­rait taper aussi rapi­de­ment, et parfois mieux ou plus court. C’est là qu’on perd pas mal de monde qui « a essayé » sans oser vrai­ment plon­ger dedans.

Commen­cez à vous forcer à faire corri­ger au lieu de corri­ger vous-mêmes, pour apprendre comment faire le prompt. Ajou­tez quelques règles par défaut pour que ça utilise vos styles et vos outils.

Le gain c’est quand, au lieu de faire corri­ger au fur et à mesure, on utilise le mode plan. Là on commence à guider l’ar­chi­tec­ture et à orga­ni­ser ce qu’on veut. C’est aussi un gain direct pour les plus jeunes parce que ça permet de se concen­trer sur l’im­por­tant au lieu de se perdre dans l’im­plé­men­ta­tion.

3. Approche fonc­tion­nelle

Pour moi le vrai palier de valeur ajou­tée a été d’ar­rê­ter de faire du baby-sitting et de commen­cer à donner des inten­tions plutôt que des instruc­tions. Le mode plan se charge de traduire ça et me permet d’in­ter­ve­nir avant la géné­ra­tion elle-même.

Spéci­fiez au fur et à mesure vos choix archi­tec­tu­raux, styles, contraintes et choix tech­no­lo­giques pour que ça vous demande le moins de re-travail possible. Au fur et à mesure, créez des règles cursor/claude pour ça et amélio­rez les chaque fois que vous avez besoin de préci­ser quelque chose de géné­rique.

Vous en êtes là ? Le palier suivant c’est d’im­po­ser des choses comme le TDD et le déve­lop­pe­ment par contrat. Deman­dez de commen­cer par les tests et les inter­faces, faites une revue sérieuse de cette étape. Le risque de surprise dimi­nue énor­mé­ment sur la suite. Ça vous permet­tra aussi de vous concen­trer sur l’im­por­tant.

4. Approche par spéci­fi­ca­tion

Le mode plan est une évidence. Pourquoi ne pas pous­ser plus loin et conce­voir les plans en mode plan ?

On commence par travailler sur des fichiers de spéci­fi­ca­tions fonc­tion­nelles et tech­nique, en mode plan. À partir de ces spéci­fi­ca­tions fonc­tion­nelles et tech­niques, on demande de créer décou­pages des tâches et des plans d’im­plé­men­ta­tion détaillés pour chaque tâche.

On itère sur chaque étape, en se concen­trant d’abord sur le haut niveau, puis en descen­dant avec plus de détail à chaque fois, concen­tré sur une tâche précise. On pourra ensuite deman­der l’exé­cu­tion des tâches, une à une (en mode plan si ça vous amuse, mais c’est proba­ble­ment moins néces­saire à ce niveau là), poten­tiel­le­ment avec un modèle moins coûteux.

C’est un vrai chan­ge­ment de travail mais on ne se détache ni de la tech­nique ni du fonc­tion­nel : on travaille sur l’im­por­tant. Taper des formu­laires, des tests et des fonc­tions utili­taires n’est clai­re­ment pas ce qui me semble le plus stimu­lant. Réflé­chir à quoi faire et comment : si.

Vous en êtes là ? Le palier suivant c’est toujours de penser plan plutôt que de four­nir des instruc­tions et de correc­tions éphé­mères pour modi­fier le résul­tat. Si un code ne corres­pond pas, amélio­rez le fichier de tâche corres­pon­dant et regé­né­rez. Si une tâche ou un enchaî­ne­ment de tâches n’est pas bon, amélio­rez les spéci­fi­ca­tions et regé­né­rez.

L’avan­tage annexe c’est qu’on peut poser quand on veut, travailler à plusieurs, et modi­fier tout ce qu’on souhaite après coup. On a aussi une docu­men­ta­tion durable de ce qu’on fait.

5. Auto­ma­ti­sa­tion

Ce que je vois venir ensuite c’est l’au­to­ma­ti­sa­tion de tout ça. On complète les règles et on crée des agents. On lie nos spéci­fi­ca­tions et nos tâches à la docu­men­ta­tion, leur statut à l’ou­til de gestion de projet.

Les tâches peuvent récu­pé­rer les retours de la chaîne d’in­té­gra­tion conti­nue et plani­fier des correc­tions immé­dia­te­ment avant que vous ne passiez pour la revue manuelle. Même chose pour des pré-revues de code auto­ma­tiques.

Ces revues de code auto­ma­tiques peuvent tenter de quali­fier les risques et propo­ser de vali­der auto­ma­tique­ment les chan­ge­ments non risqués (après une période où on aura confirmé que l’hu­main n’a en effet jamais eu à redire sur les chan­ge­ments quali­fiés comme non-risqués).

On ajoute des agents qui vont surveiller la qualité de code, la main­te­na­bi­lité, la sécu­rité, la cohé­rence, et qui vont tenter des refac­to­ring auto­ma­tique­ment quand il commence à y avoir trop de dupli­ca­tion ou de complexité. On peut aussi ajou­ter des agents qui vont s’oc­cu­per des montées en version qui ont un impact sur le code. Il y a tant de tâches qui peuvent être auto­ma­ti­sées une fois qu’on a un peu de temps libé­ré…

Bref, si le harnais de test est suffi­sant, ce qui ne tient qu’à nous au niveau des spéci­fi­ca­tions et plans d’im­plé­men­ta­tion vu que désor­mais mettre à jour les tests ne coûte pas forcé­ment cher, on peut commen­cer à penser l’in­dus­tria­li­sa­tion de toute la chaîne.

---

1. Pas de juge­ment de valeur. On parle de –1 en terme d’uti­li­sa­tion de l’IA. ↩︎

Simon Willi­son a démarré un regrou­pe­ment de ses liens à propos d’IA et de recherche de sécu­rité.

Les cita­tions montrent qu’il se passe indé­nia­ble­ment quelque chose. La seconde cita­tion (au moment où j’écris ce billet) est majeure.

On the kernel secu­rity list we’ve seen a huge bump of reports. We were between 2 and 3 per week maybe two years ago, then reached proba­bly 10 a week over the last year with the only diffe­rence being only AI slop, and now since the begin­ning of the year we’re around 5–10 per day depen­ding on the days (fridays and tues­days seem the worst). Now most of these reports are correct, to the point that we had to bring in more main­tai­ners to help us.

And we’re now seeing on a daily basis some­thing that never happe­ned before: dupli­cate reports, or the same bug found by two different people using (possi­bly slightly) different tools.

— Willy Tarreau, Lead Soft­ware Deve­lo­per. HAPROXY

Les esti­ma­tions de coût éner­gé­tique convergent depuis un an vers envi­ron 0.3Wh par requête stan­dard sur un LLM de grande taille (ChatGPT, Claude, Gemini).

À ça on peut ajou­ter envi­ron 50% de coûts fixes pour l’en­traî­ne­ment.

Je faisais des compa­rai­sons avec des coûts carbone dans mes précé­dents billets.

Une étude fait un autre compa­ra­tif inté­res­sant. 0.3Wh c’est aussi l’es­ti­ma­tion du coût éner­gé­tique d’une recherche Google. Ça a déjà de quoi remettre quelques préju­gés en place mais l’étude regarde ce qu’il se passe si on prend toute la chaîne de recherche.

Là c’est renver­sant.

Une recherche web c’est une page web, et rien que la trans­mis­sion d’une page web moyenne par 4G coûte plus d’éner­gie que la recherche. Si vous ouvrez plusieurs pages à partir des liens retour­nés par Google, autant dire que la consom­ma­tion explose.

S’il y a de la publi­cité sur la page web, on ajoute 0.10 à 0.25Wh par page, ce qui est loin d’être négli­geable face au 0.3Wh de la requête LLM.

Le papier mérite d’être lu, rien que pour prendre conscience des échelles des diffé­rents éléments. On est loin de l’in­tui­tif.

L’IA demande de savoir relire le code. On sait le faire parce qu’on a appris à l’écrire. Comment feront les jeunes qui n’ont pas eu cette expé­rience ?

Je n’ai pas cette peur.

Je me repose sur ma calcu­lette et je fais peu de calcul mental. Je ne saurais même pas utili­ser une règle à calcu­ler. Je n’ai que peu de formules ou données en tête, et je me repo­se­rai sur le web pour les retrou­ver en cas de besoin.

Bref, il y a plein de choses que je ne sais pas faire alors que ça tombait sous le sens pour des plus âgés. Il y en a certaines qui ne me servent plus, ou qui ne me sont plus aussi impor­tantes. Il y en a d’autres qui ont été rempla­cées par des outils. En échange, j’ai des nouveaux savoirs et des nouvelles compé­tences, que mes ainés n’avaient pas et qui me sont bien plus utiles aujourd’­hui. Je ne me sens pas perdant au final.

---

Je n’ai pas peur pour les jeunes parce que je pense que ça revient exac­te­ment à ça.

S’ils en ont moins besoin avec l’IA, les jeunes auront peut-être moins d’ex­per­tise dans le code. Ils appren­dront d’autres choses que moi je ne sais pas faire. Au final, accom­pa­gnés de l’IA, ils auront certai­ne­ment plus de capa­cité que je n’en ai moi aujourd’­hui.

S’ils en ont moins besoin.

Ou alors ils en auront besoin de cette exper­tise dans le code, et alors ils l’ap­pren­dront, au fur et à mesure, en commençant par faire plein de bêtises comme un junior puis en gagnant en expé­rience.

Peut-être qu’ils l’ap­pren­dront diffé­rem­ment, en reli­sant et en vali­dant des IA plutôt qu’en écri­vant eux-mêmes, ou en faisant plus de pair-progra­ming que je n’ai pu en faire à mon époque.

Ce qui est certain c’est que, si c’est néces­saire, cet appren­tis­sage aura lieu d’une façon ou d’une autre.

Si c’est néces­saire.

Je ne sais pas si ça restera néces­saire ou s’ils en auront moins besoin, mais je ne m’en fais dans aucun des deux cas. Ils s’adap­te­ront à ce besoin.

---

Je m’en fais en réalité beau­coup plus pour les plus vieux, ceux qui n’au­ront pas appris à se servir de l’IA, ou qui n’au­ront pas changé leur façon de penser et de travailler. Ceux pour qui je m’en fais c’est pour les expé­ri­men­tés actuels, pas pour les futurs juniors.

Je m’en fais pour eux parce que chan­ger, remettre en cause notre façon d’abor­der le métier et nous adap­ter à une nouvelle réalité, c’est beau­coup plus diffi­cile que de commen­cer de zéro avec cette nouvelle réalité.

Entre le vieux qui sait tout de tête et le jeune accom­pa­gné d’In­ter­net et de son smart­phone, person­nel­le­ment je parie sur le jeune.

Cet article met proba­ble­ment le doigt sur une des incom­pré­hen­sions j’ai avec les inter­lo­cu­teurs critiques à propos d’ia dans les proces­sus de dev.

Il ne s’agit pas de tout accep­ter. Oui, l’IA aujourd’­hui amène son lot de défauts. Je ne compare pas la qualité de la produc­tion de l’IA avec la qualité de la produc­tion d’un dev humain.

C’est tout le proces­sus qui change. Ce que je compare c’est le résul­tat d’un proces­sus histo­rique avec celui où l’IA est au centre. Dans ce second proces­sus on a aujourd’­hui un dev qui véri­fie, qui relance, qui contraint. C’est un chan­ge­ment de métier.

L’ar­­ticle parle de revue mais les deux points à rete­­nir pour moi c’est que l’hu­­main doit rester en maîtrise et toujours prou­­ver que le résul­­tat est le bon, sans juste faire confiance, et que le volume de code est un ennemi encore plus fort qu’a­­vant parce que l’IA est forte à géné­­rer beau­­coup de code.

J’étais resté sur des esti­ma­tions assez diverses lors de mon dernier billet.

Là on a une colla­bo­ra­tion entre Carbone 4 (Jean-Marc Janco­vici) et Mistral sur leur plus gros modèle, en regar­dant le cycle de vie complet : en partant de la construc­tion des équi­pe­ments et des data­cen­ter jusqu’au réseau et au termi­nal des utili­sa­teurs finaux, en passant bien évidem­ment par l’en­trai­ne­ment et le coût des requêtes elles-mêmes.

Je vais lais­ser la ques­tion des mine­rais parce que je connais trop peu le sujet (vos liens sont les bien­ve­nus).

Le reste je sais compa­rer.

En équi­valent CO2, votre tasse de café du matin vaut dans les 500 pages de texte géné­rées par le modèle de langage le pIus large, entrai­ne­ment et maté­riel inclus.

Un repas une fois dans l’an­née avec 100 grammes de crevettes, c’est l’équi­valent de 1 750 de pages de texte géné­rées par le modèle de langage le plus large, entrai­ne­ment et maté­riel inclus, soit presque 5 pages par jour.

En eau c’est encore plus flagrant. Votre tasse de café du matin a une empreinte de 140 litres d’eau (non, il n’y a pas d’er­reur de virgule), soit envi­ron 2 800 pages de texte géné­rées par le modèle de langage le plus large.

Une petite portion de 120 grammes de bœuf une seule fois dans l’an­née c’est l’équi­valent en eau de 9 pages de textes géné­rées par le modèle de langage le plus large, chaque jour, toute l’an­née.

---

Encore cette fois-ci, mon discours n’est pas de dire qu’on s’en moque, surtout si ces usages s’ajoutent partiel­le­ment aux exis­tants — chaque ajout freine la baisse néces­saire de nos émis­sions — mais il est préfé­rable de garder les ordres de gran­deur en tête pour éviter de foca­li­ser au mauvais endroit.

Pour pous­ser le bouchon : Si une marque de cafe­tières propo­sait d’em­barquer un petit modèle de langage dans ses appa­reils pour limi­ter les fuites ou les tasses trop remplies (c’est un exer­cice de pensée, les LLMs seraient tota­le­ment inutiles pour ça en réalité), je suis certain qu’on enten­drait crier à l’as­sas­si­nat de la terre alors que ça serait très faci­le­ment rentable du point de vue des enjeux clima­tiques et des ressources terrestres.

TL;DR: Arrê­tez le café, la viande rouge et les crevettes.

---

Vu autre­ment, même en utili­sant très massi­ve­ment l’IA (100 pages géné­rées par jour, ce qui me parait énorme), en le faisant avec le modèle le plus large (pourquoi ?), on est à 41 Kg eqCO2 et 1 800 L d’em­preinte d’eau. Ça repré­sen­te­rait 0,5% de la consom­ma­tion d’un français moyen en eqCO2 (8 tonnes eqCO2 annuelles) et 0,8% en empreinte d’eau (214 000 litres annuels), sachant que ça évite aussi quelques usages donc on ne peut pas se conten­ter d’ad­di­tion­ner.

Bien évidem­ment, ça a aujourd’­hui peu de sens d’ima­gi­ner avoir une telle consom­ma­tion, même pour quelqu’un qui s’y livre massi­ve­ment, et encore moins en utili­sant à chaque fois les modèles les plus larges.

Ça permet toute­fois de tracer une limite haute. Sauf rare excep­tion, même les plus gros utili­sa­teurs ne vont pas se retrou­ver avec un usage signi­fi­ca­tif par rapport à leur vie actuelle.