Vous pourriez me dire que j’ai la mémoire courte. Internet a entrainé de nombreuses critiques autour de la destruction des commerces physiques, de la presse écrite, de la fin des interactions humaines. Pareil pour le mobile, avec en sus des reproches, légitimes, sur l’addiction, la facilité de surveiller les individus. On pourrait aussi citer les cryptos, immense pyramide de Ponzi pour les uns, reprise du pouvoir sur les banques centrales pour les autres.

Et pourtant, avec l’IA, j’ai l’impression qu’on a passé un cap. Il n’y aurait que deux possibilités :

• les Doomers (les déclinistes) qui envisagent une apocalypse écologique, une destruction totale de l’emploi et une mise sous tutelle des opinions publiques par les Big tech qui contrôlent les IA.
• Et les Boomers (les accélérationnistes), qui prônerait une confiance aveugle dans le progrès, persuadés que l'IA va libérer l'humanité, éradiquer les maladies et générer une croissance infinie, et pour qui freiner la recherche est le vrai crime.

Choisis ton camp camarade, et si tu ne le choisis pas, c’est les autres qui le feront pour toi. Le plus “sûr” étant de ne pas en parler, mais faire l’autruche me paraît lâche, si ce n’est impossible quand on travaille dans la tech.

Bref, il faut sortir la tête du sable et je vais me risquer à l’exercice en essayant de ne pas tomber dans les caricatures. Et comme on est en pleine canicule, il me paraît évident que le premier sujet à aborder, c’est l’écologie. Est-ce que l’IA est aussi catastrophique qu’on le dit ? Est-ce que, comme le dit Camille Etienne, l’impact d’une question à une IA est stratosphériquement plus important qu’une recherche Google ? Comment ça se compare avec les autres usages numériques ? Prenons un peu le temps de regarder tout ça.

Impact écologique de l’IA

Déjà, posons quelques bases sur ce qu’on appelle l’impact écologique.

On va voir un impact de plusieurs natures :

• la consommation électrique (qui se traduit en émission de CO2)
• la consommation d’eau pour le refroidissement des data centers
• la consommation minière, nécessaire à la création des datacenters et autres terminaux

Ensuite pour simplifier, une IA consomme à deux moments différents, à la création, quand on entraine un modèle (Gemini, Codex, Claude etc…) et à l’utilisation (qu’on appelle aussi l’inférence), quand les utilisateurs interrogent le modèle.

La consommation électrique à la création

Sur la consommation électrique en équivalent CO2, il existe des modèles très différents mais la fourchette est estimé entre 500 tonnes et 12 000 tonnes.

Pour donner un équivalent :

::callout{type=primary} La différence entre les foyers US et Français repose en partie sur le fait que notre énergie est en grande partie nucléaire. ::

La consommation électrique à l’utilisation

Sur la consommation à l’utilisation, là encore c’est variable. Ca va dépendre de la question, de l’emplacement du datacenter (et donc le mix énergétique), du modèle utilisée etc…

Mais on estime que cela peut varier entre 0.03g, à 1g de CO2. On verra plus bas comment ça se compare avec internet, le gaming, le streaming etc…

La consommation d’eau

Pour parler de la consommation d’eau, il faut d’abord revenir sur une idée reçue : Non, on ne détruit pas de l’eau.

Quand l’eau est utilisée dans un système de refroidissement, que ce soit dans un datacenter, une centrale nucléaire ou que sais-je encore, elle n’est pas détruite. Quand l’eau s’évapore, elle finit ensuite par retomber sous forme de pluie.

Mais, en s’évaporant elle se déplace. Si l’eau se déplace à plus de 800km, la région dans laquelle elle a été puisée l’a effectivement perdue, temporairement mais perdue quand même.

En écologie, on distingue le prélèvement (emprunter de l'eau et la rendre au même endroit après usage) et la consommation (puiser de l'eau et l'évaporer ou la rejeter ailleurs, la rendant indisponible localement). L'IA consomme de l'eau.

A l’échelle de la planète, c’est pas forcément un problème. A l’échelle locale, par contre, cela peut créer des stress hydriques et on peut avoir une mise en concurrence entre un usage individuel, un usage agricole, et celui des centres de données.

Il faut bien comprendre qu’il y a des avancées sur le sujet. La majorité des nouveaux projets de datacenters utilisent des systèmes avec de l’eau en circuit fermé donc l’eau n’est pas évaporée. Certains pays (Irlande, Suède, Finlande) profitent de leur climat froids pour réduire de 90% des besoins en eau et on voit d’autres systèmes apparaître.
Maintenant il faut nuancer, cette fois dans l’autre sens, la majorité des datacenters actuels utilisent des systèmes à évaporation et dans tout les cas, ces systèmes demandent de l’électricité ce qui crée des tensions, par exemple en Suède.

Maintenant qu’on a dit tout ça, quelle est la consommation pour les datacenters à évaporation ?

Pour la création d’un modèle récent, on estime à environ 40 à 80 millions de litres (un petit lac) l’eau consommée (donc évaporée) nécessaire. Dans une région en stress hydrique, ça peut faire la différence.

Et si on regarde à l’usage, pour une requête, c’est entre 2 et 6.5ml d’eau par requête.

La consommation minière

::callout{type=warning} Cette partie est la plus délicate parce que c’est celle que je maitrise le moins, et en même temps, c’est sans doute celle qui mériterait le plus un article à part. On va donc survoler un peu dans ce chapitre, mais je m’engage à refaire un article plus détaillée uniquement sur cette partie dans le futur. ::

On parle souvent d’électricité et d’eau mais l’impact minier fait partie des angles morts autour de l’IA.

Pour faire tourner des IA ou pour entrainer des modèles, il faut du matériel ultra puissant et des infrastructures colossales qui vont demander du cuivre, de l’aluminium, du cobalt, du lithium, du nickel, des terres rares et j’imagine que j’en oublie.

Bon déjà ces ressources sont en quantité limitées sur terre mais j’en reparlerais dans un futur article, le recyclage de cette filière est quasi anecdotique mais en plus, l’extraction elle-même est extrêmement polluante.

A cela, il faut ajouter que le matériel actuel devient obsolète beaucoup plus rapidement. Dans la course à l’IA, on remplace beaucoup plus vite le matériel. Alors, certes, le nouveau matériel est plus efficace, notamment sur le plan énergétique mais cette rotation ultra-rapide crée un volume de déchets électroniques qu’on ne sait pas gérer.

Malgré tout, je ne sais pas encore sous quel angle et avec quel chiffre illustrer tout ça, d’autant qu’en plus ces sujets tirent avec eux des tas d’autres sujets géopolitiques (tension sur Taiwan, tension sur les terres rares etc…), donc on va garder ça de côté pour une future publication. On a déjà bien à faire avec les deux premiers sujets.

IA vs les autres usages numériques

Avec ces ordres de grandeur en tête, est-ce que l’IA est “stratosphériquement” différent du reste ?

Comment est-ce qu’on compare ça avec une recherche Google par exemple ? Ou avec du streaming, de la visio, une partie de jeu vidéo en ligne ?

IA vs Internet

Par comparaison, une requête à un moteur de recherche (Google), c’est environ 0.2g de CO2.

Selon la question et le modèle, une requête à une IA peut couter moins cher qu’une requête Google, ou aller jusque 5x fois celle d’une recherche Google.

Ce n’est donc pas “stratosphériquement” plus qu’une requête Google comme évoqué dans l’intro.

D’autant que si vous avez besoin de plusieurs recherches Google et d’ouvrir plusieurs sites pour sélectionner la réponse, l’écart se réduit, voire s’inverse.

Mais il faut séparer les usages simples : “donne moi la recette de la tarte aux fraises”, des usages complexes : “analyse moi ce document PDF de plusieurs mégas et créé une application qui permet d’afficher les résultats avec des graphiques”.

IA vs gaming vs streaming vs visio

Je vous propose de faire un exercice et comparer 1h de streaming, 1h de gaming, 1h de visio, et 1h de développement informatique assisté par IA (un usage relativement consommateur).

::callout{type=primary} Pourquoi des variations aussi fortes quand on considère 1h de dev avec l’IA ? Parce que ça inclut des usages très différents entre les usages “amateurs” qui utilisent uniquement quelques copier coller depuis le navigateur, les usages “pros” avec une délégation partielle du travail à l’IA dans un éditeur, et un usage “intensif” avec une délégation quasi totale et de multiples outils automatisés en couverture, la consommation peut être drastiquement différente. ::

Dit autrement :

• on a un rapport de x2 entre du gaming et 1h de dev avec IA en usage pro.
• la visio est ce qui consomme le moins
• le streaming est proche d’une 1h de dev en usage pro.

Là encore, quelque soit la façon de regarder les choses, c’est dur de d’y voir un écart “stratosphérique” comme on peut l’entendre ici et là.

Et pour aller plus loin, on pourrait regarder l’impact de la création des modèles IA en comparaison de l’impact écologique de la création d’un jeu vidéo, ou d’un film.

Pour un jeu AAA (gros budget du jeu vidéo), avec une équipe de 150 personnes, on peut estimer que le coût carbone est entre 500t et 3 000t de CO2 en fonction de la durée de création, les déplacements, les éventuels tournages etc… A cela il faut ajouter la maintenance annuelle pour les jeux qui sortent des nouvelles versions et des DLC en continu (WOW, Overwatch etc…).

Pour un film gros budget, on peut estimer un coût carbone **entre 3 000 et 4 000t** de CO2, incluant les transports, les lieux de tournage, les groupes électrogènes, la construction de décors.

Certes, c’est moins, mais pas tant que ça, et encore faut-il rappeler qu’on sort ++nettement++ plus de films et de jeu vidéos par an que de modèle d’IA.

C’est pas grave alors ?

Attention, ce serait évidemment du whataboutisme de cour d’école de juste dire, “oui c’est pas bien mais c’est l’autre il est pire”. C’est pas le sujet ici. Le sujet c’est davantage de se poser des questions sur nos usages. Par contre ce qui est sûr c’est que c’est largement moins évident que les discours qu’on peut lire un peu partout et surtout ça met en évidence un truc, on se focalise aujourd’hui sur l’IA, sans doute pour d’autres raisons que uniquement l’impact écologique (j’en reparlerais sur un autre article).

Mais vous allez pas acquérir des points de vertu en étant contre l’IA tout en étant pour le gaming en ligne, les films ou les compétitions de sport internationales.

Si vous avez bien suivi les chiffres, l’impact écologique de l’IA est relativement proche des autres impacts dans le numérique (streaming et gaming par exemple).

Ca ne veut pas dire que c’est bien. Dans le monde dans lequel on vit, chaque tension supplémentaire sur la planète est à questionner.

Mais ça permet de relativiser, et aussi de prendre conscience que ce sont tous nos usages numériques qu’il faut questionner, pas juste “j’ai posé une question à ChatGPT”.

Evidemment ce serait un peu rapide de conclure et de condamner le gaming parce que que jouer est moins important que travailler. Les loisirs sont importants. Mais on peut se questionner sur les usages et le volume.

Prenons un exemple : la coupe du monde de foot va couter entre 9 et 15 Millions de tonnes de CO2, soit l’équivalent de la consommation de tous les datacenters américains pendant 1 an.

Encore une fois, l’idée c’est pas de dire, eux ils font pire. On arrivera à rien comme ça.

Mais j’aime bien cet exemple. Jouer au ballon ça coute pas cher. Rassembler des milliers de gens sur 3 pays et leur faire prendre l’avion dans tout les sens, c’est une aberration, comme le fait de climatiser des stades de foot, ou d’essayer d’organiser des jeux d’hivers dans un pays désertiques.

Avec l’IA, de la même façon, entre un usage professionnel et utile, et un usage récréatif qui vise à faire créer des tonnes d’images “à la ghibli” pour les diffuser sur des réseaux sociaux, oui on peut se poser des questions.

A l’inverse dans l’IA, il y a des usages qui ne sont pas à jeter. L’IA est déjà utilisée dans la biochimie, les mathématiques, la météorologie, en découverte de médicaments et de matériaux, dans l’imagerie médicale, dans l’analyse des images satellites, dans l’agriculture.

Après ce qui est important c’est de connaitre les ordres de grandeurs et pas juste de répéter les absurdités entendues à la télé. Parce qu’en connaissant les ordres de grandeurs, on peut aussi faire des choix entre deux activités.

Je disais plus haut qu’une heure de visio c’était entre 30 et 60g de CO2. Ok, mais ça remplace un trajet Paris Lyon peut-être. En voiture c’est donc entre 60 et 90kg de CO2 d’économisé. En train c’est environ 1kg.

Je disais qu’une heure de streaming ca coutait environ 100g de CO2. Ok mais vous avez peut-être éviter de prendre la voiture pour faire 20km et aller au cinéma (soit 4.4kg), donc finalement, c’est “pas si pire”.

A chacun de faire ensuite ces choix.

Et les augmentations de datacenters ?

Une question je me suis posé avant d’écrire cet article c’était :

mais si les impacts carbone de l’IA sont finalement très proches des impacts des autres usages du numérique, et faisant l’hypothèse que ça remplace des usages sans les additionner (si j’utilise l’IA, je fais pas autre chose), pourquoi on créé plus de datacenters ?

Ok, cette question peut paraître naive mais on estime que la consommation électrique des datacenters pourrait doubler, voire tripler d’ici 2030 (Cf étude BCG et cet article de l’IRIS). Alors pourquoi ? Est ce que c’est lié à l’IA ?

D’après les articles, en partie oui, mais en partie seulement. La majeure partie de l’électricité consommée par les datacenters (les 2/3 environ) devrait être affectée à des usages historiques numériques et à l’accélération des migrations vers le cloud.

Oui l’IA joue, mais c’est surtout que le numérique prend de plus en plus de place. Là où l’IA pose souci plus que le reste c’est surtout sur le renouvellement des matériels qui est plus important mais en soit, c’est tous nos usages numériques qui se massifient : généralisation de la vidéo en 4k/8k, le cloud gaming, le streaming musical, les objets connectés etc…

Maintenant il faut pondérer. Ca reste des prévisions. Elles peuvent être surestimées, comme celles qui prévoyaient un raz de marée avec l’arrivée de la 5G.

Elles peuvent reposer sur des annonces faites par des sociétés qui ont mis toutes leurs économies dans des scénarios qui prévoient cette croissance. Si vous êtes Oracle, Nvidia, ou Google vous n’avez pas d’autres choix que de rassurer vos actionnaires en leur garantissant que ça va arriver vu les investissements déjà faits. Au passage, ce serait peut-être une bonne nouvelle que la bulle financière sur l’IA explose histoire de faire retomber la pression.

Mais tout ça c’est de la conjecture, donc gardons en tête ce chiffre de x2 ou x3. Oui les usages numériques devrait augmenter, et notamment ceux liés à l’IA.

Est ce qu’ils vont remplacer des usages physiques (comme dans mon exemple entre la visio et le déplacement en voiture) ? Est ce que c’est que additif, et pas juste du déplacement d’un usage vers un autre ? Difficile à dire.

Ce qui est sûr c’est qu’à notre échelle il y a des questions à se poser sur nos usages individuels, pas juste sur l’IA. Il faut se poser des questions sur le renouvellement de nos devices, sur le suréquipement, sur les usages récréatifs inutiles (comme la génération d’images Ghibli pour se marrer).

L’avenir n’est pas écrit, si on consomme tous un peu moins, on ne consommera pas l’électricité que certains voudraient nous vendre. S’il y a des datacenters en plus, c’est parce qu’il y a une consommation de prévue.

Faire un produit, une application, un site, c’est bien. C’est déjà pas donné à tout le monde mais c’est en réalité le plus simple. Parce que oui, la difficulté vient après, quand il s’agit de se faire connaitre.

Un bon produit que personne n’utilise est a peu près aussi utile qu’un programme électoral le lendemain de l’élection. Tout le monde s’en fout.

(j’espère que cette blague plaira à la personne qui m’a reproché de parler politique dans mon dernier billet de blog :))

Bref, dans ce billet on va parler de pub en ligne.

L’acquisition payante

L’acquisition payante consiste à dépenser de l’argent pour essayer de créer du traffic vers votre site.

Dedans on va ranger plusieurs choses (liste non exhaustive) :

• le SEA (Search engine advertising) qui consiste à mettre des pubs sur les moteurs de recherche via Google Ads ou Bing Ads
• le SMA (Social Media advertising) pour les pubs sur les réseaux sociaux (Linkedin Ads, Reddit Ads, Meta Ads etc..)
• Le retargeting : la publicité ciblée, le truc qui te réaffiches des pubs de couches sur tout les sites que tu visites parce que t’as eu le malheur d’aller regarder une fois une pub quelque part
• Le sponsoring, qui consiste à payer de l’espace dans une newsletter, une vidéo, un podcast etc… Oui c’est les fameuses pubs de VPN qu’on voit sur toutes les chaines de youtuber par exemple.

Je démarre, j’ai peu de budgets, donc le SEA et le SMA sont les deux canaux les plus abordables pour moi.

J’ai donc isolé Google Ads et Reddit Ads mais tout ne s’est pas passé comme prévu.

Le tracking de conversion

La plupart des outils comme Google Ads, Reddit Ads et consorts vont chercher à optimiser l’affichage des contenus à l’audience qui est censé “convertir” le mieux.

Oui, parce que, vendre des couches à des adolescents par exemple, c’est pas le plus efficace.

Vous allez payer un affichage d’une publicité mais à un instant T, beaucoup de gens souhaitent aussi afficher une publicité donc vous êtes en compétition avec eux sur un mécanisme d’enchère.

Par défaut vous pouvez juste dire “sur tel mot clés, je veux miser maximum 3€” et point barre.

Mais depuis plusieurs années maintenant, la plupart des plateformes d’ads vous propose de mettre des mécanismes de tracking sur votre site pour déterminer si la conversion s’est réellement fait, si l’utilisateur a vraiment fait une vente, ou une inscription. Et c’est ce signal qui va ensuite être utilisé par la plateforme pour décidé d’enchérir ou pas.

Bref, avant on disait : “je paie 3 € max pour ce mot-clé" mais désormais on donne un budget max sur une période de temps et on demande à la plateforme de le dépenser et de se débrouiller toute seule pour que ce soit le plus efficace possible. Les plateformes vont analyser des milliers de signaux en temps réel pour décider si elles misent 1€, 5 € ou rien du tout parce que l'utilisateur a peu de chances de convertir.

Sauf que, pas de chance, sur Writizzy.com je ne veux mettre aucun outil de tracking trop intrusif qui stocke des infos privées et les croise ensuite sur plusieurs sites. C’est ce qui me permet de ne pas mettre de bannières de cookies parce que j’en ai marre des bannières de cookies un peu partout et puis aussi parce que j’ai pas envie de baser mon produit sur la vente de données de mes utilisateurs.

Maintenant j’ai pas dit que je ne faisais aucun tracking, simplement mon objectif c’est de ne pas envoyer des données privées à un tiers et de calculer moi même la conversion pour ajuster mes budgets.

::callout{type=warning} Ne pas envoyer l’info de conversion aux plateformes contient de nombreuses limitations. Il faut manuellement couper les campagnes qui ne marchent pas et l’algo de ces plateformes ne sera pas capable d’adapter à la bonne audience. Je suis bien conscient que dans ce cas précis, mon éthique m’handicape. Et je vais sans doute chercher des solutions à l’avenir pour donner les signaux de conversion sans envoyer de données privées. A un moment faudra faire un choix. ::

Les métriques de conversion

Ici on va s’intéresser à plusieurs métriques :

• le traffic brut : le nombre de visites liées à une campagne de pub
• la conversion du traffic : est ce que ces visiteurs font une action utile chez moi
• le cout d’acquisition d’un client (CAC), c’est à dire le ratio entre le budget et le nombre de nouveaux users

Si par exemple je dépense 100 euros pour avoir 1 client, alors mon CAC est de 100 euros.

Ca devient intéressant lorsque le CAC est inférieur à la LTV.

Ok, cette phrase est cryptique.

La LTV (lifetime value) représente la valeur d’un client sur sa durée de vie, en gros les revenus générés par votre client.

Par exemple, imaginons un abonnement à 9 euros par mois. Si la durée moyenne d’un utilisateur sur votre plateforme est de 12 mois, alors la LTV moyenne est de 108 euros. En réalité c’est moins, puisqu’il faudrait retrancher les couts d’exploitation (le serveur par exemple) mais on va simplifier comme ça pour l’instant.

Dans l’idéal on estime que vous devriez avoir LTV = 3 x CAC

Pour Writizzy.com, j’ai seulement 6 mois d’historique donc ma LTV est forcément limité à 6 mois mais j’ai quand même des clients qui ont pris des abonnements d’un an.

Stripe me dit que ma LTV est de 181 euros.

Ok, ça peut paraitre bizarre puisque je vous disais que j’avais seulement 6 mois d’historique et donc pas le recul pour avoir des clients ayant dépensé cette somme.
Stripe utilise en réalité cette formule :

$$LTV = \frac{ARPU}{Churn}$$

• L’ARPU (Average Revenue Per User) représente le revenu moyen par utilisateur et par mois.
• Le Churn c’est le pourcentage de clients qui résilient chaque mois.

C’est donc plus une prédiction qu’une réalité.

Je pense malgré tout que mon historique va encore grandement faire évoluer cette valeur. On verra plus tard mais globalement ça veut dire que déjà si en dépensant 100 euros je peux signer un client, alors je suis gagnant.

Reddit Ads

J’ai préféré démarrer avec Reddit Ads pour dépenser mes premiers 100 euros. J’ai tenté d’utiliser Google Ads mais sans succès et le fait de pas avoir le tracking actif sur mon site m’a créé plein d’erreurs. C’est en théorie possible de faire sans mais Google a refusé de dépenser mon argent :)

Reddit, si vous ne connaissez pas, c’est une sorte de mega forum dans lequel les gens parlent de a peu près tout. On estime que ça représente entre 1 et 2 milliards d’utilisateurs actifs mensuels. C’est colossal.

Reddit est organisé sous forme de sous forums, les subreddit. Chaque subreddit parle d’un sujet, par exemple la raclette, des gens qui photographient des tranches de pain fixé sur des arbres… ou des channels réservé aux IA. Ok…

Et il est possible de diffuser des publicités sur des sous reddit, donc en théorie à des populations bien ciblées, genre, les gens qui aiment écrire des articles de blog et envoyer des newsletter, ce qui m’arrange bien pour Writizzy.

J’ai paramétré deux campagnes pour tester deux approches :

Une campagne insiste sur la différence de prix avec Substack.

La seconde insiste sur le fait qu’on doit rester maitre de nos données.

Autant vous spoiler tout de suite, j’ai changé les annonces et en réalité j’ai tout axé sur le prix au bout de 3 jours.

Voici le graphiques des impressions et de la somme dépensé par jour fournie par Reddit :

On note :

• que j’ai dépensé exactement 100 euros, à raison de 20 euros par jour pendant 5 jours
• que mon nombre d’impressions a drastiquement augmenté au 4eme jour.

Parce que oui, j’ai fait des grosses boulettes…

Le paramétrage des campagnes

Déjà la première boulette c’est que j’ai cru que ça marchait pas. C’est à dire que j’ai démarré la campagne le 9 juin. J’ai vu effectivement des choses se passer le 9 et puis pendant 2 jours j’ai cru que Reddit ne faisait plus rien.

En fait chaque jour je revenais avec le même filtre de date donc je ne voyais pas plus que le 9 juin et jusqu’au 11 juin j’ai cru que Reddit ne marchait pas…

Pour être honnête, j’ai aussi cru que ça ne marchait pas parce que je voyais quasiment pas de traffic supplémentaire arriver chez moi.

Et puis j’ai corrigé et le traffic est arrivé. Voici ce que j’ai changé :

• je suis passé d’une annonce de type Free form à Image
• J’ai fortement restreint l’audience en supprimant de nombreux pays du ciblage géographique

L’annonce Free form ressemble à un post et il faut ensuite que la personne clique sur le lien placé dans le texte. Alors que l’annonce “Image” envoie directement le traffic chez vous quand les personnes cliquent. Autant vous dire que la différence est gigantesque. Vous pouvez le constater sur le traffic, personne n’est venu avec l’annonce Free-form.

La restriction d’audience a d’autres intérêts, deux pour mon cas :

• mon produit utilise une plateforme de paiement qui n’autorise pas les paiements de tous les pays, donc il est inutile de cibler les pays non supportés
• je suis sujet à beaucoup d’attaques de spam venant de certains pays, autant rester discret vis à vis d’eux…

C’est pas grave de viser moins de gens du moment que ce sont ceux qui sont prêts à convertir et payer.

J’ai donc réduit l’audience à l’Amérique du Nord et l’Europe.

Les landings et la conversion

A partir du 11 juin, j’ai enfin eu du traffic et on parle de visites significatives, entre 5 et 7 fois plus que mon traffic habituel. Reddit est devenu à ce moment là ma source numéro 1 de traffic :

Mais c’est bien gentil d’avoir des visites, encore faut-il que ça soit utile.

Au début j’envoyais sur la page de comparaison avec Substack. Mais cette page est pas adapté pour la conversion, elle est orientée SEO. Elle fait pas écho à la pub qui était sur Reddit et qui parlait de la différence de prix avec Substack.
(En plus là vous voyez la dernière version de la page de comparaison qui était moins bien à ce moment là).

J’ai donc rapidement refait une autre page uniquement pour être une page d’atterrissage pour la campagne Reddit.

La différence entre une page orientée SEO et une page d’atterrissage c’est que la seconde peut avoir un discours orienté conversion et doit limiter le nombre de points de sortie en dehors du bouton de signup. Là où la page “SEO” doit au contraire participer au maillage interne du site et se veut plus neutre pour espérer que les bots d’indexations la propose sur les résultats de recherche.

Le bilan

Sur ces 5 jours, j’ai dépensé 100 euros, 20 euros par jour.

En réalité seul 2 jours ont vraiment été efficaces à cause de mes erreurs de démarrage.

Mon tracking dans openpanel était un peu au fraises et j’ai du l’améliorer pour mieux voir l’origine des signup. Je peux difficilement que les signups de la période sont liés à mes campagnes. Mais ce sera plus le cas pour les prochaines.

J’ai eu 1000 visiteurs uniques sur 2 jours, sur une population plutôt intéressé par mon produit. Pour info, je faisais 2000 visiteurs uniques par moi avant, donc un ajout de 1000 visiteurs c’est une augmentation de traffic de 50%. Si j’avais correctement configuré ma campagne dès le début j’aurais pu viser 1500 visites de plus.

90 personnes ont cliqué sur le signup, 44 ont été au bout. Ca reste un très bon chiffre !

J’ai pour l’instant aucune conversion payante. Certes, une personne peut se décider à convertir son compte dans le futur mais pour l’instant c’est pas le cas. Donc mon CAC n’est pas calculable et je suis pas rentable vis à vis de ma LTV.

Un seul client payant aurait rentabilisé la campagne mais je peux encore convertir des utilisateurs gratuits dans le futur.

Donc est-ce que je vais retenter l’expérience ? Oui certainement.

Pour le même budget j’aurais pu doubler voire tripler mon traffic mensuel si j’avais pas fait de conneries.

Et après c’est à moi de mieux gérer ma conversion sur site.

Je vais essayer de voir comment je pourrais envoyer le signal de conversion à Reddit sans sacrifier la privacy, si c’est possible. Apparemment je dois regarder du côté de l’api de conversion de Reddit.

Et je vais tenter d’autres angles pour les futures landing.

C’est sur que tout l’exercice est loin de ma zone de confort. Mais en réalité c’est intéressant de jouer avec tout ces paramètres et surtout de voir des résultats. Je suis très câblé chiffres alors ce jeu risque d’être au contraire très addictif.

Nous sommes dans une salle de classe, insalubre et pas chauffé comme toutes les salles de classe de banlieue parisienne, parce que ++Mo++nsieur “C’EST NOTRE PROJET !!!” a décidé que c’était plus intéressant de payer des millions d’Euros pour des powerpoint McKinsey que d’investir dans notre avenir ! … Je m’égare.

Bref, un cercle de personnes se réunit, sur des petites chaises en bois qui font mal au cl sa #!@ . Je suis présent, la mine grave. Non en fait j’ai pas écouté Jean-Michel qui vient de parler mais j’essaye toujours de comprendre comment les Spurs ont pu merder à ce point dans les derniers matchs de cette finale NBA 2026.

