Carnet de notes

Catégorie : Technique

I know jiu jitsu

Je me remets pour la troisième fois à l’apprentissage de Rust à partir du livre plus ou moins officiel. Les deux fois précédentes, j’avais lâché par manque d’envie ou d’attention.

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 questions, sur « pourquoi pas comme ça … ? », « et si je veux faire … ? », « est-ce qu’on ne pourrait pas faire … ? ». Avancer en laissant plein de questions qui ne trouvent pas de réponse facilement sur Internet c’est possible mais vite pénible. Ça freinait clairement mon apprentissage.

Cette fois-ci je suis dans Cursor, avec un LLM à mes côtés qui répond à tout de façon relativement satisfaisante. Ça semble faire une différence.

15 avril 2025
Un petit programme par l’IA
J’avance sur mes outils de sauvegarde mais aussi sur mes explorations IA.

J’ai eu besoin d’un second programme qui va lire tous les emails d’une boite au format maildir, regarder l’année du mail, et le déplacer dans une boite maildir spécifique à cette année là.

J’aurais pu le faire en Javascript ou en Ruby mais vu ce que m’a fait l’IA en quelques minutes précédemment, je me suis dit que j’allais continuer et refaire un script Go (je n’ai jamais codé une seule ligne de Go).

Voici le résultat : github.com/edas/split-maildir-by-year.

Les 300 lignes de Go ont analysé l’intégralité 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 souhaitais, sans erreur
Le code est correctement structuré, des fonctions ont été créées au fur et à mesure des besoins quand le code a évolué. Quand une fonction est un peu longue, il sépare en blocs et ajoute une ligne de commentaire pour dire ce que fait le bloc, ce qui me permet de ne pas avoir à décoder un code dans un langage que je ne connais pas.

10 demandes courtes pour avoir le programme et le faire évoluer vers mes besoins, questions de relecture incluses. 17 ajouts par la suite pour traiter des cas spécifiques rencontrés.

Je n’aurais 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 difficile pour un non-développeur, mais je vois mal ce que j’aurais eu à y gagner à le coder à la main.

À chaque modification j’ai le diff à valider mais aussi une bonne explication de l’IA sur ce qui a été modifié, comment et pourquoi. Ma relecture s’est souvent faite en diagonale sur la base des commentaires de code. L’IA a su répondre à mes questions quand j’ai rencontré des éléments moins évide

