Mais est-ce que ça ne cacherait pas quelque chose ? Est-ce que ce ne serait pas encore un coup marketing pour continuer à alimenter la hype du secteur ? Ou bien est-ce que ce serait une sorte de mouvement désespéré pour verrouiller le marché et sortir d’une situation financière compliquée ?

La lettre de Dario

Tout part de la lettre de Dario Amodei publiée il y a quelques jours : “we must pace the frontier”.
(Dario Amodei est l’actuel CEO de Anthropic qui édite Claude)

Dans cette lettre, Dario appelle à réguler/ralentir/sécuriser le développement de l’IA. Il met en avant les récents incidents autour de l’attaque cyber de Hugging Face et l’emballement lié à l’accélération du développement avec des modèles qui s’auto améliorent.

Il propose donc plusieurs mesures :

• la mise en place d’organismes d’audit et de contrôle
• une mise en place de normes de sécurité et de développement des modèles
• une coordination internationale pour réguler à l’échelle internationale

Dans la foulée, Sam Altman (OpenAI) et Elon Musk (xAI) ont tout deux validé la demande sur les réseaux sociaux, ce qui déjà en soit constitue une énorme surprise, les 3 n’étant pas spécialement du genre à passer des vacances ensemble.

Mais il faut sans doute lire entre les lignes.

Une période Pré IPO et un modèle bancal

Petit rappel de contexte, OpenAI et Anthropic prévoient une entrée en bourse prochaine. Les deux entreprises sont loin d’être rentables et dépensent des milliards en entrainement de modèle ou en cout d’inférence. Pour gagner, ou conserver, des parts de marché, les deux géants cassent les prix et sponsorisent le cout du token à perte. Mais entre investissements gigantesques et constant, et concurrence en hausse, notamment par les modèles chinois, le modèle économique semble très bancal et pourrait bien refroidir les investisseurs boursiers.

On assiste a une véritable course à l’armement, dans une industrie largement en surchauffe, dans laquelle le premier qui ralentit perd. Mais surtout, dans laquelle le niveau des investissements déjà réalisées ne permet pas de ralentir. Ce serait compliqué pour les investisseurs d’accepter que d’un coup les performances des modèles stagnent. Les plans d’investissements incluent des constructions de datacenter, des achats de composants électroniques, de la capacité électrique etc… Annoncer ralentir aujourd’hui, ce serait un gros coup pour de nombreux acteurs, mais aussi un signe négatif à envoyer pré IPO.

Sauf que accélérer pour foncer dans le mur avec un modèle économique qui ne tient pas la route, c’est pas non plus un scénario séduisant.

Alors peut-être que cette lettre serait un moyen de créer une porte de sortie.

Un marketing de la peur permanent

La lettre de Dario s’inscrit dans une stratégie marketing qui a déjà fait ses preuves. Rappelez vous des précédents :

• En 2023, une lettre ouverte avait déjà été publié pour ralentir, déjà signé par Elon Musk
• En 2023 toujours, la déclaration sur le risque d’extinction signé par Sam Altman et Dario Amodei
• En 2024, des déclarations de chercheurs OpenAI sur le risque de sécurité et de gouvernance
• En 2026, les déclarations de Jacob Coxon (Anthropic)

Je pourrais faire une liste encore très longue et même remonter à la première déclaration de Musk en 2014.

Il est bien évident que certaines personnes dans cette liste peuvent être sincère sur ces déclarations mais j’ai du mal à ne pas y voir une certaine forme de mise en scène marketing.

Mettre en avant qu’une technologie est un risque existentiel pour l’humanité, notamment si elle tombe entre de mauvaises mains ou si elle est conçus sans garde fous, ça permet deux choses :

• de mettre en valeur qu’on travaille sur une technologie surpuissante et qui méritent qu’on y investisse ou qu’on l’achète
• d’appeler à réguler les nouveaux acteur en verrouillant le marché

La lettre de Dario sur laquelle beaucoup d’experts débattent depuis 1 semaine n’est rien de plus que le prolongement de ce marketing. Mais on commence quand même à y voir quelques nouveautés.

Un appel à la régulation pour freiner la concurrence ?

Dans le texte, le CEO d’Anthropic vise explicitement l’interdiction des acteurs qui font de la distillation :

Crack down on unauthorized ++distillation++ by companies in authoritarian countries. Distillation of frontier models allows lagging companies to narrow the gap using a fraction of the cost it would take to develop their own AI independently.

La distillation permet en effet d’entrainer un modèle à partir d’un modèle frontière en économisant sur les couts.

On retrouve également :

• un appel à limiter la vente des puces les plus puissantes à la Chine (mais plus globalement aux concurrents non US)
• différences indices dans le texte qui vise à freiner/bloquer les modèles open weight (renforcement des méthodes d’audit, incompatibilité avec la notion de checkpoint de certification)

Donc à votre avis, qui serait pénalisé par une régulation sur l’IA telle qu’elle est demandé par Amodei ?

• Les acteurs Chinois qui utilisent massivement la distillation pour proposer des modèles concurrents à une fraction du prix
• L’open source et la recherche qui s’appuie sur les modèles open weight et qui de toute façon n’aura pas les moyens de mise en place des mécanismes d’audit, sans parler que les organismes de certifications ne seront pas forcément si indépendant que ça
• Mistral, qui ne pourrait plus exploiter des modèles en open weight dans ces infrastructures et devrait aussi mettre en place des mécanismes de certification sans doute très couteux et piloté par les US
• Les nouveaux entrants pour lesquels le ticket d’entrée sera trop fort
• Les hébergeurs qui vendent du calcul sur des modèles open weight

Bref, ce serait un coup dur pour l’open source, l’Europe et sa souveraineté, et les entreprises avec à la clé la création d’un oligopole capable de fixer les prix beaucoup plus facilement.

Des oppositions importantes

On pourrait penser qu’avec des bénéfices aussi forts, toute l’industrie américaine serait derrière ce projet. Eh bien, surprenamment, pas tant que ça.

Si on peut reprocher à Amodei, Altman et Musk de cacher leurs ambitions de créer un oligopole et de verrouiller le marché, il n’en reste pas moins que l’objectif affiché reste d’encadrer les risques de l’IA, en imposant une régulation mondiale, certes, mais enrobé d’un beau papier cadeau.

Mais ce n’est pas du tout l’approche des “accélérationistes”, notamment représenté par Peter Thiel et Alex Karp (Palantir) qui souhaite au contraire une dérégulation totale du marché et dont la priorité absolue est de battre la Chine.

Sans surprise on va retrouver ce même discours chez Trump (on peut rappeler que JD Vance a été présenté à Trump par Thiel), qui nous a pondu des déclarations aussi lunaire que d’habitude et dont je vous laisse apprécier la teneur :

Le seul garde-fou dont l'IA a besoin, c'est un PRÉSIDENT FORT ET INTELLIGENT (à QI élevé !), et les États-Unis en sont pourvus, et même plus ! L'administration Trump a empêché les spécialistes de l'IA de commettre des actes malveillants, ou potentiellement malveillants, comme Dario (anthropic !), qui se fait maintenant passer pour un « petit ange parfait » – et nous continuerons sur cette voie ! Nous disposons déjà d'un pouvoir considérable, tant pénal que réglementaire, sur ces entreprises ! Un complot sordide se trame contre l'IA et les centres de données, et la seule à s'en réjouir est la Chine. Celui qui domine l'IA gagne ! Nous sommes en tête face à la Chine et à tous les autres, et nous le resterons. Théoriciens du complot, traîtres, et fuiteurs, prenez garde ! Merci de votre attention ! Président DONALD J. TRUMP

Heureusement qu’il est là, le spectacle est toujours garanti…

Mais on retrouve aussi cette opposition chez Jensen Huang (CEO Nvidia) qui, rappelons-le, vient d’acheter Hugging Face pour 13 milliards de dollars et qui vient d’investir chez Mistral. L’entreprise vend des puces et de la capacité de calcul à tout le monde et voit dans l’open source une opportunité, au moins business en tout cas, alors le ralentissement demandé par Amodei est loin d’être sa priorité.

Et l’Europe ?

Le simple fait que Trump soit opposé au projet de ralentissement enterre ce projet à minima le temps de son mandat aux US. On peut difficilement imaginer un ralentissement d’ici 2028, en tout cas pas pour ces raisons là. Et même à l’avenir, il me semble incertain d’envisager que les USA acceptent de voir passer la Chine devant sans réagir.

Côté Europe, la discussion risque au contraire de laisser des traces. Elle donne du grain à moudre pour les régulateurs de l’UE qui verraient bien la mise en place de normes plus contraignantes, et pour certains gouvernements qui aimeraient bien prendre la main. Sans parler de certains politiques qui sont un peu perdus face aux enjeux et pourraient jouer contre leur camp sans même le comprendre.

Ces hésitations risquent de nous mettre en mauvaise posture si jamais nous rajoutions des barrières sur le monde open source, sur les modèles open weights ou nos champions locaux.

Bref, cet appel à ralentissement me paraît surtout une manœuvre pour s’assurer un peu de stabilité sur un marché qui s’est emballé. Si les auteurs étaient vraiment sincères sur les soucis d’alignement des modèles, s’ils étaient inquiets sur les risques d’échappement d’IA, ils ont déjà les moyens de travailler sur le problème.
Le vrai risque existentiel aujourd’hui porte surtout sur leurs futures IPO, une concurrence qui monte et un marché européen qui pourrait choisir une autre voix avec des modèles open weights.
Il parait de toute façon peu probable que la Chine souscrive à cet appel, pas plus que l’administration Trump et j’espère que l’Europe ne cédera pas à la tentation de renforcer des législations au prix de notre souveraineté future.

Github c’est bien plus qu’un repository git, c’est aussi

• un réseau social où le monde de l’open source se bat pour des étoiles
• une usine logicielle (les Github Actions)

Et si on parle de chiffre, Github c’est 180M de développeurs inscrits, une part de marché estimée au dessus des 50%, Gitlab (US) et Bitbucket (US-AU) se partageant une grosse part du reste.

Bref, si vous êtes développeurs, vous avez sans doute un compte dessus, pour faire des forks de produits open source, pour vos propres projets ou ceux de votre entreprise. L’économie mondiale du logiciel repose en partie sur cet acteur US, ce qui pose quelques questions. Que se passe-t-il quand votre économie logicielle repose sur un acteur étranger s’il devient hostile ?

• En 2019, les développeurs résidant en Iran, en Syrie, à Cuba, en Corée du Nord et en Crimée ont vu l'accès à leurs dépôts de code privés ainsi qu'à leurs comptes payants totalement bloqué.
• En 2025, 20 000 dépots Github privés ont été indexés par le moteur de recherche Bing et accessibles pour l’IA Microsoft Copilot.

Et globalement Microsoft/Github est soumis au Cloud Act et la FISA, ce qui lui impose de fournir toute ces données à l’administration américaine en cas de demande, notamment pour atteinte à la sécurité nationale, ce qui intègre la protection des intérêts économiques des Etats-Unis.
Si je traduis en termes plus simples, vous n’avez pas de garantie que votre code soit protégé si jamais l’administration US le décide.

Heureusement, il existe des alternatives en Europe, et c’est de ça dont on va parler aujourd’hui.

Le self host

La première option, c’est d’héberger des solutions open source. Dans cette catégorie on va retrouver beaucoup de solutions à base de gitlab et gitea.

Mais qui dit open source ne signifie pas neutralité. Ces deux entreprises sont US et peuvent changer leurs termes d’utilisation ou embarquer du code hostile qui se déclenche selon une géolocalisation. Ca empêche pas les forks, mais il faut réussir ensuite à créer une communauté de développeurs pour la maintenir. J’écarte donc ces choix.

Pour Gitea cependant, il existe déjà un fork Européen : Forgejo maintenu par l’organisation non-profit Codeberg.

Forgejo c’est notamment ce qui a été choisi par l’administration néérlandaise pour héberger le code source des administrations publiques.

Si vous êtes partisan du self hosting, Forgejo est à priori la seule solution disponible. Cependant le self hosting vient avec ces propres inconvénients, la maintenance et la gestion d’une infrastructure. Donc je vous propose de voir les solutions hébergées.

Les solutions hébergées

Sur le marché des solutions hébergées on va retrouver des produits à base de Forgejo justement, dont la solution la plus évidente est codeberg.org. Mais c’est une solution réservé aux projets open source donc pas du tout adapté à vos besoins entreprises si vous en avez.

On pourrait également citer tangled.org, excellent projet né en Finlande, un de mes coups de cœur, qui s’appuie sur le protocole ATProto. Le projet est uniquement fait pour l’open source aujourd’hui et inclut une dimension sociale par défaut. Mais peut-être que l’arrivée des spaces dans ATProto le rendra utilisable plus tard pour du projet privé. Cependant en l’état, pour du projet entreprise, je ne peux pas le conseiller.

J’écarte totalement toutes les solutions à base de Gitlab managé, c’est de très bonnes solutions mais ça ne satisfait pas l’idée de trouver une solution Européenne.
Par contre sur du Forgejo managé on peut citer :

• ++Codebahn++ (Suède)
• ++Codey++ (Suisse)

EDIT : On m’a aussi signalé radicle.dev, basé sur un protocole P2P et sourcehut.org que je ne connaissais pas. Je n’ai pas pu tester mais ça semble intéressant.

En dehors de ça on peut trouver deux solutions qui viennent d’émerger et qui ne sont pas basées sur Forgejo :

• pushin.eu
• rickub.com

Les deux sont en beta avec wait list ou en invite only mais j’ai eu la chance de tester rickub qui est en train de devenir ma plateforme de développement pour Writizzy et Hakanai.

Test de Rickub.com

(Premier jeu, je vous laisse trouver la référence qui se cache derrière le nom)

Comparaison

Rickub se veut comme un remplacement de Github. On va retrouver la majorité de ce qui nous intéresse dessus, les repos privés et publics, la CLI, un MCP, les Rickub action (compatible en grande partie avec les Github actions).

Sous le capot, Rickub utilise des MicroVM pour la CI, ce qui est censé garantir un temps de démarrage plus court, une meilleure isolation et des execution plus rapide. Ce qu’on peut vérifier sur le build de l’api Hakanai (3min vs 7min sur github) :

::gallery{columns=3} ::

En terme d’interface on retrouve assez facilement ses repères puisque ça reprend les habitudes qu’on peut avoir sur Github.

Côté migration, la démarche a été assez simple. J’ai créé un fichier .rickub/workflows/deploy-api.yml. C’est le même format que Github action mais avec quelques subtilités qui sont décrites dans la doc des CI/Actions et dans la doc de migration.

Un point qui m’a particulièrement plu, c’est que les rapports de test sont natifs sans avoir besoin de passer par un plugin externe.

Et ça mine de rien, c’est vraiment appréciable. J’adorerais dans le futur avoir une dimension historique pour savoir depuis quel build un test échoue ou si certains temps d’execution augmente, s’il y a des tests flaky etc… Mais chaque chose en son temps, le produit vient juste de sortir.

Tarification

Côté tarification, on trouve un plan gratuit qui permet d’avoir 5 repos privés, 500 minutes de CI et 50 AI reviews (je n’ai pas utilisé cette feature).

C’est très bien pour beaucoup d’usage personnels. C’est un peu moins généreux que Github qui propose des repos privés illimités et 2000 minutes de CI. Mais pour la CI, je dirais que l’écart doit se mesurer en sachant que la CI de Rickub est plus rapide. 500 min pour du side project, ca suffit amplement.

Ensuite vous avez des plans payants. J’ai choisi le plan à 3€/mois pour bénéficier de 3000 minutes de CI, largement plus que ce que j’ai besoin, et la pour le coup c’est légèrement moins cher que sur Github qui facture l’équivalent de 3.50 euros/mois (4 dollars).

Dans tout les cas, je m’en fiche un peu, cette somme est relativement indolore dans mon cas, et ici j’achète le fait de ne plus être le produit comme sur Github, et de privilégier des produits EU. Oui, la tech a un prix, certains produits nous ont habitué à la gratuité en s’accaparant nos données, et en créant un monopole. 3€, je les paie sans problèmes pour sortir de ça.

Les repos open source

J’ai migré partiellement pour Bloggrify mais pour le coup, la décision finale de migrer totalement n’est pas encore prise.

Github c’est aussi, et même principalement, un réseau social. Un projet opensource sur Github a plus de facilité parce que la majorité des gens y ont un compte, donc ils peuvent contribuer facilement. La plupart des évaluations de projet open source se fait sur le nombre d’étoiles, étoiles qu’on retrouve sur des agrégateurs.

Par exemple la position de Bloggrify sur jamstack.org dépend du nombre d’étoiles sur Github.

De la même façon, il y a y des robots qui parcourent Github pour lire les projets relatifs à un tag donné, c’est comme ça que Bloggrify a été référencé par certains sites dans le passé.

Donc déjà sur cette dimension, c’est compliqué de se passer de Github. J’ai donc laissé une réplication miroir entre les deux mais je suis pas sûr que ce soit très cool de gérer des issues et des PR sur deux systèmes en même temps.

Mais en plus de ça, pour l’instant, rickub ne gère pas les OIDC id-tokens qui permettent de publier des packages sur NPM**,** ce qui m’empêche d’automatiser mes releases Bloggrify sur NPM.

Conclusion

Bilan des courses, je migre sans aucun regret pour Hakanai et Writizzy. C’est sans doute moins évident pour les projets open source. Pour un usage pro/entreprise, je considère que Rickub est très prometteur et mérite fortement qu’on s’y intéresse. J’imagine que tout n’est pas encore parfait mais c’est justement avec de l’usage que le produit s’améliorera.

Et si vous êtes en Europe et que vous utilisez encore des produits US, c’est le moment de commencer à réfléchir aux portes de sorties avant que ce soit trop tard…

Mais c’est loin d’être “juste” un clone, Bluesky est né dans les projets de recherche au sein de Twitter. C’est littéralement l’évolution qu’aurait du suivre Twitter si la société n’avait pas été racheté par Elon Musk en 2021.