Et puis je me lève et je me présente.

“Bonjour je suis Hugo Lassiège, je suis avant tout développer backend et voici ma première version de Malt en 2012”

Bref, je suis nul en design.

Alors comment en 2026 j’arrive à proposer des designs comme celui de ce blog ? C’est ce que je vous propose de voir dans ce billet.

2011, l’armée des clones

::callout{type=info} Si la partie un peu historique ne vous intéresse pas plus que ça, vous pouvez directement sauter les prochaines sections pour aller sur mon workflow actuel qui est décrit plus bas. ::

2012 c’était quand même il y a longtemps et à l’époque j’utilisais Bootstrap majoritairement, ce qui explique ce petit style très caractéristique de la première capture d’écran (mixé avec des goûts esthétiques franchement discutables, je vous l’accorde).

Parce que oui, en 2011 sort un framework, Bootstrap si vous avez suivi, qui propose de mettre à disposition l’UI kit officiel utilisé chez Twitter. On retrouve dedans les lignes directrices pour faire des boutons, des formulaires, des barres de progression, tout ça dans l’esprit de l’oiseau bleu. On retrouve également tous les outils pour faire plus facilement des sites responsives avec le fameux système de grille qui va perdurer longtemps. Très longtemps.

Pour les devs backend comme moi, c’est à dire ceux ayant un gout plus que modéré pour le design, c’était l’occasion de partir sur des bases simples pour, enfin, faire des sites web qui n’ont pas l’air sorti de l’imaginaire d’un koala sous acide.

Dans la foulée de Bootstrap plusieurs autres librairies vont sortir, Foundation, Materializecss, et j’en passe mais toujours avec ce petit syndrome pour les sites qui les utilisent de “mais bordel, c’est quoi cette armée de clones”.

Du design atomique aux design systems

Maintenant c’était bien beau d’avoir une grille standard et des boutons, encore fallait il les assembler ensemble. Si les boutons, champs de saisie, blocs de texte étaient des atomes, il fallait donner une structure pour les assembler sous forme de molécules.

::gallery ::

C’est exactement cette analogie qui sera poussée progressivement à partir de 2013/2014 par Brad Frost, sous le nom d’Atomic Design.

Cette notion de molécules, c’est en réalité aussi ce qu’on pourrait appeler un composant. Un composant fixe l’assemblage de nos molécules ainsi qu’un comportement. Et c’est exactement ce qu’on retrouve dans plusieurs frameworks sortis dans la même période, React (2013), Vue (2014) et même plus généralement les Web Components (2011).

Pour l’anecdote, dans ma précédente boite (Malt) on a grandi dans la même période, on s’est dit que ce serait une super idée de mixer tout ça. On a fait du Bootstrap, puis on a regroupé tout ça avec un framework maison (les HopModules), on a ajouté Vue vers 2015, puis construit des Web Component, puis utilisé Nuxt un peu plus tard pour finalement se rendre compte vers 2023 que quand même, ca faisait beaucoup tout ça…

(Mais c’est une autre histoire que je raconte ici).

Bref, on a commencé à construire des “composants” qu’on a assemblé, standardisé pour finalement aboutir à ce qu’on appelle aujourd’hui, un design system, c’est à dire des sortes de briques de légo qu’on peut assembler ensemble et qui garantissent une certaine identité, une voix pour un site. Design system qui sont même souvent publics et que vous pouvez trouver et étudier sur différents sites.

Tailwind et les design tokens

Pour construire un design system, il manquait une brique. C’est bien beau de dire par exemple que vos boutons ont un border radius de 4px. 4, pas 2, pas 6 mais 4.

Et c’est plutôt simple à exprimer globalement :

.button { border-radius: 4px; }

Mais imaginons que vous vouliez aussi aligner ce radius sur toutes vos card ?

Imaginons que vous souhaitiez définir un padding global, une couleur “primaire” pour vos boutons principaux, les tailles de polices possibles sur l’ensemble du site.

Si le bouton est l’atome, il réalité il manquait un élément en dessous, comment on créé nos atomes ?

Courant des années 2010 (peut être via Jina Anne chez Salesforce en 2014), une personne introduit un nouveau terme : le design token.

Un design token c’est la définition de la structure de l’interface par ces tokens.

Par exemple :

• #0055ff devient le token color-brand-primary
• 16px devient le spacing-medium

etc…

Et c’est exactement l’approche de Tailwind en 2017 qui arrive avec des définitions de design tokens via tout un tas de classes utilitaires qui vont devenir très très utilisé dans les sites actuels.

Alors, Tailwind ne fait pas l’unanimité pour de nombreuses raisons et ca n’a jamais été introduit chez Malt. Mais pour mes nouveaux projets, c’est devenu la solution par défaut. Et maintenant on peut parler de mon workflow de design :)

Mon workflow pré 2024, Tailwind et ses librairies de composants

Pré 2024 (bientôt on parlera de l’ère pré agent IA…) je lançais Hakanai.io. On va pas se voiler la face, c’est mieux que ce je faisais en 2012, mais ça reste aussi gai qu’un jour d’automne à Melun.

Malgré tout, ici on retrouve mon workflow design de 2024, l’usage de Tailwind et de libraires de composants tels que preline.io ou Flowbite.com. C’est un assemblage de blocs plus ou moins cohérents visuellement mais qui ont l’avantage d’avoir une cohérence structurelle via les designs tokens de Tailwind.

Ca a l’air de rien mais c’est déjà bien. Les espacements et les respiration sont cohérents, les couleurs donnent une identité, les polices sont uniformes, bref, c’est un design system correctement utilisé. Alors oui, même Harry Potter vidé de son âme par un détraqueur a meilleure mine mais, ça marche.

Et c’est globalement l’esprit de la plupart des sites “indie” sortis dans cette période. Correct. Mais qui casse pas 3 pattes à un canard.

Et puis vint l’IA

A partir de 2024 jusque début 2025, mon workflow est devenu moins manuel. J’ai commencé à construire des interfaces en demandant à Claude de le faire. C’était encore des copiers coller entre le chat dans le navigateur et mon IDE. C’était uniquement du HTML/JS/CSS et ensuite je faisais l’adaptation à la main.

Et puis Claude est passé dans l’IDE, donc il a pu directement créer les maquettes dans mon code. Cependant Claude reproduit le style qu’il voit dans les autres pages, donc puisque le site a été créé pré 2024, eh bien il a reproduit mon style un peu “meeehhh” d’avant.

Donc déjà en 2025, j’ai commencé à changer de workflow pour certaines pages et notamment les premiers thèmes disponibles sur writizzy.com. J’ai commencé à partir d’une feuille blanche, en donnant quelques contraintes mais en faisant en sorte que Claude ne se repose pas un existant.

Parfois je lui ai demandé de s’inspirer de logiciel connus, ici avec Notion :

Malgré tout, Claude à une certaine tendance au bout d’un moment à produire un peu toujours les mêmes patterns et on peut de plus en plus reconnaitre une interface faite par une IA. C’est propre, c’est mieux que ce que je produis seul, mais ça manque d’originalité. Pour interface d’administration dans un SAAS c’est pas bien grave mais pour se démarquer sur internet, il faut faire plus d’efforts.

J’ai commencé à voir apparaitre des skills pour éviter la “slopification” : tasteskill et impeccable mais que je n’ai pas personnellement testé. Par contre depuis quelques temps j’utilise systématiquement Claude Design et là, je vois une amélioration significative de ce que je produis.

Déjà, Claude Design, qu’est ce que c’est ?

Claude design est spécialement optimisé pour la création d’interface, que ce soit pour ses instructions systèmes qui sont optimisés pour l’UI (mais pas l’UX !!), et par son outillage.

CD va en effet pouvoir visualiser le résultat et itérer en autonomie via des screenshots. Vous pourrez avoir un panneau de “tweaks” pour visualiser des options, faire des mockups low fidelity ou des interfaces abouties, commenter des zones, etc…

Mais surtout CD peut partir d’un screenshot pour avoir une ambiance. Donc si je prends le theme tux qu’on peut apercevoir dans la capture d’écran ci-dessus, je suis parti d'un site dont j’appréciais l’ambiance graphique, je lui ai fourni une image et des instructions pour qu’il reprenne l’essence : les quadrillages, les accents particulièrement vifs à certains endroits, les soulignés inclinés et épais etc… J’ai du itérer, le premier jet avait des soucis mais le résultat est plutôt intéressant.

La grande limitation c’est que CD ne peut pas comprendre les animations (sauf à lui copier coller le code de la page html), or c’est une des forces du site d’origine et pour l’instant ca reste encore une faiblesse de mon workflow.

Un autre cas d’usage, c’est de partir d’un design system. Vous pouvez en définir un directement, ou itérer sur la base du modèle qui vous semble le plus pertinent. Ici par exemple, c’est le dashboard Writizzy dans son nouveau style. Et désormais chaque nouvelle page repart de celle-ci qui sert de “design system” pour construire les suivantes.

En condensé mes workflows sont les suivants :

• création d’une maquette avec Claude Design avec 3 options :
  • à partir d’un brief
  • à partir d’un screenshot
  • à partir d’un design system
• implémentation dans mon propre code via un skill "implement-mockup” qui explique comment transcrire le code html produit par Claude dans mes technos (nuxt-ui, tailwind)

Et plus récemment, je suis en train de tester :

• utilisation de agent-browser ou playwright pour faire tester l’interface, notamment en responsive

Alors ne vous y trompez pas, je préfère largement bosser avec un designer et je le ferais quand Writizzy sera plus gros. Mais pour démarrer, pour un site indie, ca reste largement mieux que ce que je pouvais faire avant et le niveau d’attente par les utilisateurs est devenu tellement plus grand désormais que de toute façon, c’est plus vraiment une option de faire “comme avant”. Parce que oui, le design ça donne une voix à un site, une identité. Ca et bien sûr le texte, sur la page, la façon dont on s’adresse aux lecteurs. Sans identité, un site, une application, ça ne retient pas l’attention.

C’est bien sûr moins vrai sur un article de blog, vous venez lire le contenu, pas le contenant, ou sur une interface d’administration d’un logiciel. Mais quand même, vous avez pas envie d’être puni visuellement et de donner une impression de “meeehhh”.

Maintenant prenons un peu de hauteur, est ce que c’est parfait ? Non.

Oui si on regarde le chemin parcouru en 15 ans, c’est plus simple de construire des sites web. Depuis Bootstrap on a cherché l’ordre, la structure, la standardisation et ça marche.

Mais à quel prix ? On a classé des composants, documenté des marges, figé des systèmes. On a rationalisé le beau. Le problème, c’est qu’à force de tout vouloir systémiser, on a créé un web incroyablement propre, mais terriblement chiant. Un web sans friction, mais sans âme. Et l’IA, par sa nature même, est la reine absolue pour reproduire ce genre de consensus tiède. Si vous lui demandez du "propre", elle vous fera du propre.

Est-ce que je suis des fois un peu nostalgique du web moche du début des années 2000 ? Peut-être.

Enfin, pas toujours…. Ca dépend ! Je sais pas !!!

Mais peut-être que justement, si l’IA nous déleste de la tuyauterie, si la technique est automatisée, c’est l’occasion pour nous de remettre de l’intention, de l’identité, de l’émotion (je pensais pas écrire ça un jour). Peut-être que c’est ça l’évolution des prochaines années, casser les codes, et refaire du moche, mais avec une belle voix.

Vous allez me dire, c’est plutôt simple.

@Transactional   
fun doSomething() {
    ... 
    // save in database through JPA
    myRepo.save(myEntity)
    // post message
    broker.publishEvent(event)
    ...
}

Mais que passe t’il en cas d’erreur, si la transaction SQL échoue ? On se retrouve avec un message publié mais pour une opération qui n’a jamais eu lieu.

Les transactions two phase commit

C’est un problème relativement classique et on a l’habitude de le traiter avec des transactions 2 Phase commit. L’idée étant d’introduire une transaction sur toutes les opérations vers des systèmes externes, donc incluant RabbitMQ ici.

C’est un mécanisme un peu complexe qui nécessite un coordinateur supplémentaire qui va s’assurer que tout se passe bien pour ensuite valider l’écriture dans l’ensemble des systèmes.

Mais il y a plusieurs problèmes.

Le premier c’est qu’il n’est pas possible de faire des transactions 2PC avec RabbitMQ (appelé aussi transaction XA). Ce qui, vous me l’accorderez, est déjà un problème relativement important en soit.

On pourrait utiliser ActiveMQ qui supporte les transactions 2PC. Mais d’un autre côté, ce serait dommage de faire un article pour Postgresql et RabbitMQ pour finalement conclure qu’il faut utiliser ActiveMQ non ?

Le second problème, c’est que dans tout les cas une transaction 2PC pénalise les performances globales du système. Pour synchroniser deux ou plusieurs systèmes, non seulement le temps total de l’opération ne pourra être inférieur au temps minimal du système le plus lent, mais vous ajoutez également un cout lié à la coordination.

Le dernier problème, c’est que vous dégradez la disponibilité globale. La disponibilité étant la multiplication des disponibilités moyenne de chaque système. Par exemple avec deux systèmes avec 99% de disponibilité, le système total obtient une disponibilité de 98%.

$0,99 \times 0,99 = 0,9801$

Et ça c’était globalement l’état de mes connaissances jusqu’à hier. J’avais déjà utilisé des transactions XA, j’avais déjà géré des problématiques de systèmes distribuées et j’ai déjà travaillé sur un tas de scénarios de mitigation de ce type de problème.

J’ai ajouté hier RabbitMQ dans la stack de Writizzy et j’ai utilisé une autre solution : le pattern Transactional Outbox.

Le pattern transactional outbox

Si le concept sous-jacent n’est pas forcément nouveau, ce pattern spécifiquement a été popularisé par Chris Richardson entre 2014 et 2016.

Le concept est “simple” :

• ne s’appuyer que sur la base de données pour publier un évènement (étape 1)
• lire la table dans un job asynchrone (étape 2)
• publier dans la file de message depuis le job (étape 3)

Le code devient

@Transactional   
fun doSomething() {
    ... 
    // save in database through JPA
    myRepo.save(myEntity)
    // save in database
    outboxRepo.save(event)
    ...
}

Nous n’avons plus qu’une seule transaction, et la garantie que l’event est publié uniquement si la transaction réussit. Event qui sera envoyé dans RabbitMQ plus tard.

Maintenant, justement pour envoyer dans RabbitMQ, il vous faut un job pour lire la table :

@Scheduled(fixedDelay = 500)
@SchedulerLock(name = "outbox_publisher", lockAtMostFor = "PT30S", lockAtLeastFor = "PT0S")
fun run() {
    outboxPublisherService.publishPending()
}

Vous noterez ici l’usage de SchedulerLock qui permet l’usage de scheduler dans un contexte multi-noeud, pour éviter une lecture simultanée par plusieurs applications. Ca permet de remplacer Quartz que j’utilisais fréquemment jusqu’à présent.

Et il vous faut le code du service de publication

    fun publishPending() {
        val events = outboxEventRepository.findTop20ByOrderByCreatedAtAsc()
        events.forEach { event -> publishEvent(event) }
    }

    private fun publishEvent(event: OutboxEvent) {
        try {
            rabbitTemplate.invoke { t ->
                t.convertAndSend(event.exchange, event.routingKey, event.payload) { message ->
                    message.messageProperties.messageId = event.id
                    message.messageProperties.headers[HEADER_ORIGINAL_EXCHANGE] = event.exchange
                    message.messageProperties.headers[HEADER_ORIGINAL_ROUTING_KEY] = event.routingKey
                    message
                }
                t.waitForConfirmsOrDie(5_000)
            }
            outboxEventRepository.delete(event)
        } catch (e: Exception) {
            logger.error("Failed to publish outbox event ${event.id} (${event.eventType})", e)
        }
    }

Ici vous noterez qu’on a activé le mode publisher confirms de RabbitMQ et qu’on attend la confirmation de l’écriture : t.waitForConfirmsOrDie(5_000)

Mais vous pourriez me dire : “tu as de nouveau un problème double écriture dans deux systèmes”.

Et… c’est pas faux.

Mais ici c’est plus simple. Je n’ai que 3 cas :

• Tout se passe bien, rien à dire, c’est parfait.
• RabbitMQ échoue => on passe dans l’exception, on logge, on ressort, le message reste dans la table et sera réessayé
• La transaction Postgresql échoue. On passe dans l’exception mais le message est déjà envoyé !!

Le 3eme cas est important, il va arriver donc il faut le gérer. Ca implique que chaque consommateur doit être capable d’être idempotent sur la réception d’un message. C’est à dire que chaque consommateur doit pouvoir accepter deux fois le même évènement sans incident.

Ici les stratégies sont multiples :

• lire l’Id du message et le stocker quelque part pour vérifier qu’on ne fait pas deux fois l’opération, idéal pour les appels à des services externes
• déclencher des opérations idempotentes (Exemple : set status = pending, même si on le fait deux fois, ca ne pose pas de problème)

etc…

Et la gestion d’erreur ?

Mais il y a un souci, si RabbitMQ tombe, s’il est injoignable, si le disque est plein, on va logger l’exception et avec un batch qui tourne toutes les 500ms je vous laisse imaginer la quantité astronomique de log que ça va produire. Donc il nous faut un Circuit Breaker. Ca tombe bien, on peut utiliser resilience4j.

Avec un circuit breaker, on va couper l’envoi vers Rabbit en cas d’erreur et attendre un peu avant de réessayer. Je vous laisse le code ici mais je ne détaille pas, ce serait le sujet d’un autre article.

init {
    circuitBreakerRegistry.circuitBreaker("rabbitmq-outbox").eventPublisher
        .onStateTransition { event ->
            logger.warn("RabbitMQ circuit breaker: ${event.stateTransition}")
        }
}

@CircuitBreaker(name = "rabbitmq-outbox", fallbackMethod = "skipOnOpenCircuit")
fun publishPending() {
    val events = outboxEventRepository.findTop20ByOrderByCreatedAtAsc()
    for (event in events) {
        publishEvent(event)
    }
}

private fun skipOnOpenCircuit(e: CallNotPermittedException) {
    // Circuit open — state transition already logged via eventPublisher
}

private fun publishEvent(event: OutboxEvent) {
    try {
        rabbitTemplate.invoke { t ->
            t.convertAndSend(event.exchange, event.routingKey, event.payload) { message ->
                message.messageProperties.messageId = event.id
                message.messageProperties.headers[HEADER_ORIGINAL_EXCHANGE] = event.exchange
                message.messageProperties.headers[HEADER_ORIGINAL_ROUTING_KEY] = event.routingKey
                message
            }
            t.waitForConfirmsOrDie(5_000)
        }
        outboxEventRepository.delete(event)
    } catch (e: AmqpException) {
        throw e  // broker error → propagates to circuit breaker
    } catch (e: Exception) {
        logger.error("Failed to publish outbox event ${event.id} (${event.eventType})", e)
    }
}

Challenger ses propres certitudes de dev avec l'IA

Comme je le disais plus haut, je connaissais bien le mécanisme des transactions XA et l’état de mes connaissances pour résoudre ce problème s’arrêtait là.

Je me suis demandé avec curiosité si Claude allait me proposer une implémentation plus élégante et j’ai été plutôt surpris. Dans ce genre de cas précis, c’était l’occasion parfaite pour essayer d’apprendre avec l’IA et pas juste de subir un code qu’on ne comprend pas.

Laisser l’IA écrire du code sans contrôle, sans trop de surprise c’est rarement bon. Il faut un œil d’expert et in fine le code produit reste de notre responsabilité et on doit être en mesure de le comprendre. Donc il faut trouver un juste milieu entre laisser faire et micro manager l’IA.

En lui donnant mes contraintes (issues de mon expérience), c’est l’agent qui est venu avec la proposition du pattern Transactional Outbox. Et si au début j’étais un peu sceptique, j’ai essayé de comprendre chaque partie du code pour me l’approprier en posant de multiples questions. Le code n’était pas parfait, c’est suite à ces échanges qu’a été ajouté :

• le pattern publish confirm
• la résilience avec resilience4j
• le scheduler lock pour éviter les soucis en multi noeud
• l’ajout du messageid dans les headers (pour déduplication)
• claude avait ajouté une gestion d’état sur les messages qui n’était pas pertinente

Donc oui, c’était pas un plan sans accroc mais c’était une bonne façon pour moi de me forcer à me mettre à jour, me documenter et bref, d’apprendre de nouveaux trucs.

Au delà de l’aspect technique de ce billet, je voulais surtout illustrer sur la méthode que j’utilise pour coder avec un agent, et qui me permet d’allier productivité ET craft.

C’est simple, vous prenez un lieu, cool de préférence, un groupe de hacker (je vais revenir sur ce terme), vous laissez infuser pendant une petite période et vous obtenez… quelque chose, en principe un produit mais on pourrait tout simplement parler d’artefacts, prototypes, applications, machine physique etc… Mais pas juste des slides. Sinon on appellerait ca un séminaire McKinsey.

Quand je parle de hacker, attention je parle pas de la personne qui a piraté votre carte bleue le mois dernier. A défaut d’un terme plus approprié, on va plutôt parler de bidouilleur. Des gens qui cherchent à résoudre des problèmes en prenant parfois quelques raccourcis.

Une hacker residency c’est, dans l’esprit, un direct descendant des hackers space, des lieux communautaires partagés apparus courant des années 80/90. Dans l’idée il y a déjà des Hackers qui se déplacent d’un lieu à l’autre pour partager, tester expérimenter. Pour les Hackers residency, le concept se renforce avec un principe : et si on invitait un hacker d'un autre pays, si on lui filait un badge d'accès, un canapé où dormir et si on le laissait coder, hacker du matériel ou donner des ateliers bénévolement pendant un mois ? Le concept de Hacker-in-Residence était né.

Et même si la filiation n’est pas directe, on retrouve une parenté historique avec le modèle des artist-in-residence. Le principe reste le même, inviter des artistes, leur fournir un lieu pour s’exprimer, souvent avec d’autres artistes. Bref même combat, créer des lieux, parfois temporaire, dédiés à la création.

Bref, je suis à Nantes pour la semaine avec 13 autres personnes pour discuter, construire des trucs, tester, et accessoirement, prendre du plaisir !

::gallery ::

Hier encore, c’était Github, qui a manifestement ouvert une partie de son code en open source. Involontairement, certes, mais on peut quand même saluer l’initiative.

A côté de ça, en France, c’est 3 vols de données en moyenne par jour selon cet article. Mais rassurons-nous, apparemment notre premier ministre a une solution, virer le directeur de l’ANSI…

Faut dire que l’ouverture de l’ANTS (agence nationale des titres sécurisées) dans les grandes largeurs par un hacker de 15 ans via une faille triviale c’était un peu la nouille qui a fait déborder le bol de ramen.

Et selon certains, l’IA serait responsable de la baisse de qualité générale des logiciels, par exemple chez GitHub où le taux de disponibilité serait en baisse constante depuis GPT3 sur ce graphique (et l’arrivée de Microslop mais on va se concentrer sur un seul coupable).

Bon, ici, c’est du troll. Mais certains se demandent premier degré, est-ce que vraiment, l’IA serait la source de tous ces problèmes ?

C’est ce qu’on va essayer de voir. On va parler des vrais raisons de la hausse des CVE mais ce sera surtout un prétexte pour se demander si vraiment nous sommes à l’aube d’une ère du code de merde généré par IA ?

La hausse des CVE

Déjà pourquoi je parle des CVE, et c’est quoi une CVE ?

Une CVE (Common Vulnerabilities and Exposures) c’est un standard, qui recense toutes les vulnérabilités connues dans un gros catalogue. Chaque CVE est listée sous un petit nom hyper sexy, genre CVE-2024-12345.

(Oui ça fait frissonner n’est-ce pas ?)

Alors vous allez me dire, dans le monde du logiciel on parle de bug, pas de CVE et vous auriez bien raison. Mais il n’existe pas de recensement des bugs de tous les logiciels connus.

Donc ici je prends le nombre de CVE annuelles comme une sorte de révélateur du nombre de bugs dans les logiciels parce que je me dis qu’il y une petite corrélation entre baisse de qualité et augmentation des trous de sécurité. Enfin, à première vue, mais on va y revenir.

Et si on regarde ça, eh bien l’accélération pourrait dater de 2022 avec cependant une première étape vers 2017.

Si on prend l’année 2017 comme l’année de rupture, ça devient plus difficile d’imputer le problème à l’IA même avec la mauvaise foi d’un supporter marseillais (coucou Max, si tu me lis).

Dans les grandes lignes la hausse des CVE depuis 2017 s’explique probablement par un mix de facteurs :

• une plus grande pression sur les logiciels auxquels on demande désormais une nouvelle version par jour
• une explosion du numérique de façon générale
• beaucoup plus de programmes de sécurité (les bug bounty)
• une augmentation du nombre de logiciels dédiés à la sécurité informatique.
• des conflits géopolitiques importants et des attaques cyber plus fréquentes

En fait, il serait pas impossible qu’on mesure, le nombre de thermomètre (et pas uniquement le température), donc l’essor de l’industrie cyber, et d’un autre côté, l’essor du numérique qui devient un enjeu économique et géopolitique dans un contexte plutôt instable depuis des années.

Maintenant on peut quand même se poser la question pour la période post 2022 parce que la pente semble monter aussi vite que le nombre de dossiers judiciaires de Nicolas Sarkozy.

Cependant j’ai envie de dire que les CVE c’est pas le meilleur proxy pour mesurer la qualité logicielle parce qu’on l’a vu, les CVE peuvent augmenter pour des raisons plutôt exogène. C’est pas parce qu’on contrôle mieux qu’avant et qu’on scrute davantage, qu’il y a vraiment plus de bugs.

Donc on va revenir au point de départ et s’intéresser à une phrase que j’entends très souvent : l’IA c’est la mort du craft.

Avec l’IA, c’est la mort du craft

Le craft, pour ceux qui suivent pas au fond, c’est une sorte de mot valise pour regrouper tout un ensemble de pratiques qui vise à produire des logiciels de “qualité”. Si tant est qu’on sache définir la qualité d’un logiciel mais c’est un autre sujet.

Avec l’IA on ne ferait plus de qualité et l’expertise technique, l’intérêt du métier pour beaucoup, aurait disparu.

Attention, ici on a deux sujets différents :

• l'intérêt du métier disparaitrait parce qu’on ne ferait plus de craft
• le code produit par IA serait à l’informatique ce que la cuisine anglaise est à la gastronomie mondiale, c’est à dire pas terrible.

(Bon déjà rétablissons la vérité sur le second point, non la cuisine anglaise est largement pire)

Alors, il y a des personnes qui ont cherché à déterminer si le code produit par des IA était nécessairement moins “durable” que du code produit par un humain, bref si nous étions vraiment en train de construire des montagnes de dette technique à vitesse lumière.

IA slop et maintenance logicielle

Est ce que vous connaissez Dave Farley ?

Dave Farley est un des auteurs notamment du livre Continuous Delivery sorti en 2010.

Ca a été l’un de mes livres professionnels de référence pendant des années à une époque où on parlait beaucoup d’usine logicielle, de qualité et de déploiement continu. J’ai bossé des années sur ces sujets, notamment dès 2006 sur des concepts de CI distribués. J’ai bossé ensuite à partir de 2010 sur des thématiques d’industrialisation, puis à partir de 2012 sur le sujet du déploiement continu.

(ok papy mais continue ton histoire)

Eh bien Dave Farley a participé à une étude qui visait justement à déterminer quel était le code le plus maintenable entre le code produit par IA ou le code produit par des humains. Est-ce qu’il y avait plus de dette technique dans le code produit par IA ? Et la réponse est… non.

Pour être franc, même moi je suis surpris, et en même temps, pas du tout.

Je suis surpris parce que je sais l’effort d’ingénierie nécessaire pour qu’une IA marche bien. Sans ces efforts, le code ressemble vite à un Frankenstein un peu boiteux.

Mais, j’imagine que l’étude porte sur des professionnels qui ont eu le temps de mettre en place leurs outils habituels.

Construire une usine logicielle agentique

Je vous l’ai dit, j’aime créer des usines logicielles, je bosse sur ce sujet depuis des années.

