Carnet de notes

Catégorie : IA

  • Je ne crains pas de perdre mon travail

    Je ne demande même que ça.

    Travail n.m. (lat. pop. tripa­lium ; de tres, trois et palus pieu) instru­ment de torture puis appa­reil où l’on place les bœufs pour les ferrer

    Quelle mouche a donc piqué notre société pour qu’on veuille sauve­gar­der le travail ? Je suis des plus heureux que l’au­to­ma­ti­sa­tion m’épargne une quan­tité de travaux des siècles derniers, et qu’elle nous ait permis d’avoir un meilleur confort et une meilleure vie.

    J’ai une machine à laver le linge et une pour la vais­selle. J’ai une calcu­lette ainsi qu’un micro-ordi­na­teur portable. L’élec­tri­cité m’ap­porte aussi la lumière, la cuis­son, un ascen­seur et certai­ne­ment cent autres appa­reils quoti­diens.

    On est telle­ment entou­rés de travail auto­ma­tisé qu’on oublie que le travail manuel n’est plus que l’ex­cep­tion.

    Et tant mieux. Je n’en­vie pas le temps des labours manuels, des porteurs d’eau, de la coupe du bois de chauf­fage, des dépla­ce­ments à pieds peu importe la distance, etc.

    C’est la part des richesses appor­tée à chacun qu’il faut sauve­gar­der, pas le travail.

    Confondre les deux relève quand même d’un aveu­glé­ment assez profond.

    Richesses, subst. fém.
    Tout ce qui est suscep­tible de combler, de satis­faire les désirs, les besoins de l’homme.

    Le problème n’est pas que l’au­to­ma­ti­sa­tion retire du travail, ni même qu’on manque de richesses. Le problème c’est que l’au­to­ma­ti­sa­tion du travail modi­fie la répar­ti­tion des richesses (vers une plus grande concen­tra­tion).

    Dans un monde capi­ta­liste, la richesse appar­tient d’abord à celui qui contrôle les moyens de produc­tion. Il y a long­temps c’était la terre. Désor­mais ce sont les machines et les infra­struc­tures. Demain ce sera peut-être ce qu’on nomme les intel­li­gences arti­fi­cielles.

    Pour partie, les emplois perdus sont recréés ailleurs. L’enjeu c’est d’as­su­rer la tran­si­tion. Le chômage et la forma­tion sont des réponses mais elles ne sont que partielles. Ceux qui perdent un emploi ne sont pas forcé­ment les mêmes que ceux qui en trouvent un nouveau.

    Malheu­reu­se­ment, nos élus tendent à rabo­ter le chômage et culpa­bi­li­ser les personnes qui perdent leur emploi. Tout ceci est pour­tant struc­tu­rel, attendu. Il ne reste qu’un RSA de misère qui repré­sente à peine la moitié du seuil de pauvreté.

    Pour ne rien gâcher, nos élus tendent à vouloir augmen­ter le temps de travail, donc concen­trer l’em­ploi et les richesses acquises ainsi sur moins de personnes, avec forcé­ment plus de lais­sés pour compte.

    Prépa­rer la révo­lu­tion

    Ce qu’on nomme intel­li­gence arti­fi­cielle rend envi­sa­geable à une révo­lu­tion à court terme. On y croit ou on n’y croit pas, mais c’est un avenir possible, crédible.

    La diffé­rence avec la révo­lu­tion de la vapeur, de l’au­to­ma­ti­sa­tion des usines et de l’élec­tro­nique, c’est la vitesse à laquelle on imagine l’au­to­ma­ti­sa­tion prendre place.

    Ça peut être sanglant, à un point diffi­ci­le­ment compa­rable avec le passé.

    Le chômage ne peut pas être la solu­tion. L’es­poir dans la créa­tion de nouveaux types d’em­plois non plus. L’échelle des temps n’est pas la bonne.

    Il faut autre chose. D’au­cuns parlent de revenu de base, de revenu d’exis­tence ou de salaire à vie. Peu importe. Ça peut être ça ou autre chose, mais on a besoin d’une solu­tion, et on a très peu de temps pour la mettre en place.

    Si nous ne sommes pas prêts c’est un autre type de révo­lu­tion qui peut venir, tout aussi sanglant.

    Lâcheté et absence du poli­tique

    Sauve­gar­der le travail est déjà un non-sens à la base. Faire faire du travail inutile pour éviter de penser la répar­ti­tion des richesses, c’est botter en touche.

    Ça peut fonc­tion­ner pour quelques mois, quelques années, mais pas plus, et à petite échelle. Face à l’am­pleur du chan­ge­ment qu’on entre­voit, ça n’est même pas une possi­bi­lité. On mérite un peu plus de hauteur et de vision.

    Entre temps, tout ce qu’on obtient c’est de soli­di­fier le rapport de domi­na­tion entre les déten­teurs du capi­tal et ceux qui vendent leur travail, physique ou intel­lec­tuel. Comme les second n’ont pas le choix, que les premiers voient venir la possi­bi­lité d’agir seuls, on entame un cycle de régres­sions sociales.

    Tout poli­tique qui trouve sa réponse dans la sauve­garde du travail ou qui cède aux chan­tages à l’em­ploi des grandes socié­tés devrait être hué et renvoyé chez lui. Ceux qui ignorent la ques­tion ne méritent guère mieux.

    Malheu­reu­se­ment les propo­si­tions alter­na­tives ne se croisent pas ailleurs que sur les sites web. Il n’y a aucune vraie action en ce sens.

    Le fascisme qui vient

    Le fascisme et l’au­to­ri­ta­risme qui ne sont pas étran­gers à tout ça.

    On arrive au bout d’un système. On le fait perdu­rer en renforçant le main­tient de l’ordre (police, lois, enfer­me­ment, pouvoirs de l’exé­cu­tif) et en bridant la capa­cité de s’or­ga­ni­ser (répres­sion des mouve­ments sociaux, guerre ou jeux, menaces socié­tales réelles ou fantas­mées, renfor­ce­ment de la pola­ri­sa­tion, dési­gna­tion de coupables, oppo­ser les uns et les autres).

    Il n’y a pas de complot, juste un engre­nage qui se met en place de lui-même par la lâcheté ou la courte vue de nos respon­sables poli­tiques.

    Les déten­deurs du capi­tal sont malheu­reu­se­ment histo­rique­ment assez à l’aise voire acteurs dans ces périodes, et c’est encore le cas aujourd’­hui. Leur pouvoir s’y renforce.

    Ça tient un temps, jusqu’à soit explo­ser soit sentir très mauvais. Les deux ne s’ex­cluant pas.

  • Lâcher les coûts

    L’ar­ri­vée des LLMs dans le déve­lop­pe­ment web met pas mal en lumière l’ap­proche inco­hé­rente de la plupart des socié­tés françaises par rapport aux coûts.

    Un Cursor c’est 40$ par mois et par déve­lop­peur. C’est moins d’une heure de travail d’un déve­lop­peur stan­dard en France.

    On est en dessous des paliers où on devrait même en parler. Si l’au­to­no­mie de vos déve­lop­peurs ne va pas jusqu’à leur faire confiance pour une heure de travail, vous avez pas mal de choses à remettre en cause dans votre orga­ni­sa­tion.

    En réalité, les équipes qui font d’ores-et-déjà un usage inten­sif de l’IA sur tout leur process — et pas unique­ment la côté complé­tion de code dans l’édi­teur —1 ont proba­ble­ment des factures qui sont au-delà des 100$ ou 200$ par mois et par déve­lop­peur.

    Je ne serais pas étonné que, dans ces équipes, on trouve faci­le­ment la demie-jour­née de travail gagnée qui justi­fie l’abon­ne­ment Ultra à 200$.

    En fait, dans mes lectures actuelles, je vois même parler de 2000$ par mois et par déve­lop­peur. Là on commence à parler. Là ça demande de savoir si on démul­ti­plie vrai­ment la force de travail ou si on se contente de faci­li­ter le travail.

    Peut-être que le coût se justi­fie déjà, et on a un chan­ge­ment struc­tu­rel dans la façon de travailler. Peut-être que ce n’est pas encore le cas, mais lais­ser ceux qui le veulent jouer à ce niveau rend possible de voir appa­raitre un tel chan­ge­ment2.

    Le vrai enjeu est ici. Je suis heureux de débattre sur comment on peut chan­ger la donne, pas de me battre sur le coûts d’ou­tils qui repré­sentent moins d’une poignée d’heures par mois.

    1. Il parait que le quadra­tin est désor­mais devenu un marqueur pour détec­ter l’usage de textes rédi­gés par IA. Je ris jaune. Vous trou­ve­rez dans mes textes sur ce blog un usage régu­lier de cette typo­gra­phie depuis 15 ou 20 ans. Tirez-en les conclu­sions que vous voulez. ↩︎
    2. On dit que l’in­no­va­tion nait par la contrainte. Elle nait aussi par l’op­por­tu­nité et la liberté de sortir du terrain connu pour essayer, sans savoir ce que ça peut donner. ↩︎

  • IA : L’élé­­phant dans le couloir (ter)

    Je n’ai pas encore résolu mes inter­ro­ga­tions et mes contra­dic­tions sur le sujet de l’IA et de son impact sur la planète.

    Je retiens toute­fois quatre points :

    1– Personne ne peut prétendre savoir ce que sera l’ave­nir.

    On ne sait pas à quel point les usages vont s’en­vo­ler ou pas. On ne sait pas quels seront ces usages. On ne sait pas s’ils vont rempla­cer d’autres usages, ni lesquels ni en quelle propor­tion. On ne sait pas quelle sera la consom­ma­tion ni la taille des modèles futurs.

    On ne sait honnê­te­ment pas grand chose.

    Si les projec­tions sont des exer­cices inté­res­sants, il ne faut pas confondre ça avec des prédic­tions.

    2– Il y a certains futurs possibles où l’im­pact de ces outils sur la planète pour­rait deve­nir signi­fi­ca­tif, voire un des enjeux à résoudre dans le cadre de la lutte contre le chan­ge­ment clima­tique.

    Les limites de notre planète et le chan­ge­ment clima­tique sont à mes yeux peut-être les plus grands enjeux que l’hu­ma­nité ait eu depuis qu’elle existe, et les consé­quences seront proba­ble­ment désas­treuse.

    Ajou­ter au problème ou frei­ner les mesures d’at­té­nua­tion sont des risques loin d’être anodins.

    3– Il faut garder en tête les ordres de gran­deur.

    Les esti­ma­tions récentes descendent à 0.3Wh pour une requête stan­dard à un ChatGPT-like. Si les chiffres varient, on peut dessi­ner une borne supé­rieure à 3Wh.

    À 0,3Wh1, perdre 5 minutes à rédi­ger une conclu­sion ou un listing d’ac­tions, à faire une relec­ture d’or­tho­graphe ou de gram­maire sur un docu­ment, ou à faire une traduc­tion rapide, c’est entre 5 et 10 requêtes2. Ouvrir le frigo une fois de trop c’est de l’ordre de 30 à 40 requêtes3. Réchauf­fer des restes 3 minutes au micro-onde au lieu de manger froid c’est 150 requêtes4.

    Les plus curieux trou­ve­ront plein d’autres compa­rai­sons dans le point d’étape précé­dent.

    J’ajoute au moins que faire soirée raclette dans l’an­née c’est de l’ordre de 25 000 requêtes ChatGPT-like par personne, soit 60 tous les jours pendant un an5.

    Ça ne veut pas dire que ça n’a pas d’im­por­tance, et tout ajout est un ajout de trop, mais se foca­li­ser sur les usages actuels risque de géné­rer beau­coup d’at­ten­tion au mauvais endroit. C’est vrai autant à titre indi­vi­duel qu’à titre collec­tif.

    4– Certains usages ont un gain net.

    En repre­nant les exemples plus haut, utili­ser l’IA pour faire traduire, résu­mer, relire des docu­ments ou recher­cher dans ceux-ci plutôt que le faire à la main permet proba­ble­ment de dimi­nuer l’im­pact sur la planète.

    C’est pareil si l’as­sis­tance de l’IA pour cher­cher et réali­ser des menus peut permettre une fois de temps en temps d’évi­ter un aller-retour au frigo, de jeter un reste ou d’avoir une recette froide plutôt que chaude.

    Culpa­bi­li­ser l’usage par prin­cipe ressemble aux mêmes mauvaises idées derrières de bonnes inten­tions que le tri des emails qui impose de passer du temps sur l’or­di­na­teur ou le pipi sous une douche qui dure plus long­temps.

    Je n’ai toujours pas de conclu­sion.

    Ce n’est pas un décompte.

    Le second point a tendance à réveiller ma trouille déjà exis­tante sur ce que sera la vie des géné­ra­tions suivantes, dont celle de mon fils.

    Je ne veux surtout pas que les autres points incitent quiconque à mini­mi­ser ce risque ou son impor­tance.

    Agiter le chif­fon rouge ne me parait pas pour autant une bonne idée et je pense que ce serait une erreur que de trai­ter la chose de façon binaire par anti­ci­pa­tion.

    Pour l’ins­tant j’en suis là.

    Comme je disais en intro­duc­tion, j’ai encore plus de ques­tions que de réponses, et encore des contra­dic­tions.

    1. C’est ce qui semble ressor­tir de mes lectures. Si on prend 3Wh comme réfé­rence certaines compa­rai­sons sont moins impres­sion­nantes mais le prin­cipe reste. ↩︎
    2. 10W pour un ordi­na­teur portable en très faible acti­vité + 20W pour un écran externe de taille clas­sique. ↩︎
    3. Ordre de gran­deur de 1kWh par jour, consom­ma­tion augmen­tée de 17% pour 15 ouver­tures par jour ↩︎
    4. Micro-onde à 900W ↩︎
    5. Esti­ma­tion de 2,5kg d’eqCO2 par personne traduite en consom­ma­tion éner­gé­tique à l’aide du mix des USA de 365 g d’eqCO2 par kWh ↩︎

  • IA sans l’in­tel­li­gence

    Je n’aime pas ce terme d’IA, intel­li­gence arti­fi­cielle.

    On trompe les gens. On provoque un imagi­naire de science fiction avec les robots conscients d’Asi­mov et des intel­li­gences arti­fi­cielles éthé­rées de cyber­punk.

    Ce qui est sous nos doigts aujourd’­hui ne réflé­chit pas. Ce n’est pas de l’« intel­li­gence » au sens où on l’en­tend commu­né­ment mais ça reste majeur. Ça reste un poten­tiel boule­ver­se­ment socié­tal majeur.

    J’ai tenté de parler de LLM, large language model, mais c’est cibler une tech­no­lo­gie spéci­fique. Je vais conti­nuer à parler d’IA, mais je n’aime pas ça.

    Gardez-vous de vous moquer parce que ChatGPT fait une erreur sur une addi­tion de nombres à deux chiffres. L’enjeu n’est pas là.

  • IA : L’élé­phant dans le couloir (bis)

    J’avais tenté de récol­ter un peu de donnée sérieuse sur la consom­ma­tion éner­gé­tique des LLMs. C’est labo­rieux, et je n’ai pas trouvé le consen­sus que je cher­chais.

    Les données ne sont pas publiques, si tant est qu’elles soient connues, et tout n’est qu’es­ti­ma­tion à base d’hy­po­thèses.

    Il y a à la fois profu­sion d’in­for­ma­tion et de chiffres lancés, et en même temps pas tant d’études récentes qui détaillent tout ça. Celles qui existent donnent des résul­tats parfois extrê­me­ment diffé­rents les unes des autres, sur des hypo­thèses elles-aussi diffé­rentes et parfois discu­tables.

    Le tout est aussi dépen­dant de la taille comme de la géné­ra­tion du modèle utilisé. Certains demandent du calcul paral­lèle sur plusieurs GPU dédiés, d’autres sont assez petits pour tour­ner direc­te­ment sur le télé­phone. La consom­ma­tion éner­gé­tique est en fonc­tion.

    Bref, plein de choses à lire, sans qu’on puisse faci­le­ment en déter­mi­ner la fiabi­lité des esti­ma­tions ou la perti­nence des hypo­thèses. Chacun trou­vera son bonheur en fonc­tion des biais qu’il aura au départ.

    Je n’ai toute­fois pas été le seul à faire ces recherches, et il y a des réponses inté­res­santes.

    Si je ne devais donner qu’un lien pour commen­cer, c’est Andy Masley, qui a tenté l’exer­cice de tout fouiller pour tirer ses conclu­sions et qui a ensuite itéré avec les réac­tions qu’il a eu, liant plein de sources et de réac­tions sur le web, avec tendance à remettre ses chiffres et conclu­sions en cause quand c’est perti­nent (atti­tude qui me donne confiance). Vous pouvez commen­cer par le dernier épisode et suivre lien à lien.

    Note : Ce qui suit ne porte pas de juge­ment de valeur. Je ne dis pas si c’est bien, grave, ou quoi que ce soit. Tirez-en vous-mêmes vos conclu­sions.

    Elle est de combien cette consom­ma­tion éner­gé­tique alors ?

    Les études sérieuses récentes parlent d’entre 0.3 et 2.9Wh par requête ChatGPT, en faisant réfé­rence à des géné­ra­tions diffé­rentes1, et certaines avec des hypo­thèses d’en­trée/sortie d’un ordre de gran­deur plus grand que la requête moyenne. On trouve aussi du 0,2Wh pour LLaMA-65B. HuggingFace donne une esti­ma­tion éner­gé­tique de chaque requête, et j’ob­tiens plutôt du 0,18Wh pour Qwen 2.5 en 72B.

    Les pessi­mistes pren­dront 3Wh, les opti­mistes 0.3Wh2. Les deux sont crédibles.

    Malheu­reu­se­ment ça veut aussi dire que toute conclu­sion tient en équi­libre sur une donnée dont on ne connait même pas l’ordre de gran­deur réel.

    Si en plus on ajoute les modèles de taille infé­rieure comme les chatGPT-nano et les modèles 5B dans l’équa­tion, on peut certai­ne­ment encore divi­der par 5 ou 103 les esti­ma­tions opti­mistes. Si on ajoute les modèles thin­king, on peut multu­plier par 2 à 5 les esti­ma­tions pessi­mistes.

    Andy Masley utilise la vision conser­va­trice du 3Wh comme ordre de gran­deur en se disant que « ça sera en dessous » et que donc c’est un coût maxi­mum. Je suis mitigé sur l’ap­proche, parce que du coup les discus­sions se foca­lisent sur ce chiffre qui peut (ou pas) être encore un voire deux ordres de gran­deur trop grand suivant ce à quoi on fait réfé­rence.

    Ça veut dire combien en équi­valent CO2 ?

    Une grosse partie des data­cen­ters sont aux USA. Les USA ont une moyenne de 365 g d’eqCO2 par kWh mais ça reste très hété­ro­gène. La Cali­for­nie qui concentre une bonne partie de l’ac­ti­vité fait moitié moins.

    Tout n’est d’ailleurs pas non plus aux USA. Si vous utili­sez un LLM hébergé en France, les émis­sions tombent à 56 g d’eqCO2 par kWh, soit 6 fois mois.

    Il est dans tous les cas diffi­cile de lier les data­cen­ters à la moyenne d’émis­sion de leur région vu leurs efforts pour se lier à des sources d’éner­gie à faibles émis­sions plutôt au mix géné­ral.

    Bref, là aussi, même l’ordre de gran­deur n’est pas une évidence.

    Malheu­reu­se­ment ça se multi­plie : Si l’es­ti­ma­tion éner­gé­tique fait une four­chette d’un ordre de gran­deur, que l’es­ti­ma­tion d’émis­sion fait une four­chette d’un ordre de gran­deur, le résul­tat c’est qu’on a une incer­ti­tude de deux ordres de gran­deur à la fin, et prendre « au milieu » n’a aucun sens.

    Bien entendu, si on ne se fixe pas sur une taille de modèle précise, on peut ajou­ter encore un ordre de gran­deur d’in­cer­ti­tude à tout ça.

    La four­chette finale est comme vous dire « c’est quelque chose entre le Paris-Versailles aller-retour et le tour de la terre complet ». Diffi­cile de raison­ner avec ça.

    Donne nous un chiffre !

    Va savoir… vu les esti­ma­tions avec des ordres de gran­deurs quasi­ment incon­nus, ma seule conclu­sion est « je ne sais pas ».

    Je vais quand même reprendre l’idée d’Andy Masley avec quelques hypo­thèses.

    ChatGPT ou équi­valent 70B,
    borne pessi­miste,
    data­cen­ter en Cali­for­nie    		0,550 gr d’éqCO2 par requête
    ChatGPT ou équi­valent 70B,
    borne opti­miste,
    data­cen­ter en Cali­for­nie    		0,055 gr d’éqCO2 par requête
    ChatGPT-nano ou équiv. 5B,
    borne pessi­miste,
    data­cen­ter en Cali­for­nie    		0,055 gr d’éqCO2 par requête
    ChatGPT-nano ou équiv. 5B,
    borne opti­miste,
    data­cen­ter en Cali­for­nie    		0,005 gr d’éqCO2 par requête
    ChatGPT-nano ou équiv. 5B,
    borne opti­miste,
    data­cen­ter en France    		0,0017 gr d’éqCO2 par requête

    Renta­bi­lité

    Un ordi­na­teur fixe avec son écran externe consomme dans les 60 watts4, donc 1 Wh par minute d’uti­li­sa­tion. Avec nos chiffres plus haut, une requête LLM devient rentable éner­gé­tique­ment si elle évite entre 2 secondes et 3 minutes de travail5.

    On trouve aussi qu’une requête de recherche Google consomme 10 fois moins qu’une requête ChatGPT6. Tourné autre­ment, la requête au LLM est rentable si elle vous épargne 10 recherches Google. Si vous utili­sez un modèle nano, on devrait être au même ordre de gran­deur qu’une requête Google.

    Si on mélange les deux (pendant l’uti­li­sa­tion de votre ordi­na­teur vous allez faire des recherches, pendant vos recherches vous allez utili­ser l’or­di­na­teur, et faire tour­ner d’autres serveurs web), l’équi­va­lence éner­gé­tique semble attei­gnable rapi­de­ment.

    Ok, mais c’est beau­coup quand même, non ?

    Je vais éviter l’opi­nion subjec­tive. Le mieux est de prendre quelques exemples à partir du compa­ra­teur de l’Ademe :

    • Une simple tartine de beurre sans confi­ture le matin7 c’est l’équi­valent d’entre 144 requêtes et 39 500 requêtes LLM dans la jour­née.
    • Prendre 100 grammes de crevettes8 au repas une fois dans l’an­née, c’est l’équi­valent de faire au travail toute l’an­née entre plus de 2 requêtes par jour et plus d’1 requête par minute.
    • Si vous déci­dez de rempla­cer la vieille armoire de mamie qui commence à lâcher plutôt que de faire un rafis­to­lage bien moche avec clous et planches, c’est l’équi­valent de faire entre une requête toutes les 16 minutes et 17 requêtes par minute sur toute votre vie à partir de vos 6 ans, 16 heures par jour9 .

    Si certains parlent d’in­ter­dire les IAs pour des raisons éner­gé­tiques, ce que je trouve comme chiffre rend toute­fois bien plus effi­cace et perti­nent d’in­ter­dire de jeter des meubles ou de manger des crevettes ou des raclettes10, à la fois sur l’ordre de gran­deur et sur le service rendu.

    Ce que je ne dis pas

    Parce que je sais que je vais avoir pas mal de réac­tions :

    • Je ne nie pas l’im­pact envi­ron­ne­men­tal
    • Je ne dis pas que c’est rien. Ce n’est pas rien.
    • Je ne sais pas mesu­rer à quel point on risque d’uti­li­ser ces outils dans le futur, et donc le poten­tiel effet de masse
    • Je ne dis rien ici de la perti­nence, de l’uti­lité ou de la dange­ro­sité de ces outils hors des ques­tions éner­gé­tiques
    • Je ne dis pas oui ou non à un usage ou un autre, je me contente de donner les chiffres et l’in­cer­ti­tude que j’ai trou­vés

    C’est un état de réflexion, pas une conclu­sion

    Bien évidem­ment, si j’ai fait une quel­conque erreur, ce qui est loin d’être impos­sible, vous êtes les bien­ve­nus à me le signa­ler.

    Même chose si vous avez des liens à ajou­ter au débat. Je ne les ai pas forcé­ment lu, et ça peut évidem­ment chan­ger mon texte.

    1. Sans avoir de données publiques, les prix des diffé­rentes géné­ra­tions crédi­bi­lisent que la consom­ma­tion éner­gé­tique a tendance à bien bais­ser avec le temps ↩︎
    2. C’est poten­tiel­le­ment 30% de plus si on prend en compte l’en­trai­ne­ment des modèles. J’ai fait le choix de ne pas le prendre en compte parce que juste­ment on parle d’un futur où on aurait un usage massif des LLMs (les émis­sions d’aujourd’­hui sont peu signi­fiantes). Dans ce futur, si on répar­tit le coût d’en­trai­ne­ment sur la tota­lité des usages, on a des chances que ça ne soit pas si signi­fi­ca­tif que ça. Dans tous les cas, même 30% ne change pas les ordres de gran­deur de la suite. ↩︎
    3. Je me base sur la diffé­rence de prix entre ChatGPT-4.1 et ChatGPT-4.1-nano ↩︎
    4. On peut divi­ser par deux pour un ordi­na­teur portable ↩︎
    5. Suivant qu’on est sur un équi­valent ChatGPT avec un scéna­rio de consom­ma­tion pessi­miste ou un équi­valent équi­valent ChatGPT-nano hébergé en France avec un scéna­rio de consom­ma­tion opti­miste ↩︎
    6. Là aussi, il semble que ce soit une borne haute, proba­ble­ment basée sur la borne haute de la consom­ma­tion éner­gé­tique de ChatGPT ↩︎
    7. 10 grammes de beurre par tartine, à 7,9 kg d’eqCO2 par kg de beurre, donc 79 grammes d’eqCO2 par tartine. ↩︎
    8. 100 grammes de crevettes, à 20 kg d’eqCO2 par kg de crevettes, donc 2 kg d’eqCO2 la portion de crevettes. ↩︎
    9. 16 heures par jour parce que bon, à faire ça toute votre vie on peut quand même vous lais­ser 8 heures par jour pour dormir, manger, prendre une douche, vous dépla­cer, etc. ↩︎
    10. Ce n’est pas juste une remarque amusante ou du whata­bou­tisme. Je suis en fait sacré­ment sérieux. L’ali­men­ta­tion de source animale est un des éléments majeur de nos émis­sions, bien bien au-delà de ce que pour­rait deve­nir l’IA dans les scéna­rios pessi­mistes sur le futur. Mettre une taxe carbone voire des inter­dic­tions ne me parait pas tota­le­ment décon­nant.
      Oui, j’en suis là sur mon rapport au réchauf­fe­ment clima­tique, c’est dire à quel point je ne prends pas la chose à la légère et à quel point je serais prêt à bannir l’IA si j’avais l’im­pres­sion que ce serait le problème. ↩︎

  • I know jiu jitsu

    Je me remets pour la troi­sième fois à l’ap­pren­tis­sage de Rust à partir du livre plus ou moins offi­ciel. Les deux fois précé­dentes, j’avais lâché par manque d’en­vie ou d’at­ten­tion.

    Cette fois ça tient.

    Parfois c’est le moment, parfois non. Peut-être est-ce juste ça, mais je note tout de même une diffé­rence dans la méthode.

    Les dernières fois j’avais plein de ques­tions, sur « pourquoi pas comme ça … ? », « et si je veux faire … ? », « est-ce qu’on ne pour­rait pas faire … ? ». Avan­cer en lais­sant plein de ques­tions qui ne trouvent pas de réponse faci­le­ment sur Inter­net c’est possible mais vite pénible. Ça frei­nait clai­re­ment mon appren­tis­sage.

    Cette fois-ci je suis dans Cursor, avec un LLM à mes côtés qui répond à tout de façon rela­ti­ve­ment satis­fai­sante. Ça semble faire une diffé­rence.

  • Un petit programme par l’IA

    J’avance sur mes outils de sauve­garde mais aussi sur mes explo­ra­tions IA.

    J’ai eu besoin d’un second programme qui va lire tous les emails d’une boite au format mail­dir, regar­der l’an­née du mail, et le dépla­cer dans une boite mail­dir spéci­fique à cette année là.

    J’au­rais pu le faire en Javas­cript ou en Ruby mais vu ce que m’a fait l’IA en quelques minutes précé­dem­ment, je me suis dit que j’al­lais conti­nuer et refaire un script Go (je n’ai jamais codé une seule ligne de Go).

    Voici le résul­tat : github.com/edas/split-mail­dir-by-year.

    Les 300 lignes de Go ont analysé l’in­té­gra­lité de mon archive Gmail (537 000 emails quand même).

    • Je ne crois pas avoir touché le code source à la main
    • Le code a toujours compilé du premier coup
    • Le code a toujours fait ce que je souhai­tais, sans erreur

    Le code est correc­te­ment struc­turé, des fonc­tions ont été créées au fur et à mesure des besoins quand le code a évolué. Quand une fonc­tion est un peu longue, il sépare en blocs et ajoute une ligne de commen­taire pour dire ce que fait le bloc, ce qui me permet de ne pas avoir à déco­der un code dans un langage que je ne connais pas.

    10 demandes courtes pour avoir le programme et le faire évoluer vers mes besoins, ques­tions de relec­ture incluses. 17 ajouts par la suite pour trai­ter des cas spéci­fiques rencon­trés.

    Je n’au­rais pas fait plus vite moi-même, ni en Go ni dans un langage que je connais très bien. Peut-être que ça aurait été un peu plus diffi­cile pour un non-déve­lop­peur, mais je vois mal ce que j’au­rais eu à y gagner à le coder à la main.

    À chaque modi­fi­ca­tion j’ai le diff à vali­der mais aussi une bonne expli­ca­tion de l’IA sur ce qui a été modi­fié, comment et pourquoi. Ma relec­ture s’est souvent faite en diago­nale sur la base des commen­taires de code. L’IA a su répondre à mes ques­tions quand j’ai rencon­tré des éléments moins évide

    Plutôt que lister les étapes, je copie direc­te­ment mes prompts.

    I have hundreds thousands of files in the "maildir/new" directory. Each file contains a raw email with headers.

    I want a program which reads all emails one by one, look for the "Date" header, return an error in the header doesn't exists or is unreadable, and otherwise move the email file in the directory "by-year/{year}/new" where {year} is the year in the Date header.

    Je relis parce que ça va toucher des données réelles et que j’ai la flemme de faire des données de tests.

    Je vois qu’il retourne toujours une date même quand il y a une erreur. Inha­bi­tué de Go, j’ai peur de certaines erreurs de débu­tants en PHP ou en JS, où on utilise une date du jour plutôt que gérer l’er­reur. Je pose ma ques­tion et je suis rassuré par sa réponse (que je trouve logique après coup vu le fonc­tion­ne­ment des erreurs en Go)

    can the parseEmailDate return nil when it doesn't find a Date header ?

    Je vois aussi un mkdir sans test d’exis­tence préa­lable. Dans d’autres langages ça jette une erreur si le réper­toire existe. Je pose la ques­tion et là aussi je suis rassuré par sa réponse.

    what if the directory already exists line 63 ?

    Je demande une adap­ta­tion, non stric­te­ment néces­saire, pour que chaque réper­toire soit bien une boite mail­dir avec les 3 réper­toires obli­ga­toires. Ce n’est pas néces­saire à ma sauve­garde mais je préfère, au cas où ça m’évite des erreurs un jour.

    Oui, j’ai parfois basculé en français. Je ne sais ni pourquoi j’ai du français ici, ni pourquoi j’ai mis de l’an­glais avant. L’IA est confi­gu­rée pour toujours me répondre en français. Le code est toujours commenté en anglais. Je pense que propres entrées dépendent ce sur quoi mon atten­tion était à ce moment là (code, page web, etc.)

    Si le répertoire "by-year/{year}" n'existe pas, il faut aussi créer "by-year/{year}/cur" et "by-year/{year}/tmp", même si nous ne nous en servons pas

    Seconde adap­ta­tion : L’IA m’a dit plus haut qu’elle avait un code de gestion de conflit. Je vois le commen­taire dans le code qui dit qu’en cas de conflit le code ajoute un suffixe avec le times­tamp du moment pour éviter d’écra­ser un fichier exis­tant. Norma­le­ment ça ne devrait jamais arri­ver mais un suffixe risque­rait de casser le format de nommage des fichiers mail­dir donc je préfère qu’on s’ar­rête avec une erreur et que j’avise.

    if there is a conflict, to not append a timestamp to make it unique. Return an error.

    Troi­sième adap­ta­tion. Je traite un demi-million de fichiers. Je préfère que ça traite les fichiers au fil de l’eau plutôt qu’a­voir la liste d’un demi-million de fichiers en mémoire.

    Au départ c’est d’abord une ques­tion. Je ne sais pas si Go retourne un tableau ou un itéra­teur (oui, j’ai été flem­mard jusqu’à ne même pas faire atten­tion au typage). Je m’at­ten­dais à deman­der la correc­tion dans le premier cas. Au final il modi­fie de lui-même le code à partir de la seconde ques­tion pour faire des itéra­tions par lots 100 fichiers, sans que je ne le demande expli­ci­te­ment.

    En réalité c’est du script maison, qui sera lancé juste une poignée de fois. L’op­ti­mi­sa­tion est tota­le­ment inutile mais je n’ai pas encore appris à tota­le­ment lâcher prise vis-a-vis de ce que j’au­rais codé moi-même.

    What does return ReadDir in line 88 ?
    Si le répertoire contient des millions de fichiers, est-ce que la variable files ligne 88 va tout avoir en mémoire ?

    Je vais jouer avec de vraies données. Je veux voir les erreurs et m’ar­rê­ter pour corri­ger, pas que ça conti­nue et que j’ai à remon­ter voir s’il y a eu des erreurs.

    The programm should stop at the first error, not continue with the next file

    Et, parce que je n’y avais pas pensé avant : 

    Le programme doit aussi prendre un chemin en argument. C'est là que se trouveront les différents répertoires prévus.

    La première phase est faite. Je passe au test en condi­tions réelles, sur le demi-million d’email de mon archive. Chaque fois que j’ai une erreur, je lui indique et j’avance.

    C’est là que je vois que chaque client email fait bien ce qu’il veut avec les entêtes. J’ai croisé un nombre inat­tendu de formats diffé­rents et d’er­reurs dans les entêtes. Chaque fois le programme m’af­fiche l’er­reur, je copie-colle la date problé­ma­tique, l’IA corrige, et je relance jusqu’à l’er­reur suivante.

    We should also parse the format for "Mon, 21 Aug 2006 16:47:08 +0200 (CEST)"
    We should also parse the date "Mon, 1 Dec 2008 10:57:10 UT"

    Sur une erreur étrange, j’ouvre l’email et je me rends compte qu’il prend en compte la conti­nua­tion d’une entête Recei­ved comme si c’était une date, parce qu’il ne prend pas en compte les espaces avant le mot clé Date.

    TrimSpave at line 30 should only trim right space, not left space

    Parti­cu­la­rité Gmail, quand il récu­père un email d’une boite tierce (via POP3 ou IMAP), il crée des entêtes à lui, saute une ligne et après pose le vrai email. Rétros­pec­ti­ve­ment je pense que j’au­rais dû reti­rer la section ajou­tée par Gmail pour retrou­ver un email normal. Je le ferais peut-être plus tard. Là je me suis contenté de lui faire contour­ner le problème.

    When we find the header "X-Gmail-fetch-Info", we should ignore the blank line following if it exists

    Encore des ques­tions de dates…

    We should be able to parse the Date "Tuesday 29 May 2007, 16:03"
    We should also parse "Wed, 03 Mar 2010 22:36:13 +0100 CET"
    We should also parse "Thu, 22 Jul 2010 23:02:50"
    We should also parse "Mon, 30 Mar 2009 20:11:22 +0100"

    Ce coup-ci ça ne corrige pas mon problème. Rétros­pec­ti­ve­ment j’au­rais pu le comprendre parce que le message d’er­reur n’était pas exac­te­ment le même, mais je le laisse trou­ver seul. Le mot clé DATE était en majus­cules, c’était la première fois.

    pourtant le script fait une erreur sur la ligne "DATE: Mon, 30 Mar 2009 20:11:22 +0100". Pourquoi ?

    Le code qu’il me génère imbrique quatre fonc­tions de mani­pu­la­tion de texte sur une seule ligne. Je ne trouve pas ça lisible. Je pose la ques­tion.

    que fait la ligne 49 ?

    Ça semble redon­dant avec la ligne suivante, pré-exis­tante. Effec­ti­ve­ment, quand je pose la ques­tion il iden­ti­fie le doublon et le supprime.

    Il faut penser à relire (même si l’er­reur aurait juste était du code inutile). Cursor me fait vali­der chaque chan­ge­ment sous forme de diff donc c’est assez rapide et facile à faire.

    que fait la ligne 50 ?

    Encore des formats de date…

    Encore un format : "mon, 10 jul 2006 01:02:08 gmt"
    encore un : "wed, 23 jun 2004 01:19:32 cest"
    encore un "mon, 22 mar 2010 14:20:15 +0100 +0100". C'est probablement une erreur d'écriture mais il faut la prendre en compte
    "wen, 16 jul 2008 22:09:05 +0200"

    Les deux derniers cas sont forcé­ment des erreurs de la part de clients emails. Pour la première erreur il choi­sit d’igno­rer toutes les répé­ti­tions du déca­lage horaire.

    La seconde erreur est inté­res­sante parce que « wen » est proba­ble­ment là pour « wed » (wednes­day). Il iden­ti­fie l’er­reur et ajoute un code qui remplace toute une liste d’er­reurs de frappes habi­tuelles pour les code courts de jour de la semaine. Parfait.

    "wed, 19 apr 2006 12:15 -0800"

    J’ai mon premier cas d’email sans entête « Date ». Je ne sais pas si c’est auto­risé ou non mais peu importe. Je lui dis de fouiller les entêtes « Recei­ved » à la place. Je sais que ces entêtes peuvent être sur plusieurs lignes.

    L’IA va plus loin que moi, sait que la date est en seconde posi­tion dans ces entêtes, et regarde unique­ment après le premier point virgule. Elle sais aussi comment s’ap­pellent ses entêtes sur plusieurs lignes (lignes de conti­nua­tion). Mieux que ce que j’au­rais fait.

    Je note que je tape vite, avec des erreurs de frappe, un guille­met en trop, etc. Peu importe, c’est destiné à l’IA. Me relire est super­flu : je peux reve­nir en arrière si c’est mal compris.

    If you don't find any Date header, try again to look if you can find a date somewhere in a "Received" header (theere may be multiple "Received" headers") or in the lines begining with a space and following a "Received" header

  • Fin ou trans­for­ma­tion d’un métier

    BD tirée de CommitStrip. Première case: le chef/commercial parle avec l'ingénieur informaticien. Case 1 : le commercial vient voir l'informaticien, un mug à la main. L'informaticien est sur son PC, un mug à côté aussi. Commercial : un jour on n'aura plus besoin de codeur. On aura juste à définir des spécifications et ça générera automatiquement une application. Case 2 : le commercial est en train de boire dans son mug. Infoteux, devant son PC et un mug de café : T'as raison, il suffira simplement d'écrire des spécifications complètes et précises et pouf, plus besoin de codeur ! Commercial, l'air satisfait : c'est ça ! Case 3. Infoteux : Et tu sais comment on appelle des spécifications suffisamment complètes et précises pour qu'un programme puisse générer une application ? Commercial, dubitatif : Euh... Non ? Case 4. Informaticien, l'air blasé, pointant son clavier : Du code. On appelle ça du code. Le commercial est tellement surpris qu'il penche son mug par inadvertance et renverse un peu le breuvage sacré. (le alt n'est pas de moi et à été honteusement repompé)
    « Il suffira d’écrire des spéci­fi­ca­tions complètes et précises »

    Je revois cette planche de BD dans une conver­sa­tion et je trouve qu’elle passe à côté d’un élément fonda­men­tal : On ne trans­met pas juste­ment pas de spéci­fi­ca­tions complètes et précises au déve­lop­peur.

    Complé­ter, préci­ser

    Une grosse partie du boulot de déve­lop­peur c’est complé­ter et préci­ser ces spéci­fi­ca­tions incom­plètes et impré­cises.

    Complé­ter, préci­ser, le tout à partir du contexte projet, des habi­tudes et de l’im­pli­cite courant… C’est le cas d’usage exact des LLM.

    On essaie de leur faire faire « de l’IA » mais ces outils sont en premier lieu de formi­dables outils de complé­tion à partir d’un contexte et de l’im­pli­cite habi­tuel pour un type de tâche donnés. Bref, le travail d’un déve­lop­peur.

    Refor­mu­ler dans un langage plus formel

    Que fait le déve­lop­peur d’autre ? Il traduit ça dans un langage formel (le code).

    Refor­mu­la­tion, ça aussi c’est le cas d’usage parfait pour les LLM.

    La dernière tâche du déve­lop­peur est très tech­nique. C’est de l’in­gé­nie­rie logi­cielle, réus­sir à tout agen­cer pour que ce soit faci­le­ment testable, main­te­nable, évolu­tif, etc.

    Une grosse part de cette dernière tâche est basée sur l’ap­pren­tis­sage et la repro­duc­tion de motifs ou de pratiques. Le LLM est aussi parfait pour ça.

    Il reste aussi qu’il s’agit de rendre les choses testables, main­te­nables et évolu­ti­ves… par des humains. Peut être qu’une partie de ce besoin va dispa­raître ou du moins évoluer le jour où le code sera plus mani­pulé par des LLM que par des humains. Leurs besoins, faci­li­tés et diffi­cul­tés sont forcé­ment diffé­rents des nôtres.

    Appren­tis­sage

    Oui il faudra faire des aller-retours avec l’ou­til pour complé­ter ou corri­ger sa complé­tion. Il en va de même du déve­lop­peur, surtout lors de sa première arri­vée dans une équipe ou dans un projet.

    Oui un LLM fera des erreurs d’in­ter­pré­ta­tion. Un déve­lop­peur aussi.

    Est-ce que les allers-retours et erreurs seront plus impor­tants que ceux avec un déve­lop­peur ? Aujourd’­hui proba­ble­ment, demain je n’en sais rien, peut-être.

    Est-ce que ces allers-retours et correc­tions seront plus coûteux qu’un déve­lop­peur ? Alors là je n’en sais rien, mais je ne parie­rai pas dessus.

    Besoin d’ex­per­tise

    Est-ce qu’on aura toujours besoin d’un déve­lop­peur et d’ex­per­tise pour accom­pa­gner l’ou­til auto­ma­tique ? Très proba­ble­ment sur une partie, oui, mais proba­ble­ment moins en propor­tion qu’on n’en a besoin aujourd’­hui.

    Très certai­ne­ment aussi que le travail sera diffé­rent de celui d’aujourd’­hui, et que savoir inter­agir avec les outils auto­ma­tiques sera essen­tiel dans les compé­tences requises. C’est déjà partiel­le­ment le cas aujourd’­hui. On ne code pas comme au temps des cartes perfo­rées. C’est juste que les outils vont chan­ger et vont très proba­ble­ment prendre une plus grande place.

    Certi­tudes

    Je ne donne que mes certi­tudes, mes croyances et mes craintes. Je ne connais pas plus le futur que d’autres. J’ai juste le senti­ment, sans aucune tech­no­béa­ti­tude, qu’il est en train d’ar­ri­ver.

    On fait faire, dire ou espé­rer plein de choses quand on parle d’IA. Il ne s’agit pas de voiture volantes et autres IA sentientes ici.

    Ici je parle LLM, complé­tion et refor­mu­la­tion de textes. Je peux me trom­per et je ne mets ma main au feu à propos de rien, mais je me base sur des capa­ci­tés qui sont déjà là aujourd’­hui.

    Juger le futur

    Est-ce souhai­table socia­le­ment ? Est-ce soute­nable pour la planète ? Comment va-t-on gérer la tran­si­tion au niveau de la société ?

    Ce sont honnê­te­ment d’ex­cel­lentes ques­tions dont j’ai­me­rais avoir les réponses.

    Le fond n’est pas si je souhaite ou pas ce futur, c’est que je constate qu’il est en train d’ar­ri­ver, et que je veux pas faire semblant de l’igno­rer.

    Pour les futurs déve­lop­peurs

    Je crains une vraie crise dans le métier dans quelques années. Certains, beau­coup, vont rester sur le carreau.

    Je ne sais pas si j’en­cou­rage les plus jeunes à se lancer dans le déve­lop­pe­ment infor­ma­tique. Si vous le faites, je vous encou­rage à à la fois deve­nir très vite expert (parce que j’ima­gine qu’on aura besoin des experts pour complé­ter les LLM), et apprendre à coder via les LLM (pas juste « avec ») même si ce n’est pas rentable aujourd’­hui.

    Je suis conscient de la contra­dic­tion à deman­der aux juniors de deve­nir immé­dia­te­ment expert.

    Je ne suis pas certain qu’il y ait un avenir pour les déve­lop­peurs moyens, ou pour les junior. Leur valeur ajou­tée sera faible et il y aura dans un premier temps suffi­sam­ment de déve­lop­peurs formés pour jouer les experts sans devoir inves­tir des années dans des compé­tences inter­mé­diaires qui pour­raient deve­nir experts un jour.

    Pour choi­sir son futur

    Si vous êtes très tech, faites des maths, de la mani­pu­la­tion de données, des statis­tiques, et globa­le­ment de l’IA. Les places seront peut être chères et deman­de­ront des compé­tences plus avan­cées que pour être déve­lop­peur, mais il y aura du travail.

    Si vous avez envie de créer, pour moi l’ave­nir est plus dans les métiers du produit, des product mana­ger avec une colo­ra­tion et un inté­rêt tech­nique. Ça veut dire savoir parler busi­ness, marché, client, etc.

    Pour les déve­lop­peurs actuels

    Pour ceux qui sont encore majo­ri­tai­re­ment les mains dans le code, je vous conseille de passer au plus tôt dans le déve­lop­pe­ment via les LLM.

    Je sais que vous n’en ressen­tez pas le besoin, que ces outils font des erreurs que vous ne faites pas, que ça ne vous accé­lère pas aujourd’­hui.

    Le fond c’est que les plus jeunes ça les accé­lère, que demain ils auront déve­loppé leur exper­tise mais sauront aussi utili­ser ces outils, et qu’ils en compren­dront assez les limites et les défauts pour être l’ex­pert dont le métier aura besoin.

    Il y aura encore long­temps de la place pour des vieux experts du code pour la main­te­nance et pour les gros groupes qui ont plusieurs géné­ra­tions de retard. Il y a aujourd’­hui toujours besoin de déve­lop­peurs et Cobol. La vraie ques­tion : Est-ce le posi­tion­ne­ment auquel vous aspi­rez ?

    Et moi, direc­teur tech­nique ?

    Honnê­te­ment je ne sais pas. Je ne sais pas bien quel sera mon avenir.

    Le mana­ge­ment de grandes équipes de déve­lop­pe­ment risque d’être aussi has been demain que les vieux DSI dépas­sés d’aujourd’­hui. Est-ce que je veux être de ceux là ? Je ne sais pas.

    J’ado­re­rais prendre la tête d’équipes de data science, mais j’ima­gine qu’il y a une batte­rie de docteurs sur les rangs, avec une exper­tise qui me ferait défaut.

    Entre temps je vais proba­ble­ment au moins essayer d’in­té­grer des équipes qui ont sont alignées avec tout ce que je viens d’écrire.

  • [Lecture] Custo­mers don’t care about your AI feature

    Rather than enhan­cing percep­tions, the term “gene­ra­tive AI” signi­fi­cantly lowe­red expec­ta­tions of a product’s poten­tial impact

    grow­thun­hin­ged.com

    Peu surpre­nant mais c’est bien d’avoir un peu de chiffres.

    Tout le monde se met à vouloir injec­ter de l’IA par prin­cipe et s’en vanter, y compris là où ça induit plutôt une perte de valeur pour l’uti­li­sa­teur (typique­ment pour de l’in­te­rac­tion avec les équipes support).

    Si je suis étonné, c’est plutôt que l’ef­fet ne soit pas beau­coup plus néga­tif.

  • IA : L’élé­phant dans le couloir

    Je me vois mal commen­cer à plon­ger dans l’IA1 en igno­rant toute la ques­tion éner­gé­tique. Je commence ce billet pour essayer d’y voir clair.

    C’est un brouillon partagé où je vais poser des notes au fur et à mesure des lectures, pas une conclu­sion.

    On a tous nos biais, moi aussi. Quelques posi­tions de départ :

    1. J’ai un gros biais néga­tif à la base. J’ai vu passer les délires de la réalité virtuelle, des seconds mondes, du web3 et autres crypto-actifs. Je m’en suis tenu aussi éloi­gné que possible, j’en suis bien heureux et je ne souhaite vrai­ment pas entrer dans un gros hype alors que j’ai réussi à éviter les précé­dents. Le fait qu’une partie des suppor­ters de l’IA étaient suppor­ter du web3 n’est pas trop en faveur des ques­tions d’IA.
    2. Le second gros biais néga­tif vient de mes commu­nau­tés et lectures. Je navigue dans des sphères très concer­nées par les enjeux clima­tiques, qui font les efforts asso­ciées, et qui sont dans l’en­semble extrê­me­ment critiques vis-a-vis de l’IA, pour ne pas dire en total rejet. Ça ne me lie pas, mais c’est une posi­tion de départ et il est toujours diffi­cile de sortir tota­le­ment de ses préju­gés. Ici ça me sera d’au­tant plus diffi­cile que ça voudra dire tenir une posi­tion oppo­sée aux personnes qui m’en­tourent.
    3. À l’op­posé, je vois les trans­for­ma­tions à venir dans mon métier et cette fois-ci, j’y crois. J’ai à la fois envie d’être dans le train, et peur pour mon avenir si je décide de ne pas monter pour des raisons morales. Ça joue, et il va falloir que je fasse atten­tion à ce que ça ne me fasse pas cher­cher des prétextes ou des excuses.
    4. Enfin, j’ai aussi vécu les propos inco­hé­rents sur les enjeux clima­tiques, avec la chasse aux emails à effa­cer ou des préco­ni­sa­tions qui oublient tota­le­ment les ordres de gran­deurs. Parfois on désigne l’en­nemi à abattre et quand les chiffres ne tiennent pas on fini par « tout compte », ce qui est à la fois vrai et à la fois parfois juste un prétexte pour justi­fier une mauvaise posi­tion.

    Pour expli­ci­ter le dernier point, je me refuse à juste regar­der la consom­ma­tion éner­gé­tique en absolu. Il faut tout réduire mais pas tout suppri­mer. L’enjeu c’est de savoir où et comment couper.

    illustration d'un graphique en deux axes, sobriété énergétique et utilité. L'intérieur est coloré du vert (sobre et utile) marqué "à garder" jusqu'au rouge (pas sobre, pas utile) marqué "à jeter"

    Pour l’ins­tant je vais déjà collec­ter les liens qu’on me fait suivre (en vrac dans un premier temps) :

    1. C’est amusant, je vois que j’uti­lise IA quand je donne un ton posi­tif et LLM quand je donne un ton néga­tif, quand bien même dans ces contextes je parle fina­le­ment de la même chose. Je vais garder IA ici mais c’est un sujet de réflexion. ↩︎