Carnet de notes

Catégorie : Technique

  • Quelques étapes de matu­rité

    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 –11.

    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. ↩︎

  • Impact de l’IA sur la recherche de failles de sécu­rité

    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

  • IA vs Google

    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.

  • Je ne crois pas à une crise de l’em­ploi dans le secteur logi­ciel

    Ma convic­tion c’est que, dans ce domaine, la demande croit expo­nen­tiel­le­ment avec la baisse des coûts. Les besoins en auto­ma­ti­sa­tion sont quasi illi­mi­tés, ils ne sont juste pas rentables.

    Si l’IA augmente la produc­ti­vité1, la baisse des coûts va libé­rer une masse de demandes qui n’étaient pas rentables avant et qui le devien­dront. Plus on baisse les coûts, plus la demande va être massive.

    Je ne crois pas une seconde à un renver­se­ment de l’équi­libre offre/demande. C’est une croyance, une convic­tion, comme tout dans ce billet, mais elle est forte.

    Pyramide de demande, écrasée sur le bas. Les demandes très rentables en haut, les demandes peu rentables en bas. Une ligne horizontale "palier en fonction du coût de l'offre" divise la pyramide. La demande satisfaite en haut, la demande non satisfaite en bas.

    Je ne crois pas à la crise au niveau du secteur, mais ça ne veut pas dire que ça ira bien.

    Dans le dernier billet je parle du fait d’impo­ser l’uti­li­sa­tion de l’IA dans les équipes de déve­lop­pe­ment logi­ciel. Je ne dis pas que c’est idéal, mais person­nel­le­ment je m’en fais beau­coup plus pour ceux dont l’en­tre­prise ne les pousse pas vers l’IA, voire ne les met pas en capa­cité d’ap­prendre cette nouvelle façon de déve­lop­per.

    Ceux qui n’aug­mentent pas leur produc­ti­vité via l’IA vont vivre deux effets :

    1. L’aug­men­ta­tion de la demande ne les concer­nera pas, vu que leurs coûts ne permet­tront pas la renta­bi­lité pour les clients
    2. Sur les niveaux de demandes pré-exis­tants, ils seront en concur­rence avec d’autres profes­sion­nels plus produc­tifs.

    Dans ceux là, les meilleurs vont proba­ble­ment simple­ment se retrou­ver massi­ve­ment déclas­sés. Les moins bons risquent de se retrou­ver sur le carreau, dura­ble­ment.

    Je ne parie même pas qu’il sera facile de chan­ger d’avis et embarquer dans le train de l’IA après coup : Il faudra un employeur qui parie sur le vieux déve­lop­peur qui n’a pas su ou pas voulu évoluer, espé­rer que cette fois ça va fonc­tion­ner, et ça plutôt qu’em­bau­cher un jeune IA-natif promet­teur et moins cher.

    1. C’est l’hy­po­thèse, mais si vous n’y croyez pas alors il n’y a pas de crise à anti­ci­per non plus, parce que ni l’offre ni la demande ne vont chan­ger. Vous pouvez arrê­ter la lecture ;-) ↩︎

  • Je n’ai pas peur pour les déve­lop­peurs juniors

    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.

  • « On m’oblige à utili­ser l’IA »

    Je le lis cette phrase depuis quelques temps sur les réseaux sociaux alors je fais mon coming out : Ça ne me semble pas forcé­ment anor­mal. Utili­ser l’IA fait même partie des direc­tives que je donne à mes équipes.

    Plus loin : C’est un critère de recru­te­ment. Jusqu’à présent je voulais des ingé­nieurs curieux, ayant envie d’es­sayer. Désor­mais je ne prends que des personnes qui ont déjà un réel usage. La géné­ra­tion de code sur plus de 80% de ce qui est livré est un prérequis, mais non suffi­sant. Ce que je cherche ce sont ceux qui vont plus loin, qui vont utili­ser l’IA comme levier pour l’en­semble des acti­vi­tés qu’ils auront au jour le jour.

    Si certains sont bloqués sur ces sujets par leur employeur actuel, je vais cher­cher ceux qui explorent massi­ve­ment côté perso et y voient la néces­sité de chan­ger d’em­ployeur.

    Une ques­tion de stra­té­gie

    Si vous êtes convain­cus que le télé­tra­vail est la meilleure façon d’or­ga­ni­ser le travail, vous allez instau­rer une culture et une orga­ni­sa­tion qui va avec. Ça peut être plus d’écrit, plus d’asyn­chrone, un dépla­ce­ment du budget des locaux vers le maté­riel ou vers des événe­ments ponc­tuels dans l’an­née pour se retrou­ver, ou quoi que ce soit que vous imagi­nez.

    Si vous trou­vez des candi­dats qui aiment se retrou­ver dans des locaux avec leurs collègues, qui vont privi­lé­gier les discus­sions de face à face, ça ne collera pas. Ni pour eux, ni pour vous. Parfois il faut faire un choix, et lais­ser chacun faire ce qu’il veut finit par ne conve­nir à personne.

    S’il s’agit d’ac­qué­rir cette nouvelle culture de télé­tra­vail, vous allez donner des guides. Pour acqué­rir les nouveaux usages il y a une phase de trans­for­ma­tion à passer, là où on ne voit pas encore toujours le béné­fice indi­vi­duel­le­ment.

    Chan­ger c’est diffi­cile, donc vous allez aussi réduire au maxi­mum le nombre de personnes qui auront ou pour­raient avoir du mal à chan­ger. Ça passera entre autres par un critère fort sur les recru­te­ments, et même poten­tiel­le­ment par des départs si le déca­lage ne peut pas être résolu malgré les efforts.

    Faire des choix

    C’est vrai pour le télé­tra­vail. Ça peut se traduire de la même façon pour l’ab­sence de télé­tra­vail. C’est vrai pour les choix tech­no­lo­giques, pour la langue de travail, pour les horaires, et même pour des choix cultu­rels ou les valeurs portées par l’en­tre­prise.

    Parfois c’est une convic­tion forte. Parfois, même sans dire qu’une option est meilleure que l’autre, il a été jugé impor­tant que ce soit un choix commun, partagé.

    C’est vrai pour tout choix stra­té­gique. Le fait de travailler massi­ve­ment avec ou sans l’IA en est un.

    Rien de plus, rien de moins

    Faire mon choix

    Et donc oui, j’ai une convic­tion forte, avec une stra­té­gie asso­ciée, et que ça implique un chan­ge­ment radi­cal de pratiques, de métier et de façon de penser. Un choix a été fait, radi­cal aussi.

    Ça ne dit pas que les autres choix sont mauvais, c’est juste celui là qui a été fait. Il y a d’autres équipes, avec d’autres choix, et chacun va où il se sent bien.

    Chan­ge­ment

    Certains m’ont remonté que  mon billet laisse croire que c’est unique­ment une ques­tion d’im­po­ser bruta­le­ment. Ce n’est pas le cas.

    Je parle de choix d’en­tre­prise. La façon de l’ame­ner, de le déployer, l’ac­com­pa­gne­ment ou la discus­sion sont un sujet à part entière.

    Le chan­ge­ment radi­cal est par contre côté recru­te­ment, juste­ment pour ne pas avoir ensuite à gérer des situa­tions diffi­ciles.

  • [Lecture] AI writes code faster. Your job is still to prove it works.

    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.

  • L’ar­ti­san et l’usine

    J’ai passé la majo­rité de ma vie à façon­ner du code, et j’en ai fait mon métier. Je me suis long­temps vu comme arti­san logi­ciel. Pour moi c’était une des spéci­fi­ci­tés de notre profes­sion. On ne faisait pas deux fois les choses de la même façon. Sinon c’était auto­ma­ti­sable, et auto­ma­tisé. Le déve­lop­pe­ment logi­ciel c’était ce qui restait, et c’était de l’ar­ti­sa­nat.

    Je remets en ques­tion cette vision depuis quelque temps.

    Fin de l’ar­ti­san logi­ciel

    L’ar­ri­vée de l’IA change ce qui est auto­ma­ti­sable, et donc les acti­vi­tés restantes. J’ai deux futurs auxquels je crois.

    Le premier, c’est celui de l’in­gé­nieur qui va mettre en place le cadre, les outils, la surveillance, les docu­men­ta­tions, la chaîne de produc­tion et de livrai­son. On passe de l’ar­ti­sa­nat à l’usine robo­ti­sée, comme plusieurs métiers avant nous.

    Le second reste quelque part un arti­san, mais un arti­san produit plus qu’un arti­san logi­ciel. L’enjeu est de remon­ter partiel­le­ment la chaîne, se concen­trer sur ce qu’on veut produire, pourquoi, comment, et traduire le besoin. C’est fina­le­ment ce qu’on fait déjà : le déve­lop­peur traduit des besoins en code. Cette traduc­tion sera diffé­rente, et moins proche du code.

    Ces deux trajec­toires ne s’ex­cluent pas. On pourra sans doute navi­guer de l’une à l’autre selon les projets, les envies, les moments de carrière. Mais dans les deux cas, le métier change, radi­ca­le­ment, et l’ar­ti­san logi­ciel ne sera proba­ble­ment plus au cœur de l’ac­ti­vité d’ici fin 2026.

    Ça demande de chan­ger de métier, et ça pose plein de ques­tions.

    Moyen ou fina­lité ?

    La ques­tion qui m’ap­pa­raît prégnante pour cette année 2026, c’est de savoir si on fait du logi­ciel parce qu’on aime faire du logi­ciel ou parce qu’on aime faire des choses avec du logi­ciel.

    Jusqu’à présent, les deux étaient assez indis­so­ciables. Pour faire des choses avec du logi­ciel, la meilleure façon était de faire du logi­ciel, avec atten­tion et exper­tise. Pour faire un bon logi­ciel, durable, main­te­nable, évolu­tif, il fallait travailler la qualité interne, à la main.

    Cette dualité permet­tait de botter en touche avec un « les deux ». Je ne crois pas que ce soit encore vrai, ni que ça le reste long­temps.

    Pour l’amour du code

    Il y a toujours un peu « des deux » mais je sais que ce qui me motive prin­ci­pa­le­ment : ce que je vais pouvoir faire avec le logi­ciel, pas le logi­ciel en lui-même.

    Je comprends parfai­te­ment ceux qui ont appris à aimer le code, à le peau­fi­ner, à le faire gran­dir, et dont c’est la moti­va­tion prin­ci­pale. Ceux-là voudront peut-être rester dans l’ar­ti­sa­nat logi­ciel.

    Il y a toujours des arti­sans potiers, céra­mistes et porce­lai­niers aujourd’­hui. Peu, mais il y en a. Ils répondent à des demandes diffé­rentes. Certains sont experts pour des demandes hors normes. D’autres, plus nombreux, visent des objec­tifs non utili­taires : le luxe, le tourisme, les cadeaux, les symboles, l’hé­ri­tage histo­rique, l’art.

    À quoi corres­pon­dra l’ar­ti­sa­nat dans le logi­ciel ? Je ne sais pas encore. Peut-être à des systèmes critiques où la confiance exige une main humaine. Peut-être à des créa­tions où l’in­ten­tion artis­tique prime sur l’ef­fi­ca­cité. Peut-être simple­ment au plai­sir de comprendre ce qu’on construit, ligne par ligne. Il y a un métier à trou­ver, ce ne sera pas tout à fait le même et il sera proba­ble­ment plus l’ex­cep­tion que la règle.

    Je serai proba­ble­ment toujours un arti­san logi­ciel. Mes premiers codes datent d’il y a presque 40 ans. On ne remet pas faci­le­ment au placard un tel héri­tage. Je pres­sens toute­fois que cet arti­sa­nat ne sera plus mon métier.

    Comme les photo­graphes qui n’ont jamais lâché l’ar­gen­tique et la démarche artis­tique, je conti­nue­rai proba­ble­ment à coder un peu à la main, mais pour le plai­sir. Côté déve­lop­pe­ment on a toujours eu un énorme terrain de jeu hors profes­sion­nel avec l’open source. Ça restera proba­ble­ment.

  • Acti­ver les couleurs P3 sur Fire­fox et Macos

    Je ne sais pas pourquoi, Fire­fox gère l’es­pace de couleurs P3 sur Windows et Linux mais le désac­tive par défaut sur Macos.

    Vous pouvez faire le test pour voir la diffé­rence entre Fire­fox et Safari.

    Je m’en suis rendu compte et j’ai cher­ché si je pouvais chan­ger ça. J’ai trouvé cette confi­gu­ra­tion qui fonc­tionne avec succès chez moi :

    gfx.color_management.mode = /System/Library/ColorSync/Profiles/Display P3.icc
gfx.color_management.native_srgb = false
gfx.color_management.mode = 1

    Je suis très curieux de comprendre pourquoi Fire­fox est si en retard là dessus, surtout sur Macos qui gère ça nati­ve­ment.

  • IA, l’élé­phant dans le couloir (quatrième)

    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.

    Impact d'une page de texte générée (400 tokens) avec le modèle Large 2 de Mistral AI. 1,14 gramme eqCO2 0,05 litre d'empreinte d'eau 0,2 milligramme eq Sb

    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.