Nicolas Friedli

Travailler avec un budget de performance web

hello+rss@nicolasfriedli.ch (Nicolas Friedli) — Sun, 30 Aug 2026 00:00:00 +0000

Tester la performance d’un site avec Lighthouse, Web Page Test ou PageSpeed Insights est simple et rapide. Mais cela ne garantit pas une optimisation durable. Un budget de performance permet d’anticiper les contraintes, de cadrer les attentes et d’assurer un suivi continu.

La sortie de Speedlify en version 2 m’a incité à remettre cette vieille page à jour.

Qu’est-ce qu’un budget de performance?

La première visée d’un budget de performance est de faciliter le suivi continu (monitoring) de ses pages web. Un budget de performance fixe les contraintes d’affichage d’une page web en équilibrant:

les ressources consommées (temps de chargement, poids et nombre de fichiers)
les attentes des internautes (rapidité perçue, fluidité de navigation)
les limites techniques (bande passante, capacité des appareils)

Il s’agit de bien utiliser ce qui est accordé (voire de «dépenser» moins) pour garantir une expérience optimale.

Exemple pratique

Concrètement, voici comment appliquer un budget de performance avec Lighthouse:

npx lighthouse https://nicolasfriedli.ch/ \
 --budget-path=budget.json \
 --view \
 --only-categories=performance

Avec un budget défini dans un fichier JSON (mise en forme compacte):

[
 {
 "timings": [
 {"metric": "cumulative-layout-shift", "budget": 0},
 {"metric": "first-contentful-paint", "budget": 1800},
 {"metric": "largest-contentful-paint", "budget": 2500},
 {"metric": "speed-index", "budget": 1200},
 {"metric": "total-blocking-time", "budget": 0}
 ],
 "resourceSizes": [
 {"resourceType": "total", "budget": 300},
 {"resourceType": "document", "budget": 50},
 {"resourceType": "font", "budget": 200},
 {"resourceType": "image", "budget": 100},
 {"resourceType": "media", "budget": 100},
 {"resourceType": "other", "budget": 100},
 {"resourceType": "script", "budget": 10},
 {"resourceType": "stylesheet", "budget": 20},
 {"resourceType": "third-party", "budget": 10}
 ],
 "resourceCounts": [
 {"resourceType": "total", "budget": 10},
 {"resourceType": "font", "budget": 4},
 {"resourceType": "image", "budget": 4},
 {"resourceType": "media", "budget": 0},
 {"resourceType": "other", "budget": 2},
 {"resourceType": "script", "budget": 2},
 {"resourceType": "stylesheet", "budget": 4}
 ]
 }
]

Dans cet exemple, on souhaite par exemple:

l’affichage complet de la page en 2.5 secondes
l’absence de mouvements parasites (Cumulative Layout Shift à 0)
300ko maximum pour l’ensemble des transferts
10 fichiers transférés au plus

C’est un budget très strict, qui peut être utilisé pour ce site, mais trop restrictif dans bien des cas.

Comme la source JSON le montre clairement, il y a 3 catégories de mesures:

la vitesse pure (timings)
la taille des ressources (resourceSizes)
le nombre des ressources (resourceCounts)

Dans chaque catégorie, on peut spécifier une ou plusieurs valeurs.

Budget pour commencer

Il est possible de créer un budget JSON simple pour attaquer le sujet et effectuer ses premiers tests:

[
 {
 "timings": [
 {
 "metric": "largest-contentful-paint",
 "budget": 3000
 }
 ],
 "resourceSizes": [
 {
 "resourceType": "total",
 "budget": 1000
 }
 ],
 "resourceCounts": [
 {
 "resourceType": "total",
 "budget": 100
 }
 ]
 }
]

Dans ce cas, on vise:

une page qui se charge en moins de 3 secondes
qui pèse au maximum 1Mo
qui n’appelle pas plus de 100 fichiers au total

Commencez par là et essayez de le respecter. Si c’est le cas, votre site sera déjà très bon.

La discussion du budget

L’utilité d’un budget de performance dépasse le seul monitoring.

En premier lieu, le budget ouvre les débats dans l’équipe de développement lors de son établissement.

La conférence The Global Baseline, 2022 d’Alex Russell, par exemple, donne les résultats moyens que l’on est en droit d’attendre aujourd’hui. Le conférencier établit ses valeurs en fonction de réalités matérielles (capacité de calcul des téléphones) ou de réseau (bande passante). En version textuelle, une actualisation est disponible dans The Performance Inequality Gap, 2026.