Pour tout vous dire, c’est Jack Dorsey (alors CEO de Twitter) qui en fait l’annonce en 2019. C’est ensuite Parag Agrawal qui prend la tête le projet avant de devenir CEO de Twitter.

Bref, c’était un projet clé de Twitter qui visait à décentraliser les réseaux sociaux.
L’idée de la décentralisation était de trouver une solution à tout ce qui a tué Twitter, la concentration d’un pouvoir trop grand aux mains d’une seule entreprise.
Bluesky voulait que tout soit transparent et ouvert afin d’éviter toutes les dérives qu’on peut constater sur X avec son algo largement biaisé pour servir des intérêts personnels ne puisse se reproduire.
La modération, les recommandations, l’hébergement, tout peut être délégué à d’autres, donc chaque utilisateur peut, en théorie, choisir ce qu’il voit, où sont hébergés ces données et ce qu’on lui recommande.

Mais cet idéal comporte quand même des failles. Et c’est de ça dont j’aimerais parler aujourd’hui.

Réseaux décentralisés et fédérés

Bluesky n’est pas le premier à proposer un réseau décentralisé.

Mais si on parle de réseaux sociaux, au sens plus moderne du terme, je dirais que l’un des premiers c’est d’abord les newsgroup qui fonctionnaient sur usenet. Si c’est apparu en 1979, je l’ai pour ma part utilisé bien plus tard, pendant mes études (entre 1997 et 2001). Faut dire qu’en 1979 j’étais plus intéressé par apprendre à mettre correctement ma nourriture dans ma bouche qu’à parcourir les serveurs universitaires américains.

Ah oui d’ailleurs, puisque je parlais de mes études, c’est dans la même période que j’ai commencé à faire du fansub, du sous titrage amateur d’anime japonais, et c’est la que j’ai découvert d’autres réseaux sociaux décentralisés comme IRC, ou Direct Connect. Sachant qu’une partie du téléchargement, illégal, des animes sous titrés se faisait via les newsgroup justement. La boucle était bouclée.

Mais pour ces réseaux la, on ne parle pas vraiment de réseaux fédérés. C’est à dire que si vous étiez présent sur un channel IRC, vous ne pouviez pas voir ce qui se passait sur un autre channel IRC, et pareil dans Direct Connect.

Les premiers réseaux sociaux fédérés sont apparus vers 2008 avec Laconica/StatusNet puis Diaspora en 2010. Mais là je n’ai aucune anecdote personnelle à raconter sur ces réseaux parce que, je ne sais pas pourquoi, mais je suis totalement passé à côté quand ils sont sortis.

Pour autant, il y a plein de choses intéressantes à dire sur ces deux réseaux. A l’origine Laconica/StatusNet c’est une sorte de refuge de la communauté du libre face à Twitter et d’ailleurs les premières versions de Mastodon tournaient sur le protocole OStatus, lui même héritage direct du travail fait sur StatusNet. Donc on peut parler de filiation entre StatusNet et ActivityPub/Mastodon.

Quand à Diaspora, c’est un peu moins joyeux. Si le projet démarre bien avec une campagne kickstarter réussi de 200 000$ visant à faire un facebook décentralisé, l’un des fondateurs, Ilya Zhitomirskiy se donnera la mort à seulement 22 ans ce qui donnera un sérieux coup de frein au projet initial. Le réseau diaspora s’illustrera ensuite en 2014 pour avoir été le refuge numérique de l’état Islamique. La nature même du réseau empêchait toute action centrale pour lutter contre le contenu créé par Daesh, ce qui a mis en lumière une partie des défis des réseaux fédérés et ce qui a eu des conséquences sur la conception de Bluesky par la suite.

Il faut attendre 2016 pour voir une nouvelle initiative apparaître avec Mastodon puis le protocole ActivityPub en 2018.
Le réseau a connu un certain succès avec 15M d’utilisateurs (mais seulement 1M d’actifs mensuels) mais il s’est confronté à plusieurs problèmes de conception :

• une certaine forme de complexité à l’inscription (le choix d’un serveur)
• l’identité qui est lié au serveur et qui rend difficile le déplacement

S’inscrire c’est déjà faire un choix puisque le serveur peut décider avec qui il se fédère ou pas, ces règles internes de modération et si le serveur ferme du jour au lendemain, votre compte meurt avec lui.

Le fait même qu’un serveur puisse être autonome sur tout, modération, autorisation de partir etc… a fait dire à plusieurs personnes que nous avions un royaume contre une fédération de fiefs seigneuriaux.

Et c’est là qu’est arrivé Bluesky avec son protocole ATProto en 2019.

Bluesky n’est pas ATProto

Bluesky c’est le porte étendard mais Bluesky c’est uniquement une implémentation d’un protocole.
Avec ce protocole, ATProto, il y a un objectif : c’est que n’importe qui puisse refaire une application comme Bluesky, proposer de l’hébergement de vos données sur un serveur (un PDS), enrichir le protocole pour ajouter de nouveaux types d’applications. Refaire Facebook, linkedin, instagram, tout devient possible, avec la même base d’utilisateur.

En pratique on a longtemps pointé du doigt que à part Bluesky, il ne semblait rien exister d’autres. Mais ça, c’était avant. Bluesky cohabite désormais avec Eurosky, Graysky ou Blacksky pour le microblogging et avec de nombreuses autres applications comme Tangled, Sifa.id, flashes etc…

Et pour répondre aux questions de la modération qui ont été soulevé par Diaspora, un utilisateur peut désormais choisir ces services de modérations et une application comme Bluesky peut aussi masquer du contenu.

Ca permet de répondre rapidement à du contenu qui n’aurait pas sa place sur le réseau mais c’est suffisamment souple pour vous permettre de le consulter sur votre propre AppView si jamais vous le souhaitiez.

Quand aux problèmes soulevé par Mastodon, autour de la portabilité d’identité, et le risque de choisir un serveur qui modifie ces règles en cours de route ou décide de ne pas se fédérer avec des serveurs qui vous intéressent, et eh bien tout cela est également résolu. L’identité n’est pas lié au serveur mais à un annuaire et toutes les fonctionnalités (modération, feeds etc…) sont portables d’une AppView à l’autre.

Maintenant que je vous ai un peu vendus le protocole, il faut que je reboucle avec mon sujet de départ. Pourquoi l’une de ses plus grandes forces est aussi un risque pour vous ?

La transparence par défaut

Sur le réseau ATProto, tout est public. C’est à dire que vous pouvez consulter l’intégralité du réseau, connaitre le nombre d’utilisateurs, les actifs, faire des études de réseau pour observer la diffusion d’une idée bien précise, créer de l’outillage pour identifier les réseaux de comptes suspects.

C’est une énorme force et l’un des principals griefs reprochés à X depuis qu’ils ont fermé leurs Apis. Or, en Europe, X avait une obligation légale d'accès aux données pour fournir aux chercheurs agréés afin de lutter contre la désinformation. Musk ayant un certain intérêt qu’on ne puisse pas étudier les biais algorithmiques sur sa plateforme, il est désormais en conflit avec les autorités Européennes sur le sujet.

Mais ça, c’est impossible sur ATProto. Sauf que cette force se révèle aussi un vrai problème pour vous.

Vous avez peut être vu le nouvel onglet “news” dans mu.social (un client alternative à bluesky) ? Dedans vous pouvez indiquer vos préférences en termes d’infos :

Et vous pouvez également sélectionner des journaux à suivre :

Mais notez la dernière remarque :

I understand my topic and source selections will be published as a public record linked to my account, and agree to share them.

Tout est publique.

Mais en réalité, ça vaut pour tout. Tous mes likes sont publics, toutes les personnes que je suis, toutes les personnes que je bloque.

Mais ça va au delà de ca. Je vous invite à regarder les données de mon PDS.

Vous avez ici plein d’informations :

• j’ai un profil sur sifa.id
• j’ai “endorsed” des gens sur sifa.id et vous pouvez savoir qui
• j’ai une publication sur offprint (une alternative à Writizzy que j’ai voulu tester)
• j’ai publié writizzy sur atstore
• j’ai une publication sur Writizzy (ce blog)

Bref, toute mon activité lié à mon handle @eventuallycoding.com est disponible publiquement sur mon PDS.

Et ça, mine de rien, c’est un problème.

Vous n’avez pas besoin de savoir à qui je suis abonné sur standard-reader, et donc ce que je lis. De la même façon que vous n’avez pas besoin de connaitre mes orientations politiques, sexuelles ou religieuses.

L’intérêt de la décentralisation c’est, en partie, d’éviter de donner à une seule entreprise trop d’informations sur moi en croisant toutes mes données. Avec mon usage d’ATProto, je viens de donner ce croisement gratuitement.

Imaginez un forum propulsé par atproto sur lequel je viendrais parler de problèmes personnels, une addiction, une situation familiale compliquée. Vous ne devriez pas le savoir.

Bref, j’aime beaucoup le potentiel de Atproto. Par exemple, j’avoue avoir été séduit dans un premier temps quand j’ai construit mon profil sur sifa.id : https://sifa.id/p/eventuallycoding.com, une sorte de néo Linkedin. Bon déjà, techniquement c’est super intéressant d’une part et ça séduit le geek en moi mais c’est secondaire pour le grand public.
L’autre point c’est que je trouvais ça puissant de voir que sifa.id aggrégait automatiquement mes posts bluesky, mes contributions tangled, ou mes articles de blogs.

Mais en y réfléchissant bien, il y a un risque. J’ai pas forcément envie de voir mes photos de vacances posté sur flashes/instagram ou des posts sur les forums que j’évoquais plus haut arriver au même endroit.

Bref, la transparence oui, mais jusqu’à un certain point.

Et si l’information devenait privée ?

Pour l’instant, atproto n’a pas de notion de donnée privée. Mais ça pourrait changer. Une nouvelle fonctionnalité est en cours de déploiement avec les Spaces Atproto.

Sur le papier, ça semble prometteur. Cela permettra d’avoir des informations privées sur lesquelles je pourrais décider qui a accès. Les cas d’usages qu’on peut imaginer rapidement :

• des forums avec des sections privées réservées à des membres
• des messages privées natifs sur bluesky (actuellement les messages privées ne sont pas stockées sur Atproto)
• du contenu réservé aux membres sur un blog (writizzy gère déjà ce cas la, mais en n’utilisant pas atproto justement)
• des drafts privé sur un blog

etc…

Mais attention, c’est loin d’être suffisant. Il n’y a pas de notion de chiffrement. Les données sont privées, c’est le PDS qui va fournir l’accès ou non aux données mais celles-ci sont stockées en clairs. Certes, ça limite qui a accès à la données, mais la donnée existe, accessible aux administrateurs de votre PDS.

Vous pourriez bien sur héberger vous même votre PDS, mais avec l’absence de chiffrement je n’en ferais cependant pas un coffre fort pour des informations sensibles.

Dans tout cas les cas, ça ne résous pas un problème conceptuel, le fait d’associer un handle (votre identité) à tout un tas d’informations qui ne devraient pas se mélanger.

Sur le Web classique, on séparait ses usages par cloisonnement. Je créais un compte sur Reddit anonyme, un compte LinkedIn etc… Ici, la promesse de la portabilité pousse à l'effet inverse : une seule identité, qui rassemble toute les infos sur un serveur (un PDS).

Les solutions ?

Atproto est une excellente base technique pour nous permettre de construire tout un tas de réseau sociaux décentralisés et fédérés et sortir enfin des Big Tech.

Déjà il faut attendre quand même quelques évolutions importantes du protocole :

• du chiffrement de bout en bout sur certaines données. Oui je comprends que c’est difficile de chiffrer les Spaces et gérer la rotation des clés à chaque entrée/départ, mais on pourrait par contre chiffrer les DM entre deux individus.
• un mécanisme de masquage des métadonnées (par exemple mes préférences pour l’affichage des news, mes likes, les gens que je bloque) comme Zero knowledge proof

Mais peut-être que le vrai sujet est personnel.

Ce qui est sûr c’est qu’atproto, même s’il permet de résoudre le problème de la centralisation excessive chez un acteur privé, ne doit pas nous donner d’illusion. S’il résous le problème de la transparence, il ne traite pas celui du respect de nos vies privées. J’attends plus de ce qu’il propose mais dans tout les cas, le défi de la confidentialité repose sur nous.

Nous devons mettre en place une certaine forme d’hygiène personnelle vis à vis de ces réseaux en recréant le cloisonnement que nous avions avant avec un séparation stricte des identités. Même si c’est tentant et encouragé, il faut prendre le reflexe d’utiliser plusieurs identités pour séparer les activités (Public/Pro/associatif etc…). Ayez plusieurs handles. Ne traitez pas le login avec Bluesky comme vous l’avez peut-être fait avec le login Google.

Enfin, beaucoup d’entre nous ont trop facilement pris l’habitude de confier des informations sensibles sur internet. Personne n’a besoin de connaitre votre date de naissance, votre localisation, vos statut marital et j’en passe. Ne recréez pas vous même votre propre panoptique.

Je ne suis pas contre lever l'anonymat, parce qu'on est une société démocratique et que je pense que c'est une bonne discipline.

Voici ce que disait Macron récemment dans un discours à Arras en novembre 2025.

Mais, petit problème : l'anonymat sur Internet… est bien plus rare que ce qu'on croit. Alors de quoi on parle ?

Maintenant je vous spoil un peu, même quand on aura défini l’anonymat, l’expérience a déjà eu lieu, et elle s’est mal passée. En 2007 la Corée du Sud a interdit l’anonymat en ligne pour un résultat plus que contestable.

Bref, on va voir ce que "lever l'anonymat" veut vraiment dire dans la tête de nos politiques, si ça marche, et ce que ça nous coûterait. Et on va essayer de voir si on pourrait trouver d’autres solutions.

Pour ou contre ?

Alors d'un côté on va retrouver les défenseurs de l’anonymat qui y voient une garantie pour la liberté d’expression. Et de l’autre côté, et ceux qui considèrent que l’anonymat favorise les mauvais comportements en ligne et les bots.

Alors, c'est pas faux en un sens, les psychologues parlent d'effet de désinhibition puisque derrière un écran, loin de sa cible et quand on se sent difficilement identifiable, on ressent moins les conséquences de ce qu'on écrit.

Mais gardez ça en tête puisqu'on va voir si désinhibition et anonymat sont vraiment liés ou s'il y a autre chose.

En tout cas, peut-être que vous, vous ne vous êtes pas encore forgés une opinion sur le sujet. Et je peux le comprendre. Entre campagnes de désinformations à grande échelle sur les réseaux sociaux, harcèlement en ligne, promotion de contenus haineux d’un côté, ou projets de lois européens pour imposer une surveillance de masse des communications privées, voire l’imposition de la vérification d’identité pour accéder aux contenus numériques, on peut facilement se perdre sur le sujet.

Mais côté politique, on peut déjà voir plusieurs voix s’élever contre l'anonymat.
Ce qui a tendance déjà à me rendre suspicieux personnellement...

En 2023, le député Paul Midy voulait déjà associer chaque compte de réseau social à une identité numérique certifiée par un tiers agréé par l'État. L'amendement a été abandonné.

En juillet 2026, le Parlement a voté l'interdiction des réseaux sociaux aux moins de 15 ans. Et quelques jours plus tard, le député Patrick Hetzel a écrit :

Nous devons maintenant réussir à en finir avec l'anonymat sur les réseaux pour assurer la protection de tous.

Bref, la protection des mineurs c'était une première étape. Ce qui n'est pas vraiment une surprise...

Mais pour parler de ce sujet, et pour commencer, il faut régler un malentendu.

Vous n'êtes pas anonyme

Quand vous postez sous le pseudo “Kevin_du_94”, vous n'êtes pas anonyme.

L'anonymat, c'est quand personne ne peut savoir qui vous êtes, même pas la plateforme ou la police. Le pseudonymat, c'est quand le public ne sait pas qui vous êtes. Mais la plateforme sur laquelle vous publiez, elle, a votre adresse IP, votre email, souvent votre numéro de téléphone et d’autres infos personnelles vous concernant.

Et il se trouve que, en France, la loi obligé déjà les plateformes à conserver ces données depuis un décret de 2021 pour pouvoir les fournir à la justice si elle le demande.

Alors oui, on peut quand même s’approcher de l’anonymat : un email jetable, un VPN, Tor… Mais il suffit d'une erreur, une connexion sans VPN, un pseudo réutilisé, un détail sur sa vie et l'anonymat disparait. Conserver cette hygiène numérique sans aucune faille pendant des années est réservé une fraction de la population. Donc ce que la plupart des gens appellent anonymat, c'est en fait du pseudonymat.

En 2020 lors de l’affaire Mila. Une vague de cyberharcèlement avait eu lieu contre une jeune fille de 18 ans et 11 personnes ont été condamnés alors qu’ils se pensaient sans doute protégé par leurs pseudonymes. Ca n’est pas le cas.

Donc quand on parle de "lever l'anonymat", on ne parle pas de permettre à la police de retrouver les gens. Elle le peut déjà.

Non en réalité on parle d'autre chose, l’obligation à tout le monde de s'afficher sous son vrai nom, et/ou à donner sa pièce d'identité à chaque plateforme.

Maintenant vous pourriez me dire, mais alors, si on peut déjà retrouver les harceleurs, pourquoi le harcèlement continue ? Et pourquoi seulement 11 condamné dans le procès Mila ?

Parce que le problème c'est pas l'identification mais la capacité de traitement. Pharos, la plateforme de signalement du ministère de l'Intérieur, a reçu plus de 220 000 signalements en 2024, pour une équipe d'une cinquantaine de personnes. Et, je ne vous apprends rien, la justice est déjà plutôt saturée et elle ne peut pas traiter tout les cas de cyberharcèlement, d’autant plus quand on parle de milliers d’individus.

Retrouver quelqu'un, c'est possible. Le faire et juger chaque personne, c'est une autre histoire.
Enfin, ne vous en faites pas, la mauvaise remarque, à la mauvaise personne, et on saura vous retrouver très facilement... Selon que l’on soit puissant ou misérable, vous connaissez la suite.