L’usine logicielle c’est rien de plus qu’un procédé de fabrication, plus au moins industrialisé et automatisé.

Un générateur de code, aussi puissant soit-il, c’est pas une usine logicielle, c’est uniquement une des machines de l’usine.

Et si vous laissez juste tourner une des machines, c’est pas suffisant.

Quand un dev fait uniquement du copier coller de ChatGPT depuis un navigateur, c’est à peine 10% du travail et oui, le résultat est pas terrible et nécessite souvent beaucoup d’ajustements manuels.

Or, en étant un peu provoc, je dirais que retoucher au code produit c’est un échec. Imaginez la même chose dans une usine de voiture. S’il fallait des artisans qui se mettent à retoucher chaque voiture produite ce serait un peu surprenant. Et, je suis pas spécialiste, mais je crois que c’est pas comme ça que ça marche.

Bref, il faut les autres machines outils.

Dans notre métier ça consiste à construire des harnais de test et de validation, de définir les règles à respecter et de trouver des moyens de vérifier que c’est bien fait, de créer des skills pour guider le travail des IA et leur éviter de se planter, de leur permettre de vérifier eux mêmes avec des outils et donc de corriger etc… etc…

Et ça, en fait, c’est du craft. L’usage d'agents IA rend obligatoire les fameuses bonnes pratiques dont tout le monde parle mais qu’on voit pas si souvent dans les faits.

Tous les gens que je vois en ce moment dans la communauté DevWithAI c’est des crafteurs qui essaient d’améliorer leur usine logicielle. C’est des gens qui bossent sur des outils de compression de tokens comme rtk, des outils pour simplifier et uniformiser l’usage à l’échelle d’une équipe comme packmind, des guides d’usage comme celui de Florian.

Le craft n’a pas disparu. Il a changé.

Pour une boite, il y a un effort substantiel à faire pour introduire ces outils, construire une usine logicielle par dessus, créer de l’outillage, faire du platform engineering et il faut des gens pour ça, de la même façon qu’il faut des gens pour concevoir, maintenir, et faire évoluer les chaines de production dans les usines.

Bref, non, l’intérêt du métier n’a pas disparu selon moi, pour les gens qui aiment le craft et la technique.

Et si on parle de qualité, je vais vous surprendre mais, à mon échelle, je vois des bonds importants de qualité sur mes applications.

L’exemple de Writizzy

Je développe plusieurs produits, Hakanai et Writizzy. J’ai passé récemment Bloggrify en mode maintenance.
Bloggrify a démarré en 2022, Hakanai en 2023 et Writizzy en 2025.

Les deux premiers, j’ai presque pas utilisé l’IA au début puis j’ai progressivement introduit quelques copiers coller venant d’un usage très discret d’agents en lignes. C’est donc plus de 90% du code que j’ai produit à la main.

Eh bien aujourd’hui je dirais, que, ça se voit.

Attention, je suis fier de ce que j’ai fait avec Hakanai et Bloggrify. Mais pour faire une application en solo faut être très bon partout : sur la construction de l’application, sa logique, son ergonomie, son UI, sa robustesse. Or c’est pas mon cas. Donc parfois il y a des endroits où c’est un peu moins bien et ça se ressent.

Et puis au delà de ça, faire tout très bien, ça prend du temps. Quand on construis un produit, on doit toujours faire un choix entre le “parfait” et le “assez bien pour la majorité des usages”. Le modulo entre les deux étant le temps à disposition.

Parfois on capitule, on sait que c’est pas nickel, mais on vient d’y passer 1 semaine, et franchement pour une amélioration de 5% de la qualité, tant pis, on y passe pas une semaine de plus. Ce sera pour la prochaine fois. Cette fameuse prochaine fois qui n’arrive jamais.

En fait la qualité de Hakanai et Bloggrify était à géométrie variable. Il y a eu des raccourcis de pris, des pages avec une ergonomie digne du web des années 2000, et c’est pas grave, c’est comme ça qu’on construisais des produits jusqu’à présent.

Sur Writizzy, c’est plus du tout le cas. Je ne fais pas de raccourcis. Déjà pour la simple et bonne raison que pour produire du code correct avec de l’IA, il faut une usine logicielle qui tienne la route, et ca inclus des gardes fous, genre tests, linter etc… Donc ce n’est pas négociable, alors que finalement ça l’était avant pour Hakanai et Bloggrify.

En plus de ça, le cout du refactoring est devenu quasi nul. Le petit truc qui manquait pour qu’une fonctionnalité soit parfaite, désormais je peux le faire.

En fait aujourd’hui je peux prendre le temps de traiter les cas aux limites, ces fameuses petites exceptions qu’avant tu laissais sur le côté parce que “ça n’arrive jamais”. Je peux profiter du temps gagné sur le dev pour penser davantage à la sécurité, la robustesse, la scalabilité.

Produire du code est devenu une commodité. Donc j’en profite pour produire du très bon code.

Bref, je fais toujours du craft, mais il a changé de nature.
Et ce que je produis est de meilleure qualité. Alors je suis pas convaincu qu’on soit entré dans une ère du code de merde.

Maintenant il y a quand même une nuance à apporter. L'IA baisse drastiquement la barrière à l'entrée. C'est bien, mais ça veut dire qu'on se retrouve avec une marée de logiciels morts nés, de trucs qui vont pas survivre plus longtemps qu'une shitcoin promue par un influenceur de Dubaï, et des boites qui vont couper sévère dans les couts de R&D parce que… flemme, et si on augmentait les marges. Donc oui, dans ces conditions là, on va avoir un nombre de logiciels produits de mauvaise qualité qui va augmenter, des logiciels qui vont crever au bout de 3 mois parce que leur créateur vont se lasser très vite devant la réalité de gérer réellement un produit informatique. Mais les bons produits seront eux par contre bien meilleurs parce que le craft sera une condition sine qua non pour pas se crasher dans un monde où tout va aller beaucoup plus vite.

Je développe actuellement deux projets : Hakanai (pour les blogs statiques) et surtout Writizzy, qui vient de passer la barre des 550 utilisateurs en 6 mois. Mais tout cumulé, je ne dégage pas plus de 250 euros par mois et j’ai pour principe de ne pas dépenser plus que ce que gagne.

Donc j’ai une grosse contrainte, le budget. J’essaie de construire mes applications sans cramer des tokens à la vitesse de la lumière. Et je voulais vous partager comment je m’y prends.

C'est quoi Writizzy ?

Petit rappel pour situer le projet : Writizzy, c'est un équivalent à Medium ou Substack. Une plateforme pour écrire, envoyer des newsletters et monétiser son contenu. Je pense que c’est vital d’avoir des espaces d’expression hors des GAFAM (et hors US). C’est le logiciel qui fait tourner le blog que vous êtes en train de lire.

Côté code, on a trois gros morceaux :

• Une API en Kotlin.
• Une App admin en Nuxt.
• Une App "blog" (qui sert les contenus) en Nuxt également.

Pour bosser, j’utilise majoritairement Claude. Pourquoi ? Parce que ça reste le modèle le mieux noté sur les benchmarks de code.

Mais je suis proche de changer. Je vous en dis plus à la fin.

Le Context Engineering : Borner l'IA

L’idée pour travailler efficacement, c’est de donner le contexte nécessaire et suffisant au LLM pour limiter son espace de solutions. On veut lui donner des guidelines et des moyens de vérifier lui-même qu’il reste dans les clous. Si vous ne faites pas ça, ne vous étonnez pas que l’IA hallucine des API ou utilise des vieilles versions de doc. C’est normal.

Le fichier Claude.md

C’est le point d'entrée. On y trouve l’objectif du projet, la structure générale pour éviter que l'IA ne parcoure tout le code au pif, et surtout la liste des specs.

Cette liste est fondamentale dans mon process de dév, j’y reviens après. Elle sert également d’index pour Claude.

A noter que j’ai d’autres fichiers claude.md dans des sous répertoires, ces fichiers sont chargés par Claude s’il rentre dedans. J’en ai un par application (app, blog, et api). Ca me sert pour lister les technos à disposition mais j’ai tendance à plutôt utiliser les rules de plus en plus.

Les Rules (.claude/rules)

Ce sont des règles qui peuvent chargées conditionnellement. Par exemple ici, si Claude entre dans le répertoire /app, il charge les règles Nuxt.

Dans ce fichier de rules je définis les patterns que je souhaite voir utiliser, par exemple :
obligation d'utiliser Nuxt UI, de passer un coup de typecheck ou de eslint avant de finir, etc.

Ces règles, je les ai construites empiriquement. C’est a dire que le fichier était vide à l’origine, puis j’ai ajouté des rêgles en fonction des erreurs que je voyais revenir. Plus récemment j’essaie de limiter les explorations de Claude donc je lui demande systématiquement s’il a vu des patterns qu’il faut document dans les rules pour éviter de dépenser des tonnes de tokens en exploration. En plus j’aime pas trop qu’il devine en fonction du code qu’il rencontre.
Exemple de question que je lui ai posé récemment :

je cherche à améliorer les rules que j'ai déjà mis en place. Je trouve que tu as du lire beaucoup de fichiers pour comprendre le contexte et les patterns. Pourquoi ? Fais moi une synthèse des patterns que tu cherchais à connaitre pour voir si on peut en faire des rules

En fait la construction de ces fichiers de rules c’est une sorte de harnais de sécurité. Mais il faut aussi comprendre que ce n’est une garantie car les LLMs vont régulièrement ignorer des rêgles. Donc il faut renforcer les moyens de contrôle : tests, linter, CIn quality gate etc…

Je note d’ailleurs qu’il est plus facile pour ceux qui ont l’habitude de développer avec des bonnes pratiques de bosser correctement avec l’IA. Ces pratiques servent de garde-fous mais pour de nombreuses boites, c'était un peu de la poudre aux yeux mais pas très efficaces en pratique. Et justement, dans les boîtes où ces méthodes ne sont pas matures, l’IA ne décolle pas. On se demande bien pourquoi... Ou pas…

La commande "Analyst"

Une commande c’est une sorte de pré-prompt. J’utilise une commande analyst pour le brainstorming. Je lui demande d’être un spécialiste du blogging, de l'IndieWeb et de la décentralisation. Je lui demande de challenger mes besoins, de détecter les incohérences et surtout d’écrire les specs.

La Spec avant le code

Plus haut je parlais des specs qui sont listées dans le fichier claude.md.

Parlons un peu de mon cycle de dev.. Je passe systématiquement par une spec avant le moindre morceau de code significatif.
(Amusant quand je repense à l’époque où j’ai lancé Malt, il n'y avait pas grand-chose d’écrit au début…)

Avec l’IA, la spec a deux intérêts majeurs :

1. Cadrer le résultat attendu. On définit d’abord la direction, les flow utilisateurs etc..
2. Économiser des tokens dans le futur : En listant les points d'accès techniques et les fichiers clés dans la spec, Claude n'a pas besoin de chercher partout.

En effet, quand Claude va retravailler sur une feature déjà existante, il va utiliser le fichier spec pour comprendre le fonctionnement et surtout facilement revenir sur les fichiers clés. Avec ces specs, il va économiser énormément de temps pour ça, et surtout ce sera plus précis que de le laisser deviner.

Une fois la spec validée, je créé un plan d’implémentation (enfin, Claude créé un plan). Pour ça, j’ai un skill qui lui impose mes pratiques : chaque étape doit être déployable, il doit utiliser des features flags si nécessaire etc...

L'art de gérer sa fenêtre de contexte

Ici faut que je revienne sur la notion de fenêtre de contexte parce que c’est important pour optimiser le budget mensuel. Ce qui coûte cher, ce sont les sessions interminables. À chaque échange, vous renvoyez tout l'historique. Au bout d'un moment, un simple "Ok" peut coûter des dizaines de milliers de tokens. Donc déjà, ça, ça coute cher.

Mais le second effet kiss cool, plus la fenêtre est pleine, plus l'IA devient "bête". J’essaie donc ne jamais dépasser 50% de remplissage. C’est tout l’intérêt des plans d’implémentation. L’idée c’est de découper en petites tâches autonomes et de changer de session régulièrement.

Skills vs MCP : Le combat de l'efficacité

J’ai un peu évoqué les skills avant. J’en fais un gros usage pour être plus efficace. Et il y a un vrai parallèle entre efficacité et cout donc il faut que j’en parle ici.

Un Skill, c’est une compétence chargée à la demande. Par exemple, mon skill Nuxt impose à Claude d'aller lire la doc en ligne (au format Markdown) plutôt que de se baser sur ses données d'entraînement périmées.

J’ai des skills pour différentes choses :

• des apis qui précisent mes patterns de design : api-design, db-migration, write-spec

C’est parfois un peu plus que “juste” préciser des patterns, par exemple le skill db-migration liste exactement les outils à utiliser (Flyway), l’emplacement des fichiers de migration, le format des fichiers. Et côté pattern on retrouve mes principes clés de stratégie de déploiement (rolling update etc…)

• bento, nuxt, nuxt-content, nuxt-ui pour préciser comment aller chercher la doc
• des skills qui expliquent comment utiliser un cli, par exemple sentry-fix-issues qui explique comment utiliser le cli sentry pour récupérer les infos, faire un diagnostique, et corriger

À côté, on a les MCP (Model Context Protocol). C’est puissant également, mais ça prend une place plus importante dans le contexte car chaque méthode du MCP est inclus dans la fenêtre de contexte. Là où un skill, c’est uniquement la description du skill qui est incluse.
Donc Je privilégie les Skills, sauf pour :

• MCP IntelliJ : Pour naviguer proprement dans le code et compiler.
• MCP Stripe : Pour debugger la configuration.
• Claude-mem : censé retenir les décisions clés entre les sessions (je teste encore, le gain n'est pas encore flagrant).

Et le design ?

Récemment, je suis passé sur Claude Design. C’est devenu mon outil de prédilection. Je briefe, je commente des zones, je modifie à la volée, et une fois le HTML propre, je le file à mon agent Claude pour l’implémentation. C’est bien au-dessus de ce que je faisais avant en simple prompting. Les résultats sont vraiment bluffants.

Bilan : Comment tenir le budget ?

Bref, avec tout ça j’arrive à m’en sortir pour 20€ par mois mais j’ai quand même quelques astuces supplémentaires :

• La compression des tokens : J'utilise des stratégies de compression (comme rtk) ou je créé mes propres tools pour n’envoyer aux llms que ce qui est nécessaire.
• Les IA en ligne : Si je veux brainstormer "gratuitement", je vais sur Gemini. Je suis moins fan en général mais ça peut servir de relais avant d’aller vraiment bosser avec l’analyste par exemple.

Mais surtout, j’ai une astuce incroyable… je clos ma session de travail quand Claude m’indique que j’ai dépassé mon quota. Tout simplement.

Quand c'est fini, je m'arrête. Je vais faire de la menuiserie, de la cuisine, j'écris un article (c’est exactement ce que je suis en train de faire là ^^).

Ca a l’air de rien mais cette discipline est en réalité salutaire. Je ne le vois pas uniquement comme une contrainte mais aussi comme une opportunité pour faire autre chose, réfléchir, consolider ce que j’ai appris etc… Ca rejoint ce que j’écrivais sur un article récent, c’est bien de gagner du temps, mais il faut savoir en profiter.

Prochaine étape : je teste des modèles locaux. L'idée est de déléguer les petites tâches d'implémentation à ma machine et de garder Claude uniquement pour la planification stratégique. C’est vraiment le début donc j’en parlerais plus tard.

Si le sujet vous branche, allez faire un tour sur le Slack DevWithAi (plus de 2200 membres). C'est une mine d'or.

Je suis loin d’être le plus avancé possible sur ces sujets et surtout je suis dans un contexte solo. Mais si vous avez vos propres tips à partager, n'hésitez pas en commentaire, ce sera lu avec attention.

Bref, ça fait 181 jours que j’ai lancé Writizzy. C’est la plateforme de blog que j’utilise pour cet article notamment. Je suis le premier convaincu de mon propre produit, ce qui est déjà une petite victoire :)

Avec un peu (beaucoup) d’exagération je pourrais vous dire qu’en 181 jours Writizzy a réussi à se hisser au même niveau qu’un Substack, Medium ou Beehiiv en termes de fonctionnalité.

Evidemment côté utilisation c’est un peu plus loin. Il y a presque 480 utilisateurs qui l’ont testé, dont environ 130 qui sont vraiment actifs.

Et surtout, c’est loin d’être un long fleuve tranquille. J’ai une énorme épine dans le pied : j’ai très peu de gens qui découvrent le produit. Et même pire que ça, mon traffic est en baisse.

Avec 1850 visiteurs uniques en avril, c’est mon 2eme pire mois depuis le début. Et l’une des raisons (mais pas la seule), c’est le SEO.

Le SEO fait défaut

Le SEO fait défaut, ça aurait pu être un titre de film avec Jean Dujardin.

Avec 1850 visiteurs uniques mensuels, je fais presque 3 fois moins de traffic que mon propre blog, celui que vous êtes en train de lire. C’est… perfectible :)

L’essentiel du traffic vient des réseaux sociaux, de Reddit, de Facebook (?? je sais pas pourquoi), de uneed (une plateforme de lancement de produit), et des différents blogs qui utilisent déjà Writizzy.

Il y a du traffic qui vient de Google mais c’est ce qu’on appelle du traffic “Brand”. Ce sont des gens qui tapent writizzy donc ils connaissent le produit et dans ce cas on peut pas appeler ça de l’acquisition de nouveaux utilisateurs.

Donc il y a quelques semaines j’ai voulu m’auto auditer pour voir si je pouvais trouver des choses qui n’allaient pas. Et pour ça j’ai trouvé un ensemble de skills pour Claude : claude-seo.

Claude-SEO c’est une vingtaine de skills qui vont tester plusieurs parties : la qualité du contenu, les markup json-ld, le GeoSearch (ai search optimization), le technical SEO etc…

Il y en a 21, donc je vais pas tout lister, vous m’excuserez…

Une fois installé, j’ai lancé la commande /seo audit https://writizzy.com et voici le premier résultat :

47/100 c’est pas énorme et en même temps, c’est plutôt une bonne nouvelle. Ca veut dire qu’il y a des choses à faire et que l’outil va pouvoir m’aider.

Les enseignements du premier run

Claude-SEO teste pas mal de choses et notamment le SEO technique.

C’est en théorie la partie la plus simple puisqu’il s’agit de toutes les optimisations de structure, de titre, de performance, de schéma json etc…

J’ai eu des conseils plutôt pertinents notamment sur l’optimisation des images de la home et des directives de préconnexion sur mon CDN Bunny.

<link rel="preload" as="image" href="/herobg.webp" fetchpriority="high">
<link rel="preconnect" href="https://writizzy.b-cdn.net">

J’ai aussi eu pas mal de retours sur les schéma JSON-LD utilisé sur la page.

::callout{type=info} A propos de JSON-LD : Il faut comprendre qu’un robot qui indexe un site ne le lit pas comme nous. Et on peut l’aider à mieux comprendre de quoi il s’agit en lui filant des données structurées sous forme de JSON-LD. C’est invisible pour le lecteur humain mais très pratique pour le robot d’indexation. ::

Vous pouvez voir toute la structure JSON-LD de la home page que j’ai modifié grace à ce site (que je vous invite à utiliser pour vous même) : validator.schema.org

claude-seo m’a également permis de me rendre compte d’un bug dans la librairie nuxt-seo que j’utilise et qui impactait tout les title et meta description de mon site. Toutes les pages avaient les mêmes attributs.

(Au passage, Claude m’a également permis de diagnostiquer le bug pour ouvrir une issue qui a été corrigé depuis)

Mais surtout claude-seo m’a suggéré plusieurs ajouts pertinents :

• l’ajout d’un fichier llms.txt pour améliorer mon référencement par les assistants IA
• l’ajout de pages dédiées pour l’équipe fondatrice, le pricing, les pages features

Habituellement on a tendance à créer des landing page qui regroupent toute ces informations mais apparemment il peut être intéressant d’avoir d’autres pages pour répondre à des intentions de recherche bien spécifiques, comme “writizzy pricing”.

Et concernant la page about, il s’agit de renforcer l’autorité du site au vu des critères E-E-A-T, critères qui aident Google pour apprécier l’autorité/réputation/confiance qu’on peut accorder à un site.

Une fois tout ça mis en place, j’ai lancé un second run pour obtenir 64/100.

Un second run instructif et quelques bugs

claude-seo n’est pas un outil déterministe. Autrement dit, certains nouveaux problèmes pertinents peuvent apparaître alors qu’ils n’avaient pas été notés dans le premier run.

Second souci, parfois le crawling des pages échouent, par exemple lors de ce second run, le fichier llms.txt était toujours considéré absent alors qu’il était bien présent. Idem, le blog n’a pas été détecté alors qu’il était bien présent.

Cependant, on notera quand même une progression entre les deux executions et certains nouveaux problèmes étaient totalement valides :

• aucun headers de sécurité n’était présent. C’est pas crucial pour le SEO mais ça reste un mauvais signal. J’ai donc installé nuxt-security qui m’a permis de résoudre ce point très rapidement.
• plus embêtant, http://writizzy.com répondait une 200 et www.writizzy.com envoyait une erreur SSL parce que la seule URL valide c’est https://writizzy.com. C’est effectivement normal mais pas bon du tout en terme de crawling. Le http doit renvoyer vers https et le www aussi si on ne veut pas le gérer. Tout a été géré directement au niveau de bunny et de Coolify.
• Claude-seo a suggéré plusieurs ajout de directives pour le cache-control et m’a même suggéré la configuration pour Nuxt puisqu’il savait que je l’utilisais.

Je passe d’autres détections plus mineures ou moins intéressantes, ce qui nous amène à la 3eme execution : 71/100

Cette 3eme execution a surtout permis de détecter des erreurs d’implémentations sur ce qui avait déjà été fait, des erreurs d’encodage dans du JSON-LD, des logos avec un format non accepté pour open graph, quelques suggestions d’ajout de pages supplémentaires.

Verdict ?

Ce plugin Claude a été super intéressant. J’ai appris des choses (comme EEAT ou certaines entités JSON-LD que je ne connaissais pas), ça a mis en évidence des problèmes que j’aurais pu voir moi-même (comme les headers de sécurité, l’absence de redirect de http vers https) ou permis de mieux configurer mon framework Nuxt.

Je recommande très fort de tester sur son site.

Maintenant, est-ce que ça a marché ? Est ce que mon SEO est devenu le meilleur du monde ?

Eh bien pas vraiment. Pour une raison que je ne m’explique pas, Google refuse d’indexer les pages de mon site à part la Home. Si on regarde sur google avec site:writizzy.com, seule la home ressort. Et c’est confirmé dans la google search console qui liste toutes les autres pages comme “Discovered Currently Not Indexed”.

Et la, mystère.

D’autant que j’ai exactement le même problème sur hakanai.io qui est un autre produit que je réalise et seul la home est indexée encore une fois.

A ce stade, pour l’instant je suis un peu perdu. Je pense avoir vraiment bien améliorer le SEO d’un point de vue technique mais je dois passer à côté d’un énorme souci que je ne comprends pas.

Pour une raison que j’ignore, mon site est considéré comme peu fiable, ou manquant d’intérêt alors même que j’ai un domain rating de 47 et 3000 backlinks.

Bref, le SEO c’est pas juste de la tech et pour l’instant j’ai pas encore les clés :)

Si vous avez des connaissances en SEO et des idées, n’hésitez pas, je suis preneur.

Prochaines étapes, je vais reprendre chaque page une par une. Si Google juge mon contenu « inintéressant », il faut que je comprenne pourquoi.

En attendant, si vous voulez m'aider à envoyer des signaux positifs à Google (ou juste tester un outil de blogging plutôt cool), n'hésitez pas à lancer votre blog sur Writizzy avec un petit lien retour, c'est un coup de pouce qui pourrait m’aider ^^

Posons le cadre. Vous gérez un pays. Enfin non, on va augmenter la difficulté. Vous gérez un état fédéral constitué de plusieurs pays.

Cet état perd de l'argent chaque année parce qu'il achète plus qu'il ne vend aux états voisins.

Cette fuite a plusieurs conséquences, vos entreprises font moins de vente, donc elles sous-investissent. Vos habitants ont moins de boulot, sont moins bien payés.

Vous dépendez des produits importés. Les états qui vous les vendent en profitent pour vous imposer leurs conditions pour continuer de travailler avec eux.

En réalité vous l'aurez compris ce jeu existe déjà. Il s'agit de l'Europe et les produits dont je parlais ce sont essentiellement les services numériques.

Et apparemment en ce moment on étudie une solution pour contrebalancer cette lente colonisation numérique : l'open source.

Ok, alors on va étudier cette piste et essayer de comprendre où elle peut nous mener.

264 milliards d'euros et 1M d'emplois

264 milliards d'euros et 1M d'emplois, c'est ce que l'Europe laisse s'échapper chaque année vers les grandes entreprises Tech américaines (cloud, IA etc...).

Ce chiffre cache d’énormes angles morts. Le numérique c’est des emplois directs ET indirects, c’est des possibilités d’espionnage, des affaires avérées de manipulation d’opinion publique.

Et un poids constant sur nos relations, parce qu’il est difficile de résister à notre dealer numérique quand il nous impose ses conditions, par exemple pour abandonner nos politiques d’inclusion au sein de nos entreprises.

Alors dans ce contexte l’Europe veut s’appuyer sur l’European open digital ecosystem.

Donc l’open source serait la solution ?

Open source et géopolitique ?

Si l’argent n’a pas d’odeur, est ce que l’open source aussi ? Pas si sûr.

Déjà une license ouverte n’indique rien sur la gouvernance d’un projet, c’est à dire de savoir qui décide et qui capture les revenus.

Enormément de projets open source majeurs sont tout simplement financés par des grandes entreprises américaines, par exemple Kubernetes, React, VsCode, Gitlab dont une grande majorité de contributions vient d’ingénieurs salariés.

Une autre partie des projets est gérée par des fondations qui peuvent également être aux US (Apache, Linux, Mozilla par exemple).

Et en cas de conflit, l’open source a beau être ouvert, l’Europe pourrait se retrouver pénalisé.

Nous pourrions être exclu des principales plateformes de distribution de l’open source, comme Github qui a interdit son usage en Iran dans le passé.

Un projet pourrait décider unilatéralement de ne plus supporter des standards ou législations locales (comme les notions de privacy).

Un état pourrait influencer des contributeurs pour insérer des backdoors.

Mais c’est de l’open source. Alors on pourrait créer notre propre variation du code et la maintenir en Europe, non ?

Pas si simple.

Ca impliquerait de trouver, mobiliser et financer des armées de contributeurs en Europe, contributeurs qui passeraient une partie du temps à “juste” rattraper le retard pris sur le code d’origine et à vérifier qu’aucune porte dérobée n’a été introduite pour nous cibler.

Bref, ça demande des moyens et des motivés ayant juste envie de maintenir des projets construits ailleurs.

Et puis il ya une notion d'écosystème. Par exemple Huawei qui a forké android mais qui n'a pas pu accéder au store et aux google play services, ce qui a fortement limité l’intérêt.

Alors vous allez me dire, heureusement on a aussi des fondations en Europe. Eclipse a déménagé en Europe en 2020, ce qui fait d’elle la plus grosse fondation Open source européenne.

Certes, mais une fondation vit des cotisations de ses membres et les principaux contributeurs pour Eclipse sont américains (IBM, Oracle, Microsoft, Intel, Amazon, Google par exemple). Sans compter que la fondation Eclipse n’est pas la plus avancée sur les sujets du moment comme l’IA ou le Cloud.

Une fragilité structurelle de l’open source

C’est pas juste une intuition, on tourne beaucoup autour de la notion de moyens.

D’autant que jusqu’à présent on a surtout parlé des très gros projets mais la grande majorité des projets repose sur des bases fragiles.

L’open source est sous-financé. De très nombreux projets sont juste trop petits pour être visibles alors que c’est sans doute le moteur de 99% des logiciels numériques modernes (source : moi-même mais je pense pas trop me tromper).

Entre burnout des contributeurs principaux et manque de moyens pour avoir un rythme de travail compatible avec les exigences actuelles, on peut facilement faire le lien entre cette fragilité et les risques cyber. Log4shell, Hearbleed, xz sont de parfaits exemples de faille et d’attaque cyber ayant ciblé l’open source.