La discussion du budget est une occasion formidable d’instaurer un débat sur ce qui est la «norme» du moment. Elle permet d’apporter la question de la performance dans les équipes web, de manière concrète et pragmatique.

Les problématiques internes

En deuxième lieu, un budget de performance est un outil de dialogue entre les équipes.

Dans la réalité des entreprises et organisations:

les graphistes veulent des typographies spécifiques
le marketing a (soi-disant) besoin de trackers analytiques
la direction souhaite intégrer des widgets sociaux
les juristes veillent à la protection des données

L’objectif est de trouver un compromis réaliste et accessible. Un budget trop ambitieux sera ignoré, tandis qu’un budget trop permissif ne servira à rien.

Dans la durée, un fichier établi par consensus évite de devoir se justifier chaque nouvelle contrainte ou ordre venu d’un autre service. Il légitime les refus des équipes web ou permet de proposer des arbitrages concrets sur des bases solides.

Rapport aux prestataires externes

Troisièmement, travailler avec un budget de performance facilite la relation avec une agence web.

Un simple fichier budget.json permet:

de fixer des attentes claires dès le début du projet
d’évaluer si l’agence maîtrise vraiment les enjeux techniques
d’arbitrer les demandes pour éviter les compromis nuisibles
de justifier d’éventuelles corrections ou d’exiger une réduction de la facture

Ces dernières années, j’ai vu de nombreux sites institutionnels qui sont entrés en production alors qu’ils n’étaient pas optimisés. Avec un budget de performance, il aurait été possible de refuser la livraison, d’exiger des améliorations tangibles ou de négocier un rabais.

Si une agence ne semble pas comprendre de quoi il s’agit, si elle refuse d’entrer en matière sur le sujet ou si elle s’avère incapable de respecter les valeurs souhaitées, mieux vaut envisager un autre partenaire.

Conclusion

Adopter un budget de performance, c’est mettre toutes les chances de son côté pour obtenir un site rapide, fluide et optimisé, tout en facilitant les échanges entre équipes et prestataires. En définissant un cadre clair, on évite les dérives, on pacifie les choix techniques et on assure une expérience optimale aux internautes sur le long terme.

Celles et ceux qui créent des sites en militant pour l’écologie devraient aussi s’intéresser aux budgets de performance. La question du temps de chargement ne sera pas forcément leur priorité. Mais le nombre de ressources et leur taille sont en lien direct avec la consommation du site. Et la performance suivra s’il est très léger.

Pour quelques tests simples, applicables sans délai par tous les internautes, je vous recommande mon billet Tester un site web.

POSSE pour partager du contenu dans les règles de l’art

hello+rss@nicolasfriedli.ch (Nicolas Friedli) — Sat, 29 Aug 2026 00:00:00 +0000

POSSE signifie Publish (on your) Own Site, Syndicate Elsewhere. On pourrait traduire cet acronyme par: Publie sur ton propre site et partage partout ailleurs.

C’est une idée que je défends depuis très longtemps. Je soutenais cette manière de faire quand les réseaux sociaux sont arrivés. Aujourd’hui, les réseaux prétendument sociaux sont merdifiés, mais ce n’est pas une raison pour abandonner les bonnes pratiques.

Lorsque Thierry Crouzet a publié Ni POSSE, ni Facebook: un blog, simplement, je me suis étonné de sa position:

L’idée est simple: on publie chez soi, puis on diffuse partout ailleurs où c’est possible. […]

Selon POSSE, il serait bon de diffuser tant et plus, par tous les moyens, mais c’est très coûteux en énergie, donc irresponsable, et politiquement très douteux.

Je ne comprends pas du tout POSSE ainsi. Pour moi, ce n’est pas une injonction à publier partout ni par tous les moyens. Cette manière de poster ne pose aucune exigence d’automatisation (cross-posting) ou de foisonnement des partages.

POSSE est plutôt une condition minimale, un point de départ. Je le définirais ainsi:

Une fois qu’un contenu a été publié sur son propre site, il peut être relayé partout (sans risque).

En conséquence, je ne propose jamais de contenu uniquement sur des sites privateurs et à l’éthique douteuse. Ou, dit autrement, tout ce qui est publié sur un nom de domaine sur lequel je n’ai pas la maîtrise doit aussi (et avant tout) être disponible sur mon site.

L’enjeu de POSSE porte donc sur la question de la propriété du contenu, pas sur l’ampleur de la diffusion.

L’interprétation de Thierry Crouzet met la pression et pousse à l’excès. Ma compréhension de POSSE est libératrice.

La publication sur mon nom de domaine ouvre des possibles, sans rien imposer. Ensuite, tout est permis (mais tout n’est pas forcément bon): partage sur des réseaux sociaux, des messageries instantanées, des chaînes WhatsApp, des lettres de nouvelles (newsletters), d’autres sites, etc.

Quand on a assuré ses arrières, il est plus acceptable de proposer son contenu dans des endroits peu recommandables.

Je vous suggère de poursuivre avec Nicolas Hoizey dans sa conférence Ne vous laissez plus déPOSSEder de vos contenus!

Une page web est bien plus que son contenu visible

hello+rss@nicolasfriedli.ch (Nicolas Friedli) — Mon, 10 Aug 2026 00:00:00 +0000

Ce que nous voyons intuitivement d’une page web n’est qu’une petite partie de ce qu’elle contient réellement. Un contenu est placé dans un contexte, il porte des éléments sémantiques, il est en lien avec d’autres, il se situe dans un endroit précis d’un site.

Il existe plusieurs manières de créer des pages en ligne. Elles ne produisent pas les mêmes résultats. J’essaie d’expliquer pourquoi.

Mettre en ligne

Dans bien des cas, des contenus sont simplement «mis en ligne». Souvent, ils n’étaient pas destinés à être postés sur le web. Le site est un (bon) moyen de diffusion, mais le résultat reste basique.

Ces contenus prévus pour d’autres usages sont nombreux. Les articles de journaux sont calibrés et pensés pour la version papier. Des publications scientifiques finissent en longs billets de blogs. Les prédications de Diane Friedli sont premièrement orales.

Quand le travail est basique, la nouvelle publication se limite en gros à un copier-coller de son traitement de texte. C’est généralement visible en quelques secondes. Le texte est peu structuré, peu sémantique, des notes de bas de page sont nombreuses, aucun lien dans le corps.

Je ne reproche rien à ce type de publications «juste mises en ligne». Je me réjouis même d’en retrouver en errant, parce qu’elles permettent d’injecter du contenu intéressant «sur Internet». Il faut seulement avoir conscience qu’elles ne seront que rarement des pages «puissantes» de votre site. Mais si le contenu est vraiment bon, elles sortiront du lot quand même.

Quand le travail est mieux fait, ce contenu est adapté au web:

le titre est modifié pour être compréhensible à lui seul
une belle URL est choisie
une image Open Graph est ajoutée pour améliorer le partage (pas forcément visible sur le site)
le contenu de la page est structuré par des intertitres
des éléments sémantiques sont ajoutés
des liens existent

Dans mon quotidien, c’est quelque chose que je pratique très peu. Il est rarissime que je dispose de contenus «non prévus pour le web» qui se retrouvent sur un site. D’habitude, je rédige pour le web ou j’écris en ligne.

Rédiger pour le web

Une spécificité sous-estimée de la rédaction web, c’est la prise en compte du contexte. Dans un site structuré, une page a une mère, des sœurs, des filles.

Quand je commence une page, je sais très exactement où elle se situera dans la hiérarchie. Mieux, je sais quelle fonction précise elle doit remplir, à quelle question elle doit répondre. C’est le seul moyen d’y inclure tout le nécessaire et seulement le nécessaire pour éviter le cannibalisme (voir Keyword and content cannibalization: how to identify and fix it).

Quand la «localisation» et la fonction de la page sont limpides, le reste est plus facile:

rédiger un titre explicite (cohérent avec son contexte)
proposer une description (cohérente avec son contexte)
prévoir un balisage sémantique simple et fort (intertitres, emphases, listes, tableaux, blocs de détails)
proposer un maillage puissant avec des liens internes et externes précis en nombre raisonnable

En travaillant ainsi, il est fréquent de modifier des pages existantes au moment de la publication d’une nouvelle. Je peux alors ajouter des liens spécifiques vers un nouveau contenu à la place d’anciens paragraphes moins précis. Je peux influencer ma rédaction de la nouvelle page pour insérer au mieux ces liens dans le corps du texte. Tout cela ne se voit pas immédiatement à la lecture. Mais c’est ce qui fait à terme la force d’une page.

Pour le reste, on est en terrain connu. À commencer par les réponses aux questions QQOQCCP (qui? quoi? où? quand? comment? combien? pourquoi?) qui parcourent l’histoire de l’Antiquité au journalisme contemporain en passant par le référencement (SEO). Et les classiques: phrases pas trop longues, si possible actives, paragraphes de taille raisonnable, intertitres qui rythment la lecture, etc.

En pratique, je constate avec l’expérience que l’écriture en ligne rend ce travail plus efficace (et peut-être même plus simple).

Écrire en ligne

Ce que j’entends par «écrire en ligne», c’est effectuer la recherche et la rédaction sans passer par des outils intermédiaires. Dans WordPress, je pourrais écrire directement dans l’éditeur Gutenberg. Avec Hugo (comme pour ce site), je rédige en Markdown.

Si je passais par Word ou un de ses concurrents, je ne pourrais pas créer de blocs de détails directement. Je n’aurais pas les mêmes options de mise en sens disponibles (les blocs de WordPress ou les shortcodes de Hugo).

Dans mon contexte d’écriture avec un éditeur de code, Git et Hugo, j’adopte une philosophie Docs as Code. Mais qu’importent vos outils. Il me semble qu’en 2026, écrire dans un CMS (système de gestion de contenu) est adéquat.

Dans le CMS (ou mon VS Code), il est facile de traiter directement tout l’invisible. C’est notamment là que peuvent se traiter les métadonnées, ce que personne ne fera dans son traitement de texte. Celles dont j’ai déjà parlé (description, titre alternatif si nécessaire, Open Graph, etc.), mais aussi d’autres comme les directives d’indexation pour les robots, la saisie de mots-clés (tags), voire du texte caché (en commentaire).

En travaillant ainsi, je minimise le nombre d’outils ouverts. Je me simplifie la vie. Je me concentre sur le contenu. Et surtout sur tout ce qui n’est pas visible.

Remarques sur le fichier robots.txt en 2026

hello+rss@nicolasfriedli.ch (Nicolas Friedli) — Fri, 10 Jul 2026 00:00:00 +0000

Le fichier robots.txt reste intéressant envers et contre tout. Il fonctionne depuis plus de 30 ans, plutôt bien. Ce n’est pas parce que les grandes entreprises d’intelligence artificielle (IA) ne le respectent pas que je vais l’abandonner; elles ne respectent rien.

Collaboration entre honnêtes gens

Le principe du /robots.txt ou protocole d’exclusion des robots est de donner des directives pour l’exploration de son site.

C’est un fichier visible publiquement. Celui de ce site est donc disponible à l’URL https://nicolasfriedli.ch/robots.txt.

Quand un robot (aussi appelé crawler ou spider) arrive sur mon site, il dit qui il est avec l’instruction user-agent. Dans mon fichier, je donne des instructions spécifiques par nom de robot. Un exemple tout simple, en langage naturel:

Si tu es le robot d’indexation de Google, tu peux parcourir tout mon site à l’exception du répertoire /photos/.

En langage /robots.txt:

User-agent: Googlebot
Disallow: /photos/

Le truc génial du deal, c’est que:

ce répertoire ne sera pas indexé dans Google (ce que je souhaite)
car Google ne va pas le parcourir et l’analyser (ce qui lui fait économiser des ressources)

Les 2 parties sont gagnantes. L’instruction tient en quelques lignes. Et tout va bien.

Ne serait-ce que parce que des entreprises respectent cette manière de faire, je pense qu’il vaut la peine de rédiger quelques lignes d’instruction.

Déclarer ses intentions

En affichant des directives dans un fichier public, je dis clairement ce que je souhaite (ou ne souhaite pas).

Si j’exclus ChatGPT pour tout mon site, je signifie que je ne souhaite pas voir mes contenus utilisés pour fourrager la bête. Cela complète bien la licence des contenus.

Ainsi, je dis, en langage naturel:

Je ne souhaite pas que toi, ChatGPT, utilise mon contenu pour construire ta base de connaissance. Et si tu les utilisais, tu devrais respecter la licence.

Je ne me fais aucune illusion sur le manque de respect de toute règle éthique par entreprises derrière les grands modèles de langages (LLM) et IA génératives. Mais je permet à quiconque de voir comment je me positionne par rapport à ces outils.

Économiser la bande passante

Comme certains outils continuent à respecter les directives de robots.txt, c’est possible de limiter les transferts de données inutiles. Il n’y a aucune raison que des moteurs de recherche russe ou chinois indexent mon site. Les outils de référencement (SEO) n’ont pas besoin de parcourir mes contenus.

Je vais être clair, ces règles dans robots.txt ne sont pas un outil pour «lutter contre des bots». Si votre serveur croule sous la charge, ce n’est pas une réponse pertinente. C’est une fois encore une bonne pratique entre gens fréquentables. Mais l’idée que ce soit respecté me motive à jouer le jeu envers et contre tout.

Règles de mon `robots.txt`

Les règles exactes du jour sont disponibles en tout temps dans le fichier en production ou sur GitHub. Mais le principe est visible ici. J’exclus 3 types de robots.

Les moteurs de recherche qui n’ont aucun intérêt à lire mon site:

User-agent: 360Spider
User-agent: Baidu
User-agent: Baiduspider
User-agent: PetalBot
User-agent: SeznamBot
User-agent: Shenma
User-agent: Sogou web spider
User-agent: Yandex
Disallow: /

Les outils SEO:

User-agent: AhrefsBot 
User-agent: AhrefsSiteAudit
User-agent: DotBot
User-agent: MJ12bot
User-agent: SemrushBot
User-agent: SemrushBot-SA
Disallow: /

Les IA:

User-agent: Amazonbot
User-agent: anthropic-ai
User-agent: Applebot-Extended
User-agent: Bytespider
User-agent: CCBot
User-agent: ChatGPT-User
User-agent: Claude-SearchBot
User-agent: Claude-Web
User-agent: ClaudeBot
User-agent: cohere-ai
User-agent: Diffbot
User-agent: FacebookBot
User-agent: FriendlyCrawler
User-agent: Google-Extended
User-agent: GPTBot
User-agent: meta-externalads
User-agent: meta-externalagent
User-agent: meta-externalfetcher
User-agent: OAI-AdsBot
User-agent: OAI-SearchBot
User-agent: Omgili
User-agent: Perplexity-User
User-agent: PerplexityBot
User-agent: YouBot
Disallow: /

Références utiles

Je vous conseille le billet Bloquer les AI bots de Didier J. Mary, tenu à jour et beaucoup plus développé que cette page.

Il existe des listes d’exclusion prêtes à l’emploi pour qui souhaite exclure les intelligences artificielles (IA) de son site.

CloudFlare propose un Bots Directory avec les robots les plus actifs par catégories.

Je me suis inspiré de 3 ressources ci-dessus pour créer ma liste.

Exclusion technique des tricheurs

Quand les robots ne respectent pas les règles, il faut trouver d’autres solutions, par exemple:

la solution StupidAntibot de sebsauvage
l’ajout d’un «obstacle» comme Botcheck d’Andi Gohr ou Anubis
le pourrissement volontaire des contenus qui ne devraient pas être lus (si les robots respectaient les règles), c’est la proposition Poisoning well d’Heydon Pickering
les bombes de décompression ou zip bombs (un tout petit fichier qui devient immense et sature les ordinateurs qui analysent les données, mais qui peut être considéré comme une attaque)

Ces solutions visent toutes à ralentir ou arrêter les crawlers des grandes entreprises qui saturent la bande passante ou ne jouent pas le jeu. Elles sont discutables parce qu’elles dérangent les internautes. Certaines sont très consommatrices d’énergie; c’est le but, hélas.

Je suis très réticent à l’utilisation d’une solution trop centralisée comme CloudFlare. C’est une entreprise si tentaculaire qu’elle fait tomber la moitié du web à chaque problème, elle ne refuse pas la censure, etc.

De la difficulté de questionner sur l’intelligence artificielle (IA)

hello+rss@nicolasfriedli.ch (Nicolas Friedli) — Mon, 06 Jul 2026 00:00:00 +0000

La semaine dernière, j’ai été chargé de diffuser un questionnaire sur l’utilisation des intelligences artificielles (IA) au sein d’un corps de métier. Je me suis exécuté, tout en gardant pas mal de réserves sur les questions posées. Et encore plus de réserves sur les questions esquivées. Une sorte de malaise, diffus.

Aperçu des questions

Les questions étaient grosso-modo les suivantes:

êtes vous pour ou contre l’IA (sur une échelle de 0 à 10) dans différents domaines professionnels?
à quelle fréquence utilisez-vous l’IA dans ces différents domaines (entre «jamais» et «plusieurs fois par jour»)?
puis plusieurs détails d’utilisation et d’intérêt à le faire
finalement quelques enjeux prospectifs (et une dernière question sur les risques et défis)

À mes jeux, trop de questions importantes sont esquivées pour avoir des résultats intéressants. Mon propos n’est pas de critiquer ce questionnaire précis, parce presque toutes les «enquêtes» que je lis me paraissent trop superficielles. Voici pourquoi.

Esquisses précisions et de questions

Mon premier souci, c’est que tout me paraît flou. Le terme «IA» est posé sans aucune clarification et chaque personne y projette ce qu’elle veut. Entre les IA génératives (LLM), les systèmes de traduction et l’optimisation des contrastes d’une image, il y peu en commun. Dans ce contexte, je pense que «IA» signifie «grand modèle de langage», mais ce n’est que ma déduction.

On pouvait donc demander: Quelles IA utilisez-vous?

IA génératives
traduction automatique
autres

Si ma supposition que l’enquête porte sur les LLM est correcte, il y a de nouveau un problème de vision monolithique des choses. Toutes les intelligences artificielles génératives sont traitées en un bloc. Sans aucune distinction entre ChatGPT, Gemini, Claude et les autres. Il y avait moyen de demander quel système est utilisé et, surtout, comment il a été choisi.

On pouvait demander: Pour quelle raison avez-vous choisi cet outil?

on me l’a conseillé
j’en ai entendu parler dans la presse
mon ordinateur me l’a proposé
il en existe d’autres?

D’ailleurs, j’ai vu peu de débat sur l’idée même de l’utilisation d’une IA. Un peu comme si c’était déjà une fatalité. Partir de l’idée que c’est (presque) incontournable est déjà un sacré biais.

Ensuite, j’aurais apprécié des questions sur le rapport à l’employeur. Parce que l’utilisation de tels outils n’est pas qu’une question individuelle. C’est un enjeu systémique et de société. Au minimum, on pouvait demander:

Est-ce que votre employeur a émis des directives sur l’utilisation professionnelle de l’IA?
Est-ce qu’il vous a poussé à l’utiliser? Ou déconseillé de le faire?
Est-ce qu’il vous paie un abonnement?
Est-ce qu’il vous demande d’être transparent sur son utilisation?

Il y avait aussi moyen de glisser quelques pistes sur les enjeux éthiques:

Comment vous positionnez-vous par rapport aux impacts énergétiques des IA? Parce que les émissions de CO2 de Google et Amazon s’envolent.
Les sources utilisées sont-elles bien citées?
Acceptez-vous que votre travail soit utilisé par les LLM pour leur entraînement?
Êtes-vous à l’aise avec l’idée de construire vos contenus sur des articles pillés?

Bon, j’arrête là. Il n’y avait pas forcément de raison d’ajouter toutes ces questions. Mais il y avait possibilité d’en poser certaines. Parce que les enjeux sont très sérieux. Et souvent sous-estimés.

2 podcasts pour avancer

J’ai gardé cette impression de malaise face à ces questions jusqu’à aujourd’hui. Puis j’ai écouté 2 podcasts.

Dans Chronique d’un emballement autour de l’IA générative, Grégoire Barbey pose rapidement un enjeu lumineux:

L’intelligence artificielle n’est pas qu’une affaire d’usage, c’est un sujet majeur, structurant, au cœur d’une lutte de pouvoir. […] Je suis […] persuadé qu’il faut tenter d’appréhender ce sujet dans sa globalité plutôt que de le restreindre à des domaines spécifiques.

C’est exactement ce qui m’a dérangé avec le questionnaire dont je parle ci-dessus. La pratique, l’usage, le spécifique, mais aucun enjeu de fond.

Dans Le tsunami d’infos générées par IA, Jean-Marc Manach montre la déferlante qui est en train de raser le domaine des médias. Et l’indifférence (y compris de journalistes), devant ce qui se passe. C’est beaucoup trop riche pour essayer de le résumer.

L’impression que ces 2 écoutes me laissent, c’est qu’il n’est plus permis de «traiter» ce sujet en quelques enjeux théoriques. Ni par un questionnaire rapide et sans questions difficiles. Ni de considérer qu’un tel enjeu collectif peut être étudié à l’échelle personnelle.

J’ai profité de cette journée pour ajouter une slash page à l’adresse /ia de ce site.