Plutôt que lister les étapes, je copie directement 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. Inhabitué de Go, j’ai peur de certaines erreurs de débutants en PHP ou en JS, où on utilise une date du jour plutôt que gérer l’erreur. Je pose ma question et je suis rassuré par sa réponse (que je trouve logique après coup vu le fonctionnement 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’existence préalable. Dans d’autres langages ça jette une erreur si le répertoire existe. Je pose la question et là aussi je suis rassuré par sa réponse.
```
what if the directory already exists line 63 ?
```
Je demande une adaptation, non strictement nécessaire, pour que chaque répertoire soit bien une boite maildir avec les 3 répertoires obligatoires. Ce n’est pas nécessaire à ma sauvegarde 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’anglais avant. L’IA est configuré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 attention é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 adaptation : L’IA m’a dit plus haut qu’elle avait un code de gestion de conflit. Je vois le commentaire dans le code qui dit qu’en cas de conflit le code ajoute un suffixe avec le timestamp du moment pour éviter d’écraser un fichier existant. Normalement ça ne devrait jamais arriver mais un suffixe risquerait de casser le format de nommage des fichiers maildir donc je préfère qu’on s’arrê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.
```
Troisième adaptation. Je traite un demi-million de fichiers. Je préfère que ça traite les fichiers au fil de l’eau plutôt qu’avoir la liste d’un demi-million de fichiers en mémoire.

Au départ c’est d’abord une question. Je ne sais pas si Go retourne un tableau ou un itérateur (oui, j’ai été flemmard jusqu’à ne même pas faire attention au typage). Je m’attendais à demander la correction dans le premier cas. Au final il modifie de lui-même le code à partir de la seconde question pour faire des itérations par lots 100 fichiers, sans que je ne le demande explicitement.

En réalité c’est du script maison, qui sera lancé juste une poignée de fois. L’optimisation est totalement inutile mais je n’ai pas encore appris à totalement lâcher prise vis-a-vis de ce que j’aurais 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’arrêter pour corriger, pas que ça continue et que j’ai à remonter 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 conditions 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 inattendu de formats différents et d’erreurs dans les entêtes. Chaque fois le programme m’affiche l’erreur, je copie-colle la date problématique, l’IA corrige, et je relance jusqu’à l’erreur 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 continuation d’une entête Received 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
```
Particularité Gmail, quand il récupè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étrospectivement je pense que j’aurais dû retirer la section ajoutée par Gmail pour retrouver un email normal. Je le ferais peut-être plus tard. Là je me suis contenté de lui faire contourner le problème.
```
When we find the header "X-Gmail-fetch-Info", we should ignore the blank line following if it exists
```
Encore des questions 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étrospectivement j’aurais pu le comprendre parce que le message d’erreur n’était pas exactement le même, mais je le laisse trouver seul. Le mot clé DATE était en majuscules, 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 fonctions de manipulation de texte sur une seule ligne. Je ne trouve pas ça lisible. Je pose la question.
```
que fait la ligne 49 ?
```
Ça semble redondant avec la ligne suivante, pré-existante. Effectivement, quand je pose la question il identifie le doublon et le supprime.

Il faut penser à relire (même si l’erreur aurait juste était du code inutile). Cursor me fait valider chaque changement 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 choisit d’ignorer toutes les répétitions du décalage horaire.

La seconde erreur est intéressante parce que « wen » est probablement là pour « wed » (wednesday). Il identifie l’erreur et ajoute un code qui remplace toute une liste d’erreurs de frappes habituelles 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 autorisé ou non mais peu importe. Je lui dis de fouiller les entêtes « Received » à 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 position dans ces entêtes, et regarde uniquement après le premier point virgule. Elle sais aussi comment s’appellent ses entêtes sur plusieurs lignes (lignes de continuation). Mieux que ce que j’aurais fait.

Je note que je tape vite, avec des erreurs de frappe, un guillemet en trop, etc. Peu importe, c’est destiné à l’IA. Me relire est superflu : je peux revenir 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
```
23 mars 2025
Fin ou transformation d’un métier

« Il suffira d’écrire des spécifications complètes et précises »

Je revois cette planche de BD dans une conversation et je trouve qu’elle passe à côté d’un élément fondamental : On ne transmet pas justement pas de spécifications complètes et précises au développeur.

Compléter, préciser

Une grosse partie du boulot de développeur c’est compléter et préciser ces spécifications incomplètes et imprécises.

Compléter, préciser, le tout à partir du contexte projet, des habitudes et de l’implicite 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 formidables outils de complétion à partir d’un contexte et de l’implicite habituel pour un type de tâche donnés. Bref, le travail d’un développeur.

Reformuler dans un langage plus formel

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

Reformulation, ça aussi c’est le cas d’usage parfait pour les LLM.

La dernière tâche du développeur est très technique. C’est de l’ingénierie logicielle, réussir à tout agencer pour que ce soit facilement testable, maintenable, évolutif, etc.

Une grosse part de cette dernière tâche est basée sur l’apprentissage et la reproduction de motifs ou de pratiques. Le LLM est aussi parfait pour ça.

Il reste aussi qu’il s’agit de rendre les choses testables, maintenables et évolutives… par des humains. Peut être qu’une partie de ce besoin va disparaître ou du moins évoluer le jour où le code sera plus manipulé par des LLM que par des humains. Leurs besoins, facilités et difficultés sont forcément différents des nôtres.

Apprentissage

Oui il faudra faire des aller-retours avec l’outil pour compléter ou corriger sa complétion. Il en va de même du développeur, surtout lors de sa première arrivée dans une équipe ou dans un projet.

Oui un LLM fera des erreurs d’interprétation. Un développeur aussi.

Est-ce que les allers-retours et erreurs seront plus importants que ceux avec un développeur ? Aujourd’hui probablement, demain je n’en sais rien, peut-être.

Est-ce que ces allers-retours et corrections seront plus coûteux qu’un développeur ? Alors là je n’en sais rien, mais je ne parierai pas dessus.

Besoin d’expertise

Est-ce qu’on aura toujours besoin d’un développeur et d’expertise pour accompagner l’outil automatique ? Très probablement sur une partie, oui, mais probablement moins en proportion qu’on n’en a besoin aujourd’hui.

Très certainement aussi que le travail sera différent de celui d’aujourd’hui, et que savoir interagir avec les outils automatiques sera essentiel dans les compétences requises. C’est déjà partiellement le cas aujourd’hui. On ne code pas comme au temps des cartes perforées. C’est juste que les outils vont changer et vont très probablement prendre une plus grande place.

Certitudes

Je ne donne que mes certitudes, mes croyances et mes craintes. Je ne connais pas plus le futur que d’autres. J’ai juste le sentiment, sans aucune technobéatitude, qu’il est en train d’arriver.

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 reformulation de textes. Je peux me tromper et je ne mets ma main au feu à propos de rien, mais je me base sur des capacités qui sont déjà là aujourd’hui.

Juger le futur

Est-ce souhaitable socialement ? Est-ce soutenable pour la planète ? Comment va-t-on gérer la transition au niveau de la société ?

Ce sont honnêtement d’excellentes questions dont j’aimerais 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’arriver, et que je veux pas faire semblant de l’ignorer.

Pour les futurs développeurs

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

Je ne sais pas si j’encourage les plus jeunes à se lancer dans le développement informatique. Si vous le faites, je vous encourage à à la fois devenir très vite expert (parce que j’imagine 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 contradiction à demander aux juniors de devenir immédiatement expert.

Je ne suis pas certain qu’il y ait un avenir pour les développeurs moyens, ou pour les junior. Leur valeur ajoutée sera faible et il y aura dans un premier temps suffisamment de développeurs formés pour jouer les experts sans devoir investir des années dans des compétences intermédiaires qui pourraient devenir experts un jour.

Pour choisir son futur

Si vous êtes très tech, faites des maths, de la manipulation de données, des statistiques, et globalement de l’IA. Les places seront peut être chères et demanderont des compétences plus avancées que pour être développeur, mais il y aura du travail.

Si vous avez envie de créer, pour moi l’avenir est plus dans les métiers du produit, des product manager avec une coloration et un intérêt technique. Ça veut dire savoir parler business, marché, client, etc.

Pour les développeurs actuels

Pour ceux qui sont encore majoritairement les mains dans le code, je vous conseille de passer au plus tôt dans le développement via les LLM.

Je sais que vous n’en ressentez 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éveloppé leur expertise mais sauront aussi utiliser ces outils, et qu’ils en comprendront assez les limites et les défauts pour être l’expert dont le métier aura besoin.

Il y aura encore longtemps de la place pour des vieux experts du code pour la maintenance et pour les gros groupes qui ont plusieurs générations de retard. Il y a aujourd’hui toujours besoin de développeurs et Cobol. La vraie question : Est-ce le positionnement auquel vous aspirez ?

Et moi, directeur technique ?

Honnêtement je ne sais pas. Je ne sais pas bien quel sera mon avenir.

Le management de grandes équipes de développement risque d’être aussi has been demain que les vieux DSI dépassés d’aujourd’hui. Est-ce que je veux être de ceux là ? Je ne sais pas.

J’adorerais prendre la tête d’équipes de data science, mais j’imagine qu’il y a une batterie de docteurs sur les rangs, avec une expertise qui me ferait défaut.

Entre temps je vais probablement au moins essayer d’intégrer des équipes qui ont sont alignées avec tout ce que je viens d’écrire.

24 février 2025
SafetyCore

Je vois passer pas mal d’affolement et de FUD à propos du nouveau service SafetyCore sur Android.

C’est quoi ?

Le service a été annoncé par Google. Il sert à classer les messages entrants pour identifier les usages malveillants ou douteux. Il identifie aussi la nudité sur les images pour la masquer en l’attente de confirmation de l’utilisateur.

Ce dernier usage est indiqué comme activé par défaut pour les mineurs, qui bénéficieraient aussi d’une alerte informative quand ce sont eux qui envoient des images sensibles.

Tout ça est traité en local. En conséquence, ce n’est pas un service d’espionnage, de tracking ou d’information vers les autorités. Rien n’est échangé avec les serveurs de Google ou envoyé vers une autre destination.

Est-ce qu’on peut avoir confiance ?

La confiance ça ne se dicte pas, et c’est très personnel. Les développeurs de GrapheneOS, qu’on peut difficilement qualifier de pro-Google, ne semblent rien avoir à y redire.

Alors oui, on peut imaginer que maintenant ou à l’avenir, Google utilise ce service ou une future mise à jour de ce service pour un usage malveillant. C’est toutefois vrai avec tous les services de Google, que Google Play met à jour en permanence.

Si vous n’avez pas confiance en Google, le problème n’est pas ce nouveau service. C’est tout l’OS qu’il faut changer, pour un dont Google ne gère pas les mises à jour automatiques. Note : Vous devrez quand même faire confiance à quelqu’un, ce sera juste quelqu’un d’autre.

Ok, mais l’installation est cachée quand même…

Je ne crois pas qu’on puisse dire que l’installation est cachée si l’évolution a été annoncée publiquement il y a plusieurs mois.

Elle par contre automatique. Oui, c’est discutable. Maintenant il faut voir d’où on vient pour comprendre.

Par le passé Android était un nid à problèmes de sécurité. Les constructeurs ne mettaient pas tous les appareils à jour, ou peu longtemps et avec une forte latence.

Google a fait le choix, probablement à raison, de séparer l’OS en deux couches et de s’occuper lui-même de la mise à jour des services cœurs pour répondre à ces difficultés. Il le fait pour les corrections comme pour les évolutions. Si un service cœur change ou s’ajoute, votre téléphone en profite même si le constructeur n’est pas diligent.

Le service dont on parle est bien un service cœur, qui a un rôle de protection. Il est normal qu’il ait suivi la voie de la mise à jour automatique.

C’est discutable mais mieux que l’alternative.

Pourquoi n’est-il pas Open Source ?

Je ne sais pas, mais je peux tenter de supposer.

Le premier point, c’est que c’est un modèle de tri, pas un algorithme. Le code source a moins de sens si le cœur reste un gros paquet binaire.

Ils auraient pu ouvrir le modèle lui-même, avec son apprentissage. Je ne sais pas pourquoi ils ne l’ont pas fait. Peut-être est-ce pour ne pas donner d’indication sur comment éviter le classement, peut-être est-ce juste parce que l’IA est le sujet à la mode sur lequel ils veulent garder un avantage.

8 février 2025
[Lecture] Customers don’t care about your AI feature

Rather than enhancing perceptions, the term “generative AI” significantly lowered expectations of a product’s potential impact
growthunhinged.com

Peu surprenant mais c’est bien d’avoir un peu de chiffres.

Tout le monde se met à vouloir injecter de l’IA par principe et s’en vanter, y compris là où ça induit plutôt une perte de valeur pour l’utilisateur (typiquement pour de l’interaction avec les équipes support).

Si je suis étonné, c’est plutôt que l’effet ne soit pas beaucoup plus négatif.

7 février 2025
Bonnes et mauvaises pratiques d’éditeur de service en ligne
Je reçois un email qui prétend venir de Lydia et qui me demande de renvoyer mon RIB en réponse si je veux récupérer mes sous, que sinon j’aurai des frais à payer, avec une notion d’urgence avec « dernier rappel ».

Un RIB par email plutôt que de me renvoyer vers le site web ?

Décompte des points : 1x louche

L’email provient d’un nom de domaine inconnu au bataillon, qui ne semble pas du tout être celui de Lydia : info.isbs.eu.

Décompte des points : 2x louche

Il n’y a aucune page Web ni sur info.isbs.eu, ni sur www.isbs.eu, ni sur isbs.eu.

Décompte des points : 3x louche

Les liens de l’email vers l’app ou les docs sont masqués derrière des redirections click.isbs.eu, impossible de savoir où ça mène mais déjà le premier domaine n’est pas de confiance.

Décompte des points : 4x louche

Normalement je m’arrêterais là. Ça ressemble à du phising sur à peu près tous les aspects. Sur un site associatif pourquoi pas, mais pas dans le domaine financier et paiement.

Je m’apercevrai d’ailleurs plus tard que j’ai effectivement superbement ignoré les emails précédents, probablement à cause de ça, dont un dont le domaine de réponse (isbs.eu) est différent du domaine de l’expéditeur (lydia-app.com, on y reviendra), chose assez caractéristique d’un spam.

Décompte des points : 5x louche

Je ne sais pas, j’ai eu un doute cette fois-ci. L’email m’indique un solde crédible. Je veux en avoir le cœur net.

J’installe l’app Lydia en vérifiant le nombre de téléchargements pour m’assurer que c’est la bonne et je m’identifie après avoir bataillé parce que le bouton continuer fait une jolie animation mais sans passer à la page suivante tant que je n’accepte pas les traceurs (vraiment ?).

Décompte des points : 5x louche, 1x gênant

Sur l’app j’ai un solde à zéro. Bon, je ne l’utilise plus mais je sais que mon solde ne devrait pas être zéro. Il y a problème.

D’ailleurs je clique sur historique pour vérifier si on ne m’a pas tiré mes sous et je retrouve mes petits, avec du crédit en dernière transaction donc impossible d’avoir un solde à zéro. Wtf ?

Décompte des points : 5x louche, 2x gênant

Hors de question de m’arrêter là. Le solde c’est plus de 200 €.

Je repars sur l’email pour mieux comprendre. On me propose de créer un compte sur l’app Sumeria. Là je me rappelle que Lydia avait changé de nom.

Du coup j’ai de nouveau un Lydia et mes sous sont passés ailleurs (peut être avec mon accord ou mon action, même si je ne m’en souviens plus) sans capacité de les retrouver dans le nouveau Lydia.

Décompte des points : 5x louche, 3x gênant

J’installe donc l’app Sumeria en vérifiant sa vraisemblance. Je n’ose même pas tenter de refuser les traceurs ce coup ci et je tente direct de m’identifier avec le mot de passe Lydia (il m’est proposé par bitwarden donc soit c’est reconnu comme étant le même compte soit j’ai déjà manuellement ajouté l’app Sumeria à ce compte Lydia).

Il ne me dit pas que le mot de passe est mauvais mais me dit qu’il y a eu trop de tentatives (au premier essai). Pourtant il m’avait demandé mon mot de passe après m’avoir demandé mon identifiant, et me le redemande à nouveau. Je ne comprends pas.

Décompte des points : 5x louche, 4x gênant

La réinitialisation de mot de passe me dit qu’ils feront une vérification d’identité. Je suis dans le train donc ça va être difficile, et le message du nombre de tentatives m’incite à penser qu’ils ne laisseront pas passer une réinitialisation sans procédure manuelle de leur part.

Je tente plutôt le support, en demandant confirmation que l’email de départ est légitime malgré son nom de domaine, et si oui comment j’aurais pu le savoir (sous-entendu : c’est louche, faites mieux). En même temps je signale l’histoire du nombre de tentatives.

C’est un formulaire, il faut que je laisse email et téléphone avant de laisser le message. Je ne l’avais pas compris tout de suite (ça me fait arriver sur une zone de texte pleine page sans label) mais j’ai du cliquer trop vite.

Peu après je reçois un email provenant du même domaine qu’à l’origine, isbs.eu, sauf que cette fois-ci je n’ai même pas un nom Lydia ou Sumeria dans le champ expéditeur.

Décompte des points : 5x louche, 5x gênant

L’email est taggé « This message might be suspicious or spam. » par Gmail.

Décompte des points : 6x louche, 5x gênant

Tout au moins le message semble être une réponse à une demande de support, ce qui crédibilise le nom de domaine. Il me demande de répondre par email avec mon numéro de téléphone. Je suis pourtant super convaincu de l’avoir donné dans le formulaire de support.

Décompte des points : 7x louche, 5x gênant

La coïncidence serait trop forte. Je considère que l’email est légitime et je donne mon téléphone.

Je reçois alors encore un email, cette fois-ci de « xxx de Lydia Solutions » mais le domaine expéditeur a changé (!?) en cours de conversation.

Décompte des points : 8x louche, 5x gênant

Le nouveau nom de domaine est lydia-app.com. Ok, ça parle de Lydia mais le site web connu de Lydia est lydia.me. C’est quoi ce mic-mac ?

Décompte des points : 9x louche, 5x gênant

Je vais voir ce nouveau nom de domaine, qui se révèle une redirection vers sumeria.com (et donc vers Sumeria et non vers Lydia, alors que le nom référence Lydia).

Décompte des points : 9x louche, 6x gênant

Ok, et cet email me dit d’aller sur une page qui va déclencher un code par SMS et qu’il faut envoyer ce code SMS par réponse email (!!). J’ai vérifié deux fois, on me demande de renvoyer par email un code de confirmation SMS, le truc qu’on dit toujours partout de ne jamais faire.

Décompte des points : 10x louche, 6x gênant
(je ne compte qu’un seul point louche mais ça en mériterait bien 5 ou 6)

Le lien sur lequel cliquer est sur lydia-app.com (pas lydia.me ni sumeria.com) et cette fois-ci ne redirige pas vers Sumeria. J’ai une page vide, avec un unique bouton au centre de la page. Rien d’autre, dont aucun élément de réassurance. Le certificat TLS est un Let’s Encrypt, donc le nom de domaine peut appartenir à n’importe qui.

Décompte des points : 11x louche, 6x gênant

Je suis joueur, je commence vraiment à croire à un truc hyper mal foutu plutôt qu’à une malveillance. Je clique.

Je reçois un SMS avec un code et un texte qui dit explicitement d’envoyer ce code par email. J’applaudis cette réassurance, j’en avais besoin vu la sensibilité de l’opération et c’est la première de tout le parcours.

Décompte des points : 11x louche, 6x gênant, 1x réassurance

J’envoie donc ce code SMS par email (j’ai dû me forcer). Le support me répond que trois adresses sont valides pour les échanges, une en @info.sumeria.com, une en @news.sumeria.eu, et une en @info.isbs.eu.

Les deux premières j’aurais accepté la légitimité d’office. La dernière j’ai quand même du mal à comprendre mais pourquoi pas… si on oublie que c’est une adresse en @lydia-app.com qui me le dit, et qu’elle n’est pas dans la liste. Je ne pinaille pas, c’est important. Je n’ai pas non plus l’adresse en @isbs.eu par laquelle j’ai eu le début d’échange.

Décompte des points : 11x louche, 7x gênant, 1x réassurance
(j’ai hésité entre louche et gênant, je vais considérer là que c’est un problème de complétude de réponse du support donc juste gênant)

On me propose aussi de réinitialiser mon mot de passe à l’aide de ma carte d’identité ou de ma carte bancaire… qui a expiré depuis.

Décompte des points : 11x louche, 8x gênant, 1x réassurance

Pas grave, je vais répondre au mail du tout départ avec mon RIB maintenant que j’ai une bonne confiance qu’il est légitime. Tant pis pour le compte Sumeria. Tout ça ne m’a pas donné assez confiance pour le restaurer.

J’ai quand même été aidé après 20h le soir, rapidement, par email. C’est positif.

Décompte des points : 11x louche, 8x gênant, 1x réassurance, 1x positif

De façon ironique mais quand même réellement pour aider à améliorer, je lui répond que son email à elle n’est pas sur la liste des adresses légitimes et que tout ça n’est pas top pour les bonnes pratiques de sécurité.

Là elle me répond avec un lien qui donne effectivement les adresses légitimes possibles. Je me rends compte que j’aurais pu m’épargner tout ça en cherchant sur google le nom de domaine. Je serais tombé sur cette page. Fatigué, ça n’a pas été mon réflexe mais est-ce vraiment à moi de compenser leur fonctionnement louche ? Je compte une réassurance utile quand même.

Décompte des points : 11x louche, 8x gênant, 2x réassurance, 1x positif

Vous savez quoi ? La page ne contient effectivement que les trois adresses qu’elle m’a donné, il manque donc une adresse en @isbs.eu (seul un sous-domaine « info » est listé, et pas avec le même utilisateur) et rien ne liste le domaine lydia-app.com avec lequel je discute et qui m’a demandé un code SMS.

Décompte des points : 12x louche, 8x gênant, 2x réassurance, 1x positif
(là c’est point louche vu que la page web officielle et plus une discussion)

Elle m’a répondu à côté. Je lui dit que son email n’est pas listé là-bas non plus. Je mets un smiley, je suis plus amusé mais je le signale explicitement quand même parce que sinon ça ne sera pas corrigé.

Malheureusement elle insiste. Elle me dit que c’est bien sur la page web (mais non). Je sens que je l’agace.

Décompte des points : 12x louche, 9x gênant, 2x réassurance, 1x positif

J’insiste moi-même. Désolé. J’ai besoin d’avoir l’impression que ce sera traité. Je cite la page, explicite que le domaine n’y est pas. Mon propos est peut-être moi aussi un peu agacé. Je dis que je m’arrêterai là. Ma question a eu une réponse la suite c’était pour aider, pas pour me prendre la tête avec une personne du support qui est probablement de bonne volonté.

Je reçois un dernier email pour me dire que les adresses données sont uniquement pour la communication officielle de Sumeria et que le service client utilise trois autres adresses en @news.lydia-app.com, @info.lydia-app.com et @lydia-app.com. J’ai un peu de mal à voir pourquoi un news et un info pour du support et en quoi le support n’est pas officiel ou ne mériterait pas d’être crédibilisé sur la page web de réassurance mais je ne vais pas relancer, ce ne sont pas mes oignons.

Demain je tenterai d’envoyer on RIB pour récupérer mon solde. Je n’ai pas hâte. L’expérience ma très fortement refroidi côté sérieux et confiance.

Pour l’instant, si quelqu’un de Lydia/Sumeria me lit, je me doute qu’il y a des raisons à tout ce circuit, mais vous êtes quand même en train de demander à vos utilisateurs de s’habituer et d’agir à l’encontre de tout ce qu’on présente partout comme des pratiques de sécurité contre le phishing :
- Ne pas prendre en compte les emails venant de domaines inconnus
- Ne pas prendre en compte les emails avec une adresse de réponse étrange ou inconnue
- Ne pas cliquer sur des liens menant vers des cibles masquées ou inconnues
- Ne pas envoyer d’informations personnelle ou sensible par email à quelqu’un qui est censé les connaitre déjà
- Ne JAMAIS envoyer de code de confirmation SMS par email ou ailleurs que sur la page de login officielle
Pour une app finance-paiement, j’attends autre chose. Peu importe les raisons, ça mérite de faire mieux. Il y a des moyens. Au minimum :
- une interface web pour les messages du support, hébergée par le nom de domaine officiel principal (ou un sous-domaine de celui-ci)
- la capacité de retrouver sur une page du domaine officiel principal (ou un sous-domaine de celui-ci) les messages d’information importants envoyés par email
- les envois de données sensibles (comme un RIB) sont à faire sur une page web du du domaine officiel principal (ou un sous-domaine de celui-ci) et pas par email
- des pages web qui listent tous les domaines et adresses qui envoient des emails en votre nom (support inclus)
21 janvier 2025
IA : L’éléphant dans le couloir
Je me vois mal commencer à plonger dans l’IA¹ en ignorant toute la question énergé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 conclusion.

On a tous nos biais, moi aussi. Quelques positions de départ :
1. J’ai un gros biais négatif à 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 éloigné que possible, j’en suis bien heureux et je ne souhaite vraiment pas entrer dans un gros hype alors que j’ai réussi à éviter les précédents. Le fait qu’une partie des supporters de l’IA étaient supporter du web3 n’est pas trop en faveur des questions d’IA.
2. Le second gros biais négatif vient de mes communautés et lectures. Je navigue dans des sphères très concernées par les enjeux climatiques, qui font les efforts associées, et qui sont dans l’ensemble extrêmement critiques vis-a-vis de l’IA, pour ne pas dire en total rejet. Ça ne me lie pas, mais c’est une position de départ et il est toujours difficile de sortir totalement de ses préjugés. Ici ça me sera d’autant plus difficile que ça voudra dire tenir une position opposée aux personnes qui m’entourent.
3. À l’opposé, je vois les transformations à 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 attention à ce que ça ne me fasse pas chercher des prétextes ou des excuses.
4. Enfin, j’ai aussi vécu les propos incohérents sur les enjeux climatiques, avec la chasse aux emails à effacer ou des préconisations qui oublient totalement les ordres de grandeurs. Parfois on désigne l’ennemi à 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 justifier une mauvaise position.
Pour expliciter le dernier point, je me refuse à juste regarder la consommation énergétique en absolu. Il faut tout réduire mais pas tout supprimer. L’enjeu c’est de savoir où et comment couper.

Pour l’instant je vais déjà collecter les liens qu’on me fait suivre (en vrac dans un premier temps) :
1. C’est amusant, je vois que j’utilise IA quand je donne un ton positif et LLM quand je donne un ton négatif, quand bien même dans ces contextes je parle finalement de la même chose. Je vais garder IA ici mais c’est un sujet de réflexion. ↩︎
20 janvier 2025
Partage d’Eleanor Morton « Literally every company now »

20 janvier 2025
Lecture de Steve Yegge : « The Death of the Stubborn Developer »

De « The Death of the Stubborn Developer »

Here’s the rub: As of about May, LLMs can now execute most of the leaf tasks and even some higher-level interior tasks, even on large software projects. Which is great. But what’s left over for humans is primarily the more difficult planning and coordination nodes. Which are not the kind of task that you typically give junior developers.

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

However, some junior engineers pick this new stuff up and fly with it, basically upleveling themselves. And many senior engineers seem to be heading towards being left behind. So what is it, then?

(…)

Chat-Oriented Programming, 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 starting 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 generic autonomous software agents will solve the problem of chop being too difficult and toilsome. In fact some people claim that agents can take over the task graph entirely, perhaps at least for small businesses, allowing non-technical CEOs to launch apps themselves without having to hire any pesky developers.

I think those people are smoking some serious crack.

20 janvier 2025
Lecture de Steve Yegge : « The Death of the Junior Developer »

De « The Death of the Junior Developer »

Gene, as an accomplished and senior author, is delighted with his productivity gains with his LLM of choice, Claude Opus. He showed me a big writing project that he’d just finished, in which he had spent easily 45+ minutes crafting the prompt, refining it until he had a 7500-word narrative that could serve as a starting point for rewriting, editing, and adjustment. (In comparison, this blog post is about half that size.) And that draft was fantastic. I’ve read it and it’s glorious.

On a good day, Gene can write 1,000 words per day. His estimate is that Claude did for him in 90 minutes what would normally have taken him ten days. It solves the « blank-page problem » and gets him to the 20-yard line, where the fun begins.

Il y a d’autres histoires. Je note un motif que ceux qui répondent « qualité » ne semblent pas voir.

L’IA est un outil. On ne lui demande pas forcement de savoir tout faire, ni même de le faire bien. On lui demande de savoir faire assez pour amener le donneur d’ordre plus loin, ou plus vite, et majoritairement de lui permettre de se concentrer sur sa tâche réelle, son vrai métier. C’est vrai même pour celui dont la tâche est l’écriture.

My senior colleagues have recently recounted similar chat scenarios in which a more junior dev would have been completely taken in, potentially losing days to weeks of work going the wrong direction.

Or worse.

Chat, it seems, is safer for senior programmers than it is for junior ones. And a lot of companies are going to interpret « safer » to mean « better. »

(…)

Briefly, what do I mean by « senior » here? Really just two things:

– You know what you want before the AI writes it. You already have a vision for how you would write this by hand, or have it narrowed to a few reasonable options.
– You can detect when it is giving you bad guidance.

J’ajouterais : savoir utiliser l’outil. Ça reste un outil. Comprendre ses limites, sa zone d’efficacité et comment en obtenir le meilleur peut faire la différence.

Rien que : aujourd’hui les tâches répétitives finissent toujours par dérailler mais qu’il est parfait pour créer le code qui va faire cette tâche répétitive (comme un développeur en fait).

20 janvier 2025