Mais pour en revenir à ce que disait Macron :

On ne peut pas avoir l'anonymat et une absence totale de modération.

Oui, alors certes, mais qui a fixé le budget pour Pharos ?
Bon, et dans tout les cas, Pharos c'est juste pour le signalement. Est ce que j'ai vraiment envie de déléguer la modération à l'état. Ce sera quoi les critères pour déterminer, sans juge, ce qui est acceptable ou pas ? Et si c'est pas l'état, c'est qui ? Les plateformes, avec leurs propres règles et leurs propres intérêts ?

On va voir que lever l'anonymat non seulement ne répond pas à ces questions mais surtout, a d’autres conséquences négatives.

Mais est-ce que ça serait efficace de poster avec son vrai nom ?

Mais admettons quand même. Imaginons que demain, tout le monde poste sous son vrai nom. Est-ce qu'il y aurait moins de haine ?

Des chercheurs de l'université de Zurich ont analysé 532 000 commentaires, sur plus de 1 600 pétitions de la plateforme allemande openPetition.

Et le résultat, c’est que les commentateurs qui signaient de leur vrai nom étaient plus agressifs que les anonymes.

Une autre étude, publiée en 2020, a passé au crible 45 millions de commentaires du Huffington Post. Le site a changé trois fois de règle. D'abord des pseudos jetables. Puis des comptes vérifiés, avec un pseudo stable. Et enfin des commentaires via Facebook, donc sous vrai nom.

Les commentaires les plus argumentés, c'était pendant la période avec un pseudonyme stable. Et quand le site est passé au vrai nom, la qualité a baissé.

Mais, et l'effet de désinhibition dont je vous parlais tout à l'heure ? Il existe, ça c'est assez solide scientifiquement. Une revue de 2024 a compilé 15 études sur le cyberharcèlement chez les adolescents. Plus un ado se sent désinhibé en ligne, plus il a de chances de harceler.

Mais l'anonymat n'est pas le principal ingrédient pour la désinhibition. Le vrai ingrédient, c'est le fait de ne pas être vu, le fait de ne pas échanger en direct, de ne pas ressentir la réaction de l'autre, d'être décorrélé de la douleur de l'autre.

Autrement dit, ce qui désinhibe, c'est moins l'absence de nom que l'absence de face-à-face.

En même temps, regardez Facebook : le vrai nom y est obligatoire depuis toujours. Est-ce que vraiment, c'est les pays des bisounours et de l'acceptation de l'autre ? Ca se discute…

Maintenant si vous voulez une expérimentation encore plus significative, il y a eu la Corée du Sud.

En 2007, la Corée a imposé le nom réel sur tous les sites de plus de 100 000 visiteurs par jour. C’est à dire que pour commenter, il fallait s'identifier avec son numéro national d'identité.

Oui, toute ressemblance avec des propositions de lois récentes seraient pure coincidence… Ou pas.

Résultat, un an plus tard : les commentaires malveillants sont passé de 13,9 % à environ 13 %. Moins d'un point de baisse et il est difficile d'attribuer cette baisse à cette mesure.

Mais surtout, les sites ont dû stocker les numéros d'identité de dizaines de millions de personnes. Et en juillet 2011, un piratage a fait fuiter les données d'environ 35 millions de comptes, ce qui représente quasiment toute la population connectée du pays.

Donc en août 2012, la Cour constitutionnelle a annulé la loi, à l'unanimité parce que les risques dépassaient les bénéfices.

Mais pour rappel, en réalité l’anonymat, c’est pas un permis d’insulter les gens en ligne. Il y a de nombreux bénéfices dont il faut qu'on parle.

À quoi sert vraiment l'anonymat

On n'est pas la même personne partout

Vous ne parlez pas de la même façon à votre patron, à votre médecin, à vos amis et à votre famille.

Ce n'est pas de l'hypocrisie. C'est normal. Chaque contexte a ses règles. Je n'ai pas la même façon de m'exprimer dans tout les cercles que je fréquente. Et je parle pas des mêmes sujets.

Bon ça peut être parce que c'est ennuyant pour mes interlocuteurs, je me vois pas parler de mon travail à ma grand mère. Ca peut être gênant aussi, je ne parle pas des mes soucis de santé à mon employeur.

Enfin, j'ai pas d'employeur, mais vous avez l'idée.

En ligne c'est pareil, chaque pseudonyme correspond à un contexte différent.

Vous pouvez poser une question sur une maladie sur un forum santé sans que votre employeur le sache. Parler de votre dépression sans que ça remonte dans un recrutement. Militer dans une association sans que ça finisse dans votre dossier.

Parce qu’on sait maintenant depuis des années que Internet a changé les règles. Non seulement vos messages restent en ligne, pendant des décennies, mais surtout, sans ils peuvent être reliés entre eux.

Et le jour où tout est relié à votre vrai nom, tous vos contextes fusionnent. Votre vie associative, vos convictions politiques, vos déboires sentimentales. Tout le monde peut tout savoir.

Un espace pour les victimes

Or il faut bien comprendre, l'anonymat, on le présente souvent comme l'arme des harceleurs. Mais c'est aussi le bouclier des victimes.

Une femme qui fuit un conjoint violent et qui ne veut pas être retrouvée.

Un ado LGBT qui n'a pas fait son coming out et qui cherche du soutien.

Une victime d'inceste qui témoigne pour la première fois.

Un opposant politique dans un pays où les libertés individuelles sont limitées.

Pour ces personnes, le vrai nom obligatoire sur les plateformes, c'est un danger.

La dissymétrie

Et puis il y a aussi une question de rapport de force.

Quand un salarié critique son entreprise, quand un fonctionnaire dénonce un dysfonctionnement, quand un citoyen s'oppose à un élu local, ils ne sont pas à armes égales.

En face, il y a un employeur, une hiérarchie, un pouvoir. Les puissants, eux, ont déjà une voix, de l'argent, des avocats, des services de communication.

L'anonymat rééquilibre ce rapport. C'est pour ça que les lanceurs d'alerte et les sources des journalistes en ont besoin. Mais vous aussi, vous en avez besoin. Parce que vous aussi vous avez besoin de vous exprimer sans crainte de représailles ou tout simplement sans crainte qu'on établisse un profil complet de qui vous êtes, et comment vous atteindre.

Le risque politique

Quand je parle de représailles, il y a le point le plus important.

Macron dit : « on est une société démocratique ». C'est vrai...
Aujourd'hui.
Même si déjà il y a des éléments dont on peut débattre.

Mais une base de données qui relie chaque opinion exprimée en ligne à une identité, elle ne disparaît pas quand le gouvernement change.

Elle est là pour le suivant. Quel qu'il soit.

C'est justement parce qu'on est en démocratie qu'il faut éviter de construire les outils dont rêverait un régime qui ne l'est pas.

L'histoire de la liberté d'expression est pleine de pseudonymes. Voltaire, c'est un pseudonyme. Molière aussi. Les textes fondateurs de la Constitution américaine, les Federalist Papers, ont été publiés sous le nom de « Publius ».

Ces gens ne se cachaient pas pour insulter. Ils se cachaient parce que s'exprimer avait un prix.

En 1995, la Cour suprême américaine a jugé le cas d'une femme pour avoir distribué des tracts non signés contre un impôt local. Elle a gagné. Et le juge Stevens a résumé l'idée en une phrase :

L'anonymat est un bouclier contre la tyrannie de la majorité.

C'est ça, le vrai effet du nom obligatoire. Il ne fait pas taire les haters, on l'a vu. Il fait taire ceux qui pensent autrement et qui ont quelque chose à perdre. Leur emploi, leur famille, leur tranquillité.
C’est aussi pour ça que les commentaires étaient moins intéressants avec les vrais noms, l’auto censure.
On parle aussi d'effet panoptique. Le panoptique, c'est une prison imaginée au XVIIIe siècle par le philosophe Jeremy Bentham. Une tour au centre, les cellules tout autour. Depuis sa cellule, le prisonnier ne voit jamais s'il y a un gardien dans la tour. Alors il fait comme s'il y en avait toujours un. Au bout d'un moment, plus besoin de le surveiller : il se surveille tout seul. Avec le nom obligatoire, c'est pareil. Personne n'a besoin de vous punir, vous vous censurez avant même d'écrire.

D'ailleurs si on considère le vote comme un des fondamentaux de la démocratie, on peut aller jusqu'à dire que l'anonymat est une des bases de la démocratie.

Et ce n'est pas pour rien que en 2015, le rapporteur spécial de l'ONU sur la liberté d'expression concluait que le chiffrement et l'anonymat méritaient une protection forte.

Et les données fuient

Et j'oubliais mais, dernier point : toute base d'identité finit par fuiter.

En juillet 2025, au Royaume-Uni, la loi a imposé de vérifier l'âge pour accéder à certains contenus.

En octobre 2025, Discord annonce qu'un de ses prestataires a été piraté. Environ 70 000 photos de pièces d'identité se sont retrouvé dans la nature. Ces photos avaient été envoyées par des utilisateurs qui contestaient une vérification d'âge.

Même chose quelques mois plus tôt avec l'app Tea, une application censée protéger les femmes. 72 000 images fuitent, dont 13 000 selfies et photos de pièces d'identité prises pour vérifier les comptes.

Et pendant le même temps, au Royaume-Uni, le jour même de l'entrée en vigueur de la loi, les inscriptions à Proton VPN ont bondi de 1 400 %.

Et les bots ?

Reste l'argument des bots et de la désinformation. Et il est sérieux : les campagnes d'ingérence existent.

En France, le service Viginum en a documenté plusieurs. Doppelgänger, en 2023, qui clonait des sites comme Le Monde ou Le Figaro. Ou Storm-1516 : 77 opérations russes recensées en 18 mois.

Mais contre les bots, il y a déjà d'autres leviers : la détection des comportements coordonnés, la transparence des algorithmes, le règlement européen sur les services numériques (DSA). Connaitre l'identité de chacun n'est pas le bon outil.
Encore une fois, le pseudonymat, ce n'est pas l'anonymat. Déjà parce qu'on peut savoir qui se cache derrière au besoin. Mais aussi parce qu'un pseudo qu'on garde des années, il a un historique, une réputation. Un compte de bot, lui, a souvent été créé la semaine dernière, en même temps que cinquante autres, et il n'a aucun passé et des comportements détectables, en volume, en fréquence, en horaires. C'est ça qui le trahit, pas l'absence de nom de famille.

Et puis, si les réseaux sociaux n'amplifiaient pas les contenus toxiques pour créer des chambres d'échos, s'ils investissaient dans la modération et ne rémunéraient pas les gens qui font le plus de buzz, on aurait déjà une partie de la réponse en place. Mais ça, nous sommes tous responsables des réseaux qu’on choisit d’utiliser.

Prouver sans révéler

Bon. Alors on ne fait rien ?

Non. Parce qu'il y a des cas où vérifier quelque chose a du sens. L'âge, par exemple, pour les sites pornos ou certains réseaux sociaux. Mais la méthode actuelle n'est pas forcément la bonne.

Pour rappel, la loi qui interdit les réseaux sociaux aux moins de 15 ans, votée le 21 juillet 2026, a été censurée par le Conseil constitutionnel le 14 août.

Une des raisons ? Pour savoir qui a moins de 15 ans, il faut vérifier l'âge de tout le monde.

toute personne, même majeure, doit faire la preuve de son âge avant d'y accéder

Et le législateur n'avait prévu aucune garantie pour la vie privée.

Autrement dit : vérifier l'âge des mineurs, ça impliquait de contrôler l'identité de tous les adultes. Le gouvernement doit revenir avec un nouveau texte qui doit répondre à la question : comment vérifier sans ficher ?

La bonne nouvelle, c'est qu'il y a une solution qui permet de ne pas envoyer l'info complète. Personne ne sait votre age exact et personne ne sait qui vous a demandé l'info : la preuve à divulgation nulle de connaissance, zero-knowledge proof en anglais.

Un tiers de confiance, par exemple l'État, vous donne une attestation numérique. Le site reçoit seulement une preuve mathématique chiffré : « cette personne a plus de 18 ans ». Le site n'a que cette preuve mathématique, pas de nom, pas de photos, rien. Et le tiers de confiance n'est pas impliqué donc ne connait pas les sites qui vous ont demandé cette information.

Au niveau européen, c'est l'EUDI Wallet, le portefeuille d'identité numérique, qui doit intégrer ce type de preuve. Chaque pays de l'Union doit en proposer un d'ici fin 2026. Et depuis juillet 2025, une application européenne de vérification d'âge est testée dans cinq pays : la France, l'Espagne, l'Italie, la Grèce et le Danemark.

Attention, ce n'est pas magique. Il faut que l'implémentation soit sérieuse, auditée, et que personne ne garde de journal de qui a demandé quoi.

Mais la solution technique pour préserver le pseudonymat tout en donnant quelques garanties existe.

Ce que deviendrait notre double numérique

Alors, faut-il lever l'anonymat ?

Le vrai anonymat en ligne est rare, et il demande des efforts que la plupart des gens ne peuvent pas ou ne savent pas produire. Dans l'immense majorité des cas, on parle de pseudonymat, et la police peut déjà retrouver les gens

L'usage du nom ne rendra pas les gens bienveillants. Il fera surtout taire ceux qui ont le plus à perdre.

L'anonymat protège des victimes, des minorités, des lanceurs d'alerte, la liberté d'expression dans son ensemble et notre capacité à séparer nos vies.

Et on pourrait vérifier ce qui doit l'être sans ficher tout le monde. Parce que vous ne voulez pas d’un dossier unique en ligne vous concernant.

Aujourd'hui, vous avez plein de petites identités numériques. Un pseudo sur un forum, un compte pro sur LinkedIn, un vieux blog oublié. Des morceaux de vous, éparpillés façon puzzle numérique.

Lever l'anonymat, c'est relier tous ces morceaux à une seule identité. La vraie. Celle de votre carte d'identité.

Mais vous n'avez pas envie de ça. Même si vous pensez n'avoir rien à cacher.

Cette identité numérique elle accumule tout. Chaque commentaire, chaque like, chaque recherche, chaque groupe rejoint. Ca inclus votre vie d'avant, quand vous étiez jeunes et pas très malins parfois. Je peux vous garantir que j'ai participé à un journal étudiant il y a quelques années, je suis content qu'il n'en existe aucune trace.

Or le numérique, ne s'efface pas. Ce que vous avez écrit à 16 ans vous suit à 40. On peut changer d'avis, changer de vie. Votre double numérique, lui, ne change pas.

Et même si vous l'assumiez, disons que vous n'avez pas forcément envie de tout mélanger. Un recruteur, un assureur, une banque, un algorithme qui vont tous prendre des décisions sur vous à partir de ce profil, sans que vous sachiez lequel, ça devrais vous inquiéter. Oui je joue aux jeux vidéos et je regarde des animes, est-ce que cette info doit intervenir dans la décision pour une obtention de prêt ou pour un recrutement ?

La société peut changer aussi. Peut-être que votre religion, ou ce que vous mangez deviendra illégal demain parce que des personnes mal intentionnés auront pris le pouvoir. Donc ce que vous assumiez à 16 ans, peut devenir un poids.

Au delà de ça, si chaque service exige votre identité vérifiée, perdre votre compte, vous faire bannir ou vous faire voler votre identité, deviendrait synonyme d'exclusion de la société.

Bref, la question n'est pas juste l'anonymat ou non.

Voulons-nous être représentés en permanence par un dossier unique, complet et indélébile ?

Un dossier qui parle pour nous. Qui se souvient de tout. Et dont nous ne contrôlons ni les lecteurs, ni l'usage, ni l'avenir.

Aujourd'hui, entre deux solutions imparfaites, je choisis celle qui protège les individus. Un Internet un peu plus désordonné, plus fragmenté, plutôt qu'un Internet où chacun est entièrement lisible.

Et vous, qu'est-ce que vous seriez prêt à laisser votre identité numérique dire de vous ?

Ca tombe bien, vous pouvez utiliser un pseudo pour répondre en commentaires.

• logiciel européen
• logiciels open source non US (self hosting)
• logiciels open source US
• logiciels hors US
• logiciel US et Chinois.

(Malgré ça, vous verrez que j’ai 28% 14% de softs US)

Attention, cette page ne parle pas de mes outils de développement qui sont listés sur mon tech radar. Ici je parle uniquement des briques de bases permettant de créer une boite, logiciels de support, d’observabilité, d’emailing, de paiement etc…

::toc{open="true"} ::

Hosting

Paiement

Critères : Merchant of records, metered billing, coupons, connect

Alternatives que je n’ai pas pu tester :

Analytics

DNS - CDN

Support

alternative souvent cité : Crisp (France)

Monitoring - logging - observabilité

Alternatives en cours d’évaluation pour remplacer Sentry :

Feedbacks

Alternatives Européennes : upvoty (FR), LiteFeedback (FR), Feedfast (RO),

Emails

Aucun acteur européen ne me permet d’envoyer des emails marketing pour les prix de AWS. C’est en moyenne x10 sur les prix, ce qui est totalement prohibitif.

Blog d’entreprise

Ben oui, forcément que j’utilise mon produit, vous pensiez que j’allais mettre quoi ? :)

Et ce sujet des réseaux est particulièrement sensible. Parce que s’ils sont souvent vus comme des simples outils de loisirs sur lesquels on poste des photos de chat, ce sont en réalité de véritables autoroutes de l’information. Les médias, les politiques, le sport, la culture, le lien social et familial, les liens amoureux tout passe par les réseaux.

Mais comme vous devriez le savoir, l’information, c’est le pouvoir.

Que se passe-t-il quand une poignée d’industriels contrôle ces réseaux ? Lorsqu’elles peuvent collecter et analyser une quantité considérable d’informations sur nous, décider de ce que nous voyons ou de ce que nous ne voyons pas, en fonction de leurs propres intérêts ?

Bref, on aurait bien tort de ne pas les prendre au sérieux et c’est un enjeu, notamment en Europe en cette période où nous parlons régulièrement de souveraineté.

Mais c’est difficile de créer des réseaux sociaux. Ca coûte cher d’une part. Peu d’investisseurs en Europe sont prêts à financer le nouveau LinkedIn, le nouveau twitter ou le nouveau Youtube. Et surtout, pour espérer le succès, il faut réussir à vous convaincre, mais aussi à convaincre vos amis, votre famille, vos collègues parce que sinon, ça n’a aucun intérêt, c’est ce qu’on appelle l’effet réseau : la valeur du produit est proportionnelle au nombre d’utilisateurs qui l’utilise, ce qui rend quasi impossible l’arrivée de nouveaux acteurs.

Et pourtant, il existe aujourd’hui une autre voie.

Et si, plutôt que de chercher à construire le prochain Twitter, on changeait complètement la manière dont fonctionnent les réseaux sociaux ?

Et si l’on revenait, d’une certaine manière, aux origines du Web : un Web plus ouvert et plus décentralisé, où l’on pourrait choisir son fournisseur sans pour autant perdre l’accès au reste du réseau ?

Bref, laissez moi vous présenter un protocole qui pourrait nous aider à redéfinir nos réseaux sociaux et à créer des opportunités, notamment en Europe : ATProto.

Bluesky n’est pas ATProto

Vous connaissez peut-être Bluesky ?

Bluesky est un nouveau Twitter avec environ 43 Millions d’utilisateurs. Si son succès reste modeste par rapport à son ainé, sa croissance, elle, est plutôt dynamique depuis 4 ans et varie en fonction des vagues de départ régulières de X. Merci Elon…

Mais vous allez me dire, Bluesky n’est qu’une autre société américaine, donc un autre monopole en devenir. Oui, certes, mais il faut regarder sous le capot.

Bluesky repose sur un protocole : AT Protocol. C’est ce protocole qui définit les données qui sont présentes sur le réseau, comment on les stocke, comment on les visualise, comment on peut les modérer (les labelliser), bref, comment le réseau fonctionne.

Plus précisément, ça veut dire que Bluesky n’est pas obligé de posséder vos données pour les afficher. Sur Twitter, Substack ou Medium, les données sont possédées par ces sociétés et peuvent être filtrées, modifiées, ou monétisées sans votre accord.

Ici c’est différent, vos données sont hébergées sur un PDS (Personal Data Servers), et ce PDS n’appartient pas forcément à Bluesky. Par exemple, mes données sont hébergées par Eurosky, un PDS Européen.

Et je voudrais qu’on s’arrête un instant sur la page d’accueil de Eurosky :

Eurosky est également derrière mu.social, une alternative au client Bluesky et mu, est la première préfigurant des milliers d’autres apps sociales.

Parce que oui, le protocole ATProto est tellement ouvert que chaque pièce du puzzle peut être remplacé, ou étendu. Et c’est là qu’on peut commencer à s’amuser.

Tout le monde peut construire par dessus. On peut définir nos données, donc on peut construire des alternatives à Instagram (flashes, grain), à Pinterest (current.is), à Substack et Medium (Leaflet, Writizzy), à Tiktok (Spark, Skylight), à InoReader (Gleen), ou même à Github (Tangled), tout ça en partant de la même architecture, mais surtout, en profitant déjà d’une base utilisateur de 45 Millions de personnes.

L’effet réseau est déjà là.

Bluesky n’est pas ATProto, c’est une pièce d’un écosystème beaucoup plus grand : l’atmosphere.

Les lexicons

Par défaut, les données présentes sur ATProto sont faites pour afficher des messages courts. C’est le fameux message bluesky que vous connaissez déjà : un message, un auteur, un nombre de likes etc…

Mais vous ne pouvez pas poster des messages longs et puis de toute façon c’est pas vraiment fait pour lire des articles de blogs, des vidéos, ou du code source.

Mais on peut étendre tout ça via les lexicons. Un lexicon c’est un lexique, un schéma de données, c’est grosso modo l’ensemble du vocabulaire sur un enregistrement du réseau, et que certaines applications vont utiliser.

Par exemple le lexicon d’un post bluesky est défini par app.bsky.feed.post et on va retrouver des champs comme text, createdAt, langs, embed (quand il y a une image) etc…

Mais n’importe qui peut définir un nouveau lexicon. Evidemment ce ne sera pas lu par toutes les applications. Bluesky ne lira pas votre lexicon mais votre application pourra le faire.

Et justement il y a pas longtemps je suis tombé sur un lexicon qui m’a particulièrement intéressé pour les plateformes de blogs : standard.site.

L’initiative vient de trois plateformes qui se sont associées : Leaflet, pckt.blog and Offprint et qui ont proposé ce nouveau format pour les publications longues.

Ce format a tellement plu qu’il est désormais disponible via un plugin dans l’écosystème Wordpress, pour les générateurs de blogs statiques via Sequoia, et désormais, il devient central également dans Writizzy, le produit que je construis et qui fait tourner ce blog (et sans doute bientôt aussi Bloggrify que je maintiens également).

Cette intégration permet donc d’avoir une compréhension native de votre publication Writizzy dans bluesky/muSocial. Vous noterez le lien “view publication” qui n’apparait pas normalement pour un simple lien de base.

Mais surtout, cela permet à tous les posts publiées sur Writizzy d’être visible dans l’ensemble des readers qui scannent l’atmosphere pour lire des articles de blogs : standard-reader, Heron, potatonet, docs.surf, leaflet etc… Bref, en une étape, Writizzy devient membre de l’atmosphère et peut exposer un nouvel article à des millions d’utilisateurs.

Et cet exemple nous montre qu’on peut désormais créer des nouvelles apps, avec leur vocabulaire, sur les PDS existants et en profitant d’un réseau déjà établi.

Le retour d’un web ouvert et décentralisé

Au delà de cet exemple précis, ATProto offre de nombreuses opportunités de revenir à un web plus décentralisé et à votre contrôle. Vous pourriez, par exemple, avoir votre propre PDS (serveur de données personnel) qui participe au réseau AT Proto.

Et vous pouvez aller encore plus loin. Tout le protocole prévoit que chaque fonctionnalité est composable et ça inclut la modération, ou les feeds. Ce n’est pas Bluesky qui vous les impose. Encore une fois, Bluesky fournit un service, mais ce n’est pas ATProto.

Si vous voulez utiliser un autre labelliseur (un outil qui permet de faire de la modération), ou si vous voulez créer votre propre feed avec vos thématiques, vous pouvez. Je pourrais créer dans le futur un feed de l’ensemble des blogs tech Writizzy par exemple.

Bref vous pouvez reprendre le contrôle sur vos données, les algorithmes qui vous poussent du contenu et la modération associée.

Mais plus que ça, c’est des opportunités gigantesques pour reconstruire tout les réseaux sociaux qui nous manquent en Europe : Linkedin, Youtube, Tiktok, Instagram pour ne citer qu’eux.

En espérant qu’effectivement, mu.social ne soit que la première parmi des milliers.

Ce web ouvert et composable ne se fera pas tout seul, et il ne viendra pas de la Silicon Valley. Aujourd'hui, l'infrastructure est prête, le réseau d'utilisateurs existe et les briques fondamentales sont posées. À nous, développeurs, créateurs et entrepreneurs européens, de nous saisir d'ATProto pour bâtir les plateformes de demain, sur nos propres règles.

PS : ah oui, et si vous commentez en dessous du post sur bluesky/mu.social, le fil devrait remonter en commentaire sur le blog (au bug près :))

Mais il y a un thème qui semble rassembler à peu près tout le monde, pro et anti IA, il s’agirait d’une bulle, et elle va finir par exploser.

Eh bien c’est le moment de se poser la question. Est-ce que c’est une bulle ? Est-ce qu’elle peut exploser et quand ? Et quelles seraient les conséquences si c’était le cas ?

Est-ce que c’est une bulle financière ?

Si la question semble évidente pour beaucoup, elle mérite qu’on s’y attarde un peu. Est-ce que vraiment, nous sommes dans une bulle financière ? Est-ce que la valeur qu’on donne aux entreprises dans l’IA est réaliste ?

Est-ce que nous sommes en train d'assister à une transformation historique... ou à une bulle spéculative ?

Premier indice : des valorisations qui semblent absurdes

Une bulle financière n'est pas simplement un secteur qui monte très vite. Sinon Amazon en 2010, Tesla en 2020 ou Nvidia aujourd'hui auraient toutes été des bulles. La question centrale est celle de la soutenabilité : la valeur attribuée à ces entreprises est-elle réaliste ? Les investissements massifs dans l'IA reposent-ils sur des bases financières solides ?

À première vue, les comptes sont pas bons Kévin.

Anthropic réalisait environ 850 millions de dollars de chiffre d'affaires en 2024. Pourtant, quelques mois plus tard, l'entreprise était valorisée près de 19 milliards de dollars. Plus de vingt fois son chiffre d'affaires annuel.

Il faut comprendre que en finance, il y a deux logiques :

• Pour une entreprise traditionnelle, la valeur d’une action correspond aux performances connues dans le présent. Elle dépend des bénéfices générés et des actifs physiques (usines, magasins, stocks).
• Pour une startup tech, en revanche, la valeur repose sur la promesse de gains futurs. Sa valorisation ne reflète pas ses revenus actuels, souvent faibles, mais anticipe leur explosion à venir. On applique alors un "multiple" à son chiffre d'affaires ou à ses revenus récurrents. Si ce multiple dépasse rarement 10 à 15 fois le chiffre d'affaires (surtout depuis la hausse des taux d'intérêt post-2021), les entreprises pionnières de l'IA atteignent aujourd'hui des niveaux bien supérieurs, allant parfois de 20 à plus de 50 fois leur chiffre d'affaires.

Cependant, si ces multiples sont énormes, c’est pas pour autant qu’ils sont inhabituels et anormaux. Ils sont anormaux pour la période, mais pas anormaux dans l’absolu.
Dans le passé, Shopify, Snowflake, Amazon, toutes ces boites là ont dépassé les x50 et les paris se sont révélés gagnants.

Donc, mauvaise piste.

Verdict : ❌ pas concluant

Deuxième indice : une avalanche de capitaux

Depuis trois ans, plus de 1000 milliards de dollars.ont été engagés dans l'écosystème IA.

Selon la BRI (banque des règlements internationaux), 5% du PIB US sont aujourd’hui liés aux investissements dans l’IA. Ce montant dépasse celui constaté lors de la précédente bulle de l’internet en 2000.

Et en valeur absolue, la bulle Internet représentait environ 600 milliards de dollars de l'époque. Corrigé de l'inflation, là encore on se rapproche des investissements actuels dans l’IA.

Par contre, par contraste, la crise des subprimes concernait plus de 10 500 milliards de dollars de dette immobilière. Mais attention, on compare des choux et des carottes dans ce cas précis.

Ce qui est sûr c’est que les montants en jeu sont colossaux. Mais colossaux ne signifie pas anormaux. Les télécoms dans les années 80/90, le mobile dans les années 2000 ont eux aussi attiré des sommes gigantesques sans qu’on parle de bulle à leur époque.

Verdict : ❌ inquiétant mais pas concluant

Troisième indice : et si les clients étaient... les investisseurs ?

Ici on touche à une des spécificités de la potentielle crise actuelle : le chiffre d’affaire des entreprises dans l’IA augmente via leur propres dépenses dans l’IA.

Les acteurs de l’IA ne sont pas uniquement les entreprises qui créént des LLMs. C’est aussi les hyperscalers cloud ou les fabricants de puces. C’est une parfaite forme d’économie circulaire (round tripping)

NVIDIA investit dans OpenAI
        ↓
OpenAI réserve du calcul
        ↓
OpenAI signe des contrats cloud avec Oracle, Microsoft etc...
        ↓
Ces fournisseurs achètent des GPU NVIDIA
        ↓
Les recettes reviennent à NVIDIA

Le problème de cette économie circulaire, c’est qu’elle s’auto alimente et on ne sait pas encore dire si la demande réelle va suivre. Si les seuls clients de l’IA sont les autres acteurs de l’IA, disons que c’est pour le moins suspect.

Toutes les projections de nouveaux datacenters, investissement pour construire des nouvelles puces etc… seraient potentiellement à jeter en cas de retournement de marché puisque pour l’instant les seuls clients de ces entreprises, à cette échelle, c’est eux-mêmes. Et les sommes dont on parle se chiffrent en dizaines de milliards.

Verdict : ❎ inquiétant

Quatrième indice : des rentabilités inexistantes

Les investissements dans l’IA ne sont pas rentables à part pour NVidia mais c’est un peu naturel quand tu vends le matériel (Cf indice 3). Pour les acteurs les plus importants (Amazon, Google, Microsoft, Meta), pour un euros dépensé, c’est moins de 10% de la somme qui revient en revenu avec une petite palme pour Meta dont seulement 1% revient en revenus.

Même les acteurs majeurs comme OpenAi, Anthropic (ou Mistral en France) peinent à dépasser 40/50% de la somme en retour.

Bref ces acteurs ne sont pas rentables.

Mais cet indice est très bancal. C’est plutôt fréquent de surinvestir dans la phase de démarrage, surtout sur des domaines industriels qui demandent de l’investissement.

Amazon n’a pas été rentable avant sa 9eme année, Tesla avant sa 17eme année, Uber, 14 ans. Une phase de pertes importantes n'a rien d'anormal lorsqu'un secteur construit les infrastructures d'un nouveau marché. C'est même presque attendu.

En réalité, le problème n'est pas que l'IA ne soit pas rentable aujourd'hui, c’est normal. Le véritable enjeu est de savoir si elle pourra l'être demain, une fois les investissements stabilisés. C'est cette question qui reste encore largement ouverte. Est-ce que les investissements d’aujourd’hui sont pérennes ou bien est-ce qu’il faut réinvestir la même somme tous les ans ?

Pour l’instant, au vu de l’obsolescence des matériels utilisés (les puces pour l’entrainement et l’inférence), la réponse ne semble pas aller dans le bon sens.

Verdict : ❎ inquiétant

Cinquième indice : quand l'histoire commence à se répéter

Vous vous rappelez de la bulle des années 2000 ?

En 2000 il suffisait de renommer sa boite avec un .com, genre choucroute.com et hop, la valorisation augmentait. L’irrationalité était telle que les investisseurs se ruaient sur tout et n’importe quoi, et surtout n’importe quoi, histoire de pas passer à côté de la future pépite.

Et rappelons-nous que les investisseurs ne sont pas toujours les meilleurs en terme de rationalité, parce que à chaque fois, lors des grandes crises, nous avons droit à une nouvelle version de “this time, it’s different” qui justifie en gros que les fondamentaux économiques puissent être négligés.

Eh bien on assiste un peu à la même chose aujourd’hui. Toutes les boites intègrent de l’IA, tout du moins dans leurs pitchs investisseurs. Certains se mettent à réserver des extensions .ai histoire de surfer sur la vague et je suis plus que circonspect sur les valorisations de certaines boites comme Lovable (6 Milliards), cursor (60 Milliards), Devin (26 Milliards). C’est cool pour leur créateur mais, faire un wrapper sur des IA existantes, je suis pas convaincu que ca vale ce prix là.

Verdict : ❎ inquiétant

Alors oui, je ne peux pas affirmer à 100% que nous sommes dans une bulle financière mais ça y ressemble furieusement. Des valorisations extraordinaires, des investissements gigantesques, une économie qui tourne largement sur elle-même, des entreprises encore loin de la rentabilité et, surtout, un discours qui commence à ressembler étrangement à celui des grandes bulles du passé.

A ce stade, le plus intéressant n'est donc peut-être pas de savoir si une bulle existe.

C'est de comprendre comment elle pourrait éclater.

Parce que toutes les bulles n'explosent pas de la même manière.

Les déclencheurs

Les bulles finissent toujours par éclater mais le détonateur est souvent imprévisible. On peut facilement identifier les fragilités mais c’est parfois un évènement anodin qui finit par faire tomber le système.

Malgré tout je vous propose de jouer à un jeu et d’essayer de lister les déclencheurs possibles d’une éventuelle crise de l’IA.

Option 1 : Les IPO de Anthropic et OpenAI se passent mal

Anthropic et OpenAI prévoient une entrée en bourse prochaine. Si les dates exactes ne sont pas encore connues, cela pourrait se produire entre le 4eme trimestre 2026 et le 2nd trimestre 2027.

Lors de ces entrées en bourse, on va voir si les “petits porteurs” décident que le prix de l’action vaut effectivement celui qu’on lui prête aujourd’hui. Et justement, il y a plusieurs problèmes on l’a vu :

• les valorisations semblent largement trop importantes par rapport aux revenus générés
• les rentabilités sont trop faibles

A cela j’ajouterais un autre problème important : le montant des liquidités disponibles sur le marché.

La valo théorique de anthropic c'est 965 Milliards de dollars et Openai n’est pas très loin de ce chiffre.
Evidemment une IPO ne portera pas sur la totalité de la valeur mais une partie, mettons 10% (100 milliards).

Les records de levées lors d'une IPO oscillent entre 35 et 50 Milliards.
Pour aller acheter 200 milliards (pour Anthropic et openAI), est-ce que les marchés vont suivre ? Est-ce que la première levée, qui serait déjà exceptionnelle, ne va pas handicaper la seconde ?

Option A : les deux levées se font dans ces ordres de grandeur, ce sera forcément en vendant d'autres actifs pour mobiliser le cash, donc en créant  une baisse sur les cours des autres entreprises.

Option B : c’est impossible de lever ces montants, et les valeurs des deux entreprises baissent

Malgré tout, j’ai envie de mettre ce scénario de côté car je le trouve évident, trop facile et donc peu probable.

Option 2 : Les gros investisseurs réduisent la voilure

Aujourd’hui ce sont les hyperscalers qui investissent le plus dans les grosses boites de l’IA, OpenAI et Anthropic pour ne parler que d’eux pour l’instant. Et quand je parle d’investissement, je parle aussi d’investissement matériels avec des accès facilité aux infrastructures.

Sauf que pour l’instant le retour sur investissement est faible. Alors imaginons, demain, que Microsoft annonce diminuer ces investissements et baisser ces couts en datacenter/infrastructures.

Le marché ne va pas juste regarder Microsoft et les éditeurs de LLM. Il va regarder Nvidia, AMD, TSMC, les producteurs d’électricité. Toute la chaîne.

Malgré tout, cette option ne me convient pas non plus. Certes, pour Microsoft, ou Amazon, la situation n’est pas rose, elle n’est pas non plus catastrophique, car ces entreprises bénéficient de contrats publics, notamment dans le domaine militaire. Et se décider à couper les investissements maintenant c’est précipiter l’échec, se tirer une balle dans le pied, ce qui me parait peu probable.

Option 3 : Un ralentissement physique

Ce déclencheur la repose sur une idée très simple, les datacenters ont d’énormes besoins en ressources. A terme on sait que ces ressources ne seront pas disponibles, que ce soit pour l’énergie, ou les ressources minières.

Imaginons que demain :

• nous ayons des difficultés d’approvisionnement sur les terres rares, par exemple lié à un conflit avec la Chine (60 a 70% de l’extraction minière et plus de 85% de l’affinage vient de Chine)
• que l’électricité disponible ne puisse plus être fourni pour les datacenters (Ex à Dublin, aux US et à Singapour)

On pourrait imaginer un ralentissement non pas financier... mais physique. Et on retombe sur l’option 2. On va pas juste regarder le datacenter, on va regarder toute la chaîne, tout les investissements prévus et qui ne se feront pas.

Cette option est beaucoup plus crédible, selon moi, mais à moyen terme. Ca me semble difficile d’imaginer un évènement marquant d’ici 2028. Cependant je suis peut être naif car les relations avec la Chine ne cesse de se dégrader et les refus de constructions de datacenter augmentent déjà. Je classe donc cette piste en crédible.

Option 4 : L’IA atteint un plafond

C’est un vrai sujet. Imaginons que Opus 8 ne soit “que” 3% meilleur que son prédécesseur ? Les investisseurs paient pour voir une croissance exponentielle. C’est exactement ce qui motive tout le cirque qu’on peut habituellement voir à chaque sortie venant des équipes marketing de ces géants. Ils doivent nous vendre l’incroyable, car ils ne seront payés que pour l’impossible.

Que se passerait-il si cette croissance de l’amélioration des modèles diminuait ? Là encore, on en revient à l’option 2. Un investisseur majeur pourrait décider de baisser ces dépenses dans les datacenters et vous connaissez la suite.

Est-ce que cette option est crédible ? L’amélioration sur 1 an a été fulgurante et presque flippante. Malgré tout j’ai l’impression que la marge de progression reste encore importante. Mais je dis ça en étant loin d’être un spécialiste. J’aurais cependant tendance à rejeter cette option pour les 2 prochaines années en tout cas.

Option 5 : un choc macro

Cette option est plus traditionnelle. Et si demain un énorme choc secouait l’économie sans aucun rapport avec l’IA. Ca peut être une crise de l’énergie, une crise politique (un conflit ouvert entre l’Europe et la Russie par exemple), la crise de l’immobilier Chinois qui couve depuis des années.

C’est typiquement l’option où les inconnues inconnues sont plus nombreuses que les autres. Puisque cette option est par nature totalement imprévisible, je ne vais pas retenir non plus.

A ce stade vous pourriez me dire, “ok mais tu n’as retenu aucune option, donc tu ne penses pas que la bulle va éclater ?”

C’est pas tout à fait ça. Je pense que la plupart de ces causes sont trop prévisibles, ou trop long terme.
Encore une fois, prédire le déclencheur c’est particulièrement difficile. Ce sera peut-être une combinaison de facteurs avec un effet domino qu’on anticipe pas aujourd’hui. Le déclencheur pour l’explosion de la bulle internet en 2000 par exemple, c’est le relèvement des taux d’intérêts par la FED.

En tout cas j’ai du mal à ne pas imaginer un déclencheur dans les 2/3 prochaines années.

Par contre, les conséquences ne seront pas forcément celles que tout le monde imagine.

Les conséquences

J’ai pas fini de vous embêter avec les chapitres en plusieurs sections :)