Reposer sur des acteurs aussi fragiles, sans les financer, c’est de l’hypocrisie.

Mais c’est une conclusion largement partagée et l’Europe prévoit de mettre de l’argent sur la table pour financer l’open source et le poser en alternative aux grands logiciels US.

On parle de programme de financement, de plusieurs milliards d’euros et de favoriser les solutions open source.

Les communs numériques

Evidemment on en revient au problème indiqué plus haut, open source ne rime pas avec neutralité. Donc l’Europe va poser des critères et surtout poser la définition d’un commun numérique :

Un commun numérique n'est pas seulement un logiciel (le code) ; c'est un ensemble composé de trois éléments indissociables :

• Une ressource numérique : Un logiciel, une base de données, un standard technique
• Une communauté : Des développeurs, des contributeurs, des entreprises et des utilisateurs qui entretiennent la ressource.
• Une gouvernance : Un ensemble de règles qui définit qui peut contribuer, comment les décisions sont prises et comment on empêche la capture de la ressource par un acteur unique (le "verrouillage").

Un projet open source "dicté" par une seule multinationale américaine n'est pas un commun numérique, car la communauté n'a aucun pouvoir de décision réel.

Et des “communs numériques” créés en Europe, il y en a : OpenStreetMap, VLC ou tout simplement, Linux et le WEB.

Vers un open source fragmenté ?

La première crainte en cas de guerre froide numérique, c’est de voir une fragmentation de l’open source : des guerres de licenses, des exclusions de contributeurs ciblées par pays, une baisse de la collaboration internationale parce que globalement c’est déjà devenu compliqué d’obtenir un visa pour aller dans des évènements à l’étranger mais c’est en plus un acte politique (et écologique) de refuser certains déplacements à l’étranger.

Mais, si ce constat est plutôt noir, il est relativement inévitable. Dans un monde qui se referme, l’open source ne vivra pas isolé dans sa bulle. Et ça va nous forcer à nous créer notre propre identité numérique.

Une identité numérique Européenne

C’est vrai, l’open source seul n’est pas la solution parce que c’est un écosystème fragile, sous financé, et pas neutre par nature.

Une grosse partie de l’Open Source US est financé par des grandes entreprises US mais c’est surtout un cheval de Troie numérique pour capturer des revenus.

Mais combien d’entreprises tournent sur du libre aux US ?

Assez peu.

C’est moins vrai en Europe. La CPI tourne sur OpenDesk. Plusieurs administrations Françaises viennent d’annoncer leur migration sur “La suite numérique”.

On pourrait voir se dessiner une identité numérique Européenne qui repose sur des standards comme l’interopérabilité (les formats ouverts), la réversibilité (la capacité à facilement récupérer ses données), les communs numériques dont je parlais juste avant.

On pourrait voir des consortiums industriels s’allier pour créer des standards numériques, comme par exemple Eclipse SDV (pour le développement des voitures autonomes).

On pourrait imaginer des conditions dans les appels d’offre publiques pour éliminer de facto les produits US, comme par exemple une clause d'immunité extraterritoriale pour nous protéger par défaut contre les lois extraterritoriale comme le Cloud Act.

Et puis enfin on peut imaginer que l’Europe devienne une terre d’accueil de l'éthique numérique attirant des talents mondiaux qui veulent contribuer à des projets qui servent l'intérêt général plutôt que le cours de bourse d'un géant.

Bref, l’open source n’est pas une baguette magique pour que l’Europe cesse d’être une colonie numérique. Il faudra aller plus loin, ça passera par une commande publique courageuse, des financements massifs des communs numériques et une protection juridique stricte face aux lois extraterritoriales. L'identité numérique européenne ne sera pas un cadeau des géants de la Tech, mais une infrastructure que nous devrons bâtir.

Et si ce chiffre tout seul ne veut pas dire grand chose, sachez qu’il représente environ 10 fois le volume annuel des licenciements pré covid.

A ce titre, est-ce qu’on peut se dire que l’humain se fait progressivement remplacer par l’IA comme beaucoup nous l’annoncent ?

D’ailleurs en France l’INSEE parle d’une contraction du marché de l’emploi lié directement à l’essor de l’IA :

Mais bon, corrélation n’implique pas causalité donc on est en droit de se demander si au delà des effets d’annonce, il y a pas autre chose qui se cache.

Alors j’ai voulu aller un peu plus loin et m’intéresser aux causes profondes pour comprendre cette vague. Et il s’avère que l’IA n’est peut-être pas notre souci le plus important.

Larges vagues de départs causés par l’IA

Si on lit les dernières actualités il y a de quoi s’inquiéter :

• Oracle vient de licencier 30 000 personnes (20% de ces effectifs)
• Block a supprimé 40% de ces effectifs

Et j’aurais pu vous citer Meta, Amazon, Klarna, ASML, Ericsson, Salesforce, la liste est longue…

Dans la plupart des cas, l’IA fait partie des raisons invoquées. Et ce narratif a un avantage majeur car sur le papier ces boites disent : on automatise, on gagne en productivité et on réduit nos couts fixes. Ce qui a plutôt tendance à rassurer les actionnaires.

Le cours de bourse de Block par exemple s’est un peu redressé en février suite aux annonces :

Et c’est pareil pour le cours de l’action chez Oracle (annonce faite le 30 mars)

Maintenant des doutes subsistent et comme le dirait cet article : “est ce que ce serait pas surtout des licenciements avec un meilleur marketing, de l’AI washing ?”

Block compense surtout des erreurs de gestion passées

Block c’est le nouveau nom de Square, une entreprise de paiement que vous connaissez peut-être via son petit terminal de paiement qui est désormais assez présent un peu partout :

Mais Block c’est pas uniquement un terminal de paiement, c’est aussi des boites dans la crypto parce que son fondateur, Jack Dorsey, est un grand convaincu des crypto monnaies.

Jack Dorsey c’est aussi l’ex fondateur de Twitter qui a revendu l’entreprise à Elon Musk il y a quelques années.

Or Jacky, il a tendance à voir grand. Twitter faisait 8 000 employés lorsqu’il a revendu l’entreprise, entreprise qui tourne aujourd’hui avec 2800 personnes.

Chez Block, l’entreprise a vu un triplement de ces effectifs post covid. On parle d’une entreprise de 12 000 employés qui n’en faisait “que” 4000 pré 2020.

Alors bien sûr on peut le comprendre en regardant l’effet covid sur l’action Block

Sauf que le retour à la réalité en 2022 fait plutôt mal. L’entreprise stagne, et avec une explosion de la masse salariale, ça ne pouvait pas bien finir.

On a donc commencé à voir des plans de performance se dessiner :

Parce que si on regarde les fondamentaux économiques comme le fait cet article, et bien on se rend compte surtout que Block est largement moins rentable que ces concurrents avec une marge brute inférieure de moitié par rapport à eux.

L’IA aujourd’hui c’est surtout une manière “jolie” de maquiller des erreurs de gestion pour rassurer ces investisseurs.

Oracle ne licencie pas pour des gains de productivité

Le cas d’Oracle est un peu différent. Officiellement, c’est pas des départs causés par des gains de productivité, mais une réorientation des investissements vers de l’infrastructure pour supporter l’IA.

Dans leur cas aussi le cours de la bourse est plutôt inquiétant mais c’est pas le moteur principal des changements.

Comme le dit cet article, c’est avant tout de l’investissement.

The job cuts at Oracle come as it has ++invested heavily in AI++, spending both on its own infrastructure and on partnerships with other companies like OpenAI.

It plans to spend at least $50bn (£37.8bn) on infrastructure this year, and it has also raised $50bn in debt in order to "meet demand" for even more AI infrastructure.

Oracle is also part of the Stargate initiative, alongside OpenAI, Softbank and MGX, an AI investment fund backed by US President Donald Trump.

Ici il s’agit donc avant tout de réorienter son capital d’une activité traditionnelle qui bat un peu de l’aile vers une activité qui est censé la supplanter dans quelques années.

En réalité je ne vais pas critiquer. C’est une stratégie, un pari. Un pari énorme mais qui rentre dans la même catégorie que celui qu’aurait du faire Kodak quand le numérique est arrivé. Et Oracle n’a pas envie d’être le nouveau Kodak.

Le marché anticipe des gains non réalisées

Et c’est bien le sujet, personne n’a envie d’être le nouveau kodak.

Quand un leader (comme Block, Google ou Meta) licencie 10 % de ses effectifs et que son action monte en Bourse le lendemain, toutes les autres boites sont tentés de faire pareil.

Licencier parce qu'on a mal géré sa boîte serait un aveu d'échec alors que licencier parce qu'on "se transforme grâce à l'IA" c’est une vision d'avenir.

Et ce FOMO (peur de rater quelque chose), c’est ce qui explique beaucoup de plan de départs actuels. On parle de “RIFs before reality” chez Gartner, l’anticipation de gains non réalisées :

The employment deal is being rewritten in real time. CEOs are making bold moves based on AI’s promise rather than its proven impact. Layoffs linked to AI dominated headlines last year, but Gartner data shows fewer than 1% were due to actual productivity gains.

Cette anticipation conduit à des réorientations d’investissement. Le cas d’Oracle est représentatif à ce niveau. Tout le monde n’investit pas dans une infrastructure mais beaucoup réinvestissent dans l’ingénierie de façon à automatiser d’autres fonctions de l’entreprise mais surtout à être prêt pour l’avenir.

AI is no longer just a growth story; it’s a cost-reduction tool, and firms are restructuring accordingly. What we’re witnessing is a shift from headcount-driven expansion to automation-led productivity, a transition that will define the tech sector in the coming years,

Alan Cohen, analyst chez RationalFX.

Bon, ce qui est pas nouveau, et je constate une certaine forme d’hypocrisie d’une partie des développeurs qui découvrent aujourd’hui que leur métier a toujours eu pour but d’automatiser le métier des autres. C’est dommage de le découvrir quand ça nous touche personnellement…

Bref, ce qui est sûr c’est que les boites anticipent des réductions, sans avoir encore la démonstration des gains à venir. C’est pas juste quelques layoffs et on aurait des signes notamment relevé par cet article du fondateur de levels.fyi : on assiste à une simplification des chemins de carrière :

Un plan de licenciement c’est ponctuel. Mais quand on commence à supprimer des échelons dans les chemins de carrière, c’est qu’on anticipe une tendance durable de réduction globale des effectifs.

Et pourtant, encore une fois, les gains ne sont pas si évidents que ça pour l’instant.

Des gains de productivité pas encore largement démontré

On a tous notre opinion sur le sujet.

Je considère que je suis plus productif avec l’IA. Mais c’est pas l’avis de tout le monde.

Mais dans tout les cas, ce sont juste des opinions.

Il existe des études autour du sujet de la productivité mais il existe pas de consensus.

On peut trouver des études qui démontrent qu’on est moins productifs mais on peut aussi en trouver d’autres qui disent l’inverse.

Alors les causes sont multiples, la première c’est ce qu’on appelle le paradoxe de la productivité :

You can see the computer age everywhere but in the productivity statistics

Et oui, on se demandait à l’époque si l’informatique nous permettait vraiment d’être plus productifs. C’était pas du tout une certitude.

Ce paradoxe il s’explique de deux façons.

La première c’est que les entreprises passent plus de temps à configurer les outils, à former les gens et à réorganiser les flux qu'à produire réellement plus.
Et la seconde c’est parce qu’une nouvelle technologie nécessite un temps d’apprentissage qui peut être assez long pour être maitrisé. Et c’est ce qu’on voit aujourd’hui, l’usage de l’IA est totalement nouveau. Et beaucoup vont juste plus vite à faire ce qu’ils faisaient mal avant.

Et puis comme c’est pas comme si on savait mesurer la productivité des devs. Je rappelle que cette question n’a pas toujours pas trouvé de réponse universelle depuis qu’on se la pose.

Maintenant j’ai aussi entendu pas mal de CTO/DSI en fonction qui disent en off qu’ils ont les moyens de faire la démonstration. Mais qu’ils ont pas envie de la faire. Parce que faire la démonstration reviendrait ensuite à prendre des décisions qu’ils ont pas envie de prendre.

Et je peux vous dire que dans cette période, je suis ravi de plus être CTO…

Des raisons économiques plus profondes

Maintenant malgré tout, on l’a vu, gain de productivité ou pas, est-ce qu’on peut vraiment dire que tout les layoffs actuels sont liés à l’IA ? Sans doute pas.

Une étude citée récemment montre que 59 % des responsables RH admettent que l'IA a été utilisée comme "couverture" pour justifier des coupes budgétaires qui étaient en réalité dictées par :

• Le sur-recrutement post-COVID.
• La pression des investisseurs pour augmenter les marges.
• Des erreurs de stratégie interne.

Mais ce serait hyper réducteur selon moi.

C’est surtout la énième démonstration que nous avons changé d’ère post covid. Entre l’augmentation de l’inflation, les guerres commerciales en cours et les débats sans fin sur les droits de douane, l’explosion des couts sur l’énergie, les différents conflits qui paralysent une partie des échanges commerciaux internationaux, on est surtout en pleine récession.

L’IA c’est une facade pour masquer le reste. Quand Trump s’excite sur son projet Stargate (construction de datacenter), c’est du storytelling pour cacher la misère même si c’est vrai que l’IA c’est sans doute l’un des moteurs du secteur militaire dans les années à venir et la perte de vitesse des US sur le sujet les fait sans doute flipper.

Oui, parce que le pire c’est que même sur l’IA, c’est pas dit que les gens qui mènent la danse seront américains.

Les dernières modèles chinois comme Ernie, DeepSeek, Qwen, Kimi sont largement au niveau par rapport a du Gemini ou ChatGPT, sans avoir forcément couté le même prix. Kimi et Deepseek aurait couté 10% lors des phases d’entrainement par rapport à leur homologues américains.

Ce qui, au passage, est d’ailleurs encourageant mais surtout logique, la techno s’améliore et on n’a jamais vu dans le passé des technos rester aussi peu efficientes avec les années. L’ordinateur qui a envoyé une fusée dans la lune était moins performant que notre smartphone pour une consommation d’énergie pourtant largement supérieure.

Et c’est un peu pour toutes ces raisons que les entreprises US sont en pleine cure d’amaigrissement. Les acteurs dans l’IA ont besoin de devenir plus compétitifs. Ils investissent à fond et élaguent dans la masse salariale dans le même temps.

Les autres entreprises tech prennent ca pour exemple, contraintes en plus par des conditions économiques hyper défavorables et dans un contexte ou dire que licencier pour augmenter la productivité c’est plus vendeur que d’admettre la réalité.

Une nouvelle ère ?

Et nous au milieu de tout ça, eh bien…

Je vais être honnête, je me suis vraiment demandé comment conclure cet article. J’essaie toujours de finir sur une note positive, mais l'exercice est ici difficile. Je vais quand même tenter.

Est-ce la fin d’une ère ? Sans doute celle de l'hyper-croissance déraisonnée, ce qui est pas plus mal. Cette cure d’amaigrissement forcé va peut-être nous aider à revenir à l’essentiel et pas juste courir après des vanity metrics (le nombre d’employés par exemple).

C’est aussi un basculement économique global et un bloc US qui a tendance à vaciller. Je veux y voir un peu de positif en se disant que l’Europe a des cartes à jouer. On est moins touchés que les US par les énormes vagues de layoffs récentes. Sans doute parce qu’on a des masses salariales moins délirantes qu’aux US, des modèles sociaux plus solides.

Alors que les géants américains se recentrent dans la douleur, c’est le moment pour nous de combler nos retards. Ces nouvelles technologies, plus accessibles et plus efficientes, nous permettent d’aller plus vite avec moins de moyens. C’est peut-être enfin l’heure de créer de vraies alternatives technologiques européennes, plus sobres et plus pragmatiques.

Sur ce, vous pouvez retourner à une activité normale.

Et je me suis effectivement posé la question. J’ai une réponse de mon côté, que je vais vous partager. Mais je suis bien conscient que mon cas est particulier. Donc je voulais creuser un peu et je me suis rendu compte d’un truc : ce n'est pas gagner du temps qui devrait vous préoccuper. C'est : ça change quoi pour vous ?

Est-ce que vous bossez moins, plus, différemment ?

Quel est l’impact dans une grosse boîte ? Ou pour un(e) freelance ?

Bref, ++si++ une personne gagne du temps, à quoi ça lui sert ? 

Un gain de temps discutable ?

Bon déjà, pour être complet sur la question et surtout prendre du recul, une ++étude récente du METR++ (Model Evaluation & Threat Research) montre que ce gain de temps ne serait pas si évident que ça. 

L’étude montre que des développeurs expérimentés sur une base de code historique serait 20% plus lent avec l’IA, lié en grande partie aux cycles de relectures. 

Il faut prendre l’étude avec des pincettes puisqu’il s’agit d’un panel de 16 personnes. Il faut aussi comprendre le contexte, on parle de devs experts sur une base de code importante et complexe. 

Je ne vais pas m’attarder sur cette étude parce que je peux aussi en trouver d’autres qui disent l’inverse. Mais je trouvais plus honnête intellectuellement de la citer histoire d’équilibrer le débat et surtout de lui faire prendre de la hauteur.

L’idée ici, c’est qu’on ne va pas partir du principe que forcément l’IA nous fait gagner du temps. Je ne veux pas rentrer dans ce débat. A la place on va faire complètement abstraction de l’IA et juste considérer une hypothèse : 

Imaginons qu’une personne aille 20, 30% plus vite, voire même 10x plus vite pour produire du code, qu’est ce qui se passe ? Si la production logicielle devient moins couteuse, quel est l’impact sur le métier de développeur ? Qu’est-ce qu’on peut faire de ce temps gagné ?

Cette hypothèse est loin d’être débile. Aujourd’hui on se focalise sur l’IA mais le métier a radicalement changé depuis le temps où on devait cabler un ordinateur pour le programmer. On n’a eu de cesse d’améliorer la productivité. Et nos successeurs ne bosseront sans doute pas comme nous. 

Une opportunité pour les créateurs de produit

Je suis un cas particulier donc ma réponse ne s’applique pas à la grande majorité des gens. 

Je bosse à 2 sur un produit récemment créé. J’ai pas de contraintes productivistes, pas de salaire, personne à qui rendre compte.  

Je gère mon temps comme je le veux. Si jamais je finis une tâche en 1h plutôt qu’une semaine, j’ai juste le droit d’arrêter de bosser et faire autre chose. J’ai pas d’obligation d’empiler les heures pour pointer en fin de journée.

Bien sûr j’ai quand même une certaine pression, faut que le produit soit bon et adopté. Je surveille le nombre de nouveaux utilisateurs chaque mois, la croissance du chiffre d’affaires, les retours aussi qu’on me fait par email. Mais justement, pour mon cas, c’est une bonne chose d’avoir du temps supplémentaire.

Je peux répondre aux emails en y passant plus de temps. Je peux faire des analyses plus poussées, sur mon marché et les feedback utilisateurs. 

Bref, je le vie comme une opportunité.

Là où avant le “technical founder” passait tout son temps à coder le produit et vivait la tête dans le guidon avec un gros handicap pour penser long terme sur le produit, gagner du temps me permet de rééquilibrer la balance.

J’adore coder. Mais coder me prenait du temps de cerveau sur la stratégie.

Ce n’est plus le cas.

Je peux passer plus de temps sur le pourquoi, et pas le comment.

Du temps pour améliorer le produit, pas juste le complexifier

Le temps a toujours été une ressource rare dans la construction de logiciel et d’entreprise. Quand je gagne du temps je peux le passer à plein d’autres choses pour le produit, améliorer la documentation utilisateur par exemple, ou améliorer le harnais de test pour m’épargner des futurs problèmes. 

Je peux passer du temps sur des bugs que je vois passer dans les logs ou des petites pétouilles que j’avais vu dans l’interface mais que dans un autre contexte j’aurais repoussé à plus tard.

Vous avez tous en tête le symptôme de ce backlog jira infini et dans lequel on met des petites fiches d’amélioration. Ces fameux “on verra plus tard” qui sont surtout là pour nous donner bonne conscience ou pour satisfaire la personne du support qui nous en a parlé. 

“T’as vu regarde, c’est dans notre TODO list. Bon, faudra 15 ans pour dépiler cette fiche mais c’est dedans…”

Pour moi ça n'existe plus. Les petits soucis comme ça, je les empile par douzaines et le produit progressivement devient meilleur. 

Si on reprend l’analogie financière de la dette technique. A partir du moment où le code me coûte moins cher, le remboursement se fait au fil de l’eau, ce qui diminue le coût de la dette (les intérêts). 

Du temps pour se former

Depuis que j’ai moins de temps à passer sur le code, j’ai pu passer beaucoup plus de temps à réfléchir aux problèmes à résoudre. Et pour ça, j’ai pris plus de temps pour m’éduquer.

Avant j’étais pressé par le temps donc j’étais obligé de faire des raccourcis. Mais récemment j’ai pu me documenter et écrire des articles sur++ l’état de l’art autour des questions de modérations sur les plateformes de contenu++, je me suis penché sur le fonctionnement des attributions de certificats SSL, le fonctionnement des proof of work sur les captcha. J’ai creusé des sujets comme la ++parité de pouvoir d’achat++.

Et puis, aussi surprenant que ça paraisse, j’ai tout simplement lâché le clavier.

Souvent dans mes journées types, je passe du temps loin de l’écran. J’ai amélioré ma technique sur les bouillons pour les ramen, j’ai fait plein de bricolage et j’ai commencé à construire des meubles pour la maison. 

Et paradoxalement, ce temps m’aide aussi à construire mes produits. 

Vous avez déjà remarqué que vous résolviez souvent des problèmes complexes sous la douche ? 

Glander favorise la créativité.

J’ai mis du temps ++à l’accepter++ mais laisser son cerveau se reposer. Le laisser incuber une idée et vagabonder pendant qu’on fait autre chose, c’est un excellent stimulant pour résoudre des problèmes. 

Bien sûr, je sais que mon cas est spécifique. Je me vois mal démarrer une séance de menuiserie dans un open space au milieu d’une équipe de dev. Mais pour mon cas, gagner du temps sur du dev, c’est un rééquilibrage global de mes journées et paradoxalement, un travail de meilleure qualité qui est produit. 

Parce que le sujet n’a jamais été “que” de faire du code mais aussi de réfléchir au long terme, ce qui est plus simple quand on a le temps pour le faire.

Maintenant évidemment, je me doute que c’est un peu différent dans un contexte plus traditionnel. Alors je me suis documenté pour voir ce qu’on en disait ailleurs.

Productivité et burnout : le vrai coût

Une des premières réponses provient ++d’une étude de la Harvard Business Review++. L’augmentation de la productivité ne conduirait pas à une réduction du temps de travail, mais à une intensification. 

Le travail deviendrait plus intense pour plusieurs raisons : 

• l’IA supprimerait les pauses cognitives. Et oui, puisqu’il serait plus rapide de démarrer un sujet avec l’IA, on perdrait le moment de pause qui existe normalement au début de chaque projet pendant lequel on se demande comment faire. 
• l’IA gommerait les frontières entre métiers. Je me sentirais plus capable de faire du front, du design, de l’ops, du back, du mobile et donc mon périmètre de travail explose
• La gratification étant plus fréquente, on serait incité à continuer sans arrêt. Si vous faites 10 tickets par jour et que chaque ticket est rapide, pourquoi ne pas faire le 11eme ? Un petit prompt avant de fermer l’écran ?

Sauf que cette intensification vient avec un prix élevé : la fatigue, le burnout, les erreurs (parce que, quand on est fatigué on laisse passer plus de choses).

Je suis tombé sur un article qui parle exactement de ce sujet et qui compare++ l’IA à un vampire++ qui drainerait notre énergie. 

L’idée est simple, comme l’IA prend en charge toutes les tâches simples et répétitives, qui servaient autrefois de pause cognitive, il nous reste essentiellement les tâches de haut niveau, les décisions critiques.

Or nous ne sommes pas capables de prendre ce type de décision constamment pendant 8h par jour. C’est beaucoup trop intense.

C’est pour ça que, personnellement, soit je m’éloigne de l’écran une partie de la journée, soit j’y fais des activités plus récréatives : écrire un article (ce qui explique que j’écrive plus qu’avant ^^), ou me former. Et c’est d’ailleurs la recommandation de l’article, il faut trouver un nouvel équilibre.

Je ne sais pas dans quelle mesure l’article est sincère mais c’est ce qui semble être ++l’approche chez Github++. Ils ont utilisé le gain de temps, non pas pour augmenter drastiquement la productivité mais pour d’autres types de tâches, la collaboration, la réflexion. 

Faire plus ≠ Faire mieux

De toute façon, il y a une limite physique à ce que les utilisateurs finaux peuvent encaisser en termes de nouvelles fonctionnalités par jour.

C’est pas parce qu’on peut produire 10x plus de nouvelles features que c’est bénéfique pour l’utilisateur final. 

C’est ce qu’on appelle la loi de Tesler, ++la loi de conservation de la complexité++. Dans un système, il existe une quantité de complexité qu’on ne peut pas réduire. Si on la réduit quelque part, par exemple pour les développeurs qui vont plus vite, elle se répercute ailleurs, pour les utilisateurs qui doivent s’adapter à un logiciel qui évolue beaucoup trop vite. 

On s’expose aussi au risque de “feature fatigue” qui rend les logiciels trop complexes, car trop complets. C’est souvent une bonne chose d’être forcé à faire des choix. 

Bref, ce n’est dans l’intérêt de personne d’augmenter la cadence et il est préférable que les gains de productivité se reflètent davantage dans des features mieux pensées ou une augmentation du travail fait sur la qualité “invisible”. 

Quand la productivité crée l'ennui

Maintenant il y a un scénario qui me semble aussi important à mentionner. Il y a beaucoup de gens qui bossent dans des entreprises où aller plus vite ne changera absolument rien. Parce que ces entreprises luttent davantage contre leur propre inertie que contre un quelconque défi produit. 

J’ai bossé en grosse boite. Et je me rappelle très bien d’une mission en 2003 où coder n'était juste pas le sujet.

Je venais d’un job précédent ou c’était plutôt dynamique. J’étais habitué à un certain rythme. Dans ce nouveau job, on m’a donné un programme à faire. Je l’ai réalisé en 2 jours. Je suis retourné voir mon boss de l’époque. Il m’a dit qu’on en rediscuterait 3 semaines plus tard. En un an, j’ai presque rien produit et c’est sans doute la pire année de ma carrière. 

Le matin t’avais des gens qui passaient pour dire qu’il y aurait des réunions sur tel ou tel sujet et demandait qui voulait participer. Je ne comprenais pas pourquoi tout le monde y allait constamment.

Mais après j’ai compris. C’était pour occuper les journées. 

Si j’avais mis 1h pour faire mon travail plutôt que deux jours, je me serais juste ennuyé plus longtemps. 

Je savais qu’on pouvait faire des burnout. Mais là bas j’ai failli faire un bore out. Et puis j’ai commencé à me former en parallèle sur tout ce que je voulais. J’ai rentabilisé ce temps.

Mais je vous cache pas que j’étais heureux comme pas possible quand la mission s’est arrêté…

Bref, il y a des endroits où coder plus vite, ça ne changera rien. Les pauses café seront juste plus longues…

Freelances : du temps passé à la valeur produite

Maintenant il y a une population pour laquelle je me pose encore pas mal de questions. 

Partons toujours du scénario où le coût du code s’effondre, que deviennent les personnes qui facturent au temps passé ?

On pourrait imaginer qu’une partie de cette population ne va pas forcément crier sur tous les toits qu’elle a terminé son job plus rapidement, puisque ça impliquerait de perdre de l’argent.

Est-ce que c’est tenable sur le long terme, d’autant plus pour un freelance qui travaille dans les locaux du client, donc à la vue de tous ? Dans les grands groupes dont je parlais tout à l’heure, oui certainement. Mais ça ne tiendra jamais dans une entreprise dont les développeurs aussi utilisent les mêmes outils pour aller plus vite.

Et c’est là où je me demande si le forfait, la facturation au résultat, ne pourrait pas devenir plus avantageux que la facturation au temps passé.

