Pendant longtemps, je n’étais même pas certain que ce site ait besoin d’un blog.
Je passe déjà l’essentiel de mon temps de travail à résoudre des problèmes. Certains sont des tâches frontend ou backend tout à fait ordinaires. D’autres deviennent beaucoup plus spécialisés : encodage d’images, comportement des navigateurs, expériences SEO, incidents d’infrastructure, développement assisté par IA, traitement de médias ou problème étrange en production qui commence par une question simple et se transforme en plusieurs jours d’enquête.
Après cela, écrire encore quelques milliers de mots peut sembler inutile.
Qui va lire tout ça ?
Qu’est-ce que j’y gagne ?
Pourquoi ne pas simplement résoudre le problème et passer au suivant ?
J’ai fini par trouver une réponse qui me suffit : une partie de ce travail coûte trop cher en temps et en réflexion pour être simplement jetée.
Un problème difficile peut déjà contenir un article entier avant que je m’en rende compte
Mes articles ne commencent généralement pas par la pensée : « Il me faut un billet de blog cette semaine. »
Ils commencent par un problème.
Il vient parfois de mon travail, parfois de l’un de mes propres projets. Parfois, quelque chose que je ne comprends pas m’intéresse et je continue à creuser jusqu’à beaucoup mieux le comprendre.
Le traitement d’images m’a souvent entraîné dans ce genre de terrier.
Au départ, la tâche peut sembler presque absurdement simple :
Prends ces images et rends-les plus petites.
On peut demander un script à un modèle d’IA et en obtenir un presque immédiatement.
Cela ne signifie pas que l’on dispose d’un bon pipeline de traitement d’images.
La première version peut ignorer les différences entre JPEG, PNG, WebP et les contenus animés. Elle peut utiliser la même valeur de qualité pour tout, agrandir inutilement des images, mal gérer la transparence, conserver des métadonnées que l’on voulait supprimer ou supprimer celles que l’on voulait garder. Elle peut optimiser uniquement la taille du fichier sans mesurer la dégradation visuelle. Elle peut fonctionner parfaitement sur dix fichiers de test et devenir une erreur très coûteuse à une échelle bien plus grande.
Un script qui s’exécute sans erreur n’est pas la même chose qu’un système auquel je fais confiance.
Beaucoup de mes articles viennent précisément de cette différence.
Mon workflow avec l’IA est beaucoup plus lent que « demander la réponse à ChatGPT »
J’utilise beaucoup un compte ChatGPT payant lorsque je travaille sur ce genre de problèmes.
Une même conversation peut durer plusieurs jours ou plusieurs semaines. Je pose des questions, je teste les propositions, je renvoie les résultats, je remets les hypothèses en question, j’inspecte le code, je découvre un autre cas limite, je modifie l’implémentation, je relance, je compare le résultat et je recommence.
Pour certaines recherches particulièrement approfondies, j’ai accumulé plus de 100 heures de travail autour d’un même problème général.
Cela ne signifie pas que je passe 100 heures à attendre qu’un modèle d’IA découvre magiquement la réponse.
Le processus est itératif.
Il ressemble plutôt à ceci :
- Je décris le problème.
- Le modèle propose une première solution.
- Je l’exécute sur des données réelles.
- Quelque chose se révèle faible, inefficace ou simplement incorrect.
- Je renvoie les preuves dans la conversation.
- Nous changeons d’approche.
- Je teste à nouveau.
- Un nouveau cas limite apparaît.
- On recommence.
Ce cycle peut se répéter de nombreuses fois.
Le résultat utile n’est souvent pas le premier script, mais l’ensemble des échecs, mesures, corrections et décisions accumulés autour de lui.
L’IA a rendu le point de départ peu coûteux. Pas la vérification
C’est l’une des raisons pour lesquelles le débat habituel sur le contenu technique écrit avec l’IA me paraît trop simpliste.
Oui, un modèle d’IA peut produire très rapidement un tutoriel plausible.
Il peut aussi produire du code qui semble parfaitement raisonnable et qui est faux précisément dans les situations qui comptent.
Sur des problèmes techniques étroits, je veux rarement la première réponse plausible. Je veux savoir ce qui se passe lorsque je l’exécute réellement.
Si je construis un pipeline d’images, je veux inspecter la taille des sorties et leur qualité visuelle. Je veux savoir ce qui se passe avec différents formats sources. Je veux tester des dimensions inhabituelles, l’alpha, les animations et les entrées corrompues. Je veux comprendre les hypothèses sur lesquelles repose l’implémentation.
Si le script doit ensuite toucher une énorme collection, ce travail devient encore plus important.
Dix millions d’images est volontairement un exemple extrême, pas une affirmation sur la taille d’un dataset particulier que je posséderais. Mais il illustre bien le problème : une petite erreur systématique répétée dix millions de fois n’est plus une petite erreur.
Le coût de génération du code s’est effondré.
Le coût nécessaire pour déterminer si ce code mérite d’être exécuté à grande échelle, lui, ne s’est pas effondré.
Le chat est du matériel de recherche, pas l’article final
Après une longue enquête de ce type, l’historique de la conversation peut contenir une quantité absurde d’informations.
On peut y trouver :
- des approches qui ont échoué ;
- du code remplacé par la suite ;
- des résultats de benchmark utiles ;
- des logs ;
- des incompréhensions ;
- des corrections ;
- des explications de comportements obscurs ;
- des comparaisons entre différentes solutions ;
- des cas limites auxquels je n’avais pas pensé au départ ;
- et les règles finales auxquelles j’ai fini par faire confiance.
Laisser tout cela enfermé dans une conversation privée me semble être du gaspillage.
J’en extrais donc les parties utiles et j’en fais un article.
L’article n’est pas une transcription du chat. La majorité de la conversation ne devrait jamais devenir un article.
Un bon article technique nécessite une passe supplémentaire : supprimer les impasses qui n’enseignent rien, conserver celles qui expliquent quelque chose d’important, vérifier les affirmations, reconstruire la chronologie, distinguer l’observation de l’explication et transformer le résultat en quelque chose qu’un autre développeur peut réellement utiliser.
Cette étape éditoriale compte.
L’IA peut y participer, mais les preuves viennent toujours du travail effectué.
Le traitement d’images m’a appris à quel point un problème « simple » peut devenir profond
L’optimisation des images est probablement l’exemple le plus clair dans mon propre travail.
J’y ai consacré assez de temps pour que ce qui ressemblait d’abord à un ensemble de paramètres d’encodeur se transforme progressivement en un problème de système bien plus large.
Les questions changent vite.
Quel est le format source ?
Est-il animé ?
Faut-il modifier les dimensions ?
Comment choisir la qualité ?
Quelle métrique doit décider si la perte de qualité est acceptable ?
Un seuil de qualité unique fonctionne-t-il pour des images complètement différentes ?
Comment éviter l’upscaling ?
Quelles métadonnées doivent survivre ?
Que devient la transparence ?
Comment valider la sortie ?
La réduction de taille justifie-t-elle réellement le coût supplémentaire d’encodage ?
Que se passe-t-il lorsque la population d’entrée change ?
C’est pourquoi je me méfie des scripts de cinq lignes censés offrir « l’optimisation d’images ultime ».
Ils peuvent parfaitement traiter une image.
C’est différent de construire un pipeline dont on comprend les compromis.
Pour mes workloads actuels très orientés image, AVIF est généralement le format auquel je pense en premier. C’est une règle issue du type de projets sur lesquels je travaille, pas une affirmation selon laquelle tous les sites du monde devraient supprimer demain tous les formats plus anciens. Les contraintes de compatibilité, les sources, la latence, le coût de l’encodeur et l’architecture de livraison peuvent changer la réponse.
L’objectif intéressant n’est pas de déclarer un format gagnant.
C’est de comprendre suffisamment bien le workload pour prendre la décision consciemment.
J’aimerais aller aussi loin dans le traitement vidéo. Je n’en suis pas encore là. C’est aussi ce qui rend ces sujets intéressants : chaque fois que je pense avoir atteint le fond d’un problème, une nouvelle couche apparaît.
Puis un site japonais a trouvé le blog
Je n’attendais aucun résultat particulier en publiant ces articles.
Ce blog ne me rapporte pas de revenu significatif. Je le fais parce que j’aime le processus et parce que je préfère conserver le travail utile plutôt que le laisser disparaître dans d’anciens chats et dans l’historique du terminal.
Puis quelque chose que je n’attendais vraiment pas s’est produit.
Le 17 septembre 2026, le site japonais Levtech Freelance a publié une sélection dont le titre pourrait se traduire approximativement par « Blogs recommandés aux ingénieurs qui souhaitent améliorer leurs compétences ».
L’article de Levtech Freelance a inclus JSVar aux côtés de plusieurs autres blogs d’ingénierie.
Levtech fait partie d’un vaste écosystème japonais de carrière dans l’IT, et Levtech Freelance se concentre sur l’accompagnement et la mise en relation des ingénieurs IT indépendants. Ce qui m’intéressait n’était pas simplement d’obtenir un backlink. Je voulais surtout voir quelles parties de mon travail une équipe éditoriale extérieure considérait comme suffisamment intéressantes pour être décrites.
Leur section consacrée à JSVar mettait notamment en avant trois articles.
Le premier expliquait pourquoi Codex et TypeScript m’avaient semblé bien fonctionner ensemble en développement de production, notamment parce que les types et les retours du compilateur TypeScript peuvent révéler rapidement des problèmes dans le code généré.
Un autre racontait comment j’avais traduit le blog en 20 langues avec ChatGPT et vu des visiteurs issus de la recherche arriver directement sur des pages localisées depuis différents pays.
Le troisième portait sur mon expérience consistant à publier 10 000 pages SEO générées par IA, expérience qui est finalement devenue une histoire d’échec plutôt que de croissance facile.
Cette sélection m’a amusé, parce qu’il s’agit de trois articles très différents qui partagent pourtant le même schéma.
Ils sont fondés sur des choses que j’ai réellement faites.
Je ne sais pas exactement comment Levtech m’a trouvé
Il y a ici une histoire très tentante à raconter.
Je ne parle pas japonais.
Mon site possède une version japonaise.
Une publication d’ingénierie japonaise a trouvé le site.
Donc la traduction du blog en japonais a provoqué sa découverte par Levtech.
Je ne peux pas le prouver.
Peut-être que les pages japonaises ont aidé.
Peut-être qu’une recherche les a conduits à un article en anglais.
Peut-être que quelqu’un a partagé un lien.
Ou peut-être ont-ils trouvé le site par un tout autre chemin.
Je ne dispose pas de ces données d’attribution. Je ne vais donc pas fabriquer une étude de cas SEO propre et nette à partir d’éléments qui ne permettent pas de l’affirmer.
Ce que je peux confirmer est bien plus simple : j’ai publié le blog en plusieurs langues, puis une publication japonaise l’a trouvé assez intéressant pour l’inclure dans une sélection éditoriale.
C’est déjà un bon résultat.
Et il est particulièrement satisfaisant parce que la localisation était elle aussi une expérience qui, au départ, semblait demander beaucoup de travail pour un bénéfice incertain.
Cette mention comptait parce qu’elle constituait une validation indépendante
Par « validation », je ne veux pas dire que Levtech a prouvé que tout ce que j’écris est correct.
Ils n’ont pas audité mon code ni reproduit chacune de mes expériences.
Ce qui comptait était plus modeste.
Quelqu’un à l’autre bout du monde, qui écrit pour un public auquel je ne pourrais pas m’adresser moi-même dans sa langue, a trouvé suffisamment de valeur dans mon travail pour le résumer à ses lecteurs.
Je ne leur avais rien proposé.
Je n’avais pas écrit les articles d’origine pour Levtech.
Je ne m’attendais pas à apparaître dans une sélection japonaise.
C’est ce qui rend le résultat significatif pour moi.
Cela suggère qu’un article technique très spécialisé n’a pas nécessairement besoin d’une audience énorme pour mériter d’être publié.
Il doit être utile au bon lecteur.
Un développeur devrait-il lancer un blog en 2026 ?
Pour moi, oui — à une condition importante.
Il faut réellement avoir envie d’écrire quelque chose.
Je ne recommanderais pas de créer un blog technique simplement parce que quelqu’un vous a dit que tout développeur a besoin d’une « marque personnelle ».
Je ne le lancerais pas non plus dans l’espoir d’un revenu passif.
Et je ne le remplirais pas d’explications génériques sur des technologies qui disposent déjà de meilleures documentations.
Mais si votre travail produit régulièrement des choses que vous auriez aimé trouver lorsque vous avez commencé, c’est différent.
Écrivez-les.
Écrivez sur cette panne étrange en production.
Écrivez sur cette optimisation qui a pris trois jours de plus que prévu.
Écrivez sur le benchmark qui a contredit votre hypothèse.
Écrivez sur l’approche qui semblait élégante et qui a échoué.
Écrivez sur l’implémentation finale, mais expliquez aussi pourquoi l’implémentation évidente ne suffisait pas.
Ce sont ces éléments qu’il est difficile de fabriquer à partir de connaissances générales.
L’IA me donne plus de matière à écrire, pas moins
L’IA ne m’a pas convaincu que les blogs techniques étaient devenus obsolètes.
Chez moi, c’est presque l’inverse qui s’est produit.
Je peux étudier davantage d’idées parce qu’obtenir une première implémentation ou une première explication est plus rapide qu’avant.
Mais des itérations plus rapides produisent aussi davantage de preuves : plus de variantes, plus de logs, plus de benchmarks, plus de tentatives ratées et plus de choses à vérifier.
Cette matière brute ne prend de la valeur qu’après le travail nécessaire pour décider ce qui est vrai et ce qui est important.
Une conversation avec une IA contenant 500 messages n’est pas automatiquement du savoir.
Un script qui finit par survivre à de vrais tests, accompagné d’une explication des 20 versions qui ont échoué, peut le devenir.
C’est cette différence que je veux conserver dans le blog.
Publier m’empêche de laisser disparaître le travail utile
La plupart du travail technique est étonnamment temporaire.
Un bug difficile est corrigé.
Le terminal est fermé.
Le déploiement réussit.
La conversation descend dans l’historique.
Six mois plus tard, même moi, je peux ne plus me souvenir de la raison pour laquelle l’implémentation finale a cette forme.
Écrire change cela.
Cela m’oblige à reconstruire le raisonnement tant que les preuves existent encore.
Cela produit quelque chose de consultable.
Cela me donne une référence pour mon propre travail futur.
Et parfois, manifestement, cela atteint quelqu’un que je n’aurais jamais imaginé — y compris une publication d’ingénierie dans une langue que je ne parle pas.
Je n’ai toujours pas de raison particulièrement sophistiquée pour continuer ce blog.
J’aime apprendre.
J’aime construire des choses.
J’aime aller beaucoup trop loin dans des problèmes qui semblaient simples au départ.
Et après avoir passé des dizaines, parfois plus de cent heures, à obtenir une réponse utile, je n’ai plus envie que cette réponse meure dans une fenêtre de chat.
C’est une raison suffisante pour moi de la publier.
Si votre travail produit le même genre de connaissance acquise au prix de nombreux efforts, je pense que cela peut être une raison suffisante pour vous aussi.