On imagine souvent que l’éclatement d’une bulle c’est comme pour la bulle internet de 2000 ou celle des subprimes : un énorme krach économique, des tas d’entreprises à terre et terminé.

Eh bien pas forcément. Les bulles finissent toujours par éclater mais ça peut être lent et odorant et on va voir là encore plusieurs scénarios.

Scénario 1 : La bulle éclate violemment

C’est le scénario facile celui là. On l’a tous en tête. Les valorisations s’effondrent, certains grands acteurs font faillite, s’ensuit des licenciements par dizaines de milliers et l’arrêt des projets.

Pour que ce scénario soit le plus impressionnant possible, on peut imaginer une Big Tech aller au tapis, une sorte de Lehman Brother moderne, ou Worldcom pour faire le parallèle avec la bulle internet.

Attention, ce scénario est évidemment le plus douloureux puisque ça ne touchera pas “que” la tech. On parle de tout les vendeurs de matériel, les fournisseurs d’électricité, les assurances qui ont couvert les transactions, les plans d’épargne retraite, PEA, PER etc… parce que oui, une grande partie de l’investissement actuel repose sur des valeurs US, et notamment dans la tech.

J’insiste, ce sera très douloureux même si vous pensez être loin de l’IA. L’explosion de la bulle internet c’était entre 60 et 80% de perte de la valeur des indices boursiers, des millions d’emplois perdus.

Scénario 2 : une dilution

On pourrait ne pas forcément avoir un scénario aussi cinématique que le premier. On pourrait simplement avoir une baisse progressive des investissements mais un maintien des infrastructures et une réabsorption des gros éditeurs de LLM par les hyperscalers.

Ca serait potentiellement fini pour Anthropic, OpenAI en tant qu’entités indépendantes et les pertes seraient absorbés en grande partie par les GAFAM.

(Je ne parle pas de xAI qui fait déjà partie d’un consortium ou Gemini qui fait partie de Google)

Ce ne serait pas une explosion mais une dilution de la bulle IA dans les comptes des mastodontes de la tech.

Je parle de dilution mais on pourrait aussi parler de consolidation. On aurait certainement plus autant d’acteurs mais une grande partie serait absorbée par les plus résistants, Google, Amazon, Tencent par exemple.

Ce serait moins spectaculaire mais pas sans conséquences quand même. Une partie (et une partie seulement) des investissements serait mis de côté. On cesserait les investissements lourds prévus pour dans 5 ans, donc avec plus de temps pour reconstruire des budgets corrects. Il y aurait quand même des licenciements mais moins massifs.

Mon petit pincement au coeur dans ces deux scénarios, c’est que je vois mal un acteur Européen comme Mistral survivre dans ce scénario sans être absorbé complètement, sauf si l’Europe décide d’investir massivement via la commande publique. Le retard est grand et je trouve leur stratégie peu lisible aujourd’hui, et même mal ancré dans l’écosystème tech. Mais je leur souhaite le meilleur, parce qu’on a besoin d’un champion européen sur le sujet. Même si au pire on ira se bricoler des trucs avec les modèles open weight.

Maintenant vous savez quoi ?

Si on exclut le cas Mistral, malgré tout, j’ai presque envie que ça arrive et je vais vous expliquer pourquoi.

Pourquoi ce serait pas si pire

Une bulle rappelons le, c’est du capital mal investi. Alors attention, je ne dis pas que l’IA en, soit est une technologie qui n’en vaut pas la peine. C’est en train de redéfinir complètement de nombreux métiers. Mais est-ce que ça vaut le coup pour autant de faire n’importe quoi, j’en suis pas sur.

Quand Google remet en cause son objectif de neutralité carbone 2030, c’est un échec pour tout le monde. Et puis, est-ce que c’est sain d’avoir cette course à l’échalotte pour des datacenters dont on sait qu’on ne pourra pas tous les alimenter en électricité, sauf à réouvrir des centrales à gaz ?

A côté de ça, quand je parle de capital mal investi, je suis très content pour les gens qui ont créé Lovable ou Cursor, c’est cool pour eux. Mais tout ce capital pour créer une techno qui se fait déjà concurrencer par des palanquées de produits vibe codé 2 ans plus tard, c’est dommage. Le même argent aurait pu financer autre chose plus utile.

L’irrationalité capitalistique, les dérives sur les ressources minières qui nous plongent dans une crise de la RAM et des composants, l’accroissement des tensions entre pays, et tout simplement le climat actuel autour de l’IA qui devient irrespirable entre les pro et les anti, je trouve que ça fait beaucoup de raison pour espérer que ça s’arrête.

Si la bulle éclate ça signera une forme de retour à la rationalité. Je crois pas à la disparition de la techno, de la même façon qu’internet n’a pas disparu en 2000 et que le train aussi à survécu à la bulle ferroviaire des années 1840.

Ce qui disparaît dans une bulle, ce ne sont pas forcément les technologies : ce sont surtout les valorisations absurdes, les projets qui n’avaient pas de modèle économique viable et les investissements réalisés parce que “tout le monde le fait”.

Plus de rationalité ça veut dire des investissements mieux pensées, une R&D plus orienté sur l’optimisation de ce qu’on a déjà appris : les mixtures of expert, la quantification, le pruning, la HBM, l’optimisation des modèles. Il faut désormais qu’on fasse autant mais avec moins. C’est une nécessité.

On a déjà de quoi faire avec ce qu’on a déjà en main et ce serait pas mal de se poser un peu, de réfléchir aux usages qui marchent, et il y en a déjà, de trouver un vrai chemin de rentabilité et de réorienter le capital, notamment sur les enjeux de décarbonation de l’économie (électrification du parc automobile par exemple) ou les mesures d’adaptations à un climat.

Est-ce qu’une explosion de la bulle de l’IA verra la fin de l’IA ? Pas si sur. Ce sera plus un atterrissage. Mais quelque soit le scénario, il sera bénéfique, un retour aux fondamentaux économiques ET écologiques.

Faut pas s’y tromper, vu les sommes déjà investies, l’éclatement fera mal, mais plus il tarde, pire ce sera. Il faut que le pansement s’arrache, rapidement.

Mais cette opposition me rappelle un mauvais souvenir : la bataille contre le nucléaire des décennies précédentes. En voulant sortir de l'atome, une partie de l'écologie politique a précipité l'Europe dans la dépendance aux énergies fossiles et au gaz russe. Et j’ai bien peur qu’avec les datacenters et l'IA, nous soyons en train de commettre exactement la même erreur stratégique.

Entendons-nous bien, la question centrale de la consommation énergétique est cruciale. Nous devons baisser nos consommations, nos usages. Mais refuser ces infrastructures chez nous n'annulera pas le besoin en calcul : cela ne fera que le déplacer là où l'énergie est carbonée et où les normes environnementales sont inexistantes. Opposer souveraineté numérique et transition écologique est un contresens. Vouloir un avenir vert sans maîtriser les tuyaux du monde numérique, c'est choisir l'impuissance.

Une consommation numérique en hausse

Une partie des oppositions aux installations de datacenters reposent sur un élément : nous devons cesser d’accroitre la pression sur les ressources planétaires et le numérique, en croissance, est le parfait mauvais élève et le plus facile à détester.

Facile à détester car il représente symboliquement, pour beaucoup, l’addiction aux écrans, l’automatisation et les pertes d’emplois, le technofascisme de Thiel et Musk. Même si, comme tout symbole, c’est surtout une simplification à outrance qui oublie de mesurer les autres côtés positifs de la balance.

Sur le domaine écologique, on ne peut qu’être d’accord sur le fond. Notre planète est à bout de souffle et nous devons baisser notre consommation. Or les usages du numérique explosent dans un monde où chaque secteur devrait viser l’inverse. Sa part dans l’empreinte carbone de la France est passé de 2.5 a 4.4% en quelques années en France. Cette croissance est globalement identique à l’échelle mondiale et les projections tendancielles prévoient encore une augmentation.
Est-ce que nous pouvons nous le permettre ? Certainement pas.

Mais est-ce que “le numérique” est un tout homogène ? Pas si sûr, comme on peut le comprendre sur cette étude de l’AIE (agence internationale de l’énergie).

• Le numérique et notamment l’IA ont des impacts positifs quand il s’agit de travailler sur l’optimisation des systèmes énergétiques, l’optimisation du pilotage des énergies renouvelables, les modèles météos, la médecine
• mais le numérique et l’IA c’est également malheureusement des accélérateurs pour l’industrie des énergies fossiles qui permet une meilleure exploitation des gisements actuels ou la découverte de nouveaux

Et ce qui n’est pas dans cette étude de l’IEA c’est aussi la pression environnementale liée à l’industrie de l’IA sur la consommation de ressources minières pour créer des équipements de plus en plus puissants, des datacenters de plus en plus gourmands.

On pourrait aussi citer la tendance aux US à faire construire de nouvelles centrales à gaz pour alimenter les datacenters.

Evidemment pour ces raisons là, je ne peux que donner raison aux oppositions d’implantation de datacenters. Mais s’opposer sans nuances c’est aussi oublier les impacts positifs du numériques, IA inclus, qui est aujourd’hui nécessaire pour optimiser nos flux logistiques et énergétiques dans un monde à 10 Milliards d’habitants.

Et également, cette opposition en Europe me paraît oublier un détail important comme le dit Charles Gorintin sur Linkedin :

Refuser un data center en France ne supprime aucune requête. Elle sera servie ailleurs, sur un réseau au gaz ou au charbon, avec un manque à gagner économique pour nous. Chaque gigawatt que nous ne construisons pas ici se construit là où l'électricité est plus sale.

Je vais même aller plus loin, opposer souveraineté et écologie est contre productif.

Souveraineté vs Écologie : le faux dilemme

J’entends, l’écologie devrait primer devant l’économie. Evidemment. Parce que oui, avoir un portefeuille boursier en hausse dans un monde en flamme n’a pas trop de sens, ce que nous dit en substance Mathilde Saliou :

faire un petit effort pour sortir des raisonnements économiques auxquels nous sommes toutes et tous les plus habitués. Faire un pas de côté pour s’extraire du réflexe de la compétition directe avec les États-Unis et la Chine. S’il s’agit de reproduire leur modèle, de toute manière, c’est perdu d’avance. Et puis quel est ce masochisme, qui consiste à tenter de « rattraper » des pays qui ne sont des exemples ni en termes démocratiques, ni en termes environnementaux ?

J’ai cependant une autre lecture à cela : Ne pas adresser les sujets de souveraineté c'est s'exposer à ne pas être maitre de nos choix sur l'écologie.

Si tu n'as pas tes propres champions, tes propres infrastructures et un marché fort, tu subis les standards des autres. Les Américains privilégieront la rentabilité et l'hyper-consommation, tandis que la Chine arbitrera selon ses seuls intérêts stratégiques.

Quand je parle de subir je vais clarifier mon point.

Notre dépendance numérique est une immense faille dans le modèle Européen. Nous sommes dépendant à plus de 70% des produits numériques US en Europe. Nos données sont aux US et nous payons une taxe numérique constante de notre économie qui part là bas.

Cette faille n’est pas juste économique. C’est une épée de Damocles qui pèse sur nos institutions politiques. C’est par exemple :

• des attaques directes sur la Cour pénale internationale pour leur couper les accès aux logiciels américains
• des manipulations massives sur les réseaux sociaux pour orienter les choix des électeurs

Non, on ne se bat pas juste pour avoir quelques euros en plus. La souveraineté c’est s’assurer que nous restons maitre de nos choix. C’est s’assurer qu’on peut encore dire non quand l’administration américaine cherche à nous imposer les abandons des politiques de diversité en entreprise, ou quand elle cherche à influencer des juges français sur des procès, comme celui du RN (même si on est assez fort pour se saborder nous mêmes sur le sujet…).

Le pouvoir économique assure l’indépendance et assure qu’on puisse être écouté quand on parle d’écologie, ou des droits de l’homme.

Opposer souveraineté et écologie est un faux dilemme. Il n’existe pas un monde où nous pourrons choisir notre avenir sur l’écologie en étant dépendant économiquement et politiquement des autres pays.

Et l’IA, comme la construction de data centers, fait partie des clés pour rester souverain. Dire “Not in my backyard” (Cf phénomène NIMBY) est un non sens.

Parce que le numérique (et l’IA) c’est aujourd’hui des outils de dominance économique et politique. C’est de plus en plus utilisés dans les guerres cyber, dans la manipulation sur les réseaux, dans les drones qui sont désormais les nouveaux standards dans les guerres d’aujourd’hui. Et je ne dis pas que ce sont des perspectives qui m’enchantent, mais rester à égalité nous permettra de rester plus serein à chaque nouveau coup de folie d’un président étranger qui chercherait à nous nuire.

Mais au delà de cette simple posture défensive, c’est aussi se donner des alternatives.

La souveraineté comme levier de maîtrise et d'exemplarité

La souveraineté sur les datacenters c’est la capacité à**** reprendre le contrôle des infrastructures numériques, combat certes perdu dans la dernière décennie, mais pas de façon définitive.

Reprendre le contrôle, avoir la main sur nos outils c’est nous permettre d’imposer notre mix énergétique (décarboné), nos exigences d'efficacité et nos règles d'écoconception. Chose impossible sur un cloud 100 % américain ou chinois.

La souveraineté et de façon plus large, la puissance économique, c’est se donner les moyens d'imposer des normes (ex. règlementations environnementales) que les marchés étrangers sont obligés de suivre s'ils veulent nous vendre leurs produits. Parce que oui, tant que ça reste attrayant de vendre à un marché de 450 millions d’habitants qui a un bon pouvoir d’achat. Ca nous donne des effets de levier.

Et la souveraineté, ce n'est pas forcément “produire plus”, c'est se donner le pouvoir institutionnel de dire “non” par exemple si un industriel souhaite créer une centrale à gaz pour faire tourner un centre de données, ou d'imposer des plafonds de consommation énergétique.

Par contre, la souveraineté c’est pas juste la puissance industrielle et économique, mais la résilience aux chocs (climatiques, énergétiques, d'approvisionnement). Une souveraineté qui détruit son environnement détruit ses propres conditions d'existence à long terme.

Des déploiements oui, mais pas à cette vitesse

Nous devons reprendre la main sur nos infrastructures. Ca passe par des datacenters en Europe et un développement européen de l’IA pour nous extirper de notre dépendance aux US et à la Chine.

C’est d’ailleurs aussi la conclusion du shift project dans cette vidéo synthèse de 2h qui reprend l’ensemble de leurs travaux récents sur le sujet :

nous ne disons pas qu'il ne faut pas faire d'IA, mais pas dans cette trajectoire de déploiement

Avec notamment une question sur la souveraineté à la fin de la vidéo qui est répondu en deux temps :

• C’est important de réduire notre part d’énergie dépensé à l’étranger, pour des questions de dépendance (mot préféré à souveraineté dans leur cas) mais aussi pour pouvoir imposer nos arbitrages, sur la consommation ou le type d’usage.
• C’est important d’avoir nos propres modèles développé en Europe, et/ou de favoriser les modèles open weight, moins consommateurs

Pour ces raisons, ++il faut des datacenters en Europe++ MAIS piloté par des acteurs Européens.

Donc oui, même le shift project le dit.

Maintenant, ça veut dire quoi d’être sobre numériquement ? Et est-ce que tout les grands projets d’investissement Européens sont réalistes ?

Quelle est notre consommation énergétique en Europe ?
Quelle est notre capacité d’augmentation de la production énergétique ?
Quelles sont les projections nécessaires de puissance électrique nécessaire à la construction de datacenters ?
Et surtout, est-ce réaliste ? Quel arbitrage faut-il faire ?

C’est pas une question d’être pour ou contre une technologie, encore une fois je pense qu’on doit créer notre infrastructure. Mais est-ce physiquement possible ?

Des chiffres

C’est bien la théorie mais il nous faut des chiffres.

La consommation électrique actuelle des datacenters en Europe est d’environ 75 TWh/an (soit près de 2,5 à 3 % de l'électricité continentale).

Les projections pour 2030 (sur la consommation) envisage que la consommation des datacenters atteigne de 150 à 170TWh (4.5% de l’électricité produite).
Pour 2035, on envisage 230Twh, soit environ 155Twh supplémentaires par rapport à aujourd’hui.
Première question, est-ce qu’on prévoit d’augmenter de 155Twh notre production d’énergie ?

Il y a un problème de physique. L’augmentation de la consommation prévue est plus forte que l’augmentation de la production.

Côté production : Entre aujourd'hui et 2030, l'Europe prévoit de mettre en service environ 150 à 200 TWh supplémentaires d'électricité décarbonée (solaire, éolien, nucléaire). Ce sera le résultat de chantiers massifs qui mettent des années à sortir de terre.

::callout{type=warning} Attention, c’est une prédiction d’augmentation mais l'AIE souligne dans son Accelerated Case que la vitesse de mise en service réelle des réseaux et des parcs éoliens/solaires peine à maintenir cette cadence nécessaire de ~25 à 30 TWh/an de croissance nette sur tout le continent. ::

Côté demande : il y a compétition sur l’usage. l'Europe doit électrifier la voiture (passer au 100 % électrique), l'industrie (décarboner les aciéries) et le chauffage (pompes à chaleur). Les datacenters entrent en concurrence directe pour capter chaque gigawatt décarboné disponible.

Pour bien comprendre :

• Les datacenters à eux seuls réclament +155 TWh sur la même période.
• Mais la transition écologique impose déjà d'alimenter les pompes à chaleur, l'industrie et les millions de véhicules électriques, ce qui absorbe déjà l'intégralité des 50 TWh restants (du scénario le plus optimiste).

Le bilan : Il manque physiquement ++à minima++ 50 TWh d'énergie décarbonée en 2030 pour satisfaire à la fois les objectifs du Pacte Vert européen et la trajectoire actuelle du numérique.

Si on va moins vite sur la décarbonation des transports pour financer le numérique, ce sera une erreur fondamentale.

De plus certains lieux sont déjà en énorme tensions sur l’énergie :

• l’Irlande, 20% de sa conso électrique est dédié aux datacenters et a du mettre en place un moratoire de fait (subie) sur la construction de nouveaux centres de données
• Les villes comme Francfort, Londres, Amsterdam, Paris, Dublin sont en tension. Dans certains endroits, on ne peut plus construire de nouveaux logements faute d’énergie disponible.
• en Allemagne, aux Pays-Bas et au Royaume-Uni), les demandes de raccordement en attente pour les infrastructures énergétiques et industrielles représentent aujourd'hui plus de 500 GW de puissance (soit l'équivalent de plusieurs fois la capacité installée totale de la France).

Sans parler des soucis de raccordement au réseau. En Europe, il faut en moyenne 7 à 10 ans pour renforcer le réseau électrique et raccorder un gros datacenter.

Un projet d'infrastructure déposé aujourd'hui se voit attribuer des dates de raccordement au réseau électrique entre **2032 et 2038** dans plusieurs hubs européens. La demande n'est pas seulement supérieure à la production : elle va 3 fois plus vite que la capacité du réseau à poser des câbles et bâtir des postes sources.

La trajectoire de 230 Twh n’est pas réaliste physiquement.

Donc est-ce que notre réseau peut l'absorber ? Non, et surtout pas à n'importe quel prix, pas en sacrifiant le reste des efforts sur la décarbonation. La France a un atout unique en Europe : une électricité parmi les plus décarbonées du continent grâce au nucléaire et aux renouvelables. Mais notre capacité de production n'est pas infinie. Accepter tous les projets de datacenters de manière aveugle créerait un conflit d'usage direct avec la réindustrialisation ou l'électrification de nos transports.

Il y a donc deux scénarios possibles :

Choix 1, on subit : on peut effectivement refuser ces implantations. Les géants de la Tech créent alors ces capacités aux États-Unis ou ailleurs, parfois en rallumant des centrales à gaz ou au charbon, tout en nous revendant leurs services, en nous imposant leurs conditions, y compris environnementales. L'Europe paie le service, subit l'empreinte mondiale et perd la main

Choix 2, on choisit : L'Europe et la France assument de construire des datacenters sur leur sol, mais comme l'électricité n'est pas infinie, elles utilisent la souveraineté pour arbitrer et rationner.

Il nous faudra de la sobriété numérique. Et être sobre, ce n'est pas refuser de construire des infrastructures chez nous par posture idéologique et morale. C'est utiliser notre souveraineté pour conditionner et sélectionner.

Être sobre et souverain, c'est :

1. Rationner l'accès au réseau : Réserver nos capacités électriques décarbonées aux datacenters d'acteurs européens ou engagés sur des usages stratégiques (santé, climat, recherche, industrie), plutôt qu'à la surconsommation de services étrangers récréatifs (oui, on peut se dire que les nudes de Grok et les images à la Ghibli c’est peut-être pas la priorité non ?).
2. Imposer des normes environnementales drastiques : Interdiction du refroidissement à eau perdue, PUE performant (rendement énergétique pour faire simple), obligation d'écoconception (par exemple récupération de la chaleur fatale pour chauffer les logements voisins)
3. Miser sur des modèles frugaux : Favoriser le développement de modèles d'IA plus petits, spécialisés et "open-weight", bien moins gourmands en calcul.

La surconsommation prévue par les grands de la tech n’est pas une fatalité. Elle repose sur une bulle financière et des tas d’investissements en circuit fermé qui vendent aux investisseurs un plan de croissance. Ce surinvestissement permet de financer des usages à perte, des usages qui ne devraient pas être gratuits (comme Grok dans X par exemple), une multiplicité des modèles frontières, des centaines de softs pour faire la même chose, des tensions sur les resources minières, des tensions sur les composants (Cf la crise de la ram) alors même que certains usages grands public sont déjà adressés. Nous ne trierons pas plus vite nos emails avec Opus 72. La plupart des modèles open source suffisent déjà pour une grande majorité d’usage.
Nous avons déjà réalisé d’énormes avancées sur l’optimisation des couts d’entrainement ou d’inférence. La technologie ne cesse de s’améliorer en efficacité énergétique mais les usages s’intensifient. De nouvelles puces sont apparues, de nouvelles approches algorithmiques ont vue le jour. Il est temps d’empocher nos gains pour investir désormais dans ces pistes là.

J’espère que cette bulle va exploser pour assainir le marché. Mais par contre l’IA ne disparaîtra pas avec la bulle, pas plus qu’internet n’a disparu après l’explosion de la bulle internet en 2000.

Mais j’espère, pour nous, qu’il restera un acteur européen après cette explosion.

Quelle est la trajectoire soutenable ?

Alors, quelle est la limite ? Pour que le numérique reste soutenable et pas un boulet énergétique, l'Europe doit imposer un plafond d'atterrissage.

Au lieu d'accepter les projections à 230 TWh poussées par les géants de la Tech et la bulle actuelle, la trajectoire soutenable pour l'Europe se situe autour de 80 à 100 TWh/an à l'horizon 2030-2035 (soit environ 10 à 12 TWh pour la France, ce qui correspond aux scénarios prudents de RTE). À cette échelle, l'empreinte des datacenters resterait contenue à moins de 3 % de l'électricité européenne.

Ce « budget électricité » de 80 à 100 TWh permet de concilier les deux impératifs :

1. Financer la souveraineté : Offrir la puissance de calcul nécessaire pour développer nos propres champions, sécuriser nos données et faire tourner une IA industrielle et scientifique stratégique.
2. Préserver le climat : Ne pas siphonner les gigawatts décarbonés dont nos voitures électriques, nos pompes à chaleur et nos usines ont urgemment besoin pour sortir du pétrole et du gaz.

Conclusion

Opposer écologie et souveraineté est une erreur. On ne tracera pas une trajectoire écologique viable tout seul dans notre coin et sans avoir notre indépendance économique et numérique. Mais dans l’autre sens, on ne pourra pas continuer à augmenter nos usages à l’infini sans se heurter au mur des réalités physiques.

Construire des datacenters c’est se recréer de la souveraineté et donc se redonner des choix. C’est pas un chèque en blanc pour construire sans limite. Mais c'est le seul outil politique qui nous donne le droit de dire non, de poser des règles et d'imposer un plafond.

Refuser les datacenters sur notre sol sous prétexte d'écologie est une illusion d'optique. Cela ne fait qu'exporter la pollution chez des voisins au mix énergétique carboné, tout en nous privant des clés de notre avenir. Si nous voulons un monde numérique compatible avec les limites planétaires, nous devons avoir le courage de construire ses infrastructures chez nous, pour avoir le pouvoir d'en dicter les règles.

Contexte : plusieurs applications dans des monorepos (hakanai, Writizzy, Bloggrify), polyglotte (Nuxt, Kotlin, JS), solo dev, du code écrit en grande partie par des agents, du déploiement continu en production.

::toc{open="true"} ::

L'idée directrice

Même si les agents de dernière génération sont désormais capables de produire du code de qualité (bien mieux que la majorité des développeurs humains), la production de code ne représente qu'une partie de ce que j'appelle la qualité logicielle. Le reste c'est :

• l'intention (pourquoi, pour qui)
• est-ce que ça satisfait les 4 risques identifiés par Marty Cagan :
  • Value : risque lié à la valeur
  • Usability : risque lié à la facilité d'utilisation
  • Feasability : risque lié à la faisabilité
  • Viability : risque lié à la viabilité commerciale
• on peut rajouter : performance et fiabilité

Une partie de ces risques se résout avec une bonne compréhension de son marché, des benchmarks, des interviews, des tests manuels, des maquettes. Tout ça fait également partie de mon "usine logicielle" même si je ne décris pas tout ici.

Le code produit est désormais quasi 100% généré, mais ça ne veut pas dire que c'est du vibe coding. Le vibe coding tel que défini par Karpathy c'était de l'expérimentation et le fait de se laisser porter par une session de dev. Ici, je vais parler de context engineering. L'objectif c'est de donner tout le contexte nécessaire, au bon moment, pour que le logiciel corresponde à une intention et soit contrôlé systématiquement. Même si je n'écris pas le code, j'en suis responsable et je dois garder le contrôle dessus.

L'outillage décrit ici répond à plusieurs questions :

1. Qu'est-ce que l'agent sait ? (contexte, mémoire, graphe de code)
2. Qu'est-ce qu'il sait faire de façon déterministe, sans improviser ? (skills, procédures)
3. Qu'est-ce qui l'arrête quand il se trompe ? (hooks, tests d'architecture, quality gates)

Couche 1 : le contexte

Voici les fichiers lus par les agents avant de démarrer. Attention, la taille du contexte doit rester contrôlée. Un trop gros contexte coûte de l'argent et dégrade la qualité des réponses s'il devient trop chargé. On cherche à économiser les tokens et à optimiser le moment où une information est chargée.

La séparation compte : le contexte permanent reste court, le contexte spécialisé se charge quand il sert.

Contrainte long terme comme contexte. Exemple concret : je prévois d'open-sourcer une partie du code. La règle « le code destiné à l'open source ne doit jamais dépendre du code propriétaire » est écrite dans les rules et vérifiée par un test (voir couche 4). Écrire une contrainte future dans le contexte évite de payer une refonte plus tard.

On peut trouver aussi des contraintes sur :

• la copy marketing (les libellés dans l'application)
• la façon d'écrire des migrations
• les types à privilégier pour les champs en base
• les patterns d'asynchronisme
• etc. (liste très loin d'être exhaustive et qui s'enrichit régulièrement)

Une contrainte c'est propre à un projet et à une personne. C'est pas une question de qualité logicielle au sens strict du terme. C'est pas mieux ou moins bien de faire du feature flag par exemple, mais c'est ma préférence pour le déploiement partiel et l'activation de features en test.

Inutile de dire à une IA d'"écrire du code de qualité", ça ne rime à rien. Il faut expliciter ses propres contraintes.

Exemple de rule qui permet un chargement différé en fonction du contexte :

A chaque fois que je te demande de commiter, utilise le skill commit-convention

C'est tout con, mais ça évite de charger l'ensemble de la skill dans une rule (qui serait chargée systématiquement).

Voici une rule plus complexe :

---
paths:
  - "api/**/*"
---

Tu agis en tant qu'Expert Senior Kotlin et Spring Boot (DDD, Spring, JPA).
Tu as des patterns à respecter. AVANT d'écrire du code, tu DOIS invoquer le skill correspondant à la tâche que tu réalises.

## Skills à invoquer selon la tâche

| Tâche                                                                           | Skill             |
|---------------------------------------------------------------------------------|-------------------|
| Entités JPA, repositories, modèle de données                                    | `kotlin-jpa`      |
| Database schema changes, Flyway migrations, and Hibernate/Kotlin entity mapping | `db-migration`    |
| Services, logique métier, transactions                                          | `kotlin-services` |
| Controllers, APIs REST, DTOs                                                    | `kotlin-api`      |
| Tests unitaires ou d'intégration                                                | `kotlin-tests`    |
| Fin de tâche, validation avant de confirmer                                     | `kotlin-review`   |
| Feature gating par plan (offers.sql, FeatureService, quota, accès conditionnel) | `offers`          |
| Feature flags Unleash (rollout progressif, admin-only, maintenance, toggle runtime) | `feature-flags` |
| Producers RabbitMQ, consumers, outbox pattern, retry/quarantaine, config AMQP     | `rabbitmq`        |

Ici il y a deux choses importantes :

• le pattern d'activation, qui précise que cette rule ne se charge que si on touche au répertoire api
• le tableau qui liste toutes les skills disponibles, à n'ouvrir qu'en cas de besoin. Si l'IA ne fait pas de changement de schéma, aucun intérêt d'aller ouvrir la skill db-migration

Couche 2 : les skills

Une skill est une procédure écrite une fois, rejouée à l'identique. L'agent la charge tout seul quand le contexte matche. Ce chargement automatique peut parfois échouer. Dans ce cas, il faut demander explicitement d'utiliser la skill.

Le critère : est-ce que je me répète ? Si j'explique la même chose une troisième fois, ça devient une skill.

Chez moi, une trentaine, groupées par famille :

Deux choses que j'ai apprises :

• Les skills « procédure multi-fichiers » sont les plus rentables. Exemple : ajouter un bloc à l'éditeur de contenu touche trois surfaces de rendu différentes. Sans skill, l'agent en oublie systématiquement une.
• Les skills « doc à jour » sont très importantes sur du code qui évolue rapidement. Ça permet à un agent de comprendre les points d'entrée et les intentions d'une feature.

Sous-agents : pour les tâches qui génèrent beaucoup de lecture sans beaucoup de décision (audit, exploration large, rédaction de doc), je délègue à un sous-agent. Il consomme son propre contexte et me rend une conclusion, pas un dump de fichiers. Je les utilise de moins en moins, les agents récents font eux-mêmes des délégations assez ciblées.

Couche 3 : les outils

On entend souvent qu'une IA est non déterministe et qu'elle peut se tromper sur des choses triviales et qui doivent être déterministes, par exemple calculer 2+2.

C'est globalement faux désormais, et une IA ce n'est plus "juste un LLM" : elle dispose de nombreux outils pour contrôler une sortie. Il n'en reste pas moins que le meilleur moyen d'assurer une forme de reproductibilité, c'est de déléguer à des outils dont c'est le boulot.

La compilation, l'exécution des tests, les linters, tout ça c'est de la délégation. On peut déléguer à des MCP, ou à des skills qui utilisent elles-mêmes un outil en ligne de commande (CLI). J'essaie d'éviter les MCP qui sont plus consommateurs en contexte, mais j'en ai quand même quelques-uns.

MCP

GitNexus

Le repo est indexé dans un graphe (symboles, relations, flux d'exécution). Ça permet de mesurer les niveaux d'impact et de retrouver tous les liens avec le code en cours de modification :

• impact(symbole) avant de modifier : rayon d'explosion, appelants, niveau de risque
• detect_changes() avant de commiter : est-ce que je n'ai touché que ce que je voulais ?
• chercher un flux d'exécution plutôt que grepper un nom de fonction
• renommer via le graphe d'appels plutôt qu'en find-and-replace

Le vrai sujet c'est pas la vitesse, c'est de détecter tous les effets de bord d'une modification.

Claude-mem, mémoire persistante

J'utilise deux niveaux de mémoire :

• la mémoire interne de Claude
• Claude-mem, qui permet de capturer des décisions entre les sessions

Ce qu'on veut avec ces outils, c'est éviter de reproduire des erreurs, documenter des décisions et ne pas repartir à chaque fois d'une session vide.

Le mécanisme de mémoire interne de Claude Code s'est amélioré et devient plus pertinent qu'avant avec les dernières versions. Il faut cependant le contrôler et ne pas hésiter à lui demander de supprimer des règles qu'il se crée tout seul et qui sont parfois un peu idiotes. Claude-mem, j'ai honnêtement un peu de mal à mesurer l'impact négatif ou positif. J'ai pas encore assez de recul dessus.

Filtrage des sorties

Un wrapper (ici RTK) préfixe les commandes shell et ne renvoie que ce qui est nécessaire. Ça reste très limité, uniquement disponible pour quelques outils. Le gain est parfois annulé car Claude lance deux fois la commande. Ça mange pas de pain, mais je pense qu'il y a encore une marge de progression. À savoir que Claude se construit ses propres outils à la volée en Python ou en Bash, et sait aussi utiliser des mécanismes de filtrage à base de grep, tail, etc. pour optimiser lui-même les sorties des outils qu'il utilise et économiser des tokens.

Débogage avec accès aux logs et à la base de données

J'utilise deux skills pour la résolution d'incidents :

• une skill Sentry pour aller lire les informations sur Sentry et récupérer les stack traces
• une skill db-query qui donne les droits d'accès en lecture seule sur la base (l'accès en lecture/écriture est possible directement via psql sur le container Docker en dev local)

Je pourrais aussi mentionner le MCP Stripe, en lecture seule également, qui permet dans certains cas spécifiques d'aller investiguer des soucis de configuration de Stripe.

Couche 4 : les garde-fous exécutables

Les garde-fous évitent le côté aléatoire lié à la compréhension et à l'exécution d'une consigne. Il arrive qu'un LLM ignore une rule. Il faut donc fournir des outils qui s'exécutent automatiquement.

Hooks

Des scripts déclenchés par le harness de l'agent, pas par l'agent lui-même.

Autres usages qui marchent bien : bloquer l'édition de fichiers générés, exiger un test à côté de tout nouveau module, interdire un pattern dangereux.

Tests d'architecture

Les règles structurantes deviennent des tests qui cassent la CI.

Exemple réel, j'ai un test d'architecture qui préserve la frontière entre le futur code open source et le reste :

• aucun fichier du côté « ouvert » ne référence le côté « propriétaire »
• tout fichier de production appartient à l'un des deux côtés

Ça fait partie des tests automatiques, donc ça ne peut pas être contourné, à l'inverse d'une rule.

Lint de patterns

J'utilise plusieurs choses :

• ESLint pour la syntaxe
• ast-grep pour les décisions d'architecture, par exemple interdire tout appel à fetch sans passer par le client OpenAPI
• le typecheck pour le typage

Couche 5 : l'usine

Une quality gate bloquante, par application

Chaque app a son workflow sur GitHub Actions.

push sur main
   └─> quality gate : lint → lint de patterns → typecheck → tests
        └─> build image docker
             └─> push registry
                  └─> webhook de déploiement

Le job de déploiement a un needs: sur le job de qualité. Rien ne part en production sans passer la gate. C'est indispensable en règle générale, encore plus pour du code produit automatiquement.

Tester à plusieurs étages

Je devrais pas avoir besoin de réexpliquer ça, mais dans le doute, j'ai plusieurs types de test.

Je donne des instructions à Claude pour expliquer la hiérarchie des tests, gitnexus lui indique quoi rejouer pour valider ces modifications, et il a des consignes pour en écrire quand il ajoute/modifie du code.

Couche 6 : Le process produit

Comme je le disais en intro, le but c'est pas juste de produire du code, c'est de produire du code qui sert à quelque chose.

Le process commence souvent par une spec, puis un design, puis une implémentation.

Spec d'abord. J'ai un dossier de specs numérotées, une par domaine fonctionnel, indexées dans le contexte permanent. Deux skills encadrent le cycle : une pour rédiger la spec et son plan, une pour la clôturer en la mettant à jour avec ce qui a réellement été construit.

Cette spec et les discussions peuvent s'appuyer sur un fichier 'product-marketing-context.md' que je créé dans chaque projet et qui récapitule mes personas, mes compétiteurs, mon positionnement etc...

Le design. Par design j'entends deux choses : la conception technique et l'interface. La conception technique fait partie de l'étape de spec. La majorité du temps une spec suffit, mais certains cas un peu tricky nécessitent une spec dédiée à une brique technique ou à un choix technologique. Par contre l'étape de design/maquettage est à part. Je la réalise dans Claude Design. Je fais une maquette fonctionnelle et j'itère jusqu'à ce qu'elle soit parfaite. Je vérifie la compréhension, les libellés, l'utilisabilité. Ensuite je peux passer le résultat à Claude Code.

L'implémentation. Claude part de la spec et de la maquette. Il suit le plan réalisé dans la phase de spec. La spec est faite pour être livrée par étapes (protégées par feature flag). Ça me permet de faire plusieurs petites sessions d'implémentation plutôt qu'une grosse session, qui a tendance à se dégrader en qualité si elle se remplit trop.

L'étape de clôture est importante : sans elle, les specs deviennent obsolètes en six mois.

Règle explicite dans le contexte : si une spec est floue ou incohérente avec l'existant, l'agent doit poser la question, pas deviner.

Livraison progressive.

Je travaille en trunk based. Par contre j'utilise du feature flipping et du gating, ce qui représente deux choses différentes :

J'ai des skills qui expliquent la différence, pour que les agents ne fassent pas n'importe quoi et respectent mon process de travail.

Par où commencer

Si vous partez de 0, la première étape c'est la quality gate si vous n'en avez pas. Vous devez avoir un mécanisme de contrôle qui joue les tests, les linters etc... Ensuite faut commencer léger avec un Claude.md qui décrit l'essentiel, le pourquoi. Ajoutez des rules au fur et à mesure pour les patterns d'architecture importants. Dès que vous voyez des procédures qui reviennent souvent, documentez ça sous forme de skills. Et puis équipez-vous des cli et MCP pour interagir avec vos outils principaux, jira, sentry, etc...

Attention, tout skills, MCP, code repris depuis l'extérieur doit être scruté. Ce sont des dépendances qui peuvent être des vecteurs d'attaques.

A retenir

1. Ce qui compte doit être exécutable. Une consigne est suivie « la plupart du temps », mais elle peut être oubliée. Un hook ou un test est suivi tout le temps.
2. Une erreur doit être documentée. Chaque erreur doit être consignée dans une skill ou dans la mémoire.
3. Le contexte est un budget. Wrappers, filtres, sous-agents, résumés : tout ce qui réduit le bruit garde le raisonnement sur le problème.
4. Mesurer les impacts avant et après l'édition. On veut éviter l'effet « 1 bug résolu, 10 de produits ».
5. Les procédures répétitives ne s'improvisent pas. Une skill par procédure.
6. La doc de spec meurt si sa clôture n'est pas dans le process. Il faut prévoir l'étape de mise à jour et de maintenance.

A améliorer

La mise à jour des skills/rules

Il faut prendre en compte que la techno est encore très jeune, février 2025 si on considère la programmation agentique. L'outillage se perfectionne mais il faut constamment aussi le revoir. Milieu 2025, certaines consignes dans un Claude.md faisaient sens, par exemple "écris un test pour chaque nouveau service". Aujourd'hui c'est du bruit et Claude le fait naturellement. Donc il faut se méfier de ses anciennes rules, parfois elles sont obsolètes et créent du bruit. J'ai aucun moyen de mesurer et de savoir si une ancienne rules est devenu obsolète.

Les dernières versions d'Opus sont de plus en plus autonomes. L'IA prend l'initiative tout seul de builder, de regarder le contenu produit, de lire le code des dépendances pour comprendre les appels, trouver des bugs, lancer des tests dans le navigateur. C'est limite flippant et plus rigoureux que 99% des humains. Soyons honnête, je suis de moins en moins utile sur les phases d'implémentation, mais je ne veux pas perdre le contrôle du code produit. Je suis partagé entre la satisfaction d'avoir une usine logicielle de plus en plus efficace et le risque de perdre la connaissance. Je dois trouver un moyen pour contrôler a posteriori les designs, de m'approprier le résultat.

Le problème du rabbit hole

J'ai ajouté récemment une rule boyscout.md

Laisser le code toujours un peu meilleur qu'il n'était avant. Si tu vois des erreurs flagrantes, signale moi des améliorations. Si tu constates des écarts avec la doc ou des infos présentes dans tes skills, ou dans ce fichier, idem, signale les.

Mais je me retrouve à faire des sessions sans fin. Je pense que je n’ai jamais bossé sur une base de code qui se maintient autant à jour. J’ai rarement autant amélioré le produit à ce niveau de détail. Mais ça vient avec un coût, la surcharge cognitive.

Je pense que j'aurais besoin plutot de noter automatiquement ces éléments là et de les catégoriser dans une TODO list en ligne (trello, todoist etc...). Je pense que le workflow pour la maintenance devrait se déplacer ailleurs, et être partiellement automatisé.

Le manque de standardisation

Je copie colle encore mes skills/rules etc… d’un projet à l’autre. Et parfois c’est dépendant à mon poste en fonction d’un skill installé en local.

Je dois trouver un moyen de packager mes skills pour les déployer là où c’est pertinent et pour centraliser la maintenance.

Le reste

Dans les autres points d'amélioration en suspens :

• ma dépendance à Claude. Je souhaite tester des modèles open weight mais je n'ai pas le matériel pour ça. Risque modéré selon moi, tout l'écosystème bouge vers le haut
• l'IDE devient obsolète par rapport à ce nouveau workflow. J'utilise encore intellij mais je ne le trouve plus adapté à notre époque. Je n'ai pas encore vu une alternative intéressante.

En réalité, c'est un peu plus compliqué.

Les compromis

Des fois il y a des services que j’ai tellement l’habitude d’utiliser que j’ai oublié qu’ils étaient US, je pense à Sentry par exemple. C’est un service que j’utilise depuis au moins une décennie et j’ai vraiment du mal à m’en passer. Le pire c’est que si je trouve un service équivalent, c’est plutôt simple d’en sortir mais comme ça me coute 0 euros aujourd’hui, je me dis que c’est pas non plus une urgence, je finance pas un produit US pour l’instant.

J’accepte avec plaisir des suggestions ;)

Les dépendances critiques

Ensuite il y a des services critiques, open source, mais bel et bien US, je pense à Let’s encrypt. On pourrait me dire que c’est juste de la tuyauterie, c’est open source, on s’en fiche etc… Dans les faits, Let’s Encrypt a interdit son usage en Iran et en Russie également. Ca fait partie des briques de base qu’on devrait avoir en Europe pour rester souverain.

Dans les autres services critiques, il y a le paiement. J’utilise Stripe, et même s’il y a une antenne officielle en Europe ça reste un produit US. Il n’y a pas pour l’instant d’équivalent de cette qualité mais on commence à voir des produits plutôt intéressants qui émergent, je pense à Creem.io, Paddle, ou Mollie. Il y a toujours ça et là des petites fonctionnalités qui m’empêchent de vraiment faire la bascule mais les alternatives sont désormais assez sérieuses pour être utilisables dans de nombreux cas.

Mais depuis hier je me heurte à un nouvel obstacle, les emails.

Le problème des emails

Envoyer des emails n’est pas si simple qu’il y parait. Alors déjà, petit point de vocabulaire, on va distinguer :

• les emails transactionnels (oubli de mot de passe, vérification d’adresse etc…).
• les emails marketing, envoyés en masse à plusieurs destinataires (par exemple une newsletter)

Maintenant qu’on sait faire la différence, il faut comprendre que certains opérateurs refusent l’envoi d’emails marketing pour de nombreuses raisons (volonté de préserver leur réputation IP pour ne pas se faire blacklister, et pour limiter leur exposition à certains risques juridiques lié à la façon dont on envoie les emails marketing).

Pas de chance, Writizzy est un service qui peut se comparer à Beehiiv et Substack. J’envoie des newsletters.

Si j’ai choisi Scaleway à l’origine, c’est pour deux raisons :

• C’est en Europe
• Le cout pour mille emails (CPM) est de 0.25 euros.

Le mur économique

Et c’est là que tout se complique.

Le CPM c’est le nerf de la guerre. À ce niveau-là, quelques dizaines de centimes de différence changent complètement l'économie du produit. Tous les autres concurrents en Europe sont entre 0.4 et 1 euros en CPM. Entre 2 et 4 fois plus cher que Scaleway.

A ce prix la, il est impossible d’être rentable face à mes concurrents. Je ne peux pas vendre une offre compétitive avec un CPM au dessus de 0.25 si je prends une offre Européenne.

À ce stade, trois choix s'offrent à moi :

• Construire mon propre opérateur.

Je peux utiliser un produit open source (postalserver ou hyvor relay), construire ce qui manque par dessus et devenir moi-même opérateur email. C’est un chantier titanesque (vraiment…)

• Passer chez un fournisseur américain.

Il existe des solutions a 0.10 de CPM, jusqu’à 10x moins cher que certains produits EU !!

• Renoncer à proposer une offre compétitive.

A long terme, le 1er choix me semble le plus judicieux. Mais à court terme, j’ai déjà des clients, et c’est l’impératif économique qui va s’imposer à moi.

Est ce que vraiment on a envie que ce soit ça le prix de la souveraineté ? Etre moins compétitif à l’international ?

Et donc ?

Ca me fait suer de devoir choisir entre mes valeurs et la viabilité économique.

Si j'ai écrit cet article, ce n'est pas pour dire qu'il est impossible de construire un SaaS européen. Au contraire, je pense que c'est de plus en plus réaliste. Le problème n'est plus vraiment de trouver des alternatives. Elles existent désormais dans beaucoup de domaines.

Mais il faut qu’elles soient compétitives, notamment sur certains services critiques où les marges sont extrêmement faibles. Ne venez pas me dire qu’on peut pas faire moins cher qu’un service US. Je connais la réalité des boites US, les salaires sont plus élevés, leur cout marketing sont plus élevés, il n’y a rien qui justifie qu’on soit entre 4 et 10x plus cher. Et c’est pas un souci d’échelle non plus, en vendant plus cher que le marché, c’est normal de pas avoir plus de clients.

Je continuerai à privilégier des solutions européennes dès que c'est possible. Pas parce qu'elles sont européennes, mais parce que je veux qu'un jour elles deviennent les meilleures.

En attendant, certaines décisions seront dictées par l'économie plutôt que par mes convictions.

Et il faut aussi qu’on se dise quand ça bloque. Pas pour se plaindre, mais pour montrer où il reste des opportunités. Et il y en a.

Ou… pourquoi ne pas en faire ?

Je développe un produit, writizzy.com et j’ai commencé à me poser cette question en me demandant, comment faire un logiciel durable ? Est-ce que l’open source est une piste pour ça ?

Au delà de la durabilité, je travaille depuis le début des années 2000 et globalement mon métier a drastiquement changé. Une des grandes raisons est lié à l’essor de l’open source.

Alors certes, quand j’ai démarré mes études d’informatique en 1997, on travaillait déjà sur linux avec de nombreux logiciels open source mais mes premières expériences dans le monde du travail, ressemblaient surtout à de l’archéologie. Ma mission était de retrouver les CD de documentations disséminés dans les étages, et d’interroger les bons experts pour comprendre pourquoi le logiciel qu’on utilisait réagissait de telle ou telle façon. Sans avoir accès au code source il fallait deviner comment ça marche et surtout il fallait réinventer la roue sans arrêt pour a peu près tout, ce qui donnait des logiciels de qualité très discutables.

J’ai vu mon métier changer et l’open source devenir une des fondations de tout l’informatique moderne. Alors oui, j’ai envie de contribuer à mon tour.

Mais j’appréhende les contraintes qui vont avec.

Je suis tiraillé entre la volonté d’un retour à un web plus ouvert et, basiquement, les impératifs économiques.

C’est ce dilemme que je veux explorer ici. À travers l’exemple de Writizzy, voici pourquoi j’hésite à ouvrir mon code, ce que j’aimerais pourtant faire, et ce que j’envisage pour la suite.

Les bénéfices de l’open source

Bon déjà, pourquoi faire de l’open source ? A chaud je dirais :

• pour contribuer à un écosystème
• pour une distribution plus large
• pour les contributions et la sérendipité
• pour la transparence
• pour un web plus ouvert

Mais comme on va le voir, c’est pas si simple.

Un marketing et une distribution simplifiée

On va pas se mentir, l’open source est un levier de communication. L’open source permet un usage plus large et donc se de faire connaitre par bouche à oreille. C’est la possibilité d’avoir des hébergeurs qui proposeraient Writizzy en marque blanche, ou des utilisateurs qui pourraient faire leurs propres themes/plugins et les vendre sur une marketplace (comme Ghost). Ca a l’air de rien mais dès lors qu’une économie se met en place autour de votre produit, cela lui garantit une certaine notoriété. C’est de la “pub” gratuite.

Ok mais, à quel prix ?

Que ce soit Wordpress, Ghost ou Gitlab, combien utilise vraiment le service commercial proposé par l’éditeur ? Et combien de services commerciaux se sont greffés autour de ces logiciels, tout en évitant de contribuer directement au projet open source ?

Voici les chiffres d’affaires annuel estimé pour plusieurs concurrents de Writizzy :

• Substack : 45 M$
• Beehiiv : 30M$
• Ghost : 10M$

Ghost est la seule plateforme open source des 3. On estime que l’économie qui gravite autour de Ghost créé environ entre 15 et 25M$.

C’est a dire qu’environ 20M$ est capté en dehors de Ghost.

Imaginons que Writizzy marche, soyons fou, est-ce que j’ai pas le risque d’avoir des acteurs qui exploitent commercialement Writizzy, ne contribuent pas au projet open source, profite de mes investissements en publicité, et me laisse gérer toute la difficulté de la maintenance du logiciel ?

Oui l’open source c’est noble, mais ça fait pas manger et je veux pas finir comme l’un de ces innombrables projet open source qui survit péniblement et qui finit par fermer.

Deux options sont possibles, avoir une license restrictive qui empêche un usage commercial, ou juste… s’en fouttre.

Ghost s’en fout. Parce que c’est une boite sans actionnaires à rémunérer et qu’ils ne recherchent pas la maximisation de leur profit.

Mais si j’y réfléchis bien, c’est pareil pour moi. Bon déjà, je serais très heureux d’avoir ne serait-ce que le 10eme de la réussite de Ghost. Si j’y arrive, en partie, parce que le modèle open source a permis de faire parler du produit, je peux aussi me dire que j’ai atteint mon objectif non ? Et puis bon, ce serait hypocrite de ma part, moi aussi j’utilise des briques open source pour aller plus vite, non ?

Je créé un produit commercial, je ne vais pas le cacher. Mais je ne vise pas à créer une multinationale de 400 personnes donc, avoir un écosystème qui se créé autour du projet et qui vit dans son coin mais qui fait aussi augmenter la visibilité du projet, pourquoi pas ?

Après, je veux pas laisser penser que “open source = succès” magiquement. Si le projet n’intéresse personne, ce sera peut-être pareil même en open source. C’est un peu ce qui m’est arrivé sur Bloggrify.

Les contributions (inattendues) de la communauté

Vous savez comment un produit s’améliore ? Par les retours de ces utilisateurs.

J’ai l’habitude de dire, “on n’a jamais raison tout seul”.

Vous pouvez être un expert de votre propre logiciel, c’est en le confrontant avec de véritables utilisateurs que ce logiciel devient vraiment parfait.

Parce que chaque utilisateur peut venir avec des nouvelles idées, parce que vous pouvez mesurer ce qui est le plus important pour les gens et donc mieux prioriser ce qu’il faut faire ou parce que vous pouvez avoir des contributeurs directs.

Si une personne améliore votre produit, c’est une contribution utile pour tous.

Mais ça vient avec un coût, devoir répondre nuit et jour à une horde d’utilisateurs, pas toujours très respectueux du travail fourni gratuitement. Rappelez vous :

• de Jacob Thornton, co créateur de Twitter Boostrap qui a clairement fini en burnout
• de Salvatore Sanfilippo, créateur de Redis qui a également fini par craquer

Enfin ça c’est quand il y a un un succès. Dans la grande majorité du temps, votre projet va juste avoir 0 utilisateurs et presque aucun retours.

Dans le passé j’avais créé deux projets qui sont plutôt tombés dans cette catégorie :

• pg-mongo-streamer: un connecteur pour alimenter pgsql en répliquant en temps réel les events mongo
• Bloggrify, un générateur de blog statique, une sorte d’équivalent à Jekyll dans l’écosystème Nuxt

Dans les deux cas, la base utilisateur a été très faible donc les retours quasi inexistants. Dans le cas de Bloggrify, c’est surtout devenu une charge de travail pour essayer de mettre en place certains standards d’un projet open source, pour un résultat quasi nul.

Quoi qu’il en soit, oui, cette dimension me fait peur. Je ne peux que souhaiter que Writizzy ait de la traction et me retrouver dans le premier cas. Et en même temps, j’ai peur de pas être capable de suivre.

J’admets que je comprends largement Ben Johson (litestream) qui a choisi de limiter l’ouverture à la contribution pour protéger sa santé mentale et la viabilité du projet, autrement dit, choisir l’open source mais limiter la contribution. Aujourd’hui mon sujet n’est pas d’aller plus vite en termes de production de code de toute façon.

Maintenant quand je parle de contributions, je pense également en termes d’écosystèmes. C’est l’opportunité qu’il y ait des choses qui se créent de façon inattendue. Ca peut être des marketplaces de thèmes, des hébergement communautaires, des plugins, des… trucs… par définition si c’est inattendue je peux pas tellement les lister en fait :)

La transparence : exposer ses faiblesses

Un projet open source inspire confiance, en théorie. Il donne l’illusion que, étant ouvert, tout son code a été adoubé par une communauté d’expert.

Dans la réalité, ouvert ne veut pas dire être lu. Je doute que vous ayez été lire le code source de la grande majorité des outils que vous utilisez sous linux par exemple et vous n’êtes pas le seul. On pourrait citer l’affaire de la porte dérobée dans xz ou de la CVE log4shell.

Quoi qu’il en soit je reste persuadé que c’est préférable à un logiciel fermé. Est-ce que la sécurité par l’obscurité marche vraiment ? Pas vraiment, et c’est parfois l’éditeur lui-même qui place des portes dérobées dans son logiciel.

Mais justement, si j’ouvre le code de Writizzy demain, je suis pas totalement serein. J’ai fait tout mon possible pour que ce soit un logiciel bien conçu et sécurisé mais, soyons honnête, est-ce que je suis sûr à 100% que personne ne trouvera de failles de sécurité ? Non pas du tout. Un ami m’avait d’ailleurs détecté des failles dans Writizzy il y a quelques mois. J’ai des utilisateurs en production, que se passe-t-il si des individus malveillants recherchent activement des failles sur mon code à chaque release ? Ca fait clairement partie de mes craintes.

Pour ce qui est de la "qualité” du code, c’est un autre sujet. Je trouverais toujours des gens pour critiquer mais ça fait 25 ans que je travaille, ça me glisse un peu dessus. La critique est facile, l’art est difficile. Mais pour la sécurité, c’est un autre sujet, impossible à ignorer.

Et aujourd’hui j’ai pas de notion de version. Je mets en production en continu. Est-ce que je dois abandonner ce principe pour laisser un temps de repos avant la mise en production d’une nouvelle version ? Ce serait de la lourdeur supplémentaire que je m’imposerais et je n’ai pas forcément le luxe de pouvoir le faire.

Donc oui, partiellement aujourd’hui je compte sur le fait que personne ne peut lire les erreurs que j’ai pu faire avant que je les corrige. Si c’était open source, ce serait plus le cas. Ca m’imposerait une autre façon de travailler, plus lourde, et plus dangereuse pour mes utilisateurs. C’est clairement un frein.

L’architecture Writizzy est-elle compatible avec un projet open source ?

Un autre point qui m’inquiète, à partir du moment où j’ouvre le code, c’est que Writizzy a une certaine complexité architecturale. Pour faire tourner l’application c’est aujourd’hui :

• 1 API kotlin
• 1 app front pour la partie CMS
• 1 app front qui fait tourner le blog
• un base de données postgresql
• un file de message RabbitMQ

Un utilisateur pourrait souhaiter avoir une seule application et je le comprends.

Toute mon architecture repose sur le fait que je fais tourner tout les clients sur la même instance en multi tenant et j’ai tout le site commercial qui exploite mes utilisateurs dans l’application “CMS”.

Comment faire pour proposer ça en open source ? C’est très loin d’un standard comme Ghost ou Wordpress.

Bon après ce serait pas le seul logiciel comme ça. J’ai récemment installé posthog et il suffit d’utiliser un Docker compose pour cacher cette complexité donc je suppose qu’on peut trouver une solution. J’ai même envie de dire que c’est devenu la norme, désormais la brique unitaire pour installer c’est le docker compose.

Par contre, j’imagine qu’il faudrait que je sépare vraiment la partie admin et site commercial du CMS (EDIT : c’est fait depuis aujourd’hui). Cette partie là resterait en propriétaire. Et il faudrait un mode “mono tenant” pour cacher toute la complexité du multi tenant de façon à ce qu’un utilisateur puisse juste lancer son app pour lui-même.

Si j’ai des pistes, çà n’en reste pas moins des contraintes supplémentaires.

Et le plan pour Writizzy ?

Bon et donc, quel est le plan ? Je construis Writizzy avec une envie aussi de retrouver un web plus ouvert, de sortir des plateformes US, d’inciter les gens à écrire aussi. Parce que écrire, lire, s’informer, est plus que nécessaire dans le monde actuel.

Dans un précédent article je m’interrogeais sur le fait de créer un logiciel durable, l’open source faisait partie des solutions.

Donc oui, je suis partagé. J’aimerais à un moment en faire un produit open source. Concrètement, j’ai commencé à faire des modifications importantes du logiciel pour séparer la partie “commerciale” de l’application elle-même.
J’ai une trajectoire en tête pour isoler ce qui relève de mon application qui permet de vendre et hoster writizzy, du reste, le CMS et le blog.

C’est en cours. Ca permet aussi de se reposer des questions sur les dépendances, de simplifier. Mais peut-être que ça n’aboutira pas.

J’ai pas envie de refaire les erreurs de Bloggrify (trop de lourdeurs pour pas grand chose). Et peut-être que je devrais attendre de voir que Writizzy ait plus de hype derrière lui ? Beaucoup de questions, peu de réponses :)

En tout cas si vous avez de l’expérience sur des projets opensource, vos retours m’intéressent.

a+

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

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

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

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

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

Impact écologique de l’IA

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

On va voir un impact de plusieurs natures :

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

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

La consommation électrique à la création

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

Pour donner un équivalent :

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

La consommation électrique à l’utilisation

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

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

La consommation d’eau

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

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

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

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

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

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

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

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

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

La consommation minière

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

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

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

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

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

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

IA vs les autres usages numériques

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

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

IA vs Internet

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

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

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

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

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

IA vs gaming vs streaming vs visio

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

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

Dit autrement :

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

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

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

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

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

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

C’est pas grave alors ?

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

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

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

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

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

Je n’ai pas la prétention de pouvoir comparer les usages entre eux, par exemple comparer le gaming, le streaming et des usages professionnels. Et même au sein des usages professionnels, je ne vais pas décerner, seul dans mon coin, les bons et les mauvais usages. Mais collectivement il est possible qu’on soit amené à le faire, pas par gaité de cœur, mais par contraintes (Cf chapitre d’après). Mais il est probable que la question ne soit pas juste de bannir l’IA. Ce que ne dit pas non plus le Shift Project qui fait référence en France sur le sujet mais de réfléchir aux volumes et usages dans leur totalité.

nous ne disons pas qu'il ne faut pas faire d'IA, mais pas dans cette trajectoire de déploiement"

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

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

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

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

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

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

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

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

A chacun de faire ensuite ces choix.

Et les augmentations de datacenters ?

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

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

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

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

Oui l’IA joue, mais c’est surtout que le numérique prend de plus en plus de place. La part du numérique dans les émissions de CO2 globale est passé de 2% en 2010 à environ 4% aujourd’hui, avec une augmentation annuelle d’environ 6% alors même que l’objectif global est de réduire nos émissions de 5% par an pour espérer ++stabiliser++ le climat.

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

Concernant les prévisions de constructions de centre de données, et les prévisions de consommation électrique. On pourrait se dire qu’il faut pondérer. Ca reste des prévisions. Elles peuvent être surestimées, comme celles qui prévoyaient un raz de marée avec l’arrivée de la 5G.

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

Mais on parle de signatures déjà faites, de budget déjà signées, d’annonces déjà publiques, comme le projet Stargate ou les futurs investissements de l’Europe. Tous les scénarios actuels tablent entre x2 ou x3. Les usages numériques devraient augmenter, et notamment ceux liés à l’IA, plus que les autres.

Est ce qu’ils vont remplacer des usages physiques (comme dans mon exemple entre la visio et le déplacement en voiture) ? Est ce que c’est que additif, et pas juste du déplacement d’un usage vers un autre ? Il semblerait que non. Certains usages seront sans doute positifs, et vont permettre d’accélérer la décarbonation dans certains secteurs mais c’est presque anecdotique.

Et, selon le Shift Project, c’est surtout que la consommation électrique nécessaire pour faire tourner l’ensemble de ces centres de données va dépasser la capacité de nos infrastructures, et donc imposer d’utiliser des sources thermiques (centrale au gaz) pour compenser ou créer des conflits d’usage.

Donc oui, c’est alarmant. Encore une fois c’est pas le sujet d’interdire l’IA, le sujet est beaucoup plus global que ça. Comment on fait pour faire diminuer nos consommations et notre pression sur la planète ?

A notre échelle il y a des questions à se poser sur nos usages individuels. Il faut se poser des questions sur le renouvellement de nos devices, sur le suréquipement, sur les usages récréatifs inutiles (comme la génération d’images Ghibli pour se marrer). A l’échelle collective on sera contraint, et sans doute bien plus tôt qu’on le pense, à faire des choix entre mettre de l’électricité dans un centre de données ou dans l’alimentation de logement.

Mais rappelons nous d’un truc, l’avenir n’est pas écrit, si on consomme tous un peu moins, on ne consommera pas l’électricité que certains voudraient nous vendre. S’il y a des datacenters en plus, c’est parce qu’il y a une consommation de prévue. Comme dirait Coluche : "Quand on pense qu'il suffirait que les gens n'achètent plus pour que ça ne se vende pas !"

Sources

• https://projetcelsius.com/blog/combien-consomme-requete-chatgpt/
• https://mistral.ai/news/our-contribution-to-a-global-environmental-standard-for-ai/
• https://www.eesi.org/articles/view/data-centers-and-water-consumption
• http://news.bbc.co.uk/2/hi/technology/7823387.stm
• https://greenly.earth/blog/secteurs/quelle-est-l-empreinte-carbone-des-jeux-video
• https://www.carbonbrief.org/factcheck-what-is-the-carbon-footprint-of-streaming-video-on-netflix/
• https://about.netflix.com/en/news/the-true-climate-impact-of-streaming
• https://www.idleforest.com/carbon-footprint/claude
• https://www.youtube.com/watch?v=9oOjjwagGP8
• https://www.youtube.com/watch?t=4013&v=WT67wMsEE2I&feature=youtu.be
• https://www.bcg.com/press/19february2025-data-centers-vers-une-hausse-de-la-demande-energetique-mondiale-de-16-par-an-dici-2028
• https://www.iris-france.org/les-nouvelles-technologies-ia-data-centers-sont-elles-compatibles-avec-les-objectifs-de-durabilite-environnementale/
• https://openai.com/index/announcing-the-stargate-project/
• https://investir.lesechos.fr/marches-indices/enquetes/la-commission-europeenne-annonce-200-milliards-dinvestissements-pour-stimuler-le-developpement-de-lia-et-du-cloud-souverain-sur-le-continent-2235590
• https://www.theguardian.com/world/article/2024/jul/23/ireland-datacentres-overtake-electricity-use-of-all-homes-combined-figures-show

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

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

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

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

L’acquisition payante

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

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

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

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

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

Le tracking de conversion

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

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

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

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

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

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

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

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

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

Les métriques de conversion

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

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

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

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

Ok, cette phrase est cryptique.

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

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

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

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

Stripe me dit que ma LTV est de 181 euros.

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

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

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

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

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

Reddit Ads

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

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

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

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

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

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

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

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

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

On note :

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

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

Le paramétrage des campagnes

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

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

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

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

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

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

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

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

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

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

Les landings et la conversion

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

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

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

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

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

Le bilan

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bref, je suis nul en design.

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

2011, l’armée des clones

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

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

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

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

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

Du design atomique aux design systems

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

::gallery ::

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

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

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

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

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

Tailwind et les design tokens

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

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

.button { border-radius: 4px; }

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

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

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

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

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

Par exemple :

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

etc…

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

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

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

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

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

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

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

Et puis vint l’IA

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

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

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

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

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

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

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

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

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

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

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

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

En condensé mes workflows sont les suivants :

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Les transactions two phase commit

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

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

Mais il y a plusieurs problèmes.

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

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

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

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

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

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

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

Le pattern transactional outbox

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

Le concept est “simple” :

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

Le code devient

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

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

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

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

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

Et il vous faut le code du service de publication

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

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

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

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

Et… c’est pas faux.

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

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

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

Ici les stratégies sont multiples :

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

etc…

Et la gestion d’erreur ?

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

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

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

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

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

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

Challenger ses propres certitudes de dev avec l'IA

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

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

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

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

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

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

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

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

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

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

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

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

::gallery ::

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

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

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

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

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

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

La hausse des CVE

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Attention, ici on a deux sujets différents :

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

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

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

IA slop et maintenance logicielle

Est ce que vous connaissez Dave Farley ?

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

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

(ok papy mais continue ton histoire)

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

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

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

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

Construire une usine logicielle agentique

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

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

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

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

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

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

Bref, il faut les autres machines outils.

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

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

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

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

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

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

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

L’exemple de Writizzy

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

C'est quoi Writizzy ?

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

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

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

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

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

Le Context Engineering : Borner l'IA

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

Le fichier Claude.md

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

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

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

Les Rules (.claude/rules)

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

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

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

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

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

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

La commande "Analyst"

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

La Spec avant le code

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

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

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

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

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

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

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

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

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

Skills vs MCP : Le combat de l'efficacité

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

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

J’ai des skills pour différentes choses :

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

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

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

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

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

Et le design ?

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

Bilan : Comment tenir le budget ?

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

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

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

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

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

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

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

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

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

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

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

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

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

Le SEO fait défaut

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

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

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

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

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

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

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

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

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

Les enseignements du premier run

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Un second run instructif et quelques bugs

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

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

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

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

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

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

Verdict ?

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

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

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

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

Et la, mystère.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

264 milliards d'euros et 1M d'emplois

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

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

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

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

Donc l’open source serait la solution ?

Open source et géopolitique ?

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

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

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

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

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

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

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

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

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

Pas si simple.

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

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

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

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

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

Une fragilité structurelle de l’open source

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

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

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

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

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

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

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

Les communs numériques

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

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

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

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

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

Vers un open source fragmenté ?

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

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

Une identité numérique Européenne

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

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

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

Assez peu.

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

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

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

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

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

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