Nicolas Friedli

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.

Utilisation d’intelligence artificielle (IA) sur ce site

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

Je n’utilise pas d’intelligence artificielle (IA).

En détail:

je n’utilise pas d’IA pour rédiger des contenus
je n’utilise pas d’IA pour me donner des idées de contenus
je n’utilise pas d’IA pour générer des images
je n’utilise pas d’IA pour produire du code Hugo, HTML ou CSS

Toutefois, il m’arrive de passer la source d’un billet de blog en Markdown dans Google Gemini pour voir ce qu’il en ressort, quel serait le résumé, etc. J’estime que c’est acceptable pour me tenir au courant de l’état actuel des IA génératives (LLM).

Je me refuse à apposer un badge not by IA dont l’usage sera fatalement détourné. Celles et ceux qui utilisent les LLM en se faisant passer pour des rédactrices et rédacteurs ne se gêneront pas de revendiquer leur plume humaine alors que c’est pur mensonge.

Mon plaisir à réfléchir, rédiger et coder est ma priorité.

Textes courts et textes longs sur le web

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

Faut-il favoriser les textes longs? Ou privilégier les textes courts? Entre injonctions paradoxales et oscillations permanentes, il est difficile de savoir quoi produire pour bien publier sur le web.

Petit historique

Cet aperçu de ce qui s’est passé sur le web est essentiellement chronologique. Même s’il faudrait affiner avec des chevauchements et rebroussements.

Avant les CMS (systèmes de gestion de contenu), les pages étaient peu nombreuses et avaient tendance à s’allonger au fil du temps. L’ajout d’une page était «coûteux» quand il fallait, par exemple, créer une navigation à la main dans son éditeur de code.

Avec l’arrivée des CMS, il est devenu beaucoup plus simple d’ajouter un contenu. Avec les automatismes de ces outils, plus besoin d’effectuer du travail manuel pour le menu, les tags et le fil chronologique. Donc, les contenus sont devenus plus nombreux, mais moins longs.

Les réseaux sociaux #1, en premier lieu Twitter, ont imposé des contenus très courts. Les fameux 140 caractères du début. Cette contrainte avait du bon, elle invitait à réfléchir vraiment à son propos et à être précis.

Mais nous vivions en parallèle une période favorable au référencement (SEO). Les textes devaient être assez longs et structurés pour briller dans les moteurs de recherche.

Durant des années, il fallait jongler entre deux injonctions. Il fallait faire court parce que plus personne ne lisait plus d’un paragraphe, alors que les pages les plus lues via les moteurs de recherche étaient les plus longues

Et Wikipédia et ses textes longs et denses s’est imposé comme un des sites les plus importants du monde. Parce qu’il est utile et que personne n’imagine s’arrêter après 1 paragraphe.

Les réseaux sociaux #2 ont complètement changé, souvent pour le pire. J’en dis un mot dans À propos des réseaux prétendument sociaux.

Ce sont surtout les contenus publiés sur Facebook, Instagram et compagnie qui se sont allongés. Les publications sont parfois restées courtes, mais elles sont devenues des threads (suites de publications). Les images ont commencé à porter le texte qui n’était pas dans les posts, souvent au mépris de l’accessibilité (A11Y), voire de la lisibilité.

Et en même temps, comme il faut fourrager le bête et publier souvent, les contenus sont parfois presque vides. Pas courts, ni denses, ni synthétiques, mais proches de zéro. Le teaser est le contenu.

La phase réseaux sociaux #3 que nous vivons aujourd’hui est copieusement fourragée par les intelligences artificielles génératives (LLM). Les contenus sont plus étoffés; les textes étonnement longs et munis d’emojis. LinkedIn semble une source inépuisable d’exemples de sauce rallongée.

Alors que du côté des blogs, il existe une tendance au microblogging (avec des outils comme micro.blog) ou à des rubriques de notes sans titres (comme chez Kev Quirk, créateur de Pure Blog).

Pour ajouter un peu de complexité à ces oscillations, les pages de résultats des moteurs de recherche (SERP) sont complètement ~~pourries~~ modifiées par les intelligences artificielles (IA). Par conséquent, la longueur des pages dans une optique SEO n’a plus le même sens.

Je rappelle qu’il faut toujours rédiger de manière sémantique pour les internautes. Texte long, texte court, aucune importance. Le référencement suivra, les IA suivront.

Les inspirations du moment

Si j’ai rédigé ces notes, c’est après avoir lu quelques billets récents qui parlent de raccourcir son propos. Voici les sources et un extrait pour chacune.

The Courage to Stop de Jeffrey Zeldman:

What’s rare—what’s difficult—is knowing when you’ve said enough. Cutting the sentence that’s technically correct but doesn’t earn its place. Trusting the reader. Trusting the idea. Trusting the white space to do work.

Short form blogs are subversive par Luke Davis:

The shorter blogs add an element of subversion in that they go against the idea that longer is somehow better. There’s no evidence to suggest longer is better from a ranking perspective but the idea is that if it’s longer, you’ll have (hopefully) fleshed out your thoughts. But maybe a quick thought is better than an embellished one.

Your shit is unreadable par unstory:

It’s summer. It’s hot, like it has been for thousands of years. Thanks for the 1,000-word coverage and your recommendation to drink water. You saved humanity.

Blogging Can Just Be Stating The Obvious par Jim Nielsen:

So it must be that a key ingredient to blogging is simple: have a willingness to state something that seems obvious to you but nobody else is saying it.

«C’est de l’IA, je ne l’ai pas lu!» par Hubert Guillaud:

[Constance Vilanova] pointait d’ailleurs vers une étude d’un chercheur en linguistique qui a mis au point une échelle pour mesurer la réceptivité au jargon d’entreprise. Une étude qui montrait que plus on est sensible aux formules creuses, moins on performe soi-même aux tests de pensée analytique et aux tests de prise de décision. «Les grands amateurs de Linked-in speak seraient donc aussi les moins capables de repérer le vide. Ce qui crée un cercle vicieux parfait: les patrons sont récompensés pour leur langue de bois, et les équipes se peuplent progressivement de gens qui n’y voient que du feu.»

Je vous laisse ce billet en l’état. Vous saurez en tirer ce qui compte pour vous ou avoir la sagesse de l’abandonner s’il est vain. Je n’ai rien à gagner à vous garder ici; je vous recommande des réflexions autres.