Habituellement j’ai plutôt tendance à déconseiller l’engagement de résultat, surtout sur des freelances plus jeunes parce c’est pas si simple que ça de contractualiser correctement et de savoir poser des limites ou tout simplement de savoir estimer un travail avant de le réaliser. 

Mais si l’IA permettait de sécuriser le développement, et de le rendre plus rapide, le forfait pourrait regagner de l’intérêt.

Il ne s’agirait plus de facturer du temps, mais de la valeur. 

Je n’aurais aucune réserve à faire payer une certaine somme pour un travail qui a de la valeur, même si j’y passais seulement 1 ou 2 jours. 

J’ai travaillé pendant 25 ans pour être capable de donner ce résultat en 2 jours. Un client paie votre expérience, et votre capacité à utiliser des outils. Peu importe que vous soyez plus rapide. 

Au pire je pourrais baisser un peu mes prix mais mon risque se paie aussi quand je facture sur un engagement de résultat. 

Malgré tout, je ne sais pas si ce raisonnement tiendra dans la durée. Des concurrents tout aussi bons que moi pourraient s’engager avec plus de clients pour compenser une perte, et donc faire baisser les prix sur un contrat unitairement.

Je suis tombé sur ++un article qui parle un peu de ça++. Sa conclusion étant que les freelances experts vont continuer à s’en sortir mais les besoins vont diminuer. D’autant que leurs clients eux-mêmes vont aussi se mettre à faire du dev si le coût du code diminue.

Une des conclusions de l’article dit par contre que l’IA ne remplacera pas le freelance, mais que **le freelance utilisant l'IA remplacera celui qui ne l'utilise pas. **Et c’est sans doute la leçon la plus importante.

Conclusion

Encore une fois, la question n’était pas, est-ce que l’IA nous rend plus rapide. La vraie question dont je voulais discuter c’était “qu’est ce qu’on fait du temps gagné ?”.

La réponse dépend de votre contexte.

Si vous êtes dans une boîte sclérosée où coder plus vite ne change rien, vous vous ennuierez plus vite. Si vous êtes product-focused et que vous avez la liberté de piloter votre temps, c'est une opportunité incroyable de reprendre du recul sur votre produit. Si vous êtes freelance, c'est peut-être le moment de négocier différemment.

Mais il y a une limite importante : la productivité ne fait sens que si elle crée de la valeur. Débiter 10x plus de features, c'est peut-être pire pour vos utilisateurs. Gagner du temps c’est bien mais ça ne vaut quelque chose que si vous savez quoi en faire.

Bref, il n'existe pas une seule réponse. Mais par contre vous allez peut-être gagner du temps pour trouver cette réponse.

C'est globalement similaire à Hugo, ça permet de générer un blog statiquement (c'est juste un ensemble de fichiers html) puis de l'héberger ensuite, souvent gratuitement, que ce soit sur Cloudflare, GitHub, bunny.net etc...

J'étais passé auparavant par Wordpress, Joomla, Medium et j'avais envie de retrouver une certaine souplesse d'utilisation, pouvoir customiser le blog comme je voulais.

La vérité c'est certainement aussi que je suis développeur et que j'avais envie aussi d'en faire un terrain de jeu.

Et pourtant en 2026, j'avoue qu'un blog statique ça me freine beaucoup pour écrire, j'ai donc décidé de migrer à nouveau vers un blog managé : Writizzy, un autre produit que je construis.

Bref c'est l'occasion de parler de plein de sujets :

• le dogfooding : pourquoi il faut absolument utiliser ses propres produits
• pourquoi c'est dur de faire de l'open source (une des raisons)
• la satisfaction de construire un produit vraiment utilisé
• l'avenir de tous les projets, bloggrify, writizzy, mais aussi hakanai.io

Bloggrify : Quand mon blog était mon terrain de jeu technique

Bloggrify, c'est, avant tout, un coup de cœur pour l'écosystème Nuxt et notamment Nuxt-content. Vous pourrez retrouver mes critères de choix à l'époque quand j'ai migré la première fois depuis Wordpress, mais en simplifiant je listerais :

• un langage de templating simple (markdown)
• extensible (pour gérer un flux rss, un sitemap, etc...)
• le prix
• l'impact carbone (un site statique ca consomme peu)

En réalité en 2022 c'était pas encore un "produit" open source dans le sens ou c'était simplement mon blog qui était accessible à tout le monde. C'est devenu un produit open source, avec un vrai site, un README pour inciter aux contributions etc... à part entière uniquement en 2024.

A ce moment là j'avais acquis quelques convictions, il fallait que le produit soit "opinionated", c'est à dire qu'il vienne avec tout un tas de choix déjà fait pour que ce soit le plus simple possible à utiliser.

Nuxt-content fait 90% du boulot mais ça reste un outil un peu générique donc pour un blog il fallait encore rajouter pas mal de choses :

• le flux rss
• le sitemap
• la gestion du robots.txt
• les commentaires
• la gestion des tables de matière
• les boutons de partage
• une newsletter
• de l'analytics
• le SEO

etc...

C'est ça Bloggrify. C'est une sorte de starter pack pour démarrer un blog avec Nuxt-content mais en ayant déjà tout de configuré. C'est la même chose que docus, mais pour un blog. Docus étant un starter pack pour démarrer une documentation à partir de Nuxt content.

Des étoiles Github sans utilisateur

Je suis plutôt joueur. Si je fais une application ou un projet open source, j'aime bien voir des chiffres pour être sur que c'est utilisé. J'aime voir qu'il y a un usage. C'est bête mais vu l'effort que ça nécessite de faire des releases sur npm (c'est un enfer ce truc), de gérer les montées de version, de créer des themes, qui doivent eux-mêmes être mis à jour en fonction des versions du core etc... Forcément on attend un minimum de résultats.

Le projet a eu 164 stars sur GitHub, il est placé vers le milieu de tableau sur jamstack, ce qui est... bien, mais sans plus.

Par contre, j'ai quasiment 0 échos de son usage. J'ai eu quelques rares issues sur GitHub, un contributeur qui a été actif quelques semaines avant de disparaitre, et puis plus rien.

Je connais un seul blog qui l'a utilisé, avant de repartir sur hugo.

Donc au final, l'expérience est plutôt mitigé. Je suis complètement dans le brouillard quand à son usage. Ca me rajoute du boulot pour mon blog, sans que je sois sûr que ca serve à d'autres. Donc... comment dire. Au bout d'un moment ca démotive un peu.

Tout n'est pas noir, ça m'a permis par contre aussi de lancer d'autres produits :

• broadcast.hakanai.io : un système de newsletter pour blog statique qui s'appuie sur le flux RSS du site
• pulse.hakanai.io : un système de blog analytics qui est vraiment construit pour du blog et pas juste des web analytics standard.

C'est des plugins qu'on peut activer dans Bloggrify.

La construction de SAAS

Les deux produits, broadcast et pulse, ont été lancés en 2024 et 2025 respectivement. Ils vivent une petite vie tranquille mais ne font pas d'étincelles. La cible c'est les bloggeurs qui utilisent des sites statiques, autrement dit, des développeurs. Et autant vous dire que c'est la population qui est la moins prête à payer pour un service :)

Malgré tout, je suis quand même très satisfait, ces deux produits m'ont permis d'apprendre beaucoup de choses sur la construction d'un SAAS, la facturation par abonnement, la stack la plus efficace pour moi etc...

Je les utilise moi-même très régulièrement, les newsletters de mon blog étaient envoyés via broadcast. Il y a environ 150 abonnés qui ont décidé de s'abonner pour recevoir les articles dans leur boite aux lettres. Et j'ai pu utiliser pulse pour suivre les origines du traffic sur mon blog, voir quels sont les articles qui ont le mieux marché, ceux qui sont les plus lus, ou pas etc...

Encore une fois, j'aime les chiffres ^^

Par contre la réalité c'est que ces deux softs font environ 100 euros de MRR par mois, donc c'est pas là dessus que je dois compter pour assurer ma retraite.

Mais tout ça nous amène à Writizzy.

Writizzy

Avec Bloggrify je me suis quand même rendu compte que mon workflow d'écriture était devenu un peu pénible. Entre la maintenance du framework lui-même, mes allers/retours dans des outils pour la correction orthographique, l'écriture en markdown, le lancement du serveur pour vérifier que tout va bien et que j'ai cassé aucun lien, la compilation et le temps de déploiement, au final j'y perdais un temps fou.

Pour mon dernier article, on m'a signalé des fautes d'orthographes, j'ai du mettre presque 20 minutes entre l'édition et le déploiement pour effectuer les corrections.

Et je parle même pas de la gestion des images qu'il faut gérer dans Intellij, ou de la montée de version Nuxt 4 et Nuxt content qui ont pas mal ralenti tout ça avec une expérience développeur un peu moins bonne. Je reste amoureux de ces outils mais je les trouve moins adapté pour un blog vu les temps de lancement et/ou de compilation.

Pour être franc, j'étais pas conscient de ça. Je subissais ces inconvénients et je restais très content d'avoir de la "flexibilité" sur ce que je pouvais faire avec mon blog.

Et puis j'ai créé Writizzy. Writizzy c'est la synthèse de toute mon expérience de blogger. C'est un mix entre Substack, ghost, medium mais en essayant de résoudre tout les problèmes de chacun. C'est aussi construit comme une alternative européenne avec plusieurs préoccupations en tête :

• la durabilité, incluant des sujets de réversibilité et interopérabilité
• la découvrabilité
• l'accessibilité économique (la parité de pouvoir d'achat)
• la transparence (via ce blog notamment)

J'ai rapidement mis mon blog anglophone dessus mais je prévoyais absolument pas d'y mettre eventuallycoding.com.

Sauf que rapidement j'ai commencé à réaliser que j'écrivais beaucoup plus rapidement sur mon blog anglais. J'ai pris conscience de la pénibilité de mon workflow sur mon blog statique en utilisant Writizzy. La gestion des images c'est du bonheur puisque je peux copier coller mon image dans le texte. Tout est géré. J'ai une preview directe, sans lancer de serveur. Je vais prochainement ajouter un outil pour le check orthographique, donc ce sera encore une épine dans le pied en moins. Bref, c'est pratique.

Et c'est pourquoi j'ai fini par décider de migrer sur Writizzy. Ce qui pose maintenant une question : l'avenir de Bloggrify.

L'avenir de mes projets

J'ai longuement hésité à migrer eventuallycoding.com parce que je me suis dit que c'était aussi prendre le risque de tuer Bloggrify. Si même moi je l'utilise plus, ça devient risqué. Quand on utilise pas soi-même son produit, ou qu'on n'est pas obnubilé par le problème qu'il résoud, c'est quasi impossible de réussir à s'y attacher.

C'est un peu le symptôme de beaucoup de projets jetables que je vois passer sur internet. C'est fait par des gens qui papillonnent mais qui n'ont aucun attachement à leur produit. Donc oui, ne plus utiliser Bloggrify, c'est risqué.

Mais je crois que je me suis fait à l'idée. Aujourd'hui j'ai très peu d'indices me permettant de savoir si Bloggrify est utilisé. Alors que Writizzy a déjà 314 blogs, 11 utilisateurs payants (ce qui fait 135 euros de MRR), en 4 mois. Pourquoi s'acharner sur Bloggrify ? Et de toute façon, je pense que je résous le même problème avec Writizzy, mais d'une meilleure façon.

J'ai des mails de feedback ou de demandes d'évolution toutes les semaines, et j'ai plein de retours positifs par les gens qui l'utilisent. Le produit est pas parfait mais tous les jours il s'améliore. Il s'améliore parce que j'ai des retours de vrais utilisateurs, ce qui me motive constamment à peaufiner le site, fixer les trucs qui vont pas, ajouter les features qui devraient absolument être là.

Et il s'améliore aussi parce que je l'utilise beaucoup. C'est un énorme bénéfice et c'est ce qu'on appelle le dogfooding. Tous les jours je suis confronté au logiciel, donc je sais ce qu'il faut changer.

Donc oui, Bloggrify va passer en mode maintenance. Je vais en profiter pour passer tout les templates en open source. Il y en avait 2 qui étaient "premium" mais ça n'aurait pas de sens de les laisser tel quel aujourd'hui.

Je me dis que je le ferais évoluer de temps en temps mais j'avoue que je me demande si je me mens pas un peu à moi-même ^^

Pour Hakanai.io par contre, là c'est certain que je continue. Il y a un problème à résoudre qui continue de m'intéresser. J'ai des retours positifs, enfin surtout sur Broadcast. Pulse a le gros inconvénient d'être mal compris. C'est un produit qui fait du blog analytics, et personne comprend ce que ça veut dire. Il y a des conseils SEO, de la détection d'outlier, de content evergreen. Mais je suis pas très bon sur le marketing donc globalement il passe assez inaperçu hormis parmi les lecteurs de ce blog qui ont fait l'effort de le tester.

Mais en tout cas je suis motivé pour les garder.

Quand à Writizzy, il est évident qu'il n'y a aucun doute. Le produit est super intéressant à construire. Les enjeux sont vraiment sympas (construire une plateforme d'expression hors des plateformes américaines). Il y a des retours positifs et des chiffres qui vont avec (+45% de croissance users MoM).

Bref, je vous souhaite la bienvenue sur ce blog, désormais sur Writizzy. Et vous pouvez tester déjà plein de choses en tant que lecteur :

• la section commentaire
• vous inscrire à la newsletter si ce n'est pas déjà fait
• lire d'autres articles de blog créé par des bloggeurs sur Writizzy, on en a sélectionné quelques uns pour apparaître sur le feed discover. Feed qui deviendra plus customisable dans le futur :)

Bienvenue.

J'ai plus le détail en tête, mais avec le recul et sans doute beaucoup d'exagération, je dirais que c'était comme Gather mais avec 15 ans d'avance. L'application semblait bien marcher et la boite enchainait les rendez-vous avec des grosses boites qui semblaient super intéressés pour déployer ça à l'échelle de l'entreprise. On parle de grandes banques, de grands fournisseurs d'énergie, des boites vraiment sérieuses. Sauf que ça a trainé, un mois, un trimestre, un an, puis deux. Et finalement la boite est morte à attendre une vraie signature et un peu de cash accessoirement.

Mon ami a malheureusement buté dans le fameux syndrome des B2BigB, ce mal (français ?) qui a tendance à tuer beaucoup d'entreprises tous les ans.

Alors si vous créez une boite aujourd'hui ou que vous souhaitez le faire, je vous invite à réfléchir à deux fois avant de privilégier ce segment et c'est de ça dont on va parler aujourd'hui.

B2BigB

Déjà, il faut que je définisse cet acronyme. Dans le monde de l'entreprise, on a tendance à segmenter les boites en fonction des clients qu'ils visent :

• B2C (pour Business to Consumer), c'est le grand public.
• B2B (pour Business to Business), c'est la vente aux entreprises

Par exemple, Netflix, c'est du B2C et Jira c'est du B2B.

Au milieu de tout ça vous avez plein de nuances, Microsoft qui vend en B2C et en B2B par exemple. Vous avez des plateformes de C2C (échanges entre particuliers).

Mais on va rester simple, et on va juste parler de B2C et B2B.

Sauf que "B", c'est large. Entre une boite de 5 personnes et un grand groupe de 40 000 personnes, autant vous dire que la façon de vendre aux deux est très différente. Et dans cette catégorie, il y a la catégorie de la mort : les grands groupes. Difficile de vraiment dire quand commence un grand groupe, mais on les reconnait facilement. Un grand groupe commence quand une prise de décision nécessite une tétrachiée de réunions, un trimestre, un steering commitee et un approval du board ou d'un département achat...

En pratique, on peut même avoir des boites de 500 personnes qui se comportent comme ça même si c'est plus fréquent à partir de 1000. Mais dans tout les cas, ça empire avec la taille. Un trimestre peut devenir 1 an, voire 2, voire 5 (et je vous jure que j'ai vu des cycles d'achat durer ce temps-là).

Bref, ça, c'est ce que j'appelle les BigB (les gros B).

Le gros avantage des BigB c'est, en théorie, la capacité à acheter cher parce qu'on parle de déploiement à l'échelle d'un grand groupe, donc de volumes qui font rêver la plupart des boites en démarrage.

Sauf que, c'est bien souvent un mirage, dès qu'on commence à regarder les couts et les marges, mais surtout, tous les risques associés.

Des couts gigantesques, des marges faibles

Travailler avec un grand groupe, c'est bien souvent synonyme de complexité et cette complexité, elle se finance avec des spécialistes.

Il faut répondre à des processus couteux (questionnaire de sécurité de 200 pages, questionnaires légaux, contrat cadre, certification ISO machin chose) qui nécessite souvent pas mal de spécialistes (juristes, experts sécu, finance etc...). Et ça, c'est juste pour entrer dans la première étape du cycle de vente.

Pour vendre à un grand groupe, il faut déjà être prêt à dépenser des fortunes.

Au passage, on pourra noter que c'est pas ce qui empêche ces grands groupes de régulièrement figurer dans la liste des data leaks du mois. Parce que non, pondre des questionnaires excel n'est pas synonyme de qualité de la sécurité.

Suite à ça vous allez rapidement tomber dans la spirale des réunions trimestrielles avec tout un tas de personnes que vous ne verrez qu'une fois dans votre vie, dont certains profiteront de leur pouvoir passager pour passer leurs nerfs et leurs lubies sur vous. Et comme vous serez en position de faiblesse, eh bien...

Ce temps, c'est du temps qui n'est pas passé sur le produit. C'est évidemment normal de passer du temps à vendre, mais on parle de réunions trimestrielles à préparer, avec des powerpoint à la Mckinsey (vous allez même parfois avoir des scales up qui font appel à des cabinets de conseil pour remplir ces documents) et qui vont nécessiter des semaines de préparation.

Encore une fois, pour vendre à un grand groupe, il faut déjà être prêt à dépenser des fortunes et à attendre des lustres.

Mais imaginons que ça y est, vous avez enfin l'aval pour déployer dans un grand groupe. Le contrat est signé. Maintenant, c'est à vous de vous débrouiller pour l'adoption. En réalité, c'est le début d'un second cauchemar.

Il s'est passé 1 an depuis le début du cycle de vente, tous vos précédents contacts ne sont plus là. C'était peut-être des prestataires qui ont quitté la boite. Ou bien des dirigeants, mais qui ont été muté dans d'autres branches du groupe. Et désormais, il faut retrouver les personnes capables de vous aider à déployer votre solution logicielle parce que sans doute que votre chiffre d'affaires dépend de l'usage qui sera fait du logiciel. Pas de déploiement, pas d'argent.

Donc il va vous falloir une équipe dédiée de commerciaux capable de naviguer dans une bureaucratie complexe pour trouver les bons contacts et peut-être même une équipe d'implémentation dédiée. Vos coùts vont exploser et vous n'aurez pas encore à ce stade touché quoi que ce soit.

Avec un peu de chance, et parce que vous avez été assez malin pour obtenir un montant à la signature, vous finirez par émettre une première facture. Celle-ci sera payé 8 mois plus tard, fin de mois. Les 3 premiers mois ayant entrainé moults incidents parce qu'il fallait signer un bon de commande et que vous avez dû passer par 3 services différents pour ça. Pas de chance, votre tréso commence à tirer la langue.

Vous arrivez au terme de la première année et là, vous aurez le département achat qui va venir vous voir pour venir renégocier le contrat, sachant pertinemment que, en théorie, ils sont vos plus grands clients donc, ce serait naturel de faire une fleur.

Bref, 2 ans plus tard, vous avez dépensé une fortune, votre trésorerie est déficitaire, et votre marge a fondu comme la neige pendant une coupe du monde de ski en Arabie Saoudite.

Bon, ok, mettons que j'exagère et que malgré tout, ce contrat vous a permis au contraire de passer un cap, d'avoir une signature importante à mettre en avant et que la vie continue pour votre startup/scaleup. En réalité, vous ne le savez pas encore, mais vous avez invité un cheval de Troie chez vous.

La perte d'innovation

Travailler avec un grand groupe, c'est accepter la complexité inhérente à cette entreprise. Si vous avez mis 2 ans à signer un contrat avec eux, imaginez bien que tout le reste prend le même temps. Votre produit doit évoluer pour leur façon de travailler. On va vous demander des workflows d'approbation à 12 niveaux, des intégrations logicielles avec des ERP, des SSO d'entreprise mal flingués, des intégrations avec des systèmes legacy des années 90. Et puis chaque boite a son jargon interne qu'on va vous demander d'ajouter de force dans votre logiciel. Vous allez facturer en unité d'œuvre, avoir un rôle "achat" dans vos schémas RBAC (les systèmes d'autorisation), bref, en réalité, vous allez développer une extension du SI de votre premier client avec toutes ces contraintes, sa complexité, sa lenteur d'accompagnement, et ses couts.

Et quand on a un client qui représente 80% de son chiffre (et même à partir de 20% en réalité ça commence à jouer), on peut difficilement dire non. C'est donc une feuille de route régulièrement hijacké par les commerciaux dédiés à ce client, et globalement un produit qui s'éloigne du marché de masse.
Et c'est normal hein, je jette pas la pierre à cette équipe. Si vous avez dédié des gens à un client, c'est normal qu'elle essaie d'influencer la façon dont on construit le produit et même si les demandes sont absurdes. Parce que cette équipe n'a pas le recul nécessaire pour juger.

Et quand la feuille de route est régulièrement détournée, c'est aussi une énorme dette liée à la personnalisation qui va finir par freiner tout le produit dans son ensemble. Ce gros client vous a peut-être permis de doubler vos effectifs. Mais les 3/4 de la boite vont finir par bosser pour lui, et vont développer une culture logicielle propre, moins de sens UX, moins de sensibilité aux performances produits (inutile de travailler sur l'acquisition ou la conversion par exemple).

Tous les logiciels grands groupes ont une UX dégueulasse, parce que c'est pas ça qui fait vendre d'une part, et parce qu'à force de perdre de l'argent dans le processus de vente, de certification et d'accompagnement, il faut bien faire des économies quelque part, souvent sur le produit qui n'est plus en réalité central dans la relation avec ce client. On tentera de vous rassurer en vous disant que non, c'est important, mais en réalité, le produit à ce moment-là est devenu un centre de coùt qu'il faut optimiser pour ne plus perdre de marge. Marge mangée par le cabinet de conseil qui vous a aidé à déterminer la stratégie de déploiement et le prix à fixer...

Mais même quand vous "améliorez" votre produit pour ce client, vous n'allez cesser de le dégrader pour tous les autres que vous pensiez attirer ensuite en mettant en avant cette prise sur votre belle landing. Parce qu'encore fois, vous allez imposer sa complexité à toutes les autres boites qui auraient pu être intéressés par vos services.

Je noircis le tableau évidemment. Et il y a des boites qui se sont spécialisées JOUR 1 sur les grands groupes, qui ont taillé leur offre commerciale en prenant en compte tous les couts associés. Les déploiements sont chiffrés à 100k, les contrats imposent un usage minimal, tout a été cadré dès le début parce que la stratégie a toujours été de s'étendre exclusivement ici.

Mais pour toutes les boites qui envisagent "juste" de faire un GrosB pour avoir une marque de validation, mais qui visent en réalité tout le marché TPE/PME et qui cherchent du volume. C'est rarement un bon plan.

Les alternatives

Au début je disais : "ce mal (français ?)". Pourquoi je dis que c'est un grand mal français ? En réalité c'est sans doute un effet loupe et je constaterai certainement la même chose dans tous les pays. Mais tous les ans, je vois des boites qui meurent après des trimestres d'attente derrière ce fameux contrat avec un grand groupe (hier encore, je discutais avec une personne qui m'a raconté la même histoire). Donc je me dis qu'il y a quand même un truc un peu différent chez nous. On aime bien être différent.

Partiellement, j'ai l'impression que c'est lié à notre taille de marché SMB (TPE/PME) qui est moins important qu'en Allemagne (le mittelstand allemand semble plus important). On passe plus vite de la TPE aux grands groupes.
Évidemment, ensuite, en termes de crédibilité, c'est plus facile de vendre un produit une fois qu'on a le logo d'un grand groupe que plein de logos de boites inconnus.

Ce qui est sûr c'est que culturellement, il y a le CAC 40 et le reste. Le CAC 40 c'est quasiment les mêmes boites depuis 30 ou 40 ans. A l'inverse vous regardez le S&P 500, en 1990 c'était Exxon, GE, Philip Morris, IBM. Ils ont tous laissé leur place à Apple, Nvidia, Amazon, Google.

En France, les grands groupes du CAC sont structurellement stables et dominants, ce qui les rend d'autant plus attractifs comme clients pour les startups. Ils ont les budgets, la longévité, la légitimité. Mais ces mêmes grands groupes ne sont pas des tremplins vers un marché global — ce sont des marchés fermés sur eux-mêmes.

Et à l'inverse le marché TPE/PME peut fonctionner. Si je regarde Pennylane, qonto, indy, payfit, spendesk, livestorm, c'est justement en visant ce marché qu'elles ont réussi à aller loin.

A l'inverse, je me pose de vraies questions sur la stratégie d'un Mistral qui semble se positionner que sur les grands groupes (déploiement on premise, partenariat azure etc...) et qui semble délaisser le marché de masse. J'espère que ce ne sera pas le futur DailyMotion, qui a privilégié les grands médias et opérateurs télécom en passant à côté de l'opportunité de devenir la plateforme média B2C que Youtube a su devenir.

Vous aurez compris, si vous créez une boite aujourd'hui, j'aurais tendance à vous déconseiller de voir le "B2B" comme un seul et grand terrain de jeu. J'aurais tendance à vous dire d'éviter le B2BigB qui est bien souvent délétère pour les startups et finit souvent par mener à l'impasse.

Ça reste possible, mais il faut s'armer pour. Et si c'est votre choix, je ne dirai qu'une chose. Bon courage :)

Viser les grands groupes (et le service public) c'est évidemment l'accès à des marchés plus importants. Mais j'aurais tendance à conseiller d'aborder cette étape plus tard, quand la boite est déjà solide.

Quand DJI (les drones chinois) ont attaqué le marché pro, ils avaient déjà une énorme emprise sur un marché B2C. Ils sont venus avec une expertise et un savoir faire qui leur permettait d'être souverain sur leurs décisions.

Maintenant si jamais vous avez quand même cette tentation, la recette pour avoir une chance, c'est avant tout une question de séniorité des dirigeants : faut savoir dire non de façon ferme, faut arrêter de courir tous les lièvres dès qu'on voit passer un soi-disant "low hanging fruit", l'expression qui a remplacé pour moi le mot "quick win" dans mes expressions les plus détestées.
Ça n'existe pas le gain avec peu d'effort. Tout a un cout, même quand il est caché.
Et il faut avoir une bonne base financière et réputationelle pour imposer ses conditions, d'où le conseil d'avoir déjà une bonne base sur les autres segments. C'est plus facile de dire non quand un client représente 2% que quand il représente 20%.

Une stratégie que j'ai vue fonctionner plusieurs fois, c'est de créer un logiciel avec une super UX, d'être adopté par les équipes, puis ensuite d'aller voir les départements achats des boites en question pour leur mettre sous le nez les chiffres d'usages chez eux : "vous avez vu, vous avez déjà 300 personnes qui l'utilisent, ça vous dit pas de faire un contrat cadre et de mieux comprendre l'usage chez vous ?"

Là pour le coup, c'est intéressant parce que vous avez créé un produit dont l'adoption s'est faite par les équipes, vous n'avez pas modifié votre roadmap et vous êtes en position de force avec les achats pour améliorer votre présence sans subir de pression sur le reste. Bref, faites un bon produit, trackez l'usage, attendez d'avoir une empreinte suffisante, et ensuite, allez négocier.

Anthropic (Claude code) en visant d'abord les développeurs individuels (indie hacker, side project) et les petites équipes a été poussé à constamment améliorer son produit qui est devenu numéro 1 dans sa catégorie (à l'heure où j'écris, ce passage pourrait mal vieillir :)). Aujourd'hui, ils vendent des licenses entreprises.

Les bonnes boîtes sont capables de faire du volume puis de remonter la chaîne, petites boites puis grandes boîtes. J'ai rarement (jamais ?) vu l'inverse. Quand tu fais du grand groupe, tu ne sais pas revenir sur le reste des segments.

Je me crois que je me suis dit ça 3 ou 4 fois sur les 25 dernières années, mais c'est bien la première fois que les raisons qui me poussent à le faire sont les plus fortes, et que les moyens à disposition sont les plus aboutis.

Alors, pourquoi pas ?

Mais d'abord parlons des raisons, pourquoi changer ?

Vous ne l'aurez sans doute pas raté, mais l'actualité géopolitique est tendue et la dépendance tech aux US commence à devenir très dangereuse. Windows est le cheval de Troie absolue permettant l'accès à des milliers (milliards ?) de PC, autant individuels que professionnels et c'est devenu un peu difficile de passer à côté.

Entre soupcon de backdoor en 1999 avec l'affaire _NSAKEY, re-soupcon de backdoor en 2017 avec l'affaire DoublePulsar ou vraie affaire des clés de chiffrement Bitlocker fourni à la NSA, il serait hautement naif de penser que nous sommes à l'abri.

Au-delà de ça, la migration vers Windows 11 a forcé de nombreuses entreprises à renouveller un parc informatique pourtant toujours en parfait état de marche.

Bon, la première raison suffisait hein. Mais quitte à être exhaustif...

Maintenant, comme faire ?

Mes contraintes

Je veux changer, certes, mais pas dans n'importe quelles conditions et il est temps que je donne un peu de contexte.

Comme toutes les personnes qui bossent dans l'informatique, j'ai eu régulièrement des personnes qui me demandent de jeter un œil à leur imprimante qui marche plus, ou un téléphone qui démarre pas ou un logiciel de traitement de texte capricieux.

Je vous donne un scoop, je ne sais pas faire ça. Ce n'est pas mon métier. Je sais, c'est dingue, je passe mon temps sur un PC, mais je ne sais pas pour autant le réparer ou réparer tout ce qui ressemble à un assemblage de composants électroniques. Pire, je déteste ça.

Alors oui, peut-être que j'exagère, avec beaucoup d'effort et une doc en ligne, je peux vaguement résoudre quelques problèmes. Mais encore une fois, je déteste ça.

En fait, je ne veux passer pas du temps sur des outils de la vie courante, pas plus que j'ai envie de démonter mon frigo ou ma voiture.

Ok, l'exemple de la voiture est sans doute mauvais, pour le coup j'y connais vraiment rien et quand j'étais plus jeune ça me faisait marrer de bricoler mon autoexec.bat et mon config.sys pour faire tourner des jeux en mémoire haute, mais ce temps est révolu. Le gaming ça doit être un loisir, pas un défi technique.

Bref, vous l'aurez compris, je veux changer pour quelque chose de simple et qui ne me demande pas de devenir expert de lignes de commande obscures pour que tout fonctionne.

Seconde précision utile, j'utilise professionnellement unix/linux depuis 1997. J'avais déjà installé Mandrake en 99 en double boot sur mon ordinateur, et j'ai également eu des PC de travail sur Ubuntu et Debian, donc je ne pars pas de zéro et je sais que pour un usage pro, je n'aurais aucun souci d'adaptation sur linux.

Mais, pour un usage perso, j'ai besoin de pouvoir faire du montage vidéo (j'utilise Filmora) et j'aime jouer au jeu vidéo donc ça va rentrer en ligne de compte.

Et il paraît que ça tombe bien, désormais Linux sait faire tout ça.

Il paraît...

Tester sans tout casser (ou presque)

L'idée c'était pas de racheter un ordinateur, ce serait quand même un peu idiot vu que mon pc est encore très bien. Je l'ai acheté en 2018, il a 32 Gb de ram, un processeur AMD Ryzen 7, une carte GeForce GTX 1060 et fait tourner sans aucun souci des jeux comme Overwatch 2 ou Baldurs Gate 3.

L'idée, c'était pas non plus de réinstaller par-dessus Windows en prenant le risque de plus avoir de PC pendant plusieurs jours/semaines.

Donc j'ai acheté un nouveau disque SSD de 1Tb pour permettre le double boot et tester des OS. Le double boot n'est pas une solution à long terme puisque je veux me séparer de Windows et que c'est très pénible de switcher d'un système à l'autre de toute façon. Par contre, c'est idéal pour du test. Et dans tous les cas, passer de 1 à 2Tb ça commençait à devenir nécessaire parce que le montage vidéo prend rapidement de la taille sur disque.

Évidemment comme j'ai des gros doigts et une vue qui décline avec l'âge, j'ai réussi l'exploit de casser le pas de vis qui sert à fixer le disque nvme sur la carte mère. J'ai vraiment cru que j'allais abandonner bien plus tôt que prévu, mais après une petite discussion avec Gemini, j'ai découvert l'existence d'adaptateur PCI Nvme qui permet de brancher des disques SSD sur une carte PCI.

Bref, un nouvel achat, quelques jours et 20 euros de moins plus tard, j'ai pu enfin brancher ce satané disque sur ma machine.

Le choix de la distribution

La première chose à faire pour démarrer c'est de choisir une distribution Linux, télécharger un ISO d'environ 4Gb, flasher une clé usb avec BalenaEtcher, et lancer l'installation.

Retenez bien ces étapes, elles serviront plusieurs fois par la suite...

Mon premier choix s'est porté sur Bazzite, orienté gaming, mais j'ai rapidement déchanté en voyant que les cofondateurs lavaient leur linge sale sur internet ce qui n'est jamais vraiment bon signe. On l'autorise uniquement pour Linus Torvalds.

J'ai donc ensuite installé Pop!_OS, qui est censé être grand public et compatible avec un usage gaming.

Assez rapidement, j'ai enchainé les désillusions. Mon soft de montage vidéo, Filmora, n'est pas disponible sur linux, tout comme Proton Drive.

Pour Proton, il semble exister une version en cours de développement donc à la limite, je peux attendre.

Concernant Filmora, cela m'oblige à apprendre DaVinci. C'est très frustrant parce que j'ai mes reflexes sur Filmora mais j'y perdrais pas au change en apprenant DaVinci qui est un excellent soft de montage. C'est frustrant, mais ça se fait.

Par contre, j'ai cumulé ça avec pas mal de complications liées à des ralentissements et des freeze de l'ordinateur. J'ai appris à maitriser xkill (pour tuer une fenêtre) en boucle notamment lors de l'installation de lutris qui permet de lancer Overwatch.

Oui, je vais prendre Overwatch comme benchmark pour tester la faisabilité de cette migration. C'est LE jeu auquel je joue le plus. Ne me jugez pas.

Après un long moment de frustration passé sur lutris qui n'a jamais fonctionné, je suis finalement passé sur Steam parce que j'ai découvert grâce à Gemini que Overwatch est désormais jouable sur Steam. L'install de Steam a du se faire en ligne de commande puisque l'installeur de base ne fonctionnait pas (sic). J'ai ensuite lancé le donwload d'overwatch (60Gb...) puis je suis allé faire autre chose.
L'ordi s'est mis en veille et ne m'a permis pas d'en sortir ensuite... Le réveil difficile semble être aussi possible pour un ordinateur. Bref, j'ai du rebooter, et j'ai perdu le download du jeu...

Heureux (non) et frais comme un gardon (non plus), j'ai désactivé la mise en veille automatique puis relancé le download. Après plusieurs heures j'ai enfin pu lancer le jeu et... ça n'a pas marché. Le jeu s'est lancé, ça semblait fluide, mais le personnage regardait constamment le sol comme si ma souris n'était pas reconnue.

On parle de plusieurs heures de galères, beaucoup de lignes de commandes faites en terminal alors que je ne voulais clairement pas d'un OS qui m'oblige à faire ça alors j'avoue que l'envie d'abandonner était vraiment très forte.

Et puis une personne m'a dit : "peut être que je tu devrais essayer avec une distrib moins exotique".

Ok. C'est pas faux. Faut pas abandonner aussi vite.

Et puis surtout à ce stade, je dois quand même faire une petite parenthèse. L'une de mes motivations, c'était de sortir de la tech US. Mais choisir une distrib linux, certes c'est open source, mais c'est pas magique, il y a des boites derrière ces distributions. Or Bazzite et PopOS sont toutes deux d'origine US, donc dans tous les cas, j'avais pas vraiment rempli mon contrat.

Je suis donc reparti le lendemain sur Linux Mint (Irlande). Re-téléchargé un ISO, re-flashé une clé USB, refait l'installation. Joie.

Verdict, Mint semblait plus stable, aucun freeze, pas de soucis en sortie de veille, mais une interface un peu vieillotte, genre Windows des années 2000. Une personne m'a rapidement conseillé de plutôt essayer Zorin OS (Irlande).
Pas de soucis, je maitrise bien le flash de clé USB maintenant.

J'ai donc re-téléchargé un ISO, re-flashé une clé USB, refait l'installation.

Et j'avoue que le résultat est pas mal. L'OS est agréable à prendre en main, l'interface reste proche de Windows donc simple en terme d'habitudes à prendre. Par contre, cette fois je savais que le principal sujet c'était de faire marcher Overwatch pour valider totalement la migration.

J'ai donc installé Steam directement via le gestionnaire d'application fournie. J'ai lancé le téléchargement d'Overwatch (60Gb, ça n'a pas changé depuis tout à l'heure) et j'ai attendu.

Après plusieurs heures, enfin, j'ai pu démarrer le jeu et là... Nouvel échec. Le jeu était totalement saccadé, pixelisé de partout, les menus ne répondaient quasiment pas. Bref, merci xkill...

Mais cette fois, hors de question de m'arrêter là.

J'ai donc fait appel à un ami : Gemini.

D'abord, on a tenté de modifier les options de lancement du jeu en forçant l'usage de Proton, mais sans succès. Je fais comme si je connaissais Proton, en fait pas du tout. J'ai découvert Proton, Wine, Lutris dans la même journée et je ne vous ferais certainement pas un cours sur qui sert à quoi ou pourquoi Proton et pas Wine. J'en sais rien et je m'en fiche un peu.

Après plusieurs commandes lancées sur le terminal, on en vient à la conclusion que le jeu n'utilisait pas ma carte nvidia même si elle était correctement installé, car flatpack lui interdisait. Est-ce que ce diagnostic était bon ? Aucune idée. Mais j'ai installé flatseal pour gérer les permissions accordées à Steam.

Est-ce que ça a marché ? Pas du tout. Gemini m'a alors conseillé de réinstaller Steam non pas via flathub, mais via la version native directement (avec un .deb).

À ce stade, autant vous dire que j'étais plus à une installation prêt et un peu perdu de toute façon. Je connaissais même pas flathub avant la semaine dernière.

Bref, j'ai réinstallé steam, re-téléchargé le jeu (oui, encore), réinstallé proton, changé 2 fois la version de Proton parce que la version expérimentale était incompatible avec mon installation, changé 3 fois les options de lancement sous les conseils de Gemini et après plusieurs heures, le jeu s'est lancé !

Enfin, presque. Il a lancé la compilation des shaders vulkan.

Apparemment ça lui permet de les précompiler pour éviter de le faire pendant le jeu. J'ai une connaissance très limitée de ce que c'est qu'un shader, je ne sais pas pourquoi c'est nécessaire sour linux mais bon, pour 10 minutes de plus, je suis plus à ça près...

Je suis allé rapidement en partie d'entrainement, testé quelques persos et j'avais une petite sensation bizarre. Le jeu n'était pas fluide et en affichant les FPS, j'ai pu voir que j'étais plafonné à 60 FPs avec quelques petites chutes vers 50. Et je peux vous garantir que 60FPS on le sent passer. C'est des petits glitchs de temps en temps et une sensation d'absence de fluidité. C'est jouable. On peut vivre avec. Mais c'est pas du tout agréable, surtout quand on a connu le jeu a 175FPS avant, sur la même machine.

Et vous savez ce que m'a conseillé Gemini ? De tester avec Lutris.

Alors, j'ai installé lutris, re-téléchargé battle.net comme sur Pop_Os!, subit les mêmes lenteurs et saccadements, ce qui m'a permis de comprendre que c'était pas forcément PopOs le fautif, mais plutot Lutris, lancé battle.net pour arriver exactement à l'erreur que j'avais déjà eu sur PopOs et surtout la même conclusion : Lutris est un enfer.

Gemini m'a alors dit "Si Lutris te fait la tête, je te conseille d'utiliser Bottles. C'est une application ultra-moderne disponible dans la boutique Zorin qui est devenue la référence pour installer Battle.net."

Mais là, j'avoue. J'ai laissé tomber...

Bon, et si on faisait un bilan ?

Bilan

Eh bien, je ne dirais pas que c'est un échec, mais ça n'a pas marché comme dirait l'autre.

Globalement l'expérience Linux pour un usage pro en développement informatique est très bon, mais ça je le savais déjà, c'est clairement pas le frein. ZorinOs pour un utilisateur de Windows comme moi fait parfaitement le travail, on retrouve nos petits.

Pour les autres métiers ? Difficile à dire. Le risque, c'est d'avoir toujours un soft ou deux qui ne soit pas présent sur Linux. En soi, l'OS est désormais vraiment à niveau, mais si les éditeurs ne publient pas leur soft sur Linux, ça sera toujours un frein. C'est le cas par exemple des logiciels de CAO (autocad, revit, solidworks), ou de la suite Adobe pour les créatifs, de plusieurs outils pro pour les monteurs vidéos (Adobe Premiere ou After Effects).

Et ça rend l'option discutable pour un usage plus large. Encore une fois, c'est pas Linux qui est en cause ici, mais les éditeurs eux-mêmes. S'ils ne voient pas Linux comme une plateforme grand public, ce ne sera jamais grand public.

Et le grand public d'ailleurs, une partie sont des gamers et Linux, je peux difficilement dire que c'est adapté. Je sais que je vais faire bondir certains d'entre vous en lisant ça. J'ai plein d'amis qui m'ont garanti être capable de jouer sur Linux et je les crois. Mais ce serait hypocrite de ma part d'écrire que c'est aussi simple d'accès que sur Windows.

Évidemment j'exagère, pour une personne qui fait juste de la bureautique chez soi, avec un ordi déjà configuré, franchement ça devrait bien se passer. En plus c'est vrai que tous mes périphériques ont été détectées sans aucun souci, imprimante, micro RODE, double écran etc... Donc oui, je suis un peu injuste.

Mais dès qu'on touche au gaming, là, j'ai du mal à me dire que c'est ok. J'ai passé des heures à taper des lignes de commandes obscures sur un terminal. J'ai bidouillé des options de lancement dans Steam et dans les settings nvidia que j'avais jamais vu de ma vie et au final, ça ne marche pas.

On peut me dire sans aucun souci que je suis pas doué, que le problème réside entre la chaise et le clavier. Je reconnais aisèment tout ça. Je connaissais même pas la plupart des softs que j'ai manipulés ces derniers jours (flatpak, wine, proton etc...). Mais je devrais pas avoir besoin d'être doué pour jouer sur un PC. Et manifestement, je suis pas le seul à qui ça arrive parce que j'ai cherché des heures sur des sub Reddit et j'ai vu beaucoup de personnes avec des problèmes similaires.

Je voulais migrer, j'ai passé des heures là-dessus. J'ai lu des dizaines de messages sur les forums. Ne venez pas me dire que je suis de mauvaise foi. Je ne suis pas patient, c'est vrai, mais j'ai tenté.

Et le pire, c'est que je suis frustré. Parce que je voulais vraiment migrer. Je suis prêt à apprendre DaVinci pour remplacer Filmora. Je suis prêt à changer mes habitudes de travail, réapprendre à utiliser un nouvel OS. Mais bordel, je veux pouvoir jouer :)

Donc pour l'instant, je garde le double boot mais c'est pas une solution. Je suis encore entre la phase 3 (déni) et 4 (colère) du deuil en espérant pas arriver tout de suite à l'acceptation et la résignation...

Je vais continuer à chercher des solutions en ligne, mais clairement ça devient un job d'expertise et c'était pas censé être le cas et ça sent le sapin pour cet objectif 2026.

2025 a été un tournant majeur dans l'usage de l'IA, bien au-delà du simple usage individuel.

Depuis 2020 nous sommes passé du monde de l’auto complétion à l’industrialisation :

• 2021 avec Github Copilot : un usage individuel, essentiellement tourné autour d'une autocomplétion évoluée.
• puis un usage dans le navigateur pour des tâches plus complexes, nécessitant de multiples allers/retours et copier-coller
• 2025 avec Claude Code, ou Windsurf et Cursor : un usage sur le poste du développeur à travers des assistants de code

En passant progressivement de quelques lignes produites par auto complétion, à des applications codées à plus de 90% par des assistants IA, les équipes de dev doivent faire face à une obligation d'industrialiser cette pratique au risque de grosses déconvenues.

Et plus que ça, à partir du moment où le métier de développeur change, c'est en réalité toute l'équipe de développement qui doit muter avec lui.

Ce n'est plus uniquement un simple sujet de tooling, mais un sujet d'industrialisation à l'échelle d'une équipe, tout comme les frameworks de tests automatisés ont changé la façon de créer du logiciel début des années 2000.

(On testait évidemment avant les années 2000, mais la façon dont on a réfléchi à l'automatisation de ces tests via les frameworks xUnit, l'avènement des usines logicielles (CI/CD) etc... est plus récente)

Dans cet article, on va explorer comment les équipes de devs se sont adaptées via des témoignages de plusieurs boîtes Tech qui ont participé à la rédaction en abordant :

• Le Context Driven Engineering, nouveau paradigme
• Spec/Plan/Act : le workflow de référence
• L’écosystème des AI Rules
• La gouvernance et l’industrialisation
• Les défis Humains

Context driven engineering

Si le terme vibe coding s'est imposé début 2025, on parlera plus volontiers désormais de Context driven engineering ou d'agentic engineering. L'idée n'est plus de donner un prompt, mais de fournir un contexte complet incluant l'intention ET les contraintes (coding guidelines etc...).

Le Context Driven Engineering vise à réduire la part non déterministe du processus et fiabiliser la qualité de ce qui est produit.

Avec le CDE, si la spec n'a pas toujours été bien vue, elle redevient un citoyen de première zone et devient une obligation avant le code.

Separate your process into two PRs:

• The PR with the plan.
• The PR with the implementation. The main reason is that it mimics the classical research-design-implement loop. The first part (the plan) is the RFC. Your reviewers know where they can focus their attention at this stage: the architecture, the technical choices, and naturally their tradeoffs. "It's easier to use an eraser on the drawing board, than a sledgehammer at the construction site"

Source : Charles-Axel Dein (ex CTO Octopize et ex VP Engineering chez Gens de confiance)

On retrouve cette même logique ici chez Clever Cloud :

Here is the paradox: when code becomes cheap, design becomes more valuable. Not less. You can now afford to spend time on architecture, discuss tradeoffs, commit to an approach before writing a single line of code. Specs are coming back, and the judgment to write good ones still requires years of building systems.

Source : Pierre Zemb (Staff Engineer chez Clever Cloud)

ou chez Google

One common mistake is diving straight into code generation with a vague prompt. In my workflow, and in many others’, the first step is brainstorming a detailed specification with the AI, then outlining a step-by-step plan, before writing any actual code.

Source : Addy Osmani (Director sur Google Cloud AI)

Bref, on retrouve désormais cette méthode un peu partout :

• spec
• plan
• act

Spec/Plan/Act

Spec : La spécification regroupe les cas d'usages : les intentions exprimées par l'équipe de développement. On peut l’appeler RFC (request for change), ADR (architecture decision record), ou PRD (Product requirement document) selon les contextes et les entreprises.

C’est le document de base pour démarrer un développement avec une IA. La spec est habituellement relue par les experts produits, devs ou pas.

L’usage d’IA n’est pas rare non plus à cette étape (Cf. plus loin dans l’article).

Mais le contexte ne se limite pas à cela. Pour limiter les initiatives malheureuses des IA, il faut également lui fournir des contraintes, les normes de développement, les outils à utiliser, les docs à suivre. On verra ce point plus loin.

Plan : Le plan d'implémentation liste l'ensemble des étapes pour implémenter la spécification. Cette liste doit être exhaustive, chaque étape doit être réalisable par un agent de façon autonome avec le contexte nécessaire et suffisant. C'est habituellement relue par des seniors (architecte, staff, tech lead etc... en fonction des entreprises).

Act : Il s’agit de l’étape d’implémentation et peut être répartie à des sessions agentiques.

Dans de nombreuses équipes, cette session peut se faire selon deux méthodes :

*

• le mode copilote/pair programming avec une validation de chaque modification une par une
• le mode agent, ou le développeur donne l'intention puis vérifie le résultat (on verra comment plus tard)

On retrouve bien sûr des variations, comme par exemple chez Ilek qui détaille d’avantage la partie Act :

Nous en somme à la première phase de l’industrialisation qui est l’adoption. L’objectif c’est que d’ici la fin du trimestre tous les dev s’appuient sur ce framework et que l’utilisation des prompts/agents soit un réflexe. On vise donc une adoption de 100% d’ici fin mars. Notre workflow part du besoin et se découpe en plusieurs étapes qui vise à challenger les devs dans les phases de réflexion jusqu’à la validation du code produit. Voici la liste des étapes qu’on suit: 1- elaborate (challenge le besoin et interroge sur les cas limites, les choix techniques, l’architecture, etc.) 2- plan (propose un découpage technique, ce plan est fourni en sortie dans un fichier Markdown) 3- implement (Des agents vont réaliser les étapes du plan) 4- assert (un agent va valider que le résultat final répond aux attentes, lint, test, guideline) 5- review (des agents vont faire un review technique et fonctionnelle) 6- learn (mise à jour du context) 7- push (création de la MR sur gitlab) Tout ce processus se fait en local et est piloté par un développeur.

Cédric Gérard (Ilek)

Si cette méthode en 3 phases semble faire consensus, on voit pas mal d’expérimentations pour encadrer et renforcer ces pratiques, notamment avec deux outils qui reviennent régulièrement dans les discussions : Bmad et SpeckKit.

Pour avoir testé les deux, on peut aboutir assez facilement à une surdocumentation un peu verbeuse et un ralentissement du cycle de dev.

J'ai l'intuition qu'il faut éviter de reproduire numériquement des processus humains qui étaient déjà bancals. A-t-on vraiment besoin de tous les rôles proposés par BMAD par exemple ? J’ai eu l’impression de faire du SaFe en mode solo et ce n'était pas une bonne expérience :)

Ce qui est sûr, c'est que si la spec redevient reine, la spec nécessaire à une IA se doit d'être simple, sans ambiguïté. La verbosité peut nuire à l'efficacité des assistants de code.

L’écosystème des AI Rules

Si le mode agentique semble prendre le dessus sur le mode copilote, cela vient avec des contraintes supplémentaires pour s'assurer de la qualité. On veut absolument s'assurer :

• que l'implémentation respecte la spec
• que le code produit respecte les standards de l'équipe
• que le code utilise les bonnes versions des librairies du projet

Pour s'assurer de la qualité produite, les équipes fournissent le contexte nécessaire pour informer l'assistant de code des contraintes à respecter. Paradoxalement, malgré la mauvaise réputation du vibe coding et son usage auparavant réservé aux prototypes, le Context Driven Engineering remet les bonnes pratiques d'ingénierie habituelles (harnais de test, linters etc...) sur le devant de la scène. Sans elles, il devient impossible de s'assurer de la qualité du code et de l'architecture.

En plus de toutes les bonnes pratiques classiques, la plupart des systèmes agents viennent avec leurs propres concepts : le fichier de contexte général (agents.md), les skills, les serveurs MCP, les agents.

agents.md

Un assistant de code va lire plusieurs fichiers en plus de la spec qu'on lui fournit. Chaque assistant de code propose son propre fichier : Claude.md pour Claude, .cursorrules pour Cursor, windsurfrules pour Windsurf etc...

Il existe une tentative d'harmonisation via agents.md mais l'idée est toujours globalement la même : une sorte de README pour AI. Ce README peut s'utiliser de façon hiérarchique, on peut en effet avoir un fichier à la racine, puis un fichier par répertoire où c'est pertinent.

| agents.md
| 
` application 1
  | 
  ` agents.md 

Ce fichier contient les instructions à suivre systématiquement, exemple :

- l'interface est en anglais obligatoirement
- dans le backend nuxt (`server/api/`), on utilise TOUJOURS le client OpenAPI généré (`~~/server/utils/openapi`), jamais `$fetch` direct

et peut faire référence à d'autres fichiers.

Si tu dois travailler en kotlin, toujours charger le fichier rules/kotlin.md 

Avoir plusieurs fichiers permet à chaque agent de travailler avec un contexte réduit, ce qui améliore l'efficacité de l'agent en question (sans parler de l'économie sur les coûts).

Les skills, agents, serveurs MCP

En fonction des outils utilisés, on retrouve plusieurs notions qui ont chacun des usages différents.

Une skill explicite à un agent IA comment réaliser un type d'opération.

Par exemple, on peut lui donner les commandes à utiliser pour appeler certains outils de génération de code, ou de vérification statique.

Un agent peut être impliqué pour prendre en charge une tâche spécifique. On peut par exemple avoir un agent dédié à la documentation externe avec des instructions quant au ton à adopter, l'organisation recherchée etc...

Les serveurs MCP permettent d'enrichir la boîte à outils de l'agent IA. Cela peut être des accès direct à une documentation (par exemple la doc de Nuxt), voire à des outils pour consulter les infos d'un compte de test comme le MCP de Stripe.

Il est encore trop tôt pour le dire, mais on pourrait voir apparaître une notion de dette technique liée à l’empilement de ces outils et il est fort à parier que l’on verra des techniques de refactorings et de tests se profiler dans le futur.

La gouvernance et l’industrialisation

Avec l’apparition de ces nouveaux outils vient une question : comment uniformiser la pratique et profiter des bonnes pratiques de chacun ?

Comme le dit Benjamin Levêque (Brevo)

L'idée c'est : au lieu que chacun galère avec ses propres prompts dans son coin, on met en commun nos découvertes pour que tout le monde en profite.

Des Marketplaces d'entreprises

Une des premières réponses pour la mise en commun repose sur la notion de marketplace d’entreprise :

Chez Brevo, on vient de lancer une marketplace interne avec des skills et des agents. Ca nous permet d'uniformiser le code généré via l'IA (avec Claude Code), tout en respectant les standards définis par les "experts" de chaque domaine (langage, techno, etc.). Les 3 composants dans claude code : On transforme nos succès en Skills (instructions réutilisables), en Subagents (IA spécialisées) et en Patterns (nos meilleures architectures). Ne pas réinventer la roue : On passe d'une utilisation "au feeling" à une méthode systématique.

Benjamin Levêque et Maxence Bourquin (Brevo)

Chez Manomano on a aussi initié un repository afin d'y transposer nos guidelines et ADR sous un format machine friendly. On décline ensuite des agents et des skills que l'on va ensuite installer dans claude code / opencode. On a un outil de bootstrap de machine interne, on y a ajouté ce repo ce qui fait que tout les tech de la boite se retrouve outillés. C'est ensuite à chacun de référencer les règles ou skills qui sont pertinents en fonction des services. On a des skills typés intégration (utilisation de notre IAC interne pour ajouter X ou Y), d'autres qui sont des pratiques (faire une revue de code : comment faire du react a Manomano) et des commandes qui couvrent plus des orchestrations (tech refinement, implementation de feature avec revue). On observe aussi qu'il est difficile d'uniformiser les installations de MCP chez chacun, ce qui est dommage quand on voit l'impact de certains sur la qualité de ce qu'on peut produire (Serena a été cité et je rajouterai sequential-thinking). On en est au point ou on se demande comment garantir un env iso chez tout les dev, ou comment le rendre cohérent chez tout le monde

Vincent AUBRUN (Manomano)

Chez Malt, nous avons aussi démarré la mise en commun de commands / skills / AGENTS.MD / CLAUDE.MD. Classiquement, l'objectif des versions initiales est de partager un certain nombre de connaissances qui permettent à l'agent de ne pas repartir de zéro. Les propositions (via MR typiquement) sont revues dans le cadre des guildes (backend / frontend / ia). A noter qu'on se cherche encore beaucoup à l'échelle de l'engineering. Il est notamment compliqué de savoir si un élément partagé est vraiment utile au plus grand nombre.

Guillaume Darmont (Malt)

A noter qu’il existe des marketplace publiques, on peut citer :

• la marketplace Claude
• une marketplace par vercel

Attention cependant, il est obligatoire de relire tout ce que vous installez…

Parmi les méthodes de déploiement, beaucoup ont privilégié des outils customs, mais François Descamps de Axa nous cite une autre solution :

Pour le partage des primitives, nous explorons APM (agent package manager) de Daniel Meppiel. J’aime beaucoup le fonctionnement, il est assez facile d’utilisation et s’utilise pour la partie gestion de dépendances comme NPM.

Intégration dans la CI/CD

Malgré toutes les instructions fournies, il arrive régulièrement que certaines soient ignorées. Il arrive aussi que les instructions soient ambiguës et mal interprétées. C'est là où les équipes mettent en place obligatoirement des outils pour encadrer les IA :

• linting
• harnais de test
• revues de code

Si l'œil humain reste obligatoire pour tous les participants interrogés, ces outils eux-mêmes peuvent s'appuyer partiellement sur des IA.
Les IA peuvent en effet rédiger les tests. L'humain vérifie alors la pertinence des tests proposés.
Plusieurs équipes ont également créé des agents spécialisés dans la revue avec des scopes bien spécifiques : la sécurité, la performance etc...
D'autres utilisent des outils automatisés, certains directement branchés sur la CI (ou sur Github).

(je ne les cite pas mais vous pouvez les trouver facilement).

Liée à cette notion de CI/CD, une question qui revient souvent :

Il est également très difficile de savoir si une "amélioration", i.e. modification dans le fichier CLAUDE.MD par exemple, en est réellement une. Est-ce que la qualité des réponses sera réellement meilleure après la modif ?

Guillaume Darmont (Malt)

Est-ce que je peux évaluer un modèle ? Si je change mes guidelines, est-ce que l'IA génère toujours un code qui passe mes critères de sécurité et de performance ? Est-ce qu’on peut traiter le prompt/contexte comme du code (Tests unitaires de prompts).

A cela Julien Tanay (Doctolib) nous dit :

A propos de la question "est(ce que ce changement sur le skill le rend meilleur ou moins bon", on va commencer a regarder promptfoo et brainstrust (utilisé en prod pour l'IA produit chez nous) pour faire de l'eval dans la CI.(...) Par exemple avec promptfoo, tu vas vérifier, dans une PR, que pour les 10 variantes d'un prompt "(...) setup my env" le skill env-setup est bien trigger, et que l'output est correct. Tu peux vérifier l'appel du skill programmatiquement, et l'output soit via "human as a judge", ou plutot "LLM as a judge" dans le cadre d'une CI

L’ensemble des discussions semble indiquer que le sujet est encore en recherche, mais qu’il existe déjà des pistes de travail.

Les coûts

On avait un KPI principal qui était d'obtenir 100% d'adoption pour ces outils en un trimestre (...) Au début notre KPI principal c'était l'adoption, pas le coût.

Julien Tanay (Staff engineer chez Doctolib)

Le coût vient en effet souvent en seconde partie. Le schéma classique, c’est l’adoption, puis l’optimisation.

Pour maîtriser les coûts, il y a d'une part l'optimisation des sessions, qui passe par

• le fait de garder des fenêtres de sessions courtes, en ayant découpé le travail en petites étapes indépendantes.
• l'usage de la commande /compact pour garder uniquement le contexte nécessaire (ou le fait de flusher ce contexte dans un fichier pour reprendre une nouvelle session)

On retrouve par exemple ces conseils proposés par Alexandre Balmes sur Linkedin.

Cette maîtrise des coûts peut être centralisée avec les licences entreprises.
Cette bascule entre clé individuelle et clé entreprise fait parfois partie de la procédure d'adoption :

On une strat progressive sur les coûts. On fournit une clef d'api pour les nouveaux, afin de suivre leurs usages et payer au plus proche de la conso. Passer un seuil on les bascule sur des licences Anthropic enterprise car on estime que c'est plus intéressant pour les usages quotidiens.

Vincent Aubrun (ManoMano)

Sur le coût mensuel par développeur, les différentes discussions permettent de faire émerger 3 catégories :

La grande majorité oscille entre la catégorie 1 et 2.

La documentation, effet de bord positif des IA

Quand on parle de gouvernance, la documentation étant devenue le nouveau langage de programmation, elle redevient un citoyen de première zone.

On la retrouve dans les specs en markdown présent sur le projet, les ADR/RFC etc... Ces docs sont désormais maintenues en même temps que le code est produit.

Alors nous on a déclaré que le markdown c'était la source de vérité. Confluence en PLS :)

Julien Tanay (Doctolib)

Ce n’est plus un simple micro événement dans le cycle de dev du produit, géré parce qu’il le faut et rangé au placard. Les équipes les plus matures font désormais évoluer la doc pour faire évoluer le code, ce qui permet d’éviter le fameux syndrome des piles de documents d’entreprises obsolètes qui trainent sur un drive partagé.

Cela a de nombreux avantages, elle peut être utilisée par des agents spécialisés pour l'écriture de la doc utilisateur (la doc end user), ou être utilisée dans un RAG pour servir de base de connaissance, pour le support client, l'onboarding des nouveaux arrivants etc…

L'intégration de ce framework impacte la façon de gérer les incidents. Il offre la possibilité de debugger nos services avec des agents spécialisés qui peuvent s’appuyer sur les logs par exemple. Il est possible d’intérroger le code et la memory bank qui agit comme une documentation vivante.

Cédric Gérard (Ilek)

La propriété intellectuelle

L’un des sujets majeurs qui revient est évidemment la propriété intellectuelle. Il ne s’agit plus de faire de simples copier-coller dans un navigateur avec un contexte choisi, mais de donner accès à la codebase entière.

C’est une des grandes motivations de passer sur les licenses enterprise qui contiennent des clauses contractuelles de type “zero data training”, voire “zero data retention”.

En 2026 on devrait aussi voir apparaître l’AI act et la certification ISO 42001 pour auditer la manière dont les données sont collectées et traitées.

Dans les usages enterprise on note aussi des montages via des partenariats comme celui entre Google et Anthropic :

De notre côté, nous n'avons pas besoin d'allouer un montant à l'avance, ni d'acheter des licences, car nous utilisons les modèles Anthropic déployés sur Vertex AI d'un de nos projets GCP. Il suffit ensuite de faire pointer Claude Code sur Vertex AI. Cette configuration adresse également les problématiques de propriété intellectuelle.

Sur tous ces points, une autre piste semble être d’utiliser des modèles locaux. On peut citer Mistral (via Pixtral ou Codestral) qui propose de faire tourner ces modèles sur des serveurs privés pour garantir qu'aucune donnée ne franchit le firewall de l'entreprise.

J’imagine que ce serait également possible avec Ollama.

Cependant je n’ai rencontré qu’une seule entreprise qui travaillait sur cette piste pendant mes discussions. Mais on peut anticiper que l'essor des modèles locaux sera plutôt un sujet 2026 ou 2027.

Les impacts humains

Le recrutement

Si l'IA est désormais solidement implantée dans de nombreuses équipes, ses impacts dépassent désormais le cadre du seul développement.

On retrouve notamment des réflexions autour du recrutement chez Alan

Picture this: You’re hiring a software engineer in 2025, and during the technical interview, you ask them to solve a coding problem without using any AI tools. It’s like asking a carpenter to build a house without power tools, or a designer to create graphics without Photoshop. You’re essentially testing them on skills they’ll never use in their actual job. This realization hit us hard at Alan. As we watched our engineering teams increasingly rely on AI tools for daily tasks — with over 90% of engineers using AI-powered coding assistants — we faced an uncomfortable truth: our technical interview was completely disconnected from how modern engineers actually work.

Emma Goldblum (Engineering chez Alan)

La formation des juniors

Un des gros sujets porte sur la formation des juniors qui peuvent être rapidement en danger avec l'usage de l'IA. Ils sont en effet moins productifs désormais, et n'ont pas toujours l'expérience nécessaire pour challenger correctement le code produit, ou écrire correctement les spécifications. Une grande partie des tâches autrefois attribuées aux juniors est dorénavant monopolisée par les IA (code boiler plate, validation de formulaire, tâches répétitives etc...).

Cependant, toutes les équipes reconnaissent la nécessité d'embarquer les juniors pour ne pas créer un fossé d'expérience dans le futur.

Malgré cette prise de conscience, je n’ai pas vu d’initiatives spécifiquement sur le sujet qui viserait à adapter la formation des plus juniors.

L’accueil des nouveaux arrivants

Enfin l'accueil des nouveaux arrivants est bousculé par l'IA, notamment parce qu'il est désormais possible de les accompagner pour découvrir le produit

Certaines équipes ont un skill d'onboarding qui aide a setup l'env, fait un tour de la codebase, fait une PR d'exemple... Les gens sont créatifs*

Julien Tanay (Doctolib)

Par effet de bord, ce point est jugé facilité par les changements induits par l’IA, notamment aidé par le fait que les documentations soient mises à jour plus régulièrement et que l’ensemble des guidelines soient très explicites.

L’accompagnement vers un changement de métier

Un des éléments peu abordés reste l’accompagnement des développeurs face à une mutation de leur métier.

On déplace la valeur des développeurs de la production du code à la maîtrise du métier. Cela oblige à prendre beaucoup de hauteur. L’écriture du code, les pratiques comme le TDD sont des éléments qui participent au plaisir qu’on prend dans le travail. L’IA vient bouleverser ça et certain ne seront peut-être pas capable de s’epanouir dans cette évolution de notre métier

Cédric Gérard (Ilek)

La question n’est pas de savoir si le métier de développeur touche à sa fin, mais plutôt dans quelle mesure il évolue et quelles sont les nouvelles compétences à acquérir.

On peut comparer ces évolutions à ce qui est arrivé dans le passé lors des transitions entre les cartes perforées et la programmation interactive, ou avec l’arrivée des langages de plus haut niveau. Avec l’IA les équipes de développement gagnent en niveau d’abstraction, mais gardent les mêmes défis, identifier les bons problèmes à résoudre, trouver quelles sont les solutions technologiques adéquates, réfléchir en termes de sécurité, performance, fiabilité et de compromis entre tout cela.

Malgré tout, cette évolution n’est pas forcément bien vécue par tous et il devient nécessaire dans les équipes d’accompagner les personnes à considérer le développement sous un angle différent pour retrouver l’intérêt du métier.

Cédric Gérard nous met en garde également contre d'autres risques :

Il y a un risque sur la qualité des productions qui diminue. L’ia n’étant parfaite, il faut être très attentif au code généré. Cependant review du code ce n’est pas comme produire du code. La review c’est fastidieux et on peut très rapidement se laisser aller. A cela s'ajoute un risque de perte de compétence. Lire n’est pas écrire et on peut s’attendre à développer une capacité d’évaluation, mais un perdant petit à petit en créativité

Conclusion

2025 a vu l’essor de la programmation agentique, 2026 sera sans doute une année d’apprentissage en entreprise autour de l’industrialisation de ces outils.

Il y a des points dont je me réjouis, c'est le retour en force de la pensée système. Le "Context Driven Engineering" nous force à redevenir de bons architectes et de bons concepteurs produit. Si vous ne savez pas expliquer ce que vous voulez faire (la spec) et comment vous comptez le faire (le plan), l'IA ne vous sauvera pas ; elle produira juste de la dette technique à une vitesse industrielle.

Un autre effet de bord inattendu pourrait être la fin de l'ego coding, la disparition progressive de l'attachement émotionnel au code produit qui créait parfois des discussions compliquées, par exemple lors des revues de code. En espérant que cela nous rende plus critique et moins réticent à jeter du code et des fonctionnalités non utilisées.

Quoi qu'il en soit, la différence entre une équipe moyenne et une équipe d'élite ne s'est jamais autant jouée sur des compétences "anciennes". Savoir challenger une architecture, poser de bonnes contraintes de développement, avoir une bonne CI/CD, anticiper les failles de sécurité, et maintenir une documentation vivante seront d’autant plus critiques qu’avant. Et par expérience ce n’est pas si acquis que cela partout.

Maintenant, il reste des questions, il va falloir apprendre à piloter un nouvel écosystème d'agents tout en gardant le contrôle. Entre les enjeux de souveraineté, les questions autour des modèles locaux, la capacité à tester la reproductibilité et la qualité des prompts, l'explosion des coûts et la mutation du rôle de junior, nous sommes encore en pleine phase d'apprentissage.

Et en effet, on devait constamment trouver le bon équilibre entre construire du logiciel, ou l'acheter sur étagère. L'open source existait bien sûr, je pourrais citer Mysql ou Apache, mais il n'y avait pas autant de logiciel open source complet qu'aujourd'hui.

Avec le temps justement cet essor de l'open source a changé la donne.

Je peux aujourd'hui par exemple faire tourner une application sur un PAAS open source (coolify), utiliser metabase pour de la data analyse, openpanel pour du web analytics, listmonk pour de l'envoi de newsletter etc... Je peux faire le choix d'héberger et de faire tourner beaucoup de logiciels qui étaient auparavant uniquement disponibles en version propriétaire.

Donc à partir de là, c'était plus juste Build or Buy mais Build or Buy or Run. Le run apportant lui-même son lot de contraintes et de compromis.

Mais depuis l'an dernier, on assiste à nouveau à un changement et le problème est devenu Build, Buy, Run or Vibe (BBRV).
(vibe étant lié au vibe coding, même si aujourd'hui on s'éloigne de plus en plus du simple vibe coding pour une véritable industrialisation de l'usage de l'IA)

L'illusion des MOAT par la quantité de code

Un Moat (douve en anglais), c'est un avantage défensif durable. On essaie souvent quand on construit un logiciel de se créer un MOAT, c'est-à-dire un avantage compétitif. Pendant très longtemps, ce MOAT pouvait être simplement qu'un logiciel nécessitait trop de temps à être reconstruit, sans être crucial pour une entreprise.

Prenons par exemple un logiciel qui vous fournit la gestion de feature flag (unleash ou launchdarkly). C'est pas complexe en soi, mais c'est rarement coeur pour une entreprise. Donc dans le dilemne classique de Build or Buy, le Buy était souvent privilégié. Quelle serait la plus-value de reconstruire ça ?

Sauf que désormais, beaucoup de softs "simples" sont reproductibles avec des assistants de code boosté à l'IA.

Dit autrement, je dois désormais arbitrer entre prendre un produit sur étagère qui me coute peut-être entre 100 et 1000 euros par mois, et le fait de mobiliser un(e) ingénieur pendant une journée pour reproduire uniquement les fonctionnalités qui m'intéressent et à cela, je dois inclure le cout du run.

Et ça, c'est un énorme défi en perspective qui doit être pris en compte par chaque créateur de logiciel, et encore plus de SAAS.

La capacité à produire du code, n'est plus un avantage compétitif.

Si le code devient une commodité, est-ce que tous les SAAS sont voués à disparaître. Évidemment que non, mais on va illustrer ce point.

J'ai vu récemment passer deux initiatives pour reproduire Linkedin et qui ont été produit avec l'IA :

• https://nolto.social/ très prometteur, basé sur activitypub, self hostable, open source, et démarré avec lovable.dev (un assistant de code IA)
• https://ponos-job.eu/, plus simple, également open source, construit aussi avec IA.

Ces deux softs montrent qu'on peut refaire désormais avec des équipes de une ou deux personnes des logiciels très complets.

Pour reprendre une analogie que j'ai vu plusieurs fois sur internet, si la production de logiciel avant, était une construction puis un assemblage lent et méticuleux de briques, aujourd'hui, on peut coder rapidement des murs entiers. Ce qui limite un développeur, c'est sa compréhension métier. Mais plus un soft est connu et documenté, plus on peut rétro ingénierer facilement cette connaissance quand on a la tête bien faite et une connaissance fonctionnelle du métier.

Mais ici la barrière pour remplacer Linkedin, c'est pas le code en soi.

Avec l'IA, on est passé d'une économie de la rareté de la production (coder était difficile et cher) à une économie de la rareté de la confiance et de la distribution. Linkedin va garder, pour l'instant, cet avantage sur ces deux initiatives.

Et il existe d'autres barrières qui restent efficaces :

• l'accès exclusif à une donnée bien spécifique (Exemple Palantir)
• l'effet réseau. C'est ce qui protége Linkedin, Whatsapp ou X. Certains logiciels n'ont d'intérêt que s'ils sont utilisés par d'autres.
• des accréditations ou certifications réglementaires qui donnent accès à des marchés protégés (exemple le bancaire ou le militaire)
• l'implantation dans un écosystème (si un logiciel est déjà intégré et référencé au sein d'un écosystème existant, c'est dur de l'enlever sans perdre toutes ces intégrations, par exemple Jira, Salesforce ou Okta)
• la donnée captive (c'est proche du point précédent, nos données peuvent être "otages" d'un logiciel ce qui rend la sortie difficile
• la garantie de service (ça rejoint le fait de supporter le run, mais pour certains logiciels, on est prêt à payer pour ne pas endosser la responsabilité)
• un réseau physique, par exemple cloudflare ou amazon qui possèdent des datacenters. Forcément le physique est non réplicable.

Certains de ces items sont directement liés aussi à la capacité de distribution. Par exemple, je peux créer un ersatz de Slack ou Teams, mais je n'ai pas la capacité de distribution (force commerciale et intégration dans un écosystème) de Microsoft ou Salesforce pour le faire se diffuser partout.

Ceux qui ont la donnée (qu'ils l'achètent ou l'accumulent) gardent l'avantage. Parce qu'ils sont aussi capable de résoudre plus de cas d'usage. Et c'est pas étonnant que l'accès à cette donnée soit protégé. À l'inverse ceux qui ne font que manipuler et afficher de la donnée sont en danger.

Au delà de ca, je pense qu'on assiste à une nouvelle génération d'entreprise, les IA natives.

Des cloud natives aux IA natives

J'ai connu l'ère Cloud native en créant Malt en 2012.

Ça voulait dire qu'on n'avait rien en propre, pas de serveur, pas de bureaux. Tout était décentralisé et éclaté. C'était une entreprise purement online. Chaque brique de l'entreprise était un SAAS sur étagère.

Avec cette dématérialisation à outrance, les entreprises Cloud natives sont devenu liquides, facile à modifier et faire évoluer. La gestion des ressources se faisait par de la location. Je louais un service et je pouvais en changer "facilement", modulo des couts d'intégration bien sûr, sans devoir gérer avec des équipes internes, des réaffectations de serveurs etc...

L'informatique est devenu une forme de Lego géant.

Et pour moi, qui avait connu les entreprises non cloud natives, qui est allé coder en salle serveur directement pour reprendre la main sur une machine défaillante, ou qui a subi des pannes de clim en salle serveur ayant fait tomber toute l'infra, la différence est flagrante. De même, je suis passé d'une époque ou demander un serveur de CI pouvait prendre littéralement 3 mois, avec des formulaires d'ouverture réseau à n'en plus finir, à un simple click sur une interface.

Être cloud native c'est devenu aussi naturellement une facon simple d'épouser des concepts modernes de sécurité, comme le Zero Trust architecture qui est par définition impossible à éviter dans ce contexte. Vous ne pouvez pas faire confiance au réseau puisque votre réseau interne, c'est Internet. C'est devenu un avantage lors de la crise covid. Je n'ai pas connu, comme certaines boites, le fait de devoir faire des rotations sur les heures de login le matin parce que le réseau interne et le VPN d'entreprise n'était pas dimensionné pour autant d'accès externes. Je n'ai pas connu l'obligation de revenir au bureau pour récupérer du courrier, ou revalider mon pc sur le réseau interne de la boite.

Et je peux vous dire que j'ai vu passer des gens dans la boite qui venaient de boites traditionnelles et qui n'ont jamais réussi à comprendre cette culture, toujours à se questionner sur le nombre de services utilisé par la boite et incapable d'appréhender la vraie nature de ce que nous étions.

Je sais que c'est encore dur, même aujourd'hui, de faire prendre conscience que le Cloud a littéralement été l'un des moteurs majeurs de la tech sur la décennie 2010. Beaucoup voient dans le cloud une simple entourloupe marketing, le fait de déplacer ses serveurs chez quelqu'un d'autre, une simple infogérance. En 2026 il y a encore beaucoup d'entreprises qui ne sont pas cloud natives. Et c'est normal. On ne passe pas d'un monde à l'autre d'un claquement de doigt, si même c'est possible.

Quand je dis que ça a été moteur, il faut comprendre que ça a créé de la souplesse et donc de la vitesse, vitesse qui a été déterminante pour toutes les boites post 2008 (en France, Blablacar, doctolib, Malt, Backmarket etc..). Ce changement technologique a aussi permis de créer beaucoup d'opportunités pour reconstruire des services existants, mais sous forme de briques en ligne (les fameux SAAS).

Mais aujourd'hui, on voit apparaitre des entreprises IA natives. Des entreprises pour lesquelles la production de code est devenu une commodité. La capacité de production a drastiquement augmenté.

Si le Cloud Native a "simplifié" l'infrastructure, l'IA est en train de "simplifier" la mise en œuvre.

(* Et oui, je sais, simplifier est sans doute un mauvais terme parce que faire tourner dans le cloud, ou produire du code de bonne qualité avec une IA n'est pas si simple que ça)

• 2010 : On a tué la complexité de l'infra (le hardware).
• 2024+ : On tue la complexité de l'implémentation (le software).

Conséquence : Le développeur "IA Native" devient un architecte d'intention plutôt qu'un ouvrier du code.

Le choc culturel

De la même façon qu'avec le Cloud, l'IA va créer de nombreuses opportunités. Je suis prêt à parier qu'on va voir de plus en plus des initiatives (comme celle de linkedin cité plus haut) où des softs déjà existants vont se faire totalement recréer par des entreprises avec 10 ou même 100x moins de gens, sans parler des nombreux projets open source qui vont eux-aussi naitre pour remplacer des softs "commoditaire", comme par exemple la gestion des feature flags dont je parlais plus haut.

Donc ça, c'est le premier choc. Il faut s'attendre à voir émerger beaucoup de compétiteurs très rapides dans les années qui arrivent face à des softs bien établis.

Mais il existe un corrolaire de ça, car de la même façon qu'en 2026 on a encore beaucoup d'entreprises non cloud natives et qui ne le seront jamais, beaucoup d'entreprises ne deviendront pas IA natives sans heurts.

Oui certains softs vont garder de l'avance, mais une entreprise IA native va pouvoir lutter sur les prix (le cout de production étant moindre) ou faire plus de marge, donc plus d'investissement.

Comme je le disais juste avant, j'imagine peu de boites "non IA natives" devenir IA natives, parce que ça aurait des impacts sociaux dans l'entreprise gigantesques. C'est une question de culture, la culture étant la facon dont on répond systématiquement à un problème donné. Une boîte IA Native ne cherche pas à réduire ses coûts de 20%, elle cherche à opérer avec une structure de coût fondamentalement différente (10x ou 100x moins de staff pour le même résultat).

Bref, c'est pas "juste" les boites qui font de l'IA qui vont représenter la nouvelle génération de startups post 2020, mais sans doute aussi tout un tas de petites entreprises très lean, avec peu de gens et qui vont frapper de plein fouet de nombreux business bien établis.

Et s'il y a un profil qui devrait tirer son épingle du jeu, c'est le Product engineer : la personne capable de comprendre les problèmes à résoudre et de se mettre à la place de l'utilisateur.

Et vous, dans vos roadmaps actuelles, quelle portion de votre logiciel est déjà devenue une "commodité" que l'IA pourrait reconstruire en un week-end ? Quel est le vrai rempart qui vous restera demain ?

Ce débat est loin d'être anodin et spoiler : il n'y a pas de gentils dans cette histoire.

Blocage DNS et désaccords

Vous n'avez peut-être pas suivi l'affaire mais l'Italie vient d'infliger une amende record de 1% du CA mondial de Cloudflare pour ne pas avoir agi et bloqué des sites pirates.

Cloudflare a en effet refusé.

Pour comprendre l'enjeu, il faut d'abord parler DNS. Un DNS, c'est un registre d'adresses d'Internet, une sorte de gros index qui fait la liaison entre un nom de domaine et une adresse IP. Un peu comme un annuaire qui fait le lien entre votre nom de famille et votre adresse physique.

Les blocages DNS sont souvent critiqués, car ils soulèvent plusieurs problèmes :

Le premier, c'est la performance. Un DNS se doit d'être le plus efficace possible au risque de ralentir l'ensemble du net. C'est l'une des couches réseau les plus basses et on ne peut pas se permettre de mettre trop de logique applicative dedans. Par exemple, on veut éviter de tester si cette adresse fait partie d'une liste de sites non autorisés, d'autant plus si on veut le faire par pays d'origine du visiteur.

Et justement, cette notion d'origine du visiteur a de l'importance. Si l'Italie décide de bannir un site, ce n'est pas pour autant que cette décision doit s'appliquer en Australie ou au Japon. Donc en théorie, pour bien faire les choses, il faudrait considérer que le pays d'origine du visiteur influe sur la réponse du DNS.

Cloudflare invoque 200 milliards de requêtes journalières qui passent par ses serveurs. Si on commence à avoir tout un tas de règles au niveau DNS, c'est tout le trafic mondial qui serait potentiellement ralenti. En tout cas selon Cloudflare.

Sauf que cette excuse de la performance est mise à mal par un fait simple : Cloudflare sait déjà faire ça. Ils le font sur leur DNS "famille" (1.1.1.3) qui filtre le contenu adulte et les malwares. Donc techniquement, le savoir-faire existe.

Au-delà des critiques sur la performance, on peut reprocher aux blocages DNS de manquer de finesse. Si un utilisateur d'un service partagé comme Youtube se faisait bannir, c'est le domaine entier qui se retrouverait bloqué. On ne peut pas juste bannir une chaîne.

Et enfin, si on commence à avoir des règles de ce type au niveau DNS, c'est la première porte ouverte à une fragmentation du réseau. Ça commence à ressembler au grand firewall chinois.

Ce n'est pas qu'un problème italien

Le sujet des blocages DNS n'est pas une spécificité italienne.

En France, Canal+ a les mêmes demandes face à Google, Cloudflare et Cisco pour essayer de lutter contre le streaming sportif. On retrouve le même conflit en Belgique.

À l'inverse, l'Allemagne a jugé disproportionnée le blocage DNS et a rejeté les demandes faites en ce sens. Enfin, c'est uniquement la cour de Cologne, et rien ne dit que ça ne pourrait pas évoluer dans le futur.

Les alternatives au blocage DNS

Maintenant quelles seraient les alternatives si on voulait vraiment bloquer du contenu ? Est-ce qu'il y en a d'autres que de passer par les serveurs DNS ?

Le registrar : on peut demander au registrar de suspendre un domaine. Un registrar, c'est l'entité qui attribue les noms de domaines et c'est localisé. Les .fr sont attribués par une entité juridique française, les .de par une entité allemande. Un juge peut imposer une décision à un registrar français facilement. Mais c'est plus dur de le faire appliquer sur d'autres registrars. Et je rappelle que les .com, .org etc. sont gérés aux US. En pratique on retrouvera rarement, voire jamais, des sites pirates sur un .fr ou un .it. Ce serait beaucoup trop simple d'aller toquer à leur porte.

Les FAI : en France, on a des censures au niveau des fournisseurs d'accès internet, qui ont chacun des résolveurs DNS. C'est moins impactant que de taper sur un Cloudflare parce qu'un FAI est forcément national par défaut. Il y a moins cette notion d'extraterritorialité. Mais ça se contourne plus facilement aussi, même s'il faut être un utilisateur avancé pour changer son DNS.

Le déréférencement : chaque moteur de recherche sait supprimer des URLs pour un territoire donné. Un juge peut faire une demande pour interdire le référencement d'un site. C'est efficace, même si ça n'empêche pas de taper l'URL du site directement.

Le blocage par IP : c'est radical, ça peut s'effectuer au niveau des FAI ou au niveau pays directement au niveau des points d'échanges internationaux. Mais c'est globalement une mauvaise idée, ça manque totalement de finesse. C'est comme ça que l'Italie a réussi à bloquer Google Drive il y a quelques mois.

Couper les sources de revenus : la solution ultime, c'est de passer directement par Visa ou Mastercard. Ça a été fait dans les affaires Wikileaks, Megaupload et même Pornhub en 2020. Mais c'est en pratique plutôt une prérogative américaine puisque Visa et Mastercard sont des entreprises US, et ça reste très exceptionnel.

Le signalement à l'hébergeur : c'est une solution qui fonctionne bien pour les sites qui ont un hébergeur localisé. Je donnais l'exemple de Youtube plus haut, on peut effectivement signaler un contenu qui enfreint les conditions d'utilisation de la plateforme. C'est possible également de saisir un hébergeur, comme OVH etc... Mais là encore, on pourra être limité par la juridiction dont dépend l'hébergeur en question.

Ce qu'on peut en conclure c'est qu'il n'existe pas de solutions parfaites et c'est souvent un mix qui utilisé en fonction des compromis que l'on peut faire.

Neutralité du réseau ?

Concernant les DNS, le vrai débat dépasse la simple technique.

Est-ce qu'on accepte de "casser" des morceaux d'infrastructure "neutre" pour un gain marginal contre le piratage, ou est-ce qu'on considère que c'est une ligne rouge ?

L'Allemagne a plutôt dit non. L'Italie et la France disent oui.

J'ai du mal à avoir un avis tranché et absolu, mais j'ai l'impression qu'on met le doigt dans un engrenage dangereux.

Aujourd'hui c'est le piratage qui sert de prétexte. Demain, ce sera peut-être des sites d'opposants politiques, comme en Russie ou en Turquie, ou des sites de lanceurs d'alertes, comme Wikileaks dans le passé.

Qui va définir ce qui est acceptable ou pas ? En théorie la réponse est simple, le droit et la justice.

Et c'est justement là où le bât blesse en France ou en Italie. Ce n'est pas le droit qui tranche, mais une autorité administrative. Le Piracy Shield italien exige un blocage en 30 minutes sans contrôle judiciaire. En France, c'est pareil, l'ARCOM peut demander une coupure auprès des FAI, sans jugement.

Cette absence de contrôle et de recours, cette notion de précipitation aussi — on parle de 30 minutes pour décider d'un blocage national — c'est exactement ce genre de dispositif qui peut servir à faire un blackout total comme en Iran récemment.

Mais inutile d'aller en Iran ou en Turquie : on pourrait citer le cas de l'interdiction de TikTok en Nouvelle-Calédonie en 2024 lors des manifestations. C'est une décision administrative qui a ensuite été considérée illégale au regard du droit par le Conseil d'État. Mais il a fallu un an pour corriger le tir.

La réponse de Matthew Prince, CEO de Cloudflare

Changeons d'angle et prenons le temps de lire la réponse de Matthew Prince, CEO et cofondateur de Cloudflare, sur Twitter.

Le début, c'est ce qu'on vient de se dire : un rappel des faits avec une opposition entre la vision italienne (et globalement européenne) versus la vision technique défendue par Cloudflare qui ne veut pas s'occuper de ça.

Maintenant, le tweet ne s'arrête pas là. Et là, ça commence à déraper.

D'abord, Cloudflare mentionne ce qu'ils vont faire dans l'immédiat : ne plus assurer la sécurité des futurs jeux olympiques à Milan (ça se discute, c'était fourni gratuitement, quand tu te prends une amende d'1% de ton CA mondial tu peux te vexer), couper les accès gratuits de tous les utilisateurs en Italie (un peu disproportionné), virer tous les serveurs d'Italie (on sent l'énervement), ne pas installer de bureau sur place (celle-là m'a fait rire, on avait prévu mais finalement non, c'est pas une vraie menace).

Ce qu'il faut surtout noter c'est qu'on parle de mesures de rétorsions. On est dans le cas d'une entreprise US qui menace un état Européen.

Mais c'est le paragraphe suivant qui me titille :

"J'apprécie que JD Vance prenne un rôle de leadership et s'attaque à ce type de régulation qui constitue un problème fondamental d'injustice commerciale et qui menace également les valeurs démocratiques. Et dans ce cas, @ElonMusk a raison : la liberté d'expression (#FreeSpeech) est essentielle et est menacée par une cabale déconnectée de la réalité, composée de décideurs politiques européens très perturbés."

Et là, le débat change de nature. On n'est plus sur une question technique ou juridique. Quand le CEO de Cloudflare invoque JD Vance et Elon Musk pour parler de free speech, on entre dans autre chose.

Le free speech à géométrie variable

Il faut s'attarder sur l'ironie autour du free speech, parce que c'est l'argument massue souvent utilisé par le parti de Trump.

Je rappelle que Musk utilise allègrement la censure sur sa propre plateforme et qu'il a accepté sans aucune réserve de censurer l'opposition à Erdogan en Turquie en 2025 parce que ça servait son propre agenda.

Je pourrais aussi rappeler que l'administration actuelle de Vance mais aussi de Musk, puisqu'il en a fait partie, a censuré plus de 350 mots de toute communication officielle, dont les mots femme, changement climatique ou handicap.

Le free speech aux US, c'est aussi le licenciement de plusieurs personnalités notamment dans les médias pour ne pas être d'accord avec le gouvernement actuel.

Donc free speech, c'est un peu à géométrie variable. C'est une hypocrisie.

D'ailleurs, quand on creuse un peu, Cloudflare lui-même a fait de la censure en 2017 et en 2019 de son propre chef, sans aucune contrainte extérieure, dans les affaires Daily Stormer et 8chan. Donc le principe, ce n'est pas "on ne censure jamais", c'est "on censure quand nous on décide".

En fait, on peut mettre toute la novlangue possible et imaginable sur à peu près tous les sujets. Mais surtout, le free speech ici, c'est un argument de négociation commerciale habillé en principe démocratique.

Et ça pose une question qu'on ne peut plus ignorer : notre dépendance à ces infrastructures US, c'est aussi une dépendance à leurs agendas politiques.

Il n'y a pas de gentils

En bref, dans cette histoire, on peut tout autant remettre en question la légitimité de la méthode, c'est-à-dire le blocage par une autorité administrative sans décision judiciaire.

On peut émettre une réserve sur les dérives possibles et probables de ces outils.

Et pour autant, on peut reconnaître que ce n'est pas non plus très sain d'avoir des dépendances aussi fortes à des entreprises américaines qui peuvent menacer directement des États de ne pas se conformer au droit local, qu'il soit bien fait ou non, ET tout en ayant eux-mêmes leur propre agenda sur ce qui est acceptable ou non.

Il n'y a pas de gentils ici ou de méchants. On a des choses à surveiller sur l'usage généralisé du contrôle numérique par nos propres États. Mais on doit aussi ne pas tomber dans le piège de laisser d'autres pays décider à notre place.

Il ne faut pas se leurrer. Non, la technologie n'est pas neutre comme le prétend Matthew Prince. Et on voit bien que ceux qui contrôlent les tuyaux voudraient bien, eux aussi, décider de ce qui passe dedans. Et ce serait encore pire que de laisser cette décision à une autorité administrative, malgré toutes les critiques que je peux y faire.

Pour ma part j'ai pris les devants en imaginant que Cloudflare pourrait avoir les mêmes conflits avec la France. J'ai donc supprimé tout mes sites gérés sur Cloudflare et j'utilise désormais Bunny.net pour les mêmes services.

Sauf que Writizzy propose des thèmes et on souhaite facilement pouvoir personnaliser les composants pour chaque thème.

Dans cet article je souhaite vous montrer comment utiliser Nuxt-Mdc pour ce cas de figure relativement commun.

Nuxt-mdc

Le module nuxt-mdc est utilisé par nuxt content mais il est possible de l'utiliser directement pour interpréter du contenu markdown et l'afficher en HTML. C'est une brique fondamentale de Nuxt-Content mais heureusement exploitable en standalone.

Parmi les fonctionnalités de Nuxt-mdc, on peut utiliser des MDC components. Un MDC component est globalement un balisage markdown qui fera ensuite appel à un composant Vue pour l'affichage.

Par exemple avec ce markup :

::card
The content of the card
::

On va demander à Nuxt-mdc d'utiliser le composant Card pour rendre le bloc précédent.

C'est aussi ce qu'utilise Nuxt-mdc pour rendre tous les Prose components, qui correspondent aux composants customs : titres, liens, blockquote etc... créés suite au parsing markdown. En interne en effet, chaque balise standard de Markdown est transformée en MDC components, par exemple :

## un titre

est transformé en

::h2
un titre
::

(C'est une simplification. En réalité, c'est plutôt une substitution au niveau du renderer. Le renderer lit l'arbre AST qui contient un noeud h2 et décide d'utiliser le composant h2 pour le rendre. Mais on peut vulgariser comme ça)

Cette fonctionnalité permet à l'utilisateur de Nuxt-Mdc de customiser l'affichage de chaque MDC component, donc les Prose components aussi.

Pour surcharger un composant Prose ou pour proposer un composant custom, il suffit de les placer dans le répertoire app/components/mdc sur une application Nuxt.

Cependant, et si on souhaite que ces composants changent en fonction du thème sélectionné ? C'est exactement la question que je me suis posée pour Writizzy.

Un système de thème pour composants

Sur Writizzy je développe un système de thème. On peut choisir l'apparence de son blog parmi ceux listés ici : https://writizzy.com/docs/your-blog/themes. J'ai repris partiellement ce que j'avais déjà fait pour Bloggrify (un projet opensource pour créer des blogs statiques).

Mais avec Writizzy j'étais plutôt insatisfait de cette solution notamment pour les composants customs. C'est évident que l'apparence doit changer en fonction du thème.

Et il se trouve qu'il existe une fonctionnalité non documentée dans Nuxt-Mdc qui permet exactement de faire cela.

Par défaut, la documentation conseille d'utiliser le composant MDC pour afficher du markdown, par exemple :

<script setup lang="ts">
const md = `
::alert
Hello MDC
::
`
</script>

<template>
  <MDC :value="md" tag="article" />
</template>

Cependant MDC utilise lui-même MDCRenderer en arrière-plan. Et en regardant le code source de MDCRenderer, on note une propriété intéressante : components

Cette propriété permet de passer la liste des composants à utiliser. Par défaut, MDCRenderer va rechercher dans cette liste, et sinon dans components/mdc donc on peut surcharger les composants qu'on souhaite modifier :

<script setup lang='ts'>
const mdcComponents = {
  callout: TerminalCallout,
  blockquote: TerminalBlockquote,
  pre: TerminalCode
}
</script>
<template>
  <MDCRenderer 
    :body="ast.body" 
    :data="ast.data"
    :components="mdcComponents"
  />
</template>

Et voilà !

Désormais on peut personnaliser chaque composant en fonction du thème.

Cette approche fonctionne bien pour Writizzy et je compte l'appliquer aussi à Bloggrify. Si vous utilisez Nuxt-MDC avec un système de thèmes, c'est à mon avis la solution la plus propre — même si elle mériterait d'être documentée officiellement.

J'ai d'ailleurs ouvert une issue pour clarifier son statut. En attendant, ça fonctionne en production sur Writizzy sans souci.

Bien sûr, cela fait maintenant 4 ans qu'on parle d'IA jusqu'à l'écœurement, j'ai fait quelques posts et vidéos sur le sujet, mais l'évolution entre début 2025 et début 2026 est désormais flagrante.

Avec cette évolution vient une question majeure, quel est l'impact pour notre métier ? Comment le réinventer ?

Je vous propose une petite revue de presse pour aborder cette question.

L'ère des agents ?

Dans cet article, Simon Willison, co créateur de Django et Lanyrd, pointe le changement majeur de 2025 : l'année des agents.

Avec l'apparition fin 2024 des flows dans Windsurf et Claude Code en février 2025, tout a changé. Pour beaucoup, nous sommes passés de simple copier-coller entre le navigateur web et notre IDE à une délégation complète de l'activité de production de code.

2025, c'est aussi :

• la popularisation de l'expression vibe coding, qui continue de diviser entre incompréhension et mépris
• la normalisation des abonnements à 200$/mois
• les modèles conversationnels de génération d'image comme nano banana (auparavant on n'itérait pas, il fallait trouver le bon prompt du premier coup)
• le début des modèles de code locaux, que j'espère grandement voir se développer

Allez lire l'article de Simon, c'est beaucoup plus complet. Mais ce qu'il faut retenir c'est qu'avec ces agents, la nature même de notre métier a changé et c'est sans doute pas près de s'arrêter.

Un métier en mutation

Pour ceux, nombreux, qui continuent de ne pas utiliser l'IA, ou qui utilisent uniquement l'auto complétion basique dans l'IDE, le réveil risque d'être brutal. Le métier est en radical changement.

Je vous propose de lire cet article sur ce thème.

• "The Inevitable Evolution of the Developer Role" de Smaine Milianni

Smaine insiste sur l'évolution du rôle :

• from execution to direction
• from local optimizations to system-level thinking
• from writing instructions to defining intent

Et bien sûr que c'est inconfortable puisque ça relativise le prestige traditionnellement associé à l'écriture de code, en apparence.

When an LLM can generate boilerplate, implement well-scoped features, refactor safely, review code tirelessly… Then the act of typing code stops being the core differentiator, and that’s uncomfortable for many of us.

Je dis bien en apparence, car si le métier change, l'expertise/expérience reste un différenciateur important. Dans le flow actuel, je reste celui qui donne les directives, je corrige l'architecture, je définis le besoin et les problèmes à résoudre, les comportements attendus.

Mais comme le précise yoandev

l’IA exige une rigueur architecturale encore plus grande. Pourquoi ? Parce que l’IA est un amplificateur. Elle magnifie ce qui existe déjà. Si je lui donne une codebase spaghetti, elle va produire plus de spaghetti, plus vite. Si je lui donne une architecture propre avec des responsabilités claires, elle devient un assistant chirurgical redoutablement efficace. Le principe est simple : Garbage In, Garbage Out.

Maintenant il faut bien comprendre que ces nouvelles pratiques sont apparus en 2025, le terme même de vibe coding est apparu dans un tweet en février ! Donc aujourd'hui, l'une des questions importantes, c'est : "comment allons-nous industrialiser ces nouveaux usages et les rendre plus compatibles avec une production logicielle fiable ?"

Le temps de l'industrialisation

Si je simplifie, mon métier est désormais de concevoir et d'écrire ensuite ce que je veux voir apparaître dans mon application. C'est un métier de rédaction, puis de vérification. Je dois contrôler que l'architecture est correcte, que la sécurité et la performance ont été prises en compte, que le modèle est cohérent.

Une fonctionnalité avancée me prend entre 2 et 6h en fonction de la complexité et de mes crédits disponibles ^^ (non je ne paie pas 200/mois). Certaines fonctionnalités auraient pu me prendre 1 à 2 semaines de travail.

Pour Chris Loy, le software devient une commodité

Traditionally, software has been expensive to produce, with expense driven largely by the labour costs of a highly skilled and specialised workforce. This workforce has also constituted a bottleneck for the possible scale of production, making software a valuable commodity to produce effectively. Industrialisation of production, in any field, seeks to address both of these limitations at once, by using automation of processes to reduce the reliance on human labour, both lowering costs and also allowing greater scale and elasticity of production. Such changes relegate the human role to oversight, quality control, and optimisation of the industrial process.

Mais nous n'en sommes qu'au début et beaucoup se demandent justement comment fiabiliser ce qui est produit par les assistants de code, ce qui implique :

• d'optimiser le nombre de tokens nécessaires pour réduire les coûts
• de fiabiliser les sources documentaires utilisées par les IA
• de garantir la cohérence globale via l'usage de guidelines
• de garantir la conformité entre l'implémentation et la spec

Bref, industrialiser.

Vous retrouverez toutes ces questions dans l'article de Nicolas Martignole : L’IA générative va changer notre façon de coder (unpopular opinion)

Il y a quelques approches qui ont déjà émergé comme :

• BMAD qui propose tout un ensemble d'agents conversationnels pour simuler une équipe complète.
• SpecKit, un peu dans le même esprit mais en beaucoup plus simple.

Pour avoir essayé les deux, je ne m'y suis pas retrouvé. Effectivement BMAD permet de simuler une équipe complète. Mais ça m'a rappelé les travers des grandes boites. J'ai quadruplé mon temps de conception, j'ai explosé mon quota de crédits et la spécification produite était beaucoup trop verbeuse et complexe. J'ai eu l'impression de faire du SAFe avec moi-même. Et c'est pas une expérience que je recommande...

SpecKit est nettement plus simple, mais toujours trop verbeux à mon goût. Pour une simple fonctionnalité, il a créé une demi-douzaine de fichiers, des PRD, des specs fonctionnelles, des specs techniques etc... C'est sans doute ce qu'on veut dans un grand groupe industriel. C'est inadapté dans à peu près tous les autres contextes. Trop de doc tue la doc.

Ce serait dommage de réinventer un métier et de recréer immédiatement des bullshits jobs robotisés...

Maintenant puisqu'on parle de mutation, est-ce la fin des développeurs ou le renouveau ?

Fin ou renouveau ?

Cette question est revenue tellement au fil des années que ça en devient caricatural.
Jusqu'à présent, la conclusion a toujours été la même : non.

Parce qu'on a eu le fameux effet rebond qui fait qu'en simplifiant l'usage, on a eu plus de demandes de développeurs.

J'ai tendance à modérer cette conclusion qui devient trop automatique aujourd'hui et j'ai bien peur qu'on se conforte dans une de sorte de réflexe pavlovien. Oui la réponse a systématiquement été non mais je vous invite à réfléchir à cet article qui nous rappelle le parallèle entre les développeurs et les tisseurs de 1811 pendant la fameuse révolte des luddites.

Voici ce qu'on oublie souvent : pendant la première révolution industrielle en Angleterre, les salaires réels ont stagné pendant 40 ans alors que la productivité explosait. Quarante ans. Deux générations de travailleurs ont vu leur niveau de vie se dégrader pendant que les propriétaires d'usines s'enrichissaient.

Oui, il peut y avoir un effet rebond, mais ça peut prendre longtemps et ne pas forcément profiter à tous :

Le World Economic Forum note que chaque révolution industrielle a créé plus d'emplois qu'elle n'en a détruits. Mais (et c'est un gros mais) les personnes qui perdent leur emploi ne sont pas forcément celles qui en trouvent un nouveau.

Les recherches historiques montrent que pendant la deuxième révolution industrielle, les jeunes travailleurs s'adaptaient en changeant de métier vers les secteurs en croissance. Les travailleurs plus âgés, eux, restaient coincés dans des emplois dévalorisés ou basculaient vers des postes non qualifiés.

Ce qui est sûr, c'est qu'il semble désormais y avoir une inéluctabilité à ces changements comme le rappelle Salvatore Sanfilippo, le créateur de Redis

But, in general, it is now clear that for most projects, writing the code yourself is no longer sensible, if not to have fun. (...) you can't control it by refusing what is happening right now. Skipping AI is not going to help you or your career.

Même pour Linus Torvalds, la question ne se pose plus :

Is this much better than I could do by hand? Sure is.

On retrouve ce même constat chez Jaana Dogan (principal engineer chez Google)

I’m not joking and this isn’t funny. We have been trying to build distributed agent orchestrators at Google since last year. There are various options, not everyone is aligned, etc. I gave Claude Code a description of the problem, it generated what we built last year in an hour.

Vous pourrez retrouver cette citation dans un article de Pragmatic Engineer qui parle du même sujet When AI writes almost all code, what happens to software engineering?.

Je pourrais aussi vous citer Quentin Adam (CEO de Clever Cloud)

As developers, we should be careful not to turn healthy skepticism into outright rejection of innovation. History shows that many of the biggest leaps in our field came from tools or ideas that were initially dismissed as “dangerous”, “lazy”, or “not real engineering”.

Pour finir sur une note plus optimiste, j'ai aimé cet article de Mattias Geniar : Web development is fun again

There’s mental space for creativity in building software again.

Je me retrouve pas mal dans cet article. Construire une application est difficile, mais j'adore construire des produits. Désormais, je peux aller beaucoup plus loin, et plus rapidement. Je peux m'attarder sur ce qui compte vraiment et pas refaire les mêmes boilerplate encore et encore pendant 20 ans. Pour moi, c'est un accélérateur et ça change totalement la façon dont je crée du logiciel. Je passe plus de temps à réfléchir, concevoir, penser aux problèmes à résoudre et moins de temps à me prendre la tête sur des détails d'implémentations. Je produis du meilleur logiciel et oui, c'est fun.

Et maintenant ?

Difficile à dire ce que sera 2026 quand on voit à quelle vitesse tout a accéléré en 2025 d'autant qu'on peut difficilement mettre de côté ce qui se passe aussi dans le monde réel et les potentiels impacts que cela pourrait avoir sur nous. Il me parait improbable que l'on revienne en arrière sur l'usage de l'IA de façon volontaire, mais d'autres évènements extérieurs pourraient nous contrarier en Europe, si par exemple les US nous coupaient l'accès à certains services, ou s'ils les utilisaient pour de l'espionnage industriel à grande échelle.

Alors peut-être que ce sera l'année de la recherche d'optimisation pour faire tourner plus facilement, pour moins cher et moins énergivore, ces fameux agents sur des machines locales. Ce sera peut-être aussi l'année de l'industrialisation de l'usage des LLMs en entreprise, mais avec une séparation nette, entre des boites AI natives et les autres. Je ferai un article plus complet sur ce sujet précis dans le futur.

Quoi qu'il en soit, restez à l'écoute. Le métier change, vite.

Ok, la question n'est pas nouvelle et vous pourriez vous demander le rapport avec la discussion github ci-dessus. Discutons-en.

La demande était simple : ajouter un fichier llms.txt, destiné à rendre la documentation plus facilement consommable par les LLM.
La réponse l’était tout autant : refus, pour des raisons économiques.

Mais quel rapport entre les deux ?

Moins de trafic = moins d’argent

Le raisonnement est en réalité très simple et est expliqué par Adam Wathan (créateur de Tailwind):

Traffic to our docs is down about 40% from early 2023 despite Tailwind being more popular than ever. The docs are the only way people find out about our commercial products, and without customers we can't afford to maintain the framework.

La documentation est aujourd’hui le principal canal marketing des produits commerciaux de Tailwind (sponsoring, Tailwind Plus, etc.).
Or, depuis 2023, le trafic vers ces docs a chuté de manière significative, alors même que Tailwind n’a jamais été aussi populaire.

L'équation est donc simple :

• moins de trafic
• moins de conversions
• près de 80 % de revenus en moins
• et, très concrètement, 75 % de l’équipe licenciée

Dans ce contexte, simplifier l’accès des LLM à la documentation revient à accélérer la fuite de la seule source de revenus.

D’un point de vue purement économique, la décision se comprend et ce n'est pas anti IA, c'est simplement une réalité économique comme le précise Adam :

Right now there's just no correlation between making Tailwind easier to use and making development of the framework more sustainable. I need to fix that before making Tailwind easier to use benefits anyone, because if I can't fix that this project is going to become unmaintained abandonware when there is no one left employed to work on it. I appreciate the sentiment and agree in spirit, it's just more complicated than that in reality right now.

Freiner l’intégration LLM : solution ou stratégie défensive ?

La vraie question n’est pas “est-ce justifié ?”, mais plutôt :

Est-ce viable à moyen terme ?

Et selon moi, probablement pas. Les usages ont changé, les développeurs ne lisent plus systématiquement les docs. Ils interrogent ChatGPT, Copilot, Cursor ou Claude. La documentation est consommée indirectement.

Nier cette réalité c'est prendre plusieurs risques :

• des implémentations approximatives générées par les LLM
• des concurrents plus “IA-native” mis en avant
• une perte progressive de pertinence, malgré une adoption apparente

Autrement dit, protéger le trafic aujourd’hui peut coûter la pertinence demain.

Un problème plus large que Tailwind

Ce débat dépasse largement Tailwind.

J'utilise beaucoup Nuxt, j'adore ce framework et il me semble qu'ils ont connu des soucis similaires avec Nuxt UI ou Nuxt Studio.
Je prends Nuxt comme exemple, mais le problème est généralisable.

Depuis le rachat par Vercel, ces projets ont fini par devenir complètement open source et quelque chose me dit que l'adoption de Nuxt-UI a explosé.

En fait, et surtout avec l'IA, le traditionnel dilemme build vs buy est complètement bouleversé. Il est plus simple de prototyper rapidement, donc la valeur perçue des outils baisse et la monétisation devient plus difficile.

Attention, je ne dis pas que Nuxt, Tailwind Plus ou Nuxt-UI sont aisèment reproductibles avec l'IA. Il y a aussi la vision de leurs créateurs qui en font des outils uniques. C'est aussi parce que ce sont des outils open source que les feedbacks sont plus nombreux et que ces outils s'améliorent continuellement.

Mais beaucoup de développeurs pourraient être tentés de ne pas acheter la petite partie payante d'un projet open source sous prétexte que c'est beaucoup plus accessible qu'avant de le faire soit-même. Bref, c'est dur de vendre des modules additionnels sur des projets open source, et pour le coup c'est pas un scoop, on le savait déjà.

Dans ce contexte, le rachat de Nuxt par Vercel peut se lire comme une manière d'avoir de l'air, de sécuriser le développement. Mais c'est aussi une externalisation du problème avec un coût évident, une perte de contrôle et un risque de sous-investissement à long terme.

Ce n’est pas une solution structurelle, c’est un compromis.

Pour en revenir au sujet, une hypothèse se dessine de plus en plus clairement : La documentation ne sera plus un canal marketing humain.

Elle sera lue par des machines, résumée, transformée, injectée dans des prompts. Refuser cette évolution est un risque en soi.
Mais l’accepter sans modèle économique en est un autre.

Quelles pistes possibles ?

J'essaie d'y réfléchir et je vois plusieurs directions intéressantes. La question n’est plus comment faire venir les développeurs sur le site ? mais plutôt comment être présent là où ils codent réellement ?

On va commencer par une piste, celle qui me séduit le moins :

• Docs consommables via API

On pourrait imaginer que le fichier llms.txt soit proposé sur une API payante ou semi payante :

• avec rate limiting
• potentiellement réservée aux clients ou sponsors

C'est techniquement faisable, mais j'imagine pas chaque développeur prendre un abonnement pour chaque fichier llms.txt existants.

Maintenant je vois une seconde piste plus intéressante, et si on déplacait le marketing au plus près des utilisateurs ?

EDIT : Quelqu'un vient de m'informer de l'existence d'un nouveau protocole actuellement testé par Cloudflare en version bêta : pay per crawl.

Sur le papier, cela pourrait être intéressant. L'idée est de déclencher un échange entre le robot d'indexation et Cloudflare afin de facturer à une IA des frais pour l'indexation d'une page donnée.

Si cela devenait la norme, si le coût par requête était très faible (par exemple, 0,00001 $ par appel) et si les agents IA étaient capables d'intégrer cela dans leurs propres modèles de tarification pour les utilisateurs finaux, alors cela pourrait potentiellement fonctionner et fournir une nouvelle source de financement pour les projets open source.

Cela fait beaucoup de « si », mais pourquoi pas.

• MCP / serveur IA officiel

Imaginons que Tailwind propose sa ressource MCP officielle mais avec des instructions pour que les agents IA mentionnent obligatoirement les produits payants au bon moment.

Ca peut être sous forme de bannière affichée régulièrement dans la console pour inciter à la visite du site ou signaler les produits payants. Ca pourrait être aussi pour signaler à l'utilisateur qu'il est en train de refaire quelque chose qui existe déjà dans la version payante, par exemple dans Tailwind Plus.

L'idée c'est pas de créer une bannière intrusive, mais qui s'affiche au bon moment, avec le bon message.

EDIT : Vous pouvez également créer un serveur MCP payant qui sera très utile pour votre produit. C'est l'approche adoptée par DaisyUI. Ce serveur MCP comprend divers outils qui vont au-delà de la simple connaissance de la documentation, avec des bonnes pratiques, des outils de migration et des modèles.

Plus j'y pense et plus je considère que le vrai déplacement à opérer est là, ne plus chercher la monétisation uniquement dans le navigateur mais dans l’outil où le développeur travaille réellement

Aujourd’hui, c’est le prompt. Et quelque chose me dit que ce problème est généralisable aux moteurs de recherche qui se font également bypasser de plus en plus mais c'est une autre histoire. Ce qui est sûr, c'est que je ne serais pas étonné d'avoir des placements de produits dans le futur dans les LLMs.

Bref, le problème n’est pas l’IA. Le problème, c’est que le modèle économique de l’open source reposait sur un monde qui n’existe plus et si l’usage a quitté le navigateur pour le prompt, la monétisation devra suivre.