Carnet de notes

Catégorie : IA

  • 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 finit par « tout compte », ce qui est à la fois vrai et à la fois parfois juste un prétexte pour 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. ↩︎

  • Partage d’Elea­nor Morton « Lite­rally every company now »

  • Lecture de Steve Yegge : « The Death of the Stub­born Deve­lo­per »

    De  « The Death of the Stub­born Deve­lo­per »

    Here’s the rub: As of about May, LLMs can now execute most of the leaf tasks and even some higher-level inter­ior tasks, even on large soft­ware projects. Which is great. But what’s left over for humans is prima­rily the more diffi­cult plan­ning and coor­di­na­tion nodes. Which are not the kind of task that you typi­cally give junior deve­lo­pers.

    C’est peut être là que je diverge. C’est vrai pour les déve­lop­peurs « code », un peu moins pour les déve­lop­peurs « produit ».

    Howe­ver, some junior engi­neers pick this new stuff up and fly with it, basi­cally uple­ve­ling them­selves. And many senior engi­neers seem to be heading towards being left behind. So what is it, then?

    (…)

    Chat-Orien­ted Program­ming, CHOP for short (or just chop). Chop isn’t just the future, it’s the present. And if you’re not using it, you’re star­ting to fall behind the ones who are.

    Ne croyez pas qu’on a à faire à encore un rêveur qui imagine un futur avec des voitures volantes. On parle du présent.

    They believe these gene­ric auto­no­mous soft­ware agents will solve the problem of chop being too diffi­cult and toil­some. In fact some people claim that agents can take over the task graph enti­rely, perhaps at least for small busi­nesses, allo­wing non-tech­ni­cal CEOs to launch apps them­selves without having to hire any pesky deve­lo­pers.

    I think those people are smoking some serious crack.