CINXE.COM

<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Nicolas Friedli</title><link>https://nicolasfriedli.ch/</link><description>Recent content on Nicolas Friedli</description><generator>Hugo -- gohugo.io</generator><language>fr</language><managingEditor>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</managingEditor><webMaster>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</webMaster><copyright>Creative Commons BY-SA</copyright><lastBuildDate>Mon, 31 Mar 2025 00:00:00 +0000</lastBuildDate><atom:link href="https://nicolasfriedli.ch/index.xml" rel="self" type="application/rss+xml"/><image><url>https://nicolasfriedli.ch/apple-touch-icon.png</url><title>Nicolas Friedli</title><link>https://nicolasfriedli.ch/</link></image><item><title>Liens</title><link>https://nicolasfriedli.ch/blogroll/</link><pubDate>Sun, 02 Feb 2025 18:38:04 +0100</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blogroll/</guid><description>Une sélection de sites personnels, disposant d’un flux RSS et avec des publications durant la dernière année. Ce sont des sites que je lis dans mon agrégateur. Dans l’Antiquité, on appelait une telle liste de liens un blogroll. <h2 id="web-en-francais">Web (en français)</h2> <ul class="grid"> <li><a href="https://tcrouzet.com/">Thierry Crouzet</a></li> <li><a href="https://louisderrac.com/">Louis Derrac</a></li> <li><a href="https://ploum.net/">Lionel Dricot</a></li> <li><a href="https://affordance.framasoft.org/">Olivier Ertzscheid</a></li> <li><a href="https://www.quaternum.net/">Antoine Fauchié</a></li> <li><a href="https://bertrandkeller.info/">Bertrand Keller</a></li> <li><a href="https://larlet.fr/david/">David Larlet</a></li> <li><a href="https://www.standblog.org/blog/">Tristan Nitot</a></li> <li><a href="https://www.arthurperret.fr/">Arthur Perret</a></li> <li><a href="https://sebsauvage.net/links/">Sébastien Sauvage</a></li> </ul> <h2 id="web-en-anglais">Web (en anglais)</h2> <ul class="grid"> <li><a href="https://whitep4nth3r.com/">Salma Alam-Naylor</a></li> <li><a href="https://maggieappleton.com/">Maggie Appleton</a></li> <li><a href="https://css-irl.info/">Michelle Barker</a></li> <li><a href="https://set.studio/">Andy Bell</a></li> <li><a href="https://chriscoyier.net/">Chris Coyier</a></li> <li><a href="https://coryd.dev/">Cory Dransfeldt</a></li> <li><a href="https://www.cassie.codes/">Cassie Evans</a></li> <li><a href="https://www.lkhrs.com/">Luke Harris</a></li> <li><a href="https://amyhupe.co.uk/">Amy Hupe</a></li> <li><a href="https://adactio.com/">Jeremy Keith</a></li> <li><a href="https://una.im/">Una Kravets</a></li> <li><a href="https://www.zachleat.com/">Zach Leatherman</a></li> <li><a href="https://ethanmarcotte.com/">Ethan Marcotte</a></li> <li><a href="https://www.matuzo.at/">Manuel Matuzović</a></li> <li><a href="https://blog.jim-nielsen.com/">Jim Nielsen</a></li> <li><a href="https://matthiasott.com/">Matthias Ott</a></li> <li><a href="https://heydonworks.com/">Heydon Pickering</a></li> <li><a href="https://kevquirk.com/">Kev Quirk</a></li> <li><a href="https://csswizardry.com/">Harry Roberts</a></li> <li><a href="https://pimpmytype.com/">Olivier Schöndorfer</a></li> <li><a href="https://www.typewolf.com/">Jeremiah Shoaf</a></li> <li><a href="https://www.sarasoueidan.com/">Sara Soueidan</a></li> <li><a href="https://hidde.blog/">Hidde de Vries</a></li> </ul> <h2 id="blogs-protestants">Blogs protestants</h2> <ul class="grid"> <li><a href="https://olivierbauer.org/">Olivier Bauer</a></li> <li><a href="https://lauredevaux.ch/">Laure Devaux Allisson</a></li> <li><a href="https://dianefriedli.ch/">Diane Friedli</a></li> <li><a href="https://eliojaillet.ch/">Elio Jaillet</a></li> <li><a href="https://www.ethikos.ch/">Armin Kressmann</a></li> <li><a href="https://espritdeliberte.leswoody.net/">James Woody</a></li> </ul> <h2 id="remarque">Remarque</h2> Ces 3 catégories reprennent des titres des mes catégories de flux RSS. La liste complète des flux suivis est disponible sur demande au format OPML. Vous pourrez l’intégrer facilement à votre lecteur de flux habituel (Feedly, Inoreader, Feedbin, etc.).</description></item><item><title>Recherche</title><link>https://nicolasfriedli.ch/search/</link><pubDate>Mon, 10 Feb 2025 10:54:11 +0100</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/search/</guid><description>Trouver quelque chose sur ce site avec la recherche statique Pagefind. <link href="https://nicolasfriedli.ch/pagefind/pagefind-ui.css" rel="stylesheet"> <script src="https://nicolasfriedli.ch/pagefind/pagefind-ui.js"></script> <div id="search"></div> <script> window.addEventListener("DOMContentLoaded", (event) => { new PagefindUI({ element: "#search", pageSize: 10, showSubResults: true, showImages: false, autofocus: true }); }); </script></description></item><item><title>Contact</title><link>https://nicolasfriedli.ch/contact/</link><pubDate>Tue, 21 Jan 2025 20:15:53 +0100</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/contact/</guid><description>Toutes les informations utiles pour me proposer un mandat, m’employer, me poser une question ou me faire part d’une remarque sur ce site. <h2 id="coordonnees">Coordonnées</h2> Nicolas Friedli Rue du Château 3 2013 Colombier (NE) Suisse <a href="mailto:hello+2025@nicolasfriedli.ch">hello+2025@nicolasfriedli.ch</a> <a href="tel:+41328414874">+41 32 841 48 74</a> (urgences uniquement) <a href="sms:+41793443382">+41 79 344 33 82</a> (Signal ou SMS) IDE: CHE-469.715.163 Merci de privilégier le mail. Je ne réponds pas aux prises de contact sur WhatsApp Je ne suis pas présent sur les réseaux sociaux Bluesky, Instagram, LinkedIn, Mastodon ou Twitter (X). Et j’ai une présence passive sur Facebook pour administrer 2 pages. J’en dis quelques mots dans <a href="https://nicolasfriedli.ch/blog/reseaux-sociaux-regles/">Mes règles d’utilisation des réseaux sociaux</a>. Pour m’identifier, voici <a href="https://nicolasfriedli.ch/images/nicolas-friedli.jpg" title="Portrait de Nicolas Friedli">mon portrait</a>. <h2 id="mengager">M’engager</h2> Je favorise les mandats de consultant de quelques jours (répartis sur quelques semaines). Tous mes travaux sont facturés au forfait. Je souhaite recevoir la description d’un éventuel mandat avant une première rencontre. Une demande précise a plus de chances de me convaincre de travailler pour vous. Pour en savoir plus: <ul> <li><a href="https://nicolasfriedli.ch/bio/">quelques éléments biographiques</a> sur mon parcours</li> <li><a href="https://nicolasfriedli.ch/about/">à propos</a> sur les choix techniques de ce site</li> </ul> C’est toujours Nicolas Friedli qui réalise le travail: pas d’employé·e, pas de stagiaire, pas de sous-traitance.</description></item><item><title>3 remarques avec l’arrivée d’AI Overviews en Suisse</title><link>https://nicolasfriedli.ch/blog/ai-overviews/</link><pubDate>Mon, 31 Mar 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/ai-overviews/</guid><description>Google déploie ses AI Overviews en Suisse et l’impact sur la navigation en ligne sera majeur. C’est un machin qui s’affiche en haut des résultats de recherche, qui ne sert à rien (dans les exemples que j’ai subis), qui prend de la place, etc. En version courte, je dirais que c’est une belle étape dans la <a href="https://ploum.net/2023-06-15-merdification.html">merdification</a> de Google. Watson en parle dans <a href="https://www.watson.ch/fr/suisse/google/619805212-google-lance-ai-overview-en-suisse-et-ca-inquiete-le-pays">Google a changé son moteur de recherche et ça inquiète déjà</a>, Le Temps en parle dans <a href="https://www.letemps.ch/cyber/en-suisse-google-va-bouleverser-son-moteur-de-recherche-avec-les-ai-overviews-quatre-questions-pour-comprendre">En Suisse, Google va bouleverser son moteur de recherche avec les AI Overviews: quatre questions pour comprendre</a> et plein d’autres médias vont en parler prochainement. J’en tire 3 conclusions provisoires: sur les liens, sur la navigation et sur la recherche. <h2 id="les-liens-restent-la-base-du-web-avec-le-contenu">Les liens restent la base du web (avec le contenu)</h2> Rien de neuf ici. Les contenus et leur mise en lien sont l’essence du web. L’arrivée de l’intelligence artificielle renforce leur importance (même si elle donne parfois l’impression de leur inutilité). <h3 id="precision-des-liens">Précision des liens</h3> Il est probable que moins d’internautes arriveront sur des pages précises de votre site. Si la réponse donnée par AI Overvieuws suffit, le clic n’est pas une évidence, hélas. En conséquence, quand des internautes cliquent et son sur votre site, il me paraît important de leur donner du bon contenu. Le contenu «pur», mais aussi les liens internes et externes qui permettent de le mettre en relation avec d’autres contenus de valeur. Ainsi, il est possible de continuer sa navigation en approfondissant la thématique, plutôt qu’en la survolant par des réponses résumées. Pour aller plus loin, je vous conseille le billet <a href="https://paulstamatiou.com/browse-no-more">Browse No More</a>. Touts les moyens sont bons pour proposer des liens précis, par exemple les QR codes. Le renvoi sur votre page d’accueil me semble bien peu pertinent, mais celui sur un contenu de qualité devient nécessaire. Je donne quelques conseils pratiques dans <a href="https://nicolasfriedli.ch/blog/conseils-qr-code/">Conseils d’utilisation des QR codes</a>. <h3 id="navigation-et-architecture-dinformation">Navigation et architecture d’information</h3> Si les liens à l’interieur du contenu de la page sont toujours les plus forts, les autres outils de navigtations comptent aussi. Les outils qui permettent de se repérer dans le site sont connus: <ul> <li>fil d’Ariane (breadcrumb)</li> <li>petits menus contextuels</li> <li>pages reliées (related)</li> </ul> Les méga-menus sont mauvais pour le référencement (SEO), c’est connu de longue date. Mais ils sont aussi (et surtout) problématiques pour les internautes. Lorsque j’arrive sur une page par un moteur de recherche, il est peu probable que je continue ma navigation sur le site en parcourant un menu immense. C’est plus simple de retourner d’où je viens: chez Google&hellip; Et avec une nouvelle réponse AI Overviews, il n’est vraiment pas certain que je revienne sur le site. Pour aller plus loin, je vous conseille la conférence <a href="https://www.writethedocs.org/videos/na/2017/building-navigation-for-your-doc-site-5-best-practices-tom-johnson/">Building navigation for your doc site: 5 best practices</a>. <h2 id="qualite-du-moteur-de-recherche-interne">Qualité du moteur de recherche interne</h2> Finalement, le retour systématique à la recherche Google après la lecture d’une page va encore s’amplifier. Ce qui change, c’est que la probabilité de revenir sur le site baissera encore. Mais je ne vois pas le recours à la recherche d’un mauvaise œil. À condition que la recherche se fasse avec le moteur interne du site. Il existe plein de raisons de s’assurer d’obtenir des résultats d’un domaine précis plutôt que le <a href="https://fr.wikipedia.org/wiki/Gloubi-boulga">gloubi-boulga</a> généré par des intelligences artificielles en compilant des sources. On peut donc souhaiter des moteurs de recherches: <ul> <li>rapides</li> <li>précis</li> <li>tolérants à la faut de frappe</li> <li>bien visibles</li> <li>etc.</li> </ul> Si j’ai plus de chance de trouver un contenu par un excellent moteur de recherche interne, peut-être que je ne retournerai pas chez Google pour bidouiller avec des <a href="https://nicolasfriedli.ch/blog/recherche-google-avancee/">recherches avancées</a>. Sur ce site, j’essaie <a href="https://nicolasfriedli.ch/blog/recherche-statique-pagefind/">PageFind</a> en espérant qu’il donne satisfaction. Finalement, je vous invite à consulter le site gouvernemental du <a href="https://www.gov.uk/">GOV.UK</a>. Peut-être qu’une bonne recherche interne est la solution au délires de Google et autres géants du web.</description></item><item><title>Élements biographiques</title><link>https://nicolasfriedli.ch/bio/</link><pubDate>Thu, 13 Mar 2025 16:48:41 +0100</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/bio/</guid><description>Nicolas Friedli est titulaire d’un master en théologie protestante de l’Université de Neuchâtel. Il est consultant web indépendant et salarié à 30% pour le web et les réseaux sociaux de l’EREN (Église réformée évangélique du canton de Neuchâtel). Il apprécie les sites web simples, performants et pérennes. Il a travaillé ou travaille avec SPIP, DokuWiki et WordPress, 3 outils qu’il utilise toujours en production. Aujourd’hui, il privilégie les sites statiques et Hugo. Durant les 15+ dernières années, il a travaillé pour les domaines: <ul> <li>de la culture (musée, ensemble instrumental, festivals)</li> <li>de l’écrit (agence de presse, maison d’édition, mensuel français)</li> <li>de l’entreprise (finance, immobilier, industrie)</li> <li>de la formation (promotion d’études universitaires, formation continue)</li> <li>des institutions (sites romands, cantonaux et locaux)</li> <li>des organisations (communes, ONG)</li> <li>de la santé (cabinets, sites professionnels)</li> <li>du sport (tournoi ATP de tennis, courses populaires, équipement)</li> </ul> Convaincu que les sites d’institutions et d’organisations ont un énorme potentiel d’amélioration, il se passionne pour l’architecture d’information, la performance web et le référencement local. Le contenu et les liens sont les briques essentielles pour proposer un site web utile. Il s’est exprimé régulièrement dans des sessions de formation professionnelle et dans des interventions publiques. Il est marié à <a href="https://dianefriedli.ch/">Diane Friedli</a>, pasteure, et père de 2 enfants adolescents, Lucien et Clémence.</description></item><item><title>Notes sur SPIP en 2025</title><link>https://nicolasfriedli.ch/blog/spip/</link><pubDate>Mon, 17 Feb 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/spip/</guid><description>SPIP est un magnifique système de publication né en 2001. Il a eu ses heures de gloire dans le monde francophone (et ailleurs). Il n’est plus aussi populaire mais qu’importe. Pour des tests sur <a href="https://theologique.ch/">theologique.ch</a>, j’ai réinstallé un SPIP tout frais. Même s’il est peu probable que je conserve ce site sous SPIP, je vous explique pourquoi il reste génial en 2025. Le projet a été modifié et je ferai un site en <a href="https://nicolasfriedli.ch/blog/falc-plain-ia/">langage simplifié</a> avec Hugo. En fin de billet, je vous donnerai aussi quelques «problèmes» qui m’empêchent de l’utiliser plus souvent. <h2 id="amelioration-progressive">Amélioration progressive</h2> J’apprécie particulièrement la gestion très progressive des champs activables. SPIP a été conçu pour la publication éditoriale et ça se ressent. Au départ, un article, c’est un titre et un corps de texte. Selon la demande, je peux activer, seulement quand c’est nécessaire: <ul> <li>un sur-titre</li> <li>un sous-titre</li> <li>un descriptif (ou résumé)</li> <li>un chapo (ou introduction)</li> <li>un post-scriptum</li> </ul> Immense avantage de cette progressivité, rien d’inutile n’est affiché dans l’interface d’administration. Elle reste simple et légère. Elle se complexifie en fonction des nécessités avec le temps. <h2 id="attribution-des-auteurs">Attribution des auteurs</h2> Alors que beaucoup de systèmes de gestion de contenu (CMS) ont exactement un auteur ou une autrice par article, SPIP est beaucoup plus souple. Pour rappel, chez WordPress, c’est une personne pour les articles et pas de signature pour les pages. Pour chaque page, il permet d’attribuer zéro, un ou plusieurs auteurs et autrices. Une fois qu’une personne se voit listée, elle devient responsable de la page et peut la modifier. Cela ouvre de belles perspectives pour un travail collaboratif. <h2 id="syntaxe-de-redaction-et-gestion-typographique">Syntaxe de rédaction et gestion typographique</h2> De son origine dans le monde de la presse, SPIP a gardé l’excellence de sa gestion typographique. Chaque page est rédigée avec une syntaxe particulière, en pur texte. Ainsi, on évite les <del>délires</del> variations de mises en pages. Les copier-coller ne produisent pas les horreurs possibles avec les systèmes visuels WYSIWYG (What you see is what you get). La logique de SPIP, c’est WYMISYG (What you mean is what you get): ce que vous voyez, c’est ce qui est conforme à votre pensée. Les corrections typographiques permettent de ne pas se soucier des choix des personnes en charge de la rédaction. Il y a toujours une espace insécable avec les deux-points, les points-virgules, etc. Ici, je n’utilise pas d’espacement autour des ponctuations, mais je ne peux pas être certain qu’une autre personne le respectera. Avec SPIP, tout est uniformisé de force. <h2 id="gestion-des-url-et-maillage-interne">Gestion des URL et maillage interne</h2> C’est une des raisons pour lesquelles j’ai installé SPIP sur theologique.ch. J’ai activé les URL libres. Ce qui signifie que je peux choisir la chaîne de caractère de l’adresse de la page, toujours en minuscule et à la racine. Si je déplace une page dans la hiérarchie, l’adresse ne change pas. Ainsi, je peux construire une structure au fil du temps, en conservant les adresses. Mieux, comme les liens se font par raccourcis, du genre <code>[-&gt;art1]</code>, le titre et le lien seront toujours corrects. Même quand le titre change, même quand l’emplacement dans le site change. Et si je décide de changer une URL, l’ancienne adresse reste valide, avec une redirection propre de type 301. <h2 id="notion-de-popularite">Notion de popularité</h2> SPIP mesure la <a href="https://www.spip.net/fr_article1846.html">popularité des publications</a>. Ce qui permet de classer les articles par ordre décroissant de visites à un moment donné. J’ai bien envie de construire, une fois, un site dont les classement seraient dynamiques, en favorisant le plus lu. C’est bien entendu peu imaginable avec un site statique (à moins de s’adosser à une plateforme de déploiement). C’est une bonne raison d’installer SPIP. Évidemment, ce genre de choix est discutable. Mais le tester «en vrai» sur un site personnel m’intéresse. <h2 id="gestion-des-mots-cles">Gestion des mots clés</h2> Au départ, pas de mots-clés activés. L’interface reste minimale, comme déjà dit. Mais quand j’ai besoin de taxonomies, je peux activer les mots-clés. Puis créer de groupes et des mots. La gestion avancée permet des choses intéressantes comme: <ul> <li>l’attribution par les personnes en charge de l’administration seulement (et non les rédacteurs et rédactrices)</li> <li>l’incitation à choisir au moins un mot-clé d’un group</li> <li>l’interdiction de choisir plus d’un mot-clé d’un groupe</li> </ul> C’est à la fois très simple et très malin. <h2 id="installation-et-optimisation">Installation et optimisation</h2> Dès son installation, SPIP propose tout le nécessaire (batteries included). Et l’installation, avec un base SQLite, et la configuration prennent à peine quelques minutes Pas besoin de se surcharger le tout de plugins et extensions pour avoir un «vrai» site. L’optimisation est présente par défaut: <ul> <li>concaténation et minimisation des CSS</li> <li>concaténation et minimisation du JavaScript</li> <li>système de cache pour un site rapide et fiable</li> </ul> Les statistiques internes sont déjà présente, la gestion des images aussi. Tout est beau dans le meilleur des monde. Mais&hellip; <h2 id="les-problemes-de-spip">Les «problèmes» de SPIP</h2> Il n’est pas possible d’installer des thèmes comme avec WordPress. Ni de les configurer aussi simplement; SPIP n’est pas un cliquodrome. Son thème par défaut est un peu daté (mais très efficace). Et ce CMS ne dispose pas de tout l’écosystème de WordPress. La syntaxe n’est pas Markdown, aujourd’hui la plus utilisée. Normal, elle est née avant! Mais elle peut dérouter et déplaire. Beaucoup de personnes restent réticentes au balisage léger. Elles préfèrent le «à la Word», même s’il est moins efficace dans la durée. La documentation est médiocre. Certaines parties sont bonnes, mais elle contient un nombre impressionnant de vieilleries et de scories. Elle ne peut pas inspirer pas confiance à une personne qui découvre SPIP. SPIP n’est pas produit pas une fondation ou une grande entreprise. Pour beaucoup, c’est problématique. Ce CMS est géré par des personnes, sans réel·le propriétaire. Quand on voit les conflits de gouvernance chez WordPress actuellement, on se dit que c’est peut-être une bonne idée&hellip; Finalement, SPIP n’a pas de marketing, pas de modèle économique, pas de vrai calendrier. Celles et ceux qui le créent sont idéalistes, libertaires, libristes, etc. La nouvelle version arrive «quand elle est prête». Beaucoup d’entreprises et d’organisations refusent de se fier à un tel fonctionnement (qui dure pourtant depuis très longtemps). <hr> Une personne qui <a href="https://nicolasfriedli.ch/blog/blog-2025/">lance un blog en 2025</a> et qui ne souhaite pas un site statique devrait peut-être s’intéresser à SPIP.</description></item><item><title>Écologie et cohérence sur le web</title><link>https://nicolasfriedli.ch/blog/ecologie-coherence/</link><pubDate>Thu, 13 Feb 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/ecologie-coherence/</guid><description>Depuis des mois, je teste tous les sites qui militent pour l’écologie quand je les visite. Ils sont politiques, institutionnels, associatifs ou personnels. Malheureusement, leur bilan carbone est souvent médiocre. Cette situation m’interroge. J’essaie d’en comprendre les raisons, sans chercher à dénoncer les mauvais élèves. <h2 id="ne-pas-voir-limpact-du-numerique">Ne pas voir l’impact du numérique</h2> On pourrait penser que l’impact énergétique du numérique passe sous le radar. Pourtant, de nombreux sites écologistes sont les premiers à parler de 5G, d’intelligence artificielle et de cloud. Je ne peux donc pas légitimement estimer que le coût du numérique soit inconnu. Peut-être que les responsables des organisations estiment que leur «petit» site est peu problématique. C’est une pente glissante. Avec le même type de raisonnement, je pourrais me demander pourquoi baisser mon chauffage de quelques degrés. Je ne vais pas sauver les glaciers. Le principe de cohérence: <blockquote> Toutes les présences numériques ont des coûts énergétiques. Donc la présence numérique de notre organisation a aussi un coût, même minime.</blockquote> <h2 id="tests-faciles-et-competence-technique">Tests faciles et compétence technique</h2> Évidemment, c’est très facile de voir que ma consommation de chauffage diminue parce que j’ai décidé d’avoir froid. Mais je ne vois pas la facture énergétique de mon site. Il n’est pas possible d’estimer que toute organisation a les compétences techniques en interne pour évaluer sérieusement son site web. Difficile, sans un profil technique, de voir si une image est mal dimensionnée, si le code Javascript est trop lourd, etc. Je pourrais répondre qu’il existe des spécialistes dans ce domaine. Puisque j’ai pas de compétences en panneaux solaires, j’appelle un·e spécialiste. Pourquoi en serait-il autrement de mon site? La bonne nouvelle, c’est qu’il existe d’excellents outils pour évaluer un bilan carbone sans effort. Il suffit de copier une adresse dans le <a href="https://www.websitecarbon.com/">Website Carbon Calculator</a> pour obtenir une indication globale en quelques secondes. On peut aller un peu plus loin avec <a href="https://ecograder.com/">Ecograder</a> qui va détailler ses résultats. Ou on peut se rendre chez <a href="https://pagespeed.web.dev/">PageSpeed Insights</a> et s’intéresser au bilan de performance. La performance n’est pas le bilan écologique, mais toutes les lourdeurs inutiles qui sont signalées sont intéressantes. Le principe de cohérence: <blockquote> Notre organisation propose un site web (bien) meilleur que la moyenne du moment. Nous testons régulièrement notre bilan carbone.</blockquote> <h2 id="ce-qui-nest-pas-produit-ne-consomme-rien">Ce qui n’est pas produit ne consomme rien</h2> Ce qui m’interpelle le plus dans cette question de cohérence, c’est d’oublier des règles de base. Toute personne douée de raison se rend compte que ce qui est le plus léger, c’est ce qui n’est jamais produit. Pas besoin non plus de compétences très pointues pour savoir que le texte est plus léger que les images et que les images sont plus légères que la vidéo. La logique classique, c’est de supprimer ce qui est le moins important. C’est une sorte de détox numérique. La bonne solution, c’est plutôt de se demander, toujours ce qui est nécessaire. Avant d’ajouter une fonctionnalité, puis d’évaluer son bilan carbone, il faut se demander s’il y a besoin d’elle. Une image (même d’arbres verts) n’est pas forcément utile pour porter ses arguments. Plutôt que d’optimiser une image superflue, mieux vaut ne pas l’afficher du tout (et passer son texte en vert). Le principe de cohérence: <blockquote> À chaque étape de conception de notre présence numérique, notre organisation se demande ce qui est nécessaire, utile ou superflu. Notre sobriété numérique, c’est de savoir fixer des priorités et de travailler sur l’essentiel.</blockquote> <h2 id="gouvernance--cahier-des-charges">Gouvernance &amp; cahier des charges</h2> Le vrai problème des sites médiocres, c’est celui de la gouvernance de l’organisation. Ce n’est pas une question de web ou de technique, mais une question de gestion et d’objectifs. Il est nécessaire de nommer une personne en charge des bonnes pratiques de l’institution elle-même. Elle se chargera d’analyser les pratiques de mobilité, de chauffage, de consommation, etc. internes. Si ces personnes existaient, elles veilleraient à ce que le cahier des charges du site web mentionne au moins les éléments suivants: <ul> <li>le site est hébergé par une entreprise écoresponsable</li> <li>le site obtient un bilan A ou B (Website Carbon Calculator)</li> <li>les <a href="https://checklists.opquast.com/fr/assurance-qualite-web/?tag=ecoconception">règles Opquast relatives à l’écoconception</a> sont respectées</li> </ul> Le principe de cohérence: <blockquote> La démarche d’écoconception fait partie de tous les projets de notre organisation. Une personne (une équipe) a pour tâche spécifique de veiller à son application à toutes les étapes de développement et d’utilisation.</blockquote> <h2 id="favoriser-la-surconsommation-par-sa-negligence">Favoriser la surconsommation par sa négligence</h2> Le principal problème des sites web peu performants, c’est qu’ils incitent à la surconsommation. Ils consomment trop de ressources par rapport à ce qu’ils proposent. C’est malheureux mais ce n’est pas le plus grave. Quand un site est lourd et mal conçu, il s’affiche mal si le périphérique est ancien ou de gamme moyenne. Il demande plus de bande passante. Parfois, il n’est pas pleinement fonctionnel. Au final, il convainc les internautes à changer de matériel pour obtenir une expérience de navigation décente. Le principe de cohérence: <blockquote> Notre organisation propose un site léger et efficace. Elle veille à permettre une utilisation adéquate sur tout périphérique. Elle estime qu’elle doit améliorer sa présence sur le web pour ne pas imposer de nouveaux matériels.</blockquote> <h2 id="incoherence-et-faiblesse-du-discours">Incohérence et faiblesse du discours</h2> Comme j’ai un profil technique, j’ai tendance à passer un site à la moulinette et à émettre un jugement rapide. Il n’est pas écoconçu, incompatible avec les valeurs prônées par l’organisation. C’est tout le discours qui est décrédibilisé. Heureusement pour les organisations à visée écologique, le monde semble moins tranché que moi. Pourtant, je suis convaincu que la cohérence entre discours et actes est essentiel pour faire passer un message. Ignorer les efforts nécessaires et cacher les faiblesses sous le tapis est une stratégie risquée (et perdante). <hr> Je suis très réservé sur l’idée d’un badge (comme <a href="https://www.websitecarbon.com/badge/">Website Carbon Badge</a>) pour afficher son bilan carbone. C’est discutable d’utiliser des ressources (mêmes minimes) pour prouver que l’on utilise peu de ressources. Mais peut-être qu’il est nécessaire de recourir à de tels artifices pour faire passer un message. Pour mieux faire, on peut simplement ajouter un <a href="https://www.websitecarbon.com/website/nicolasfriedli-ch-blog-ecologie-coherence/">lien vers le test de cette page</a>. Cliquez pour savoir si mon discours est crédible!</description></item><item><title>Métadiscours et sites personnels</title><link>https://nicolasfriedli.ch/blog/metadiscours/</link><pubDate>Tue, 11 Feb 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/metadiscours/</guid><description>Un blog court toujours le risque de glisser vers le métadiscours. Autrement dit, de parler avant tout de lui-même. C’est particulièrement le cas pour tout site qui parle du web. Mais ce n’est pas un problème en soi. Une brève définition du métadiscours selon la page de Wikipédia en anglais <a href="https://en.wikipedia.org/wiki/Metadiscourse">metadiscourse</a> en dit un peu plus: <blockquote> Dans la philosophie du langage, le métadiscours est une discussion sur une discussion, par opposition à une simple discussion sur un sujet donné.</blockquote> Le paradoxe suivant est posé. Si je ne parle que de mon blog sur mon blog, j’ai l’impression de tourner en rond. Mais, quand je lis de blogs techniques, j’observe que les billets qui parlent des coulisses du site sont ceux qui m’intéressent le plus. Un équilibre doit être possible. <h2 id="lexemple-de-la-page-now">L’exemple de la page <code>/now</code></h2> Il y a quelques années, Derek Sivers a proposé de publier de <a href="https://nownownow.com/about">page <code>/now</code></a> sur nos sites. Elle a pour vocation de parler de ce sur quoi les blogueurs et blogueuse sont focalisés actuellement. Elle se distingue des pages à propos et contact qui donnent des informations pérennes. Une petite phrase de <a href="https://blog.professeurjoachim.com/billet/2024-01-14-ma-page-now-ou-plutot-en-ce-moment">Joachim Robert sur les pages <code>/now</code></a> m’a interpellé: <blockquote> Moins un blog est mis à jour, plus il y a de probabilité que ce qui y est publié a pour sujet les aspects techniques dudit blog.</blockquote> Elle a été signalée dans le billet <a href="https://larlet.fr/david/2024/01/08/">Liens</a> par David Larlet, qui ajoute: <blockquote> J’ai ri. Je n’ai jamais fait une telle page car je sais que je n’arriverais pas à la maintenir à jour.</blockquote> Il a raison. Ce sur quoi une personne qui gère un site travaille actuellement devrait se voir par l’actualité de ses publications. Finalement, un blog vivant est déjà une pagee <code>/now</code> en soi. C’est pourquoi, en l’état, je me limiterai à des nouveaux billets. Rédiger une page dédiée, c’est tomber dans le métadiscours pour le métadiscours. Sauf quand une telle page est aboutie et dynamique comme la <a href="https://www.coryd.dev/now">page <code>/now</code> de Cory Dransfeldt</a>. Il a même proposé une vidéo sur le sujet: <a href="https://www.youtube.com/watch?v=AzcFZJYEpnQ">Building a performant <code>/now</code> page using 11ty</a>. C’est donc un métadiscours sur une page de métadiscours! <h2 id="contenus-utiles-et-contenus-reflexifs">Contenus utiles et contenus réflexifs</h2> De manière un peu caricaturale, il existe 2 types de contenus: <ul> <li>les contenus utiles: la mise à disposition de ressources pratiques (articles techniques, documentation, guides, etc.)</li> <li>les contenus réflexifs: la mise en récit de la construction du site lui-même (réflexions sur les choix éditoriaux, les évolutions techniques, etc.)</li> </ul> Mais qui s’intéresse un peu à la publications sur le web se rendra rapidement compte que c’est beaucoup plus compliqué. Il vaut la peine de relire [Enseignements du framework Diátaxis]/blog/diataxis-introduction/ et sortir de la caricature. Très souvent, les contenus réflexifs sur des projets web permettent de beaucoup mieux choisir ses outils. Dans ce cas, j’ai besoin du métadiscours sur les choix opérés, le pourquoi. Je ne cherche pas le «meilleur», mais le mieux adapté à mes besoins. Par exemple celui qui est presque aussi bon que le meilleur, mais beaucoup plus facile à utiliser. J’en parle dans <a href="https://nicolasfriedli.ch/blog/optimisation-raisonnable/">Philosophie d’optimisation raisonnable</a> <h2 id="se-centrer-sur-soi-ou-elargir-le-propos">Se centrer sur soi ou élargir le propos</h2> En rédigeant <a href="https://nicolasfriedli.ch/blog/blog-2025/">Lancer un blog en 2025(?)</a>, je me suis demandé si je parlais de ma présence en ligne ou de l’importance des sites personnels au sens large. Je parlais d’un blog, mais je parlais surtout d’une thématique plus large: la merdification des choses. Dans <a href="https://nicolasfriedli.ch/blog/garanti-sans-chatgpt/">Garanti sans ChatGPT (ou pas)</a>, je suis parti de mon site pour parler d’un sujet beaucoup plus général. La question de savoir s’il fallait ajouter une mention du type rédigé sans intelligence artificielle n’était que le point de départ pour parler d’un sujet de société. Quand le développeur Max Böck propose un système de changement de couleur du site dans <a href="https://mxb.dev/blog/color-theme-switcher/">Color Theme Switcher</a>, difficile de dire s’il parle de son site ou de développement web. Quand je propose le billet <a href="https://nicolasfriedli.ch/blog/recherche-statique-pagefind/">Recherche statique performante avec PageFind</a>, est-ce que je parle de mon blog ou de recherche sur le web? Ou plutôt de l’importance des règles Opquast et de la veille technologique? C’est tout l’intérêt d’un blog qui parle en «je» (explicitement ou implicitement). C’est justement ce que j’y cherche. C’est encore plus vrai quand la thématique principale d’un blog est le web. <h2 id="devoiler-les-coulisses">Dévoiler les coulisses</h2> Parfois, il existe assez de production de contenu pour ne pas avoir «besoin» de faire du métadiscours. C’est le cas du <a href="https://dianefriedli.ch/">blog de ma femme Diane Friedli</a>. Elle y publie ses prédications, des contes de Noël, des recensions, etc. Elle n’aurait pas besoin de parler des coulisses&hellip; et pourtant elle le fait. Dans <a href="https://dianefriedli.ch/poeme-acidule-ados/">Poème acidulé pour les ados</a>, elle rappelle le contexte de production et propose quelques lignes sur ses études en théologie. Elle aurait pu nous donner le texte seul; elle a choisi de le contextualiser. Et dans <a href="https://dianefriedli.ch/ce-blog-a-10-ans/">Ce blog a 10 ans</a>, est-ce qu’elle s’exprime vraiment au sujet de son blog? Ou est-ce qu’elle dit quelque chose sur sa vocation pastorale et sa manière de pratiquer son métier? Est-ce qu’elle tend une perche à ses collègues pour les inciter à bloguer aussi? Ce genre de contenu, qui propose discours et métadiscours, est ce qui fait toute la richesse des blogs et des sites personnels. Au final, les internautes ne n’y trompent pas, il y a bien une personne derrière le texte. Si celles et ceux qui s’expriment publiquement ouvraient les portes du laboratoire, la question des IA (intelligences artificielles) serait abordée autrement. Il n’y a pas de honte à utiliser ChatGPT ou à reprendre de l’existant, à condition de dire quelque chose de sa démarche, de ses forces, de ses limites et de la pertinence du résultat. <h2 id="personnes-ou-organisations">Personnes ou organisations</h2> J’ai un attachement aux personnes beaucoup plus qu’aux organismes et aux institutions. C’est d’ailleurs pour cette raison que j’ai libellé ainsi tous les intitulés de ma page <a href="https://nicolasfriedli.ch/blogroll/">liens</a>, même quand les sites ont un autre nom officiel. Quand les organisations ajoutent du métadiscours, c’est presque toujours <del>du bullshit</del> pour se justifier (et c’est mortifère). Quand des blogueurs et blogueuses parlent de leur blog, c’est la vraie vie qui surgit. <h2 id="envoi">Envoi</h2> Est-il encore possible de toucher les internautes en se réfugiant derrière l’académisme du nous ou le verbiage des organisations? À quoi bon (essayer de) vulgariser s’il n’y a pas de présence humaine pour nous prendre par la main? Finalement, que signifie choisir la vie dans nos modalités d’expression sur le web? Nous en sommes à installer des extensions de navigateurs pour détecter les contenus générés par IA. Il faudrait profiter du même élan pour détecter les contenus vides. Le métadiscours, malgré ses faiblesses et ses limites, est toujours ce qu’il y a de plus riche. Il révèle la personne derrière le texte. C’est précisément ce qui manque à tant de contenus aujourd’hui. <hr> Ce billet reprend une ancienne publication. J’ai essayé de fournir à ChatGPT cette archive et un liste de liens frais. Puis une trame rédactionnelle. J’ai obtenu un article correct mais complètement banal sur le métadiscours. Il était à l’exact opposé ce que que je prétends (et tente de faire) ici.</description></item><item><title>Recherche statique performante avec PageFind</title><link>https://nicolasfriedli.ch/blog/recherche-statique-pagefind/</link><pubDate>Mon, 10 Feb 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/recherche-statique-pagefind/</guid><description>Un moteur de recherche peut améliorer l’expérience des internautes (UX) en offrant un accès rapide aux contenus d’un site. Pour les sites statiques, il faut soit coder une recherche côté client à la main, soit utiliser un service tiers comme Algolia. Ou alors on peut utiliser PageFind qui se distingue par sa facilité d’intégration et ses performances. <h2 id="qualite-web">Qualité web</h2> La règle <a href="https://checklists.opquast.com/fr/assurance-qualite-web/le-site-propose-un-moteur-de-recherche-interne">Opquast 163</a> est sans équivoque: <blockquote> Le site propose un moteur de recherche interne. Le moteur de recherche est, avec le plan du site, les menus et le lien de retour à l’accueil, un des moyens fondamentaux de réorientation et d’accès à l’information. Rendez-le présent et facile d’accès.</blockquote> Je signale que la règle <a href="https://checklists.opquast.com/fr/assurance-qualite-web/chaque-page-de-resultats-de-recherche-peut-etre-atteint-via-une-adresse-web">Opquast 164</a> ne sera pas respectée: <blockquote> Chaque page de résultats de recherche peut être atteinte via une adresse Web.</blockquote> Alors que la règle <a href="https://checklists.opquast.com/fr/assurance-qualite-web/il-est-possible-de-relancer-une-recherche-depuis-sa-page-de-resultats">Opquast 165</a> le sera: <blockquote> Il est possible de relancer une recherche depuis sa page de résultats.</blockquote> <h2 id="presentation-de-pagefind">Présentation de PageFind</h2> <a href="https://pagefind.app/">PageFind</a> est conçu pour ajouter une recherche interne aux sites statiques: <ul> <li>il analyse toutes les pages générées (en local) pour créer un index</li> <li>il génère le code nécessaire pour l’affichage et la recherche côté client</li> <li>il est rapide à la compilation et léger à l’usage</li> <li>il est utilisable sans configuration (et il est configurable)</li> <li>il est très bien documenté</li> </ul> Je viens de parcourir l’ensemble de la documentation pour imaginer les possibles cet outil. Elle est très claire, bien structuré, ni trop longue, ni trop succincte. Si le sujet vous intéresse, je vous conseille ces vidéos: <ul> <li><a href="https://www.youtube.com/watch?v=WgoBoX4qTk8">Static Search on Hugo: The Journey to Pagefind v1.0</a></li> <li><a href="https://www.youtube.com/watch?v=wb6tD2gDv2c">Workshop and Interview with Pagefind engineer Liam Bigelow</a></li> </ul> Je conseille de toujours se renseigner sur les objectifs d’un projet avant de l’adopter ou non. PageFind vise à être performant sur de grands sites, en utilisant le moins de bande passante possible et sans infrastructure particulière ou de service tiers. Je suis impressionné du resultat, avec des réponses souvent meilleures que la recherche de <del>WordPress</del> des CMS classique. <h2 id="inclure-la-recherche-dans-hugo">Inclure la recherche dans Hugo</h2> Comme je ne souhaite pas la recherche sur toutes les pages, j’ai créé un shortcode Hugo que je peux placer où je le veux. Je pourrais très bien l’appeler ici avec un simple <code>{{&lt; search &gt;}}</code>. Sur ce site, j’ai choisi de l’intégrer dans une page dédiée à la recherche. Le code de <code>layout/shortcodes/search.html</code> est une reprise la proposition de <a href="https://pagefind.app/docs/">Getting Started with Pagefind</a> avec quelques <a href="https://pagefind.app/docs/ui/">options de configuration</a>: <pre tabindex="0"><code>&lt;link href=&#34;/pagefind/pagefind-ui.css&#34; rel=&#34;stylesheet&#34;&gt; &lt;script src=&#34;/pagefind/pagefind-ui.js&#34;&gt;&lt;/script&gt; &lt;div id=&#34;search&#34;&gt;&lt;/div&gt; &lt;script&gt; window.addEventListener(&#34;DOMContentLoaded&#34;, (event) =&gt; { new PagefindUI({ element: &#34;#search&#34;, pageSize: 10, showSubResults: true, showImages: false, autofocus: true }); }); &lt;/script&gt; </code></pre>Bien entendu, je lance PageFind entre la compilation avec Hugo et le déploiement sur le serveur. <h2 id="conclusion">Conclusion</h2> La promesse de PageFind est tenue. Il est très simple d’intégrer une bonne recherche à un site statique en quelques minutes. Le lien se trouve dans le menu principal. Désormais, j’attends 2 informations pour faire un vrai bilan. Est-ce que la recherche est bonne? La pertinence des résultats, la rapidité de recherche et la qualité de l’affichage sont essentielles. Vos retours tant positifs que négatifs sont précieux. Est-ce qu’elle est utilisée? Les statistiques Plausible vont me donner quelques indices sur l’utilisation réelle de la page de recherche. Si elle n’est pas utilisée, je me poserai aussi la question d’inclure la recherche sur toutes les pages du site. J’en profite pour créer un <a href="https://nicolasfriedli.ch/blog/linkmail/">mail prérempli</a> pour les résultats: <a href="mailto:hello+2025@nicolasfriedli.ch?subject=Test%20de%20PageFind&amp;body=Hello%2C%0D%0A%0D%0AJe%20viens%20de%20tester%20un%20peu%20PageFind%20sur%20ton%20site%20et%20voici%20ce%20que%20je%20peux%20en%20dire.%0D%0A%0D%0AC%E2%80%99est%20globalement%3A%20excellent%20%2F%20bon%20%2F%20moyen%20%2F%20mauvais%20%2F%20non%20fonctionnel%0D%0A%0D%0AExemples%20de%20recherche%20qui%20fournissent%20de%20bons%20r%C3%A9sultats%3A%0D%0A%0D%0AExemples%20de%20recherche%20qui%20fournissent%20de%20mauvais%20r%C3%A9sultats%3A">Envoyer mes tests de recherche dans TestFind</a>. Merci!</description></item><item><title>Nom de domaine personnel: un atout pour vos QR codes, Mastodon & Bluesky</title><link>https://nicolasfriedli.ch/blog/nom-domaine-personnel/</link><pubDate>Sun, 09 Feb 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/nom-domaine-personnel/</guid><description>Notre présence en ligne est devenue une extension de notre identité personnelle et professionnelle. Réserver son propre nom de domaine est une solution simple et efficace pour reprendre le contrôle. Il permet d’assurer la pérennité de son identité numérique, d’être facilement identifiable et d’éviter les changements imposés par des plateformes. Ce billet explore trois usages concrets d’un nom de domaine: QR codes, Mastodon et Bluesky. Il ne revient pas sur des sujets rebattus comme la pérennité des adresses mail ou d’un <a href="https://nicolasfriedli.ch/blog/blog-2025/">blog personnel en 2025</a>. <h2 id="utilisation-de-qrcodes">Utilisation de QR codes</h2> J’ai essayé de donner des <a href="https://nicolasfriedli.ch/blog/conseils-qr-code/">conseils pour l’utilisation des QR code</a> dans un long billet. La question de son propre nom de domaine est centrale. Je n’y reviens pas ici. J’ajoute simplement que le passage par un nom de domaine pérennise les choses. Avec un nom de domaine, vous pouvez investir dans des supports durables: <ul> <li>gravure sur un pendentif (ou ma médaille du chien)</li> <li>impression en grande taille pour la porte de la voiture</li> <li>pyrogravure d’une plaquette professionnelle</li> <li>tatouage sur l’avant-bras</li> </ul> Évitez d’engager des frais pour tout code qui ne renvoie pas à votre nom de domaine personnel. En particulier pour le tatouage&hellip; <h2 id="utilite-du-nom-de-domaine-personnel-chez-mastodon">Utilité du nom de domaine personnel chez Mastodon</h2> <h3 id="validation-des-liens">Validation des liens</h3> Sur un profil Mastodon, qui remplace très bien Twitter (X), il est possible d’obtenir des validations. Dans mon cas le compte <a href="https://mastodon.social/@nicolasfriedli">@nicolasfriedli</a> propose 2 liens validés: GitHub et mon site personnel. Ces liens sont en vert. Mieux encore, lors d’une recherche, le lien validé s’affiche en vert dans les résultats. Je peux donc vérifier instantanément que la personne que je vais suivre est bien celle qui possède le nom de domaine que je consulte régulièrement. C’est un critère de validation fort, simple et efficace. <h3 id="attribution-dauteur-ou-dautrice">Attribution d’auteur ou d’autrice</h3> On peut aussi valider son nom sous ses publications (author attribution) pour une liste précise de sites. Lorsque je publie sur mon site personnel, il y a mon nom Mastodon sous la publication. C’est très plus utile lorsque d’autres personnes partagent mes publications (<a href="https://mastodon.social/@nicolasfriedli/113973218633632714">exemple en action</a>). <h3 id="adresse-perenne-avec-webfinger">Adresse pérenne avec WebFinger</h3> Finalement chez Mastodon, en utilisant le <a href="https://docs.joinmastodon.org/spec/webfinger/">protocole Webfinger</a>, il est possible de créer une adresse de raccourci indépendant de l’instance utilisée, donc pérenne. Mon profil lié à un nom de domaine que je possède est @n@frdl.ch. C’est un alias, que je peux rediriger en tout temps vers une autre instance Mastodon. <h2 id="nom-de-compte-chez-bluesky">Nom de compte chez Bluesky</h2> Bluesky (ou bsky) est un autre remplaçant possible de Twitter (X). Il a choisi un système intéressant pour les noms de comptes. En principe, les comptes se terminent en <code>.bsky.social</code>. Le nom complet d’un compte pour moi pourrait être <code>nicolasfriedli.bsky.social</code>. Avec un nom de domaine, on peut se passer totalement du <code>.bsky.social</code>. Je dispose désormais du compte @nicolasfriedli.ch. Regardez l’adresse: <a href="https://bsky.app/profile/nicolasfriedli.ch">bsky.app/profile/nicolasfriedli.ch</a>. Détail frappant: elle contient un <code>.</code> (point) alors que ce n’est pas possible lors de l’inscription. J’ai validé mon nom de compte par mon nom domaine. Le truc génial, c’est que si tu possèdes le nom de domaine <code>monsieurmichu.ch</code>, personne ne pourra réserver le profil Bluesky à ta place. Autrement dit, même si tu ne crées pas de compte, il est «réservé». Bravo à Bluesky pour cette idée simple et brillante. <hr> Je conseille de réserver vos comptes chez <a href="https://www.infomaniak.com/fr">Infomaniak</a>. Chaque compte donne droit à une adresse mail avec des alias et la <a href="https://nicolasfriedli.ch/blog/mail-plus/">possibilité d’utiliser le signe +</a>. Et aussi à un petit hébergement qui peut être suffisant pour quelques pages de présentation. Et dans le doute, c’est simplement <code>prenomnom.ch</code>. <hr> Je ne compte pas utiliser les comptes Mastodon et Bluesky créés pour faire quelques tests.</description></item><item><title>Utiliser des liens mail préremplis sur son site web</title><link>https://nicolasfriedli.ch/blog/linkmail/</link><pubDate>Sat, 08 Feb 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/linkmail/</guid><description>Les liens <code>mailto</code> sont un moyen simple et efficace d’encourager les utilisateurs au contact direct par mail. Ils peuvent être enrichis pour inclure un sujet, un message prérempli et d’autres informations. Nous verrons comment tirer parti des liens mailto préremplis, en comparant leurs avantages et leurs limites face aux formulaires de contact. Je vous propose une solution efficace pour les automatiser dans Hugo grâce à un shortcode. <h2 id="structure-des-liens">Structure des liens</h2> La syntaxe des liens HTML la plus simple pour un mail, c’est: <pre tabindex="0"><code>&lt;a href=&#34;mailto:hello+linkmail@nicolasfriedli.ch&#34;&gt;hello+linkmail@nicolasfriedli.ch&lt;/a&gt; </code></pre>En Markdown, il est possible de le saisir avec: <pre tabindex="0"><code>[hello+linkmail@nicolasfriedli.ch](mailto:hello+linkmail@nicolasfriedli.ch) </code></pre>Et, parfois, les outils de rédaction ou les périphériques de lecture transforment du simple texte en lien cliquable: <pre tabindex="0"><code>hello+linkmail@nicolasfriedli.ch </code></pre>Mais ce qui est intéressant, c’est d’ajouter directement du contenu au lien lui-même. C’est facile avec <a href="https://mailtolink.me/">mailtolink.me</a>. Le résultat, c’est <a href="mailto:hello+mailto@nicolasfriedli.ch?subject=Ton%20article%20sur%20LinkMail&amp;body=Je%20viens%20de%20lire%20ton%20billet%20sur%20les%20liens%20mail%20et%20j%E2%80%99ai%20une%20question%20%2F%20une%20remarque%20%2F%20un%20compl%C3%A9ment%20%C3%A0%20apporter.">une réponse à ce billet</a>. Le sujet du message est déjà renseigné, tout comme mon adresse (logique) et quelques lignes de texte. Et si cela ne fonctionne pas bien, la suite vous explique pourquoi. Dans votre CMS (probablement WordPress), il suffit de copier le code généré par mailtolink.me comme toute n’importe quelle cible de lien. <h2 id="avantages-des-liens-mail-preremplis">Avantages des liens mail préremplis</h2> Les liens <code>mailto</code> enrichis offrent certains avantages: <ul> <li>l’adresse d’envoi est fatalement valide</li> <li>la personne qui envoie le mail possède toujours une copie dans sa boîte</li> <li>les messages peuvent être complétés librement</li> <li>il est possible d’ajouter des pièces jointes</li> </ul> La difficulté c’est qu’il faut utiliser l’<a href="https://fr.wikipedia.org/wiki/Encodage-pourcent">encodage-pourcent</a>. C’est facile avec l’outil mailtolink.me, mais plus difficile (ou franchement pénible) à la main. <h2 id="pourquoi-les-formulaires-de-contact-posent-probleme">Pourquoi les formulaires de contact posent problème</h2> Je n’aime pas beaucoup les formulaires de contact. Ils créent potentiellement beaucoup de problèmes: <ul> <li>si l’adresse d’envoi est fausse, il n’y a aucune vérification</li> <li>ils permettent rarement l’envoie de pièces jointes (ou limitent leur nombre)</li> <li>il demandent un nombre important de <a href="https://checklists.opquast.com/fr/assurance-qualite-web/?theme=formulaires">contrôles de qualité</a></li> <li>ils ne sont pas plus effiaces contre le spam que de filtres de messagerie</li> </ul> Le seul avantage est qu’ils permettent de bien structurer une demande, avec des champs distincts (qui peuvent recevoir des contraintes et validations). Je conseille <a href="https://www.paris-web.fr/2022/conference/decouvrez-le-bon-html-et-economisez-du-js-et-du-css">Découvrez «le bon HTML» et économisez du JS et du CSS</a> pour en savoir plus. <h2 id="les-inconvenients-et-limites-des-liens-mailto">Les inconvénients et limites des liens <code>mailto</code></h2> J’ai vanté les mérites des liens `mailto, mais ils ne sont pas exempts de défauts. Mais je ne vous cache pas qu’ils posent aussi certains problèmes. Amy Hupe et Adam Silver les ont documentés dans <a href="https://adamsilver.io/blog/the-trouble-with-mailto-email-links-and-what-to-do-instead/">The trouble with mailto email links and what to do instead</a>. En résumé, ces liens posent problème quand: <ul> <li>une messagerie n’est pas configurée sur le périphérique</li> <li>je souhaite avoir le choix de la messagerie au clic</li> <li>je souhaite copier une adresse</li> </ul> Je m’inspire de leur approche dans le passage offering choice et propose: <ul> <li>un lien textuel avec le contenu du mail prérempli</li> <li>l’affichage de l’adresse en pur texte à côté</li> </ul> Ainsi, toutes les options restent possibles en fonction des préférence de l’internaute. <h2 id="shortcode-dans-hugo">Shortcode dans Hugo</h2> C’est très facile à faire avec mailtolink.me, mais je souhaite automatiser la procédure dans Hugo. Ainsi, je souhaite créer un lien prérempli quand je rédige en Markdown: <pre tabindex="0"><code>{{&lt; linkmail to=&#34;hello+linkmail@nicolasfriedli.ch&#34; subject=&#34;Test de Link Mail&#34; text=&#34;Envoyer une proposition&#34; &gt;}} Exemple de texte qui préremplit le message. Avec un saut de ligne. {{&lt; /linkmail &gt;}} </code></pre>Pour effectuer la transformation, je crée <code>layouts/shortcodes/linkmail.html</code>: <pre tabindex="0"><code>&lt;a href=&#34;mailto:{{- .Get &#34;to&#34; -}}?subject={{- .Get &#34;subject&#34; -}}&amp;body={{- strings.TrimSpace .Inner -}}&#34;&gt; {{- .Get &#34;text&#34; -}} &lt;/a&gt; ({{ .Get &#34;to&#34; }}) </code></pre>Et j’obtiens le résultat escompté: <a href="mailto:hello&#43;linkmail@nicolasfriedli.ch?subject=Test%20de%20Link%20Mail&body=Exemple%20de%20texte%20qui%20pr%c3%a9rempli%20le%20message.%0aAvec%20un%20saut%20de%20ligne.">Envoyer une proposition</a> (hello&#43;linkmail@nicolasfriedli.ch) Attention, c’est une solution <a href="https://fr.wikipedia.org/wiki/Quick-and-dirty">Quick-and-dirty</a>. Je ne fais aucune vérification dans le shortcode. Mais la transformation par Hugo se charge de l’encodage-pourcent et <code>strings.TrimSpace</code> supprime des espaces inutiles. C’est l’essentiel. Cette solution rapide fonctionne bien dans Hugo, mais elle pourrait être améliorée avec des vérifications supplémentaires. Il faudrait l’adapter aux cas spécifiques, affiner la mise en forme du lien et optimiser la syntaxe d’appel. Toutefois, c’est une approche intéressante pour systématiser l’usage des liens <code>mailto</code> enrichis sans outil tiers.</description></item><item><title>Améliorer la typographie des nombres en CSS</title><link>https://nicolasfriedli.ch/blog/typographie-nombres-css/</link><pubDate>Fri, 07 Feb 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/typographie-nombres-css/</guid><description>Avec quelques lignes de code, il est possible d’améliorer la présentation de sa page de manière discrète mais efficace. La propriété <code>font-variant-numeric</code> permet une gestion typographique avancée des nombres. <h2 id="variantes-de-font-variant-numeric">Variantes de <code>font-variant-numeric</code></h2> Parmi toutes les propriétés (voir <a href="https://developer.mozilla.org/fr/docs/Web/CSS/font-variant-numeric">font-variant-numeric</a> chez MDN), 5 sont bigrement utiles: <ul> <li>2 agissent sur leur graphie: <code>lining-nums</code>et <code>oldstyle-nums</code></li> <li>2 agissent sur la largeur des chiffres: <code>proportional-nums</code> et <code>tabular-nums</code></li> <li>1 permet de modifier le zéro: <code>slashed-zero</code></li> </ul> <code>lining-nums</code> propose des chiffres alignés sur le ligne de base du texte et de hauteur uniforme. Presque toutes les polices les utilisent par défaut. Alors que <code>oldsyles-nums</code> propose des chiffres «à l’ancienne», aussi appelés <a href="https://fr.wikipedia.org/wiki/Chiffres_elz%C3%A9viriens">elzéviriens</a>. La police Georgia a la particularité de ne proposer que de tels chiffres. <code>proportional-nums</code> ne force pas la largeur des chiffres (donc 1 est généralement plus étroit que 0). C’est ce qui est courant dans le texte. Alors que <code>tabular-nums</code> impose une même largeur pour les 10 chiffres (à la manière d’une police à chasse fixe). C’est un vrai plus dans les tableaux (et dans le code). <code>slashed-zero</code> permet d’afficher un 0 barré ou pointé qui se distingue au mieux de la lettre O. C’est utile pour des raisons d’accessiblité, mais je ne l’utilise pas ici. <h2 id="mise-en-application-en-css">Mise en application en CSS</h2> On applique un comportement par défaut puis on précise les usages particuliers. Pour toute la page, par défaut: <pre tabindex="0"><code>html { font-variant-numeric: oldstyle-nums proportional-nums; } </code></pre>Pour les liens (et éventuellement pour la titraille): <pre tabindex="0"><code>a /*, h1, h2, h3, h4 /* { font-variant-numeric: lining-nums proportional-nums; } </code></pre>Pour les tableaux et le code: <pre tabindex="0"><code>code, pre, table { font-variant-numeric: lining-nums tabular-nums; } </code></pre>Je ne vois pas de raison d’utiliser la combinaison <code>oldstyle-nums tabular-nums</code>. Si la police utilisée ne dispose pas de ces variations, elle s’affichera quand même parfaitement. C’est donc sans risque. <h2 id="le-probleme-de-google-fonts">Le problème de Google Fonts</h2> Pour visualiser tous les caractères et les variations d’une police, rien ne vaut <a href="https://wakamaifondue.com/">Wakamai Fondue</a>. Je préfère sa version ancienne à la version beta disponible en bas de page. Je télécharge <a href="https://fonts.google.com/specimen/Roboto">Roboto</a> chez Google Fonts. Puis je passe le fichier <code>Roboto-Regular.ttf</code> dans la moulinette. 922 caractères et 1321 glyphes pour 143Ko. Mais dans la pratique, on essaie d’utiliser des versions limitées (ici à l’alphabet latin) pour alléger le fichier et dans un format plus optimal (woff2). J’effecture la transformation sur mon ordinateur: <pre tabindex="0"><code>glyphhanger --formats=woff2 --subset=Roboto-Regular.ttf --LATIN </code></pre>Et j’envoie <code>Roboto-Regular-subset.woff2</code> chez Wakamai Fondue: 245 caractères, 409 glyphes pour 24Ko. Dans la pratique, les développeurs et développeuses utilisent très souvent le génial <a href="https://gwfh.mranftl.com/fonts">google-webfonts-helper</a> pour obtenir des polices déjà optimisées via Google Fonts. Pour l’exemple présent, <code>roboto-v47-latin-regular.woff2</code> que j’envoie aussi en cuisine. Dans la caquelon, je trouve 229 caractères, 363 glyphes pour 20Ko. Google Fonts supprime des options de la police de départ, dont les fameux chiffres elzéviriens. On peut considérer que c’est une très bonne optimisation ou que ça revient à dénaturer la typographie. Le problème, c’est que, selon le <a href="https://almanac.httparchive.org/en/2024/">Web Almanac 2024</a>, 85% des sites font appel à des polices web (webfonts). Et je parie que, quand elles ne font pas appel à Google Fonts, elles sont obtenues via google-webfonts-helper dans une grande majorité des cas. Autant dire que vous risquez de ne jamais voir Roboto, Fira Sans et plein d’autres belles polices à leur juste valeur. Pour que les internautes les voient, il faut faire ses optimisations soi-même ou miser sur les polices locales. <hr> Si vous utilisez Android, vous devriez voir des chiffres elzéviriens. Ils s’affichent en Roboto locale (appelée par <code>system-ui</code>) parce que je ne vous impose pas une police web. Si vous utilisez un périphérique Apple, vous ne verrez logiquement pas de «old style nums» parce que San Francisco (appelée par <code>ui-sans-serif</code>) n’en propose pas. Sauf si vous avez installé Roboto sur votre ordinateur. Si vous utilisez Windows, vous verrez probablement cette page en police Segoe UI qui propose aussi la variation elzévirienne. Note. Ces indications sont valables au moment de la publication de cette page. Je changerai peut-être ma feuille de style sans les remettre à jour.</description></item><item><title>Travailler avec un budget de performance web</title><link>https://nicolasfriedli.ch/blog/budget-performance/</link><pubDate>Thu, 06 Feb 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/budget-performance/</guid><description>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. <h2 id="quest-ce-quun-budget-de-performance">Qu’est-ce qu’un budget de performance?</h2> La première visée d’un budget de performance est le contrôle suivi (monitoring) facilité de ses pages web. Un budget de performance fixe les contraintes d’affichage d’une page web en équilibrant: <ul> <li>les ressources consommées (temps de chargement, poids et nombre de fichiers)</li> <li>les attentes des internautes (rapidité perçue, fluidité de navigation)</li> <li>les limites techniques (bande passante, capacité des appareils)</li> </ul> Il s’agit de bien utiliser ce qui est accordé (voire de «dépenser» moins) pour garantir une expérience optimale. <h2 id="exemple-pratique">Exemple pratique</h2> Concrètement, voici comment appliquer un budget de performance avec <a href="https://developer.chrome.com/docs/lighthouse/overview/">Lighthouse</a>: <pre tabindex="0"><code>npx lighthouse https://nicolasfriedli.ch/blog/budget-performance/ \ --budget-path=budget.json \ --view \ --only-categories=performance </code></pre>Avec un budget défini dans un fichier JSON (mise en forme comptacte): <pre tabindex="0"><code>[ { &#34;timings&#34;: [ {&#34;metric&#34;: &#34;cumulative-layout-shift&#34;, &#34;budget&#34;: 0}, {&#34;metric&#34;: &#34;first-contentful-paint&#34;, &#34;budget&#34;: 1800}, {&#34;metric&#34;: &#34;interactive&#34;, &#34;budget&#34;: 1000}, {&#34;metric&#34;: &#34;largest-contentful-paint&#34;, &#34;budget&#34;: 2500}, {&#34;metric&#34;: &#34;speed-index&#34;, &#34;budget&#34;: 1200}, {&#34;metric&#34;: &#34;total-blocking-time&#34;, &#34;budget&#34;: 0} ], &#34;resourceSizes&#34;: [ {&#34;resourceType&#34;: &#34;total&#34;, &#34;budget&#34;: 100}, {&#34;resourceType&#34;: &#34;document&#34;, &#34;budget&#34;: 50}, {&#34;resourceType&#34;: &#34;font&#34;, &#34;budget&#34;: 0}, {&#34;resourceType&#34;: &#34;image&#34;, &#34;budget&#34;: 200}, {&#34;resourceType&#34;: &#34;media&#34;, &#34;budget&#34;: 200}, {&#34;resourceType&#34;: &#34;other&#34;, &#34;budget&#34;: 200}, {&#34;resourceType&#34;: &#34;script&#34;, &#34;budget&#34;: 5}, {&#34;resourceType&#34;: &#34;stylesheet&#34;, &#34;budget&#34;: 5}, {&#34;resourceType&#34;: &#34;third-party&#34;, &#34;budget&#34;: 5} ], &#34;resourceCounts&#34;: [ {&#34;resourceType&#34;: &#34;total&#34;, &#34;budget&#34;: 10}, {&#34;resourceType&#34;: &#34;font&#34;, &#34;budget&#34;: 0}, {&#34;resourceType&#34;: &#34;image&#34;, &#34;budget&#34;: 10}, {&#34;resourceType&#34;: &#34;media&#34;, &#34;budget&#34;: 0}, {&#34;resourceType&#34;: &#34;other&#34;, &#34;budget&#34;: 2}, {&#34;resourceType&#34;: &#34;script&#34;, &#34;budget&#34;: 1}, {&#34;resourceType&#34;: &#34;stylesheet&#34;, &#34;budget&#34;: 0} ] } ] </code></pre>Dans cet exemple, on souhaite par exemple: <ul> <li>l’affichage complet de la page en 2.5 secondes</li> <li>l’absence de mouvements parasites (Cumulative Layout Shift à 0)</li> <li>100ko maximum pour l’ensemble des transferts</li> <li>l’absence complètes de polices web (webfonts)</li> </ul> C’est un budget très strict, adapté à ce site, mais trop restrictif dans bien des cas. Comme la sources JSON le montre clairement, il y a 3 catégories de mesures: <ul> <li>la vitesse pure (timings)</li> <li>la taille des ressources (resourceSizes)</li> <li>le nombre des ressources (resourceCounts)</li> </ul> Dans chaque catégorie, il est possible de spécifier une ou plusieurs valeurs. <h2 id="budget-pour-commencer">Budget pour commencer</h2> Il est possible de créer un budget JSON simplifié pour attaquer le sujet et faire ses premiers tests: <pre tabindex="0"><code>[ { &#34;timings&#34;: [ { &#34;metric&#34;: &#34;largest-contentful-paint&#34;, &#34;budget&#34;: 3000 } ], &#34;resourceSizes&#34;: [ { &#34;resourceType&#34;: &#34;total&#34;, &#34;budget&#34;: 1000 } ], &#34;resourceCounts&#34;: [ { &#34;resourceType&#34;: &#34;total&#34;, &#34;budget&#34;: 100 } ] } ] </code></pre>Dans ce cas, je vise: <ul> <li>une page qui se charge en moins de 3 secondes</li> <li>qui pèse au maximum 1Mo</li> <li>qui n’appelle pas plus de 100 fichiers au total</li> </ul> Commencez par là et essayez de le respecter. Si c’est le cas, votre site sera déjà très bon. <h2 id="la-discussion-du-budget">La discussion du budget</h2> Je vois d’autres utilités que le monitoring à l’établissement d’un budget de performance. En premier lieu, les débats dans l’équipe de développement lors de son établissement. La conférence <a href="https://www.youtube.com/watch?v=BmiVevOUvho">The Global Baseline, 2022</a> 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 <a href="https://infrequently.org/2024/01/performance-inequality-gap-2024/">The Performance Inequality Gap, 2024</a>. 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. <h2 id="les-problematiques-internes">Les problématiques internes</h2> En deuxième lieu, un budget de performance est un outil de dialogue entre les équipes. Dans la réalité des entreprises et organisations: <ul> <li>les graphistes veulent des typographies spécifiques</li> <li>le marketing a (soi-disant) besoin de trackers analytiques</li> <li>la direction souhaite intégrer des widgets sociaux</li> <li>les juristes veillent à la protection des données</li> </ul> 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. <h2 id="rapport-aux-prestataires-externes">Rapport aux prestataires externes</h2> Troisièmement, travailler avec un budget de performance facilite la relation avec une agence web. Un simple fichier <code>budget.json</code> permet: <ul> <li>de fixer des attentes claires dès le début du projet</li> <li>d’évaluer si l’agence maîtrise vraiment les enjeux techniques</li> <li>d’arbitrer les demandes pour d’éviter les compromis nuisibles</li> <li>de justifier d’éventuelles corrections ou d’exiger une réduction de la facture</li> </ul> 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. <h2 id="conclusion">Conclusion</h2> 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 qui militent 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.</description></item><item><title>Activer les polices Google Fonts à la demande</title><link>https://nicolasfriedli.ch/blog/google-fonts-demande/</link><pubDate>Wed, 05 Feb 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/google-fonts-demande/</guid><description>Google Fonts est un service qui fonctionne très bien. Mais je refuse d’envoyer des polices distantes sur votre périphérique sans votre autorisation. De plus, c’est souvent inutile si vous avez des polices correctes installées. Ce billet fait suite aux difficultés de proposer une <a href="https://nicolasfriedli.ch/blog/inter-variable-opsz/">police locale variable</a> correctement. Note. Cette proposition fonctionne sur cette page au moment de sa mise en ligne. Le code reste valable, mais il ne sera plus forcément actif sur ce site. <h2 id="la-solution-facile-et-rapide-google-fonts">La solution (facile et rapide) Google Fonts</h2> Je propose une solution toute simple pour celles et ceux souhaitent une police précise (qui ont des problèmes d’affichage). J’active les Google Fonts si la variable <code>googlefonts</code> a la valeur <code>yes</code> sans le stockage web local (localStorage). Cette solution n’est active que sur cette page, mais elle s’active sur tout le site en utilisant ce code sur chaque page. <pre tabindex="0"><code>if (localStorage.getItem(&#34;googlefonts&#34;) === &#34;yes&#34;) { let link = document.createElement(&#34;link&#34;); link.rel = &#34;stylesheet&#34;; link.href = &#34;https://fonts.googleapis.com/css2?family=JetBrains+Mono:ital,wght@0,100..800;1,100..800&amp;family=Roboto:ital,wght@0,100..900;1,100..900&amp;display=swap&#34;; document.head.appendChild(link); } </code></pre>On pourrait d’arrêter là et dire aux internautes qui souhaitent des Google Fonts d’entrer la valeur <code>yes</code> au bon endroit. Ce serait un peu rude (plus que leur conseiller d’installer <a href="https://fonts.google.com/specimen/JetBrains+Mono">JetBrains Mono</a> et <a href="https://fonts.google.com/specimen/Roboto">Roboto</a>). Donc, on ajoute un bouton qui stocke la valeur et ajoute la feuille de style sans délai: <pre tabindex="0"><code>&lt;button id=&#34;googlefonts&#34;&gt;Activer les Google Fonts&lt;/button&gt; &lt;script&gt; document.getElementById(&#34;googlefonts&#34;).addEventListener(&#34;click&#34;, function() { localStorage.setItem(&#34;googlefonts&#34;, &#34;yes&#34;); let link = document.createElement(&#34;link&#34;); link.rel = &#34;stylesheet&#34;; link.href = &#34;https://fonts.googleapis.com/css2?family=JetBrains+Mono:ital,wght@0,100..800;1,100..800&amp;family=Roboto:ital,wght@0,100..900;1,100..900&amp;display=swap&#34;; document.head.appendChild(link); }); &lt;/script&gt; </code></pre>Il y a du code dupliqué (ce n’est pas très propre), mais comme je ne l’utilise que sur cette page, je m’en fiche un peu. On pourrait aussi ajouter seulement la valeur dans le localStorage et attendre le rechargement de la page pour agir. <pre tabindex="0"><code>&lt;button id=&#34;googlefonts&#34;&gt;Activer les Google Fonts&lt;/button&gt; &lt;script&gt; document.getElementById(&#34;googlefonts&#34;).addEventListener(&#34;click&#34;, function() { localStorage.setItem(&#34;googlefonts&#34;, &#34;yes&#34;); }); &lt;/script&gt; </code></pre>Le résultat, c’est ceci: <button id="googlefonts" class="plausible-event-name=Google+Fonts">Activer les Google Fonts</button> <script> function applyGoogleFonts() { if (!document.getElementById("google-fonts-link")) { let link = document.createElement("link"); link.id = "google-fonts-link"; link.rel = "stylesheet"; link.href = "https://fonts.googleapis.com/css2?family=JetBrains+Mono:ital,wght@0,100..800;1,100..800&family=Roboto:ital,wght@0,100..900;1,100..900&display=swap"; document.head.appendChild(link); } document.documentElement.style.fontFamily = "'Roboto', sans-serif"; document.querySelectorAll("pre, code").forEach(el => { el.style.fontFamily = "'JetBrains Mono', monospace"; }); } document.getElementById("googlefonts").addEventListener("click", function () { localStorage.setItem("googlefonts", "yes"); applyGoogleFonts(); }); if (localStorage.getItem("googlefonts") === "yes") { applyGoogleFonts(); } </script> Désormais, c’est mémorisé: ce périphérique chargera les Google Fonts. Pour toujours (à moins de modifier manuellement la valeur du localStorage ou de créer un bouton qui se charge de le faire). Si vous revenez sur cette page, ce sera toujours le cas sans cliquer à nouveau sur le bouton. <h2 id="la-solution-locale">La solution locale</h2> J’avais testé une solution complètement locale avec Inter: <ol> <li>Conversion des polices variables en <code>woff2</code> et limitation aux caractères latins (subsetting).</li> <li>Ajout des <code>@font-face</code> qui vont bien dans la feuille de style.</li> <li>Quand les webfonts sont acceptés dans le localStorage (par un bouton), ajout d’une class sur <code>html class=&quot;webfonts&quot;</code>.</li> <li>Déclaration de <code>font-family</code> spécifique à <code>html.webfonts</code>.</li> <li>Cacher le bouton d’activation s’il a le localStorage comprend déjà l’acceptation.</li> </ol> Tout est disponible dans le commit <a href="https://github.com/nfriedli/nicolasfriedli.ch/commit/6f1fb29130cbbcd2907e01c2e7cb5da7f043631b">6f1fb29</a> sur GitHub. <h2 id="les-chantiers-inutiles">Les chantiers inutiles</h2> Ce titre est un hommage aux <a href="https://fr.wikipedia.org/wiki/Grands_travaux_inutiles">grands travaux inutiles</a>. Au fond, ces 2 propositions me paraissent inutiles, parce que mes choix de polices système suffisent. Mais j’avais envie de tester 2 choses. D’une part, laisser le choix aux internautes concernant les polices Google Fonts. Cela peut se mettre en place en 5 minutes. Et il n’est pas besoin de faire clignoter des bannières de consentement et autres trucs. Un bouton; c’est tout! D’autre part, tester le chargement conditionnel d’une police locale, pour imaginer une solution sans service tiers. C’est un peu plus pénible à maintenir, notamment pour réactualiser les polices quand nécessaire. C’est un peu plus compliqué à mettre en œuvre, notamment selon les jeux de caractères utilisés sur le site. Mais c’est possible. À la suite de cet exercice avec des web fonts, je suis encore plus convaincu des polices locales. Je proposerai désormais toujours de travailler avec font stacks système. Puis permettre d’activer d’autres fontes par un bouton. Je suis presque certain que personne ne cliquera. <hr> Ce page transfère environ 5ko de données pour le contenu (HTML et CSS). À l’activation des polices Google Fonts, ce sont un peu plus de 120ko qui sont téléchargés. C’est 24 fois plus. Rien à ajouter!</description></item><item><title>Inter variable avec taille optique</title><link>https://nicolasfriedli.ch/blog/inter-variable-opsz/</link><pubDate>Tue, 04 Feb 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/inter-variable-opsz/</guid><description>Sur mon poste Linux, la police d’écriture Inter installé localement est variable (graisses de 100 à 900). Mais elle n’utilise pas les tailles optiques (<code>opsz</code>). Cela (me) pose problème, car Inter est trop espacée en grande taille, pour les titres et les intertitres. Si j’utilise Inter en webfont (fichier <code>woff2</code>), tout va bien. La police est variable en graisse (<code>wght</code>) comme en taille (<code>opsz</code>) Dans ma recherche pour proposer une font stack (pile de polices) de qualité sans recourir à des envois de fichiers, je croyais avoir enfin trouvé la solution. Comme Chrome et Firefox ne sont pas d’accord sur la manière de nommer une police dans un <code>font-face</code>, cette solution ne fonctionne pas toujours! Si vous souhaitez une solution qui marche partout en 2025, il faut passer par un webfont&hellip; <h2 id="inter-avec-font-face">Inter avec <code>font-face</code></h2> Pour obtenir la variation tant souhaitée, je déclare la police avec <code>font-face</code>, comme si c’était une police distante: <pre tabindex="0"><code>:root { font-optical-sizing: auto; } @font-face { font-family: &#34;Inter Variable&#34;; /* sélection de la version variable */ font-style: normal; font-weight: 100 900; src: local(&#34;Inter Variable&#34;); /* nom local de la police */ } @font-face { font-family: &#34;Inter Variable&#34;; /* sélection de la version variable */ font-style: italic; font-weight: 100 900; src: local(&#34;Inter Variable Italic&#34;); /* nom local de la police */ } </code></pre>Cette déclaration ne fonctionne pas dans Chrome pour Windows. <h2 id="proposition-de-font-stack">Proposition de font stack</h2> Désormais, je peux créer une font stack optimale (les familles génériques n’ont pas de guillemets): <pre tabindex="0"><code>html { font-family: &#34;Inter Variable&#34;, /* Inter variable, déclarée précédemment, si installée */ ui-sans-serif, /* utilise San Francisco (variable) disponible sur iOS */ &#34;Inter&#34;, /* Inter en version statique (non variable), si installée */ &#34;Roboto&#34;, /* Roboto, si installée */ system-ui, /* Segoe UI sur Windows, Roboto sur Android, à choix sur Linux */ sans-serif; /* la police sans empattement de secours */ } </code></pre>Avec une telle «pile d’écritures», je suis certain que vous aurez quelque chose de beau et de très lisible. Vous pouvez ajouter <code>&quot;Arial&quot;</code> avant <code>system-ui</code> si vous souhaitez éviter autant que possible Segoe UI dont l’apparence diffère nettement des autres. Sans surprise, je vous invite à <a href="https://rsms.me/inter/download/">installer Inter</a>. Soit en version variable, soit en version statique. La version statique est plus fiable et je vous conseiller d’installer les 18 fichiers. Et sans surprise non plus, au vu des problèmes d’implémentation, ces propositions resteront un simple exercice de style.</description></item><item><title>Lancer un blog en 2025(?)</title><link>https://nicolasfriedli.ch/blog/blog-2025/</link><pubDate>Mon, 03 Feb 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/blog-2025/</guid><description>Le web de 2025 est en pleine mutation. L’intelligence artificielle est sur toutes les lèvres, pour de bonnes et de mauvaises raisons. Les moteurs de recherche vont changer drastiquement. Les réseaux sociaux partent en vrille et sont devenus infréquentables. La réponse est claire: un site personnel est plus que jamais d’actualité. On me pose des questions sur le lancement d’un blog personnel aujourd’hui. Je propose une «réponse publique» qui pourra être utile à d’autres. <h2 id="merdification-generalisee">Merdification généralisée</h2> Nous vivons une période de <a href="https://ploum.net/2023-06-15-merdification.html">merdification des choses</a>. Les grands réseaux que nous pensions pérennes font n’importe quoi, à défaut de disparaître. Il n’est plus possible de miser sur leur durée de vie. La <a href="https://ici.radio-canada.ca/nouvelle/2047650/merdification-enshittification-cory-doctorow-decrypteurs">merdification du web</a>, en particulier, peut nous inciter à trouver d’autres pistes. Inventer un nouveau web correct passe probablement par le foisonnement de sites personnels. Peut-être des blogs. Peut-être des <a href="https://maggieappleton.com/garden-history">jardins numériques</a>. Ce qui est toujours le point de départ, c’est un nom de domaine personnel. <h2 id="importance-du-nom-de-domaine">Importance du nom de domaine</h2> Matthias Ott propose une magnifique lettre de nouvelles: <a href="https://newsletter.ownyourweb.site/">Own Your Web</a>. Votre superpouvoir, dit-il, c’est votre site personnel avec votre propre nom de domaine. Il a raison. Ce n’est pas très compliqué, même si vous n’avez pas encore un site sur le feu. Rendez-vous chez Infomaniak et réservez un nom de domaine à votre nom. Le plus simple est souvent le meilleur. Dans mon cas: nicolasfriedli.ch; pour ma femme: <a href="https://dianefriedli.ch/">dianefriedli.ch</a>. Avec votre nom de domaine, vous pouvez changer d’hébergeur ou de plateforme. Votre «chez vous» le restera tant que vous payez vos 10 francs par année. Il y a plein de <a href="https://nicolasfriedli.ch/blog/nom-domaine-personnel/">bonnes raisons de posséder un nom de domaine personnel</a>. <h2 id="wordpress-en-2025">Wordpress en 2025</h2> WordPress est en pleine crise. Ou plutôt Matt Mullenweg, son créateur, est en pleine crise. Il fait feu dans tous les sens et son entreprise <a href="https://www.lemondeinformatique.fr/actualites/lire-automattic-reduit-sa-contribution-a-la-version-open-source-de-wordpress-95730.html">Automattic réduit sa contribution à la version open source de WordPress</a>. Si WordPress ne représentait pas la moitié du web, ce ne serait pas très important. Mais là, c’est problématique. D’un côté, c’est la solution idéale pour lancer un blog personnel sans compétences pointues. De l’autre, rien n’est certain pour sa santé à moyen terme. S’il existe plein d’autres solutions, aucune n’a l’importance de WordPress. Une liste récente est disponible dans <a href="https://manuelmoreale.com/a-better-list-of-blog-platforms">Blog Platforms</a>. Elle propose beaucoup de petites solutions pas forcément plus sûres. Malgré le WordPress Drama du moment, WordPress est toujours un outil pertinent. <h2 id="conseil-pour-lancer-un-wordpress">Conseil pour lancer un WordPress</h2> Après l’achat d’un nom de domaine chez Infomaniak, je vois 2 solutions pour disposer d’un blog. <h3 id="plateforme-wordpresscom">Plateforme wordpress.com</h3> Pour 60 francs par année, je choisirais un <a href="https://wordpress.com/pricing/">hébergement chez wordpress.com</a>. Le plan Personal est amplement suffisant pour débuter. J’ai la faiblesse de penser que, dans ces délires, Matt Mullenweg ne sabordera pas wordpress.com immédiatement. C’est la solution la plus simple (pas de configuration compliquée, mises à jour automatique). Et les exportations pour passer à un WordPress hébergé sont toujours possibles. <h3 id="wordpress-heberge">WordPress hébergé</h3> L’autre solution, c’est d’installer soi-même son WordPress. Sans surprise, je conseille Infomaniak. Avec la messagerie, vous vous en tirerai pour 200 francs par année. Comme il est possible d’héberger 20 domaines, vous pouvez mutualiser les frais avec une connaissance. Donc, si un·e ami·e a déjà un blog chez Infomaniak, il peut valoir la peine de demander le gîte. Attention à ne pas installer n’importe quoi comme thèmes et comme extensions. Je conseille toujours de viser des thèmes officiels et d’éviter des constructeurs de pages qui sont des usines à gaz. Et n’installez que des extensions qui ont fait leurs preuves, sans créer de dépendances vitales pour votre contenu. Vous pouvez n’en utiliser aucune et votre site personnel fonctionnera très bien! Je n’aime pas l’installation automatique de WordPress qui est proposée. Mais je comprends sont intérêt pour sa simplicité. <h2 id="site-statique-ou-pas">Site statique (ou pas)</h2> Je ne me verrais pas lancer un blog autrement que par un <a href="https://nicolasfriedli.ch/blog/site-statique-generateur-hugo/">site statique</a>. Sans surprise, Hugo a ma préférence. Mais <a href="https://www.11ty.dev/">Eleventy</a> a des qualités à condition d’installer node.js et de parler couramment Javascript. Avec un nom de domaine (réservé chez Infomaniak), une adresse mail (dans l’offre gratuite d’Infomaniak) et un hébergement gratuit sur un CDN, il est possible de bloguer pour presque rien. Netlify, CloudFlaire ou GitHub Pages offrent (au sens propre) des prestations suffisantes pour un site personnel. <h2 id="kirby">Kirby(?)</h2> Si je lançais un blog aujourd’hui, je passerais peut-être à <a href="https://getkirby.com/">Kirby</a>. Ce CMS coûte 95 francs et il faut y ajouter un hébergement. C’est une solution très souple, qui permet de sites complètement personnalisés et rapides. J’ai confiance dans le modèle économique proposé. Il est probablement moins sujet à la merdification que les grandes plateformes. Je n’aurais aucun souci s’il fallait le migrer vers un autre outil. Toutefois, je ne peux le conseiller par manque d’expérience. <hr> En résumé: <ul> <li>nom de domaine chez Infomaniak</li> <li>1 mail gratuit chez Infomaniak</li> <li>solution Personal de wordpress.com</li> </ul> <hr> Après <a href="https://nicolasfriedli.ch/blog/spip/">quelques tests avec SPIP</a> en 2025, je ne l’exluerais pas d’office.</description></item><item><title>Des polices d’écriture à installer sans hésiter</title><link>https://nicolasfriedli.ch/blog/polices-installer/</link><pubDate>Sun, 02 Feb 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/polices-installer/</guid><description>Cette page est en «rédaction publique»: pas aboutie mais déjà disponible. Commentaires et suggestions bienvenu·e·s! Voici une sélection de polices d’écriture disponibles gratuitement. Si elles étaient plus souvent installées, il serait possible de limiter drastiquement les téléchargements pour des sites plus rapides et écologiques. Comme beaucoup de périphériques n’en disposent pas, on envoie des polices (web fonts) à chaque visite, au mépris de tout bon sens. Un choix aussi restreint que celui proposé ici serait suffisant pour peut-être 90% du web. Je me suis déjà exprimé sur le sujet des <a href="https://nicolasfriedli.ch/blog/polices-systeme/">polices système</a>. Je sais que je prêche dans le désert, mais vous conseille quand même de les installer pour en disposer en local. Toutes les polices ci-dessous sont disponibles en téléchargement (non pas seulement comme polices web) chez <a href="https://fonts.google.com/">Google Fonts</a>. Mais j’essaie de vous proposer des liens plus intéressant pour les découvrir. <h2 id="criteres-de-choix">Critères de choix</h2> Pour les polices sans et avec empattement, je souhaités au moins 4 versions pour disposer d’une police droite, de l’italique et du gras (700). Je ne me vois pas publier du texte sur le web sans ces variantes. Les polices listées dans <a href="https://modernfontstacks.com/">Modern Font Stack</a> sont signalées par 🧰 Les polices citées par <a href="https://www.typewolf.com/google-fonts">The 40 Best Free Fonts Available on Google Fonts</a> sont signalées par ⭐. <h2 id="sans-empattement-sans-serif">Sans empattement (<code>sans-serif</code>)</h2> <h3 id="archivo">Archivo</h3> Archivo est une police d’apparence simple et classique (à première vue). Elle propose un bel italique, avec notamment un f bien différent de la police droite La lettre g est très particulière en version droite. Disponible en version variable pour la graisse et la largeur. À tester chez Omnibus-Type: <a href="https://www.omnibus-type.com/variable-fonts/#archivo">https://www.omnibus-type.com/variable-fonts/#archivo</a> <h3 id="asap">Asap</h3> Asap la particularité de ne pas varier en largeur quelle que soit la graisse utilisée. Mais c’est bien une police proportionnelle; le i est plus étroit que le m, contrairement aux chasses fixes. Disponible en version variable pour la graisse et la largeur. C’est aussi une police d’Omnibus-Type: <a href="https://www.omnibus-type.com/variable-fonts/#asap">https://www.omnibus-type.com/variable-fonts/#asap</a> <h3 id="fira-sans">Fira Sans ⭐</h3> Fira Sans est une des plus belles polices de ces 15 dernières années. Elle n’est pas variable, mais disponible en 9 grasses différentes. Des versions condensée et très condensée sont disponibles. L’italique est magnifique. <a href="https://bboxtype.com/typefaces/FiraSans/">https://bboxtype.com/typefaces/FiraSans/</a> <h3 id="ibm-plex-sans">IBM Plex Sans ⭐</h3> IBM Plex Sans fait partie de la grande famille IBM Plex, avec le version à empattement (IBM Plex Serif) et celle à chasse fixe (IBM Plex Mono). C’est un excellent choix pour qui souhaite un souhaite un ensemble typographique complet et cohérent. Plusieurs assemblages sont possibles, par exemple le code en mono, les titres et les citations en serif et le corps du text en sans sérif. <a href="https://www.ibm.com/plex/">https://www.ibm.com/plex/</a> Autre famille complète intéressante: Source Sans 🧰, Source Serif &amp; Source Code 🧰 par Adobe. Mais la logique des noms (numéro de version dans le nom, présence de «pro») les rend pénibles à utiliser dans une pile de polices. <h3 id="inter">Inter 🧰 ⭐</h3> Inter est une des polices à la mode, mais c’est amplement mérité. Elle est variable et dispose de la taille optique. C’est la police (gratuite) qui remplace le mieux San Francisco d’Apple. La version 4 propose un italique très (trop?) différent du droit. Je vois de plus en plus de sites qui suggèrent Inter (et souvent Roboto) dans leur liste <code>font-style</code>, mais sans envoyer de fichiers sur vous ne l’avez pas. Donc c’est une priorité de l’installer pour éviter de tomber sur Arial. Pimp my Type propose une vidéo intéressante sur la version 4: <a href="https://pimpmytype.com/inter-v4/">https://pimpmytype.com/inter-v4/</a> La page du créateur Rasmus Andersson permet de visualiser toutes les possibilités (font features): <a href="https://rsms.me/inter/">https://rsms.me/inter/</a> <h3 id="montserrat">Montserrat 🧰 ⭐</h3> J’aime assez peu cette police pour le corps du texte, mais la trouve excellent pour la titraille. Ou pour des texte courts en assez grande taille. Mais je serais heureux de la savoir installée sur beaucoup d’ordinateurs pour pouvoir l’appeler sans exiger un téléchargement. Comme c’est une des fontes les plus utilisés chez Google Fonts, ce serait une excellente nouvelle. <a href="https://github.com/JulietaUla/Montserrat">https://github.com/JulietaUla/Montserrat</a> <h3 id="noto-sans">Noto Sans 🧰</h3> Noto n’est pas seulement une police, mais un grand projet de Google. L’idée est de produire un ensemble qui permettent d’écrire toutes les langues. Noto Sans est une excellente police, sans grande originalité mais belle et efficace. Elle peut être accompagnée de Noto Serif, de Noto Sans Mono et même de jeux d’emojis colorés ou noir/blanc. À conseiller vivement si vous consultez des sites en alphabet non latin. <a href="https://fonts.google.com/noto">https://fonts.google.com/noto</a> <h3 id="poppins">Poppins ⭐</h3> Poppins est une police géométrique bien équilibrée, particulièrement appréciée pour son apparence moderne et lisible. Elle taille un peu grand et large pour des longs textes. Elle est parfaite pour la titraille. <a href="https://www.fontshare.com/fonts/poppins">https://www.fontshare.com/fonts/poppins</a> <h3 id="public-sans">Public Sans</h3> Public Sans est une police inspirée de Libre Franklin et développée par le gouvernement américain pour des usages institutionnels. Elle est neutre, moderne et fonctionne bien pour des interfaces web et du texte courant. C’est à mon avis un police sous-estimée (ou méconnue). <a href="https://public-sans.digital.gov/">https://public-sans.digital.gov/</a> <h3 id="roboto">Roboto 🧰 ⭐</h3> Roboto est la police <a href="https://fonts.google.com/analytics">la plus utilisée de Gooogle Fonts</a> et la police par défaut d’Android. Autant dire qu’elle est partout. C’est un peu la nouvelle Arial. Je vois de plus en plus de sites qui suggèrent Roboto (et souvent Inter) dans leur liste <code>font-style</code>, mais sans envoyer de fichiers sur vous ne l’avez pas. Donc c’est une priorité de l’installer pour éviter de tomber sur Arial. Elle est disponible en version variable et en version statique (avec 9 graisses) chez Google Fonts: <a href="https://fonts.google.com/specimen/Roboto">https://fonts.google.com/specimen/Roboto</a> Je déconseille Roboto Flex qui est beaucoup trop complexe d’utilisation. <h3 id="ubuntu">Ubuntu 🧰</h3> La police Ubuntu a été conçue pour le système d’exploitation Ubuntu. Elle est contemporaine et très lisible à l’écran. Je ne l’aime pas beaucoup&hellip; mais elle est listée dans des fonts stacks de référence. <a href="https://design.ubuntu.com/font">https://design.ubuntu.com/font</a> <h2 id="avec-empattement-serif">Avec empattement (<code>serif</code>)</h2> <h3 id="alegreya">Alegreya ⭐</h3> Alegreya est des plus belles polices à empattement qui existe. Elle taille un peu petit, mais est très lisible avec une taille assez grande. L’italique est splendide et les ligatures fabuleuses. <a href="https://huertatipografica.com/en/fonts/alegreya-ht-pro">https://huertatipografica.com/en/fonts/alegreya-ht-pro</a> <h3 id="fraunces">Fraunces ⭐</h3> Fraunces est une police assez géniale. Elle se rapproche de Cooper Black, très à la mode pour la titraille. Mais elle est surtout étonnement efficace pour du texte. Une des premières polices à présenter un jeu de variations intéressant. <a href="https://fraunces.undercase.xyz/">https://fraunces.undercase.xyz/</a> <h3 id="gelasio">Gelasio</h3> Gelasio, créée par Eben Sorkin, remplace très bien Georgia dont elle reprend l’apparence générale et les métriques. Elle est surtout libre et gratuite, contrairement à l’excellente police de Matthew Carter. Elle a l’avantage de proposer plus de graisses différentes (et une version variable) ainsi que 2 jeux de nombres au lieu d’un seul. En version courte, toute séquence <code>Georgia, serif</code> d’une feuille de style devrait devenir <code>Gelasio, Georgia, serif</code>. <a href="https://pimpmytype.com/font/gelasio/">https://pimpmytype.com/font/gelasio/</a> <h3 id="literata">Literata</h3> Magnifique, point! Pas besoin d’en parler, il suffit de regarder <a href="https://clagnut.com/blog/2422/">ce qu’en fait Richard Clagnut</a> pour l’adopter. Lisibilité exceptionnelle, avec des tailles optiques. Une des polices techniquement les plus complètes du moment. Pour compléter le passage sur Gelasio, j’aurais tendance à conseiller <code>Literata, Gelasio, Georgia, serif</code> pour un site sans empattement. <a href="https://www.type-together.com/literata-font">https://www.type-together.com/literata-font</a> <h3 id="lora">Lora ⭐</h3> Lora est une police avec empattement particulièrement élégante. L’italique a une apparence calligraphique. Je la trouve parfois trop fine (ou trop petite) sur les sites web. <a href="https://www.cyreal.org/fonts/lora/">https://www.cyreal.org/fonts/lora/</a> <h3 id="merriweather">Merriweather ⭐</h3> Merriweather est une des polices à empattement les plus lisibles. Elle est disponible en version variable: graisse, largeur et taille optique. En version statique, elle taille grand et demande un interligne assez important (1.6 me semble le minimum). La version variable n’est pas disponible sur Google Fonts. Elle se trouve chez le fondeur: <a href="https://github.com/SorkinType/Merriweather">https://github.com/SorkinType/Merriweather</a> <h3 id="noto-serif">Noto Serif</h3> Noto Serif est l’équivalent avec empattement de Noto Sans. Elle fait partie de l’énorme projet Noto qui vise à couvrir toutes les langues et tous les caractères du monde. Je la trouve que c’est une des meilleures polices à empattement, moins banale que la variante sans. <a href="https://fonts.google.com/noto/specimen/Noto+Serif">https://fonts.google.com/noto/specimen/Noto+Serif</a> <h3 id="piazzolla">Piazzolla</h3> Piazzolla est une police étonnante. Elle semble cabossée de partout et reste pourtant très lisible pour du texte long. C’est en partie parce qu’elle dispose de taille optique. Je rêverais de la savoir installée souvent et de pouvoir jouer avec. <a href="https://piazzolla.huertatipografica.com/">https://piazzolla.huertatipografica.com/</a> <h2 id="pour-les-titres-et-intertitres">Pour les titres et intertitres</h2> Si ces quelques polices étaient installés sur beaucoup de périphériques, il serait facile de proposer des assemblages intéressants et conforme au contenu du site. La sélection est brève, mais j’ai l’impression que ce serait suffiant pour beaucoup de cas: <ul> <li>Barlow Condensed</li> <li>Bebas Neue</li> <li>Bricolage Grotesque</li> <li>Fraunces</li> <li>Roboto Slab 🧰</li> <li>Syne ⭐</li> </ul> Sans oublier que Merriweather ou Poppins vont très bien pour la titraille. <h2 id="polices-a-chasse-fixe-monospace">Polices à chasse fixe (<code>monospace</code>)</h2> Ces polices sont normalement prévues pour du code. Certaines ont des fonctions particulières (ligatures). <h3 id="courier-prime">Courier Prime</h3> Courier Prime est prévue explicitement pour le texte, notamment l’écriture de scénarios. Elle est très lisible à l’écran et l’italique est de belle qualité. <a href="https://quoteunquoteapps.com/courierprime/">https://quoteunquoteapps.com/courierprime/</a> <h3 id="jetbrains-mono">JetBrains Mono</h3> JetBrains Mono est la police que j’utilise dans mon éditeur de texte. Elle est parfaitement optimisée pour la lecture du code. Je ne vois pas de raison de chercher plus loin. Comme elle dispose d’un bel italique et de plusieurs graisses, elle peut être utilisée sans problème pour un site web (y compris le texte). La page de présentation officielle est excellente: <a href="https://www.jetbrains.com/fr-fr/lp/mono/">https://www.jetbrains.com/fr-fr/lp/mono/</a> <h3 id="autres-polices-a-chasse-fixe">Autres polices à chasse fixe</h3> <ul> <li>Fira Code ou Fira Mono</li> <li>Hack</li> <li>IBM Plex Mono</li> <li>Roboto Mono</li> <li>Source Code Pro 🧰</li> <li>Ubuntu Mono</li> <li>Victor Mono</li> </ul> Il y peu de raisons de les installer si vous ne lisez pas régulièrement du code. Pour visualiser des polices dédiées à la programmation dans leur milieu naturel: <a href="https://www.programmingfonts.org/">https://www.programmingfonts.org/</a></description></item><item><title>À propos</title><link>https://nicolasfriedli.ch/about/</link><pubDate>Sat, 01 Feb 2025 16:27:52 +0100</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/about/</guid><description>Ce site est simple et efficace. Il fait la part belle au texte. Je ne suis pas opposé à l’utilisation d’images, à conditions qu’elles apportent des informations utiles. Pour le moment, il n’y en a pas. nicolasfriedli.ch est créé avec l’excellent <a href="https://gohugo.io/">Hugo</a>, un générateur de sites statique rapide. Le site actuellement en ligne a été compilé avec la version 0.145.0. Ses sources sont disponibles dans un <a href="https://github.com/nfriedli/nicolasfriedli.ch/">dépôt GitHub public</a>. Elles permettent de voir le contenu des pages avant compilation (Markdown), la configuration d’Hugo et de suivre l’ensemble des évolutions. Son contenu est sous licence libre Creative Commons BY-SA. Vous pouvez utiliser des extraits de code sans me citer, à condition de ne pas faire de votre site une copie du mien. Il est hébergé en Suisse, chez <a href="https://www.infomaniak.com/">Infomaniak</a>, une entreprise écoresponsable. Même si je trouve les services comme Netlify ou CloudFlare performants et agréables, j’ai fait le choix de mon pays et de l’écologie. Un <a href="https://nicolasfriedli.ch/index.xml">flux RSS</a>, avec l’ensemble du contenu des pages, permet de s’abonner au site. Les flux RSS (ou ATOM) sont des outils qui changent la vie. Je n’envoie pas de lettre de nouvelles; je ne souhaite pas savoir qui me suit. La vie privée compte à mes yeux, c’est pourquoi je ne vous traque pas. nicolasfriedli.ch utilise des statistiques propres (<a href="https://plausible.io/privacy">Plausible Analytics Privacy Policy</a>) comme seule ressource externe. Je teste régulièrement mon site pour m’assurer de toujours obtenir d’excellents résultats: <ul> <li>scores verts dans <a href="https://pagespeed.web.dev/">PageSpeed Insights</a></li> <li>A+ dans <a href="https://www.websitecarbon.com/">Website Carbon Calculator</a></li> <li>aucune erreur d’accessibilité chez <a href="https://wave.webaim.org/">WAVE Web Accessibility Evaluation Tools</a></li> <li>HTML valide selon le <a href="https://validator.w3.org/">Markup Validation Service du W3C</a></li> <li>CSS valide selon le <a href="https://jigsaw.w3.org/css-validator/">CSS Validation Service du W3C</a> (sauf propriété nouvelles&hellip;)</li> <li>RSS valide selon le <a href="https://validator.w3.org/feed/">Feed Validation Service du W3C</a></li> </ul> J’essaie de respecter toutes les <a href="https://checklists.opquast.com/fr/assurance-qualite-web/">règles Opquast</a> applicables. Lorsque j’interviens sur des sites en tant que consultant, je recherche les mêmes standards de qualité.</description></item><item><title>Programme ou stratégie?</title><link>https://nicolasfriedli.ch/blog/programme-strategie/</link><pubDate>Fri, 17 Jan 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/programme-strategie/</guid><description>Plutôt qu’un planning ou programme rigide souvent inefficace face aux imprévus, je propose de privilégier une stratégie web flexible et contextuelle, capable d’évoluer avec les réalités du moment et les attentes des utilisateurs. Elle est plus difficile à expliquer et à faire accepter, mais elle fait ses preuves dans la durée. Il y a presque 10 ans, j’ai publié un premier billet général sur la stratégie web. Je l’avais complété par un second, plus concret. Les deux, à peine actualisés, sont réunis sur cette page. <h2 id="survivre-en-entreprise-ou-en-institution">Survivre en entreprise ou en institution</h2> Il faut un planning! Un programme de publication qui permet de prévoir tout ce qui va se passer sur votre site et vos réseaux sociaux durant la prochaine année. Grâce à lui, vous ne serez plus jamais en retard dans la rédaction de vos contenus, vous ne serez plus inquiet ce qui arrivera la semaine prochaine, votre supérieur saura exactement où vous allez et vos ventes vont augmenter. Franchement, vous y croyez une seule seconde? Vous savez très bien que vous serez à la bourre pour rédiger vos contenus. Vous savez que vous découvrirez les échéances de la semaine le lundi matin. Vous savez que votre supérieur vous placera dans des situations de double contrainte. Quant à vos ventes, qui sait? Et surtout, nous savons tous que ces fameux plannings ne servent qu’à rassurer un supérieur, un comité directeur, un conseil ou une assemblée. Même si le programme n’a pas été lu, la simple vue d’une grille et de quelques schémas produit son effet rassérénant et apaise les tensions. Mais tout cela ne sert à rien pour votre travail au quotidien. Il vaut mieux penser stratégie, avec les mots d’Edgar Morin, dans Introduction à la pensée complexe: <blockquote> La notion de stratégie s’oppose à celle de programme. Un programme, c’est une séquence d’actions prédéterminées qui doit fonctionner dans des circonstances qui en permettent l’accomplissement. Si les circonstances extérieures ne sont pas favorables, le programme s’arrête ou échoue. […] la stratégie, elle, élabore un ou plusieurs scénarios. Dès le début, elle se prépare, s’il y a du nouveau et de l’inattendu, à l’intégrer pour modifier ou enrichir son action.</blockquote> Des circonstances extérieures, il y en a toujours et partout. En voici quelques exemples: <ul> <li>si vous êtes libraire: la qualité de la rentrée littéraire de l’année, l’implantation ou la faillite d’un concurrent, la politique de prix ou de renvois d’Amazon</li> <li>si vous êtes garagiste: les nouveaux modèles de la marque que vous représentez, ceux des marques concurrentes, le prix de l’essence et les scandales façon Volkswagen</li> <li>si vous gérez une piscine: la météo</li> <li>si vous êtes webmaster, quel que soit votre domaine professionnel: l’arrivée de nouvelles technologies (p.ex. les smartphones), de nouvelles plateformes (p.ex. les réseaux sociaux), de nouveaux outils (p.ex. les applications)</li> </ul> Vous pouvez continuer à planifier pour faire plaisir à votre supérieur et gagner quelques jours de calme. Ou élaborer une véritable stratégie. La première étape pour passer au niveau stratégique, c’est de comprendre (et de faire comprendre) que, sur le web, la nouveauté et l’inattendu, c’est tous les jours. Il faut prendre le temps nécessaire et suffisant pour l’expliquer à ses responsables. S’ils comprennent, vous n’aurez plus jamais à proposer de planning. Et s’ils ne comprennent pas, cherchez du travail ailleurs. <hr> <h2 id="esquisses-de-strategie-web">Esquisses de stratégie web</h2> Après la publication de la première partie, j’avais reçu un message. Le contenu en résumé: <blockquote> Tu as raison de dire que les programmes ne marchent pas (ou pour une durée limitée seulement). Ils servent surtout à faire plaisir à un supérieur plutôt qu’à améliorer les résultats du travail. Mais tu ne dis rien sur la stratégie, sinon que plus rien ne peut être programmé.</blockquote> Vous avez compris le paradoxe de l’histoire: une stratégie universelle et figée serait en quelque sorte un programme. La stratégie est donc toujours contextuelle: votre entreprise (ses moyens humains, techniques et financiers; ses objectifs), vous (vos compétences, votre cahier des charges) et l’extérieur (les concurrents, l’actualité). Ce serait un peu simple de s’en tirer ainsi. Voici donc quelques éléments concrets de stratégie web. <h3 id="externaliser-ou-internaliser">Externaliser ou internaliser?</h3> Avez-vous déjà remarqué que la très grande majorité des entreprises, même les plus petites, se chargent de leur comptabilité en interne. Alors que beaucoup d’entreprises, pas forcément petites, font appel à des agences de communication externes pour la réalisation de leur site web, de leurs éléments graphiques, voire pour la rédaction de leurs contenus. C’est facilement explicable. Depuis toujours, on tient ses comptes. La communication, au sens large du terme, est une histoire bien plus récente. Mais est-ce une bonne idée? Au fond, la capacité de faire évoluer son site web, de produire ses documents et de rédiger ses textes en interne n’est-elle pas plus stratégique que des additions? Internaliser de telles compétences est un choix stratégique, bien plus ambitieux que de programmer un budget de communication. Ou alors, externaliser de telles compétences est un choix stratégique, à condition de ne pas agir simplement au cas par cas, mais dans une logique construite et continue. <h3 id="planification-financiere">Planification financière</h3> Avez-vous déjà remarqué que, bien souvent, les dépenses dans le domaine du web sont prévues de la même manière que l’on envisage l’industrie lourde ou l’immobilier? La première année, on investit 50000. Puis on prévoit 5000 pour les années suivantes. Soit 70000 sur 5 ans. Nombreux sont celles et ceux qui n’ont pas vu venir le responsive design, les réseaux sociaux, les intelligences artificielles, etc. Et qui traînent durant des années des sites complètement dépassés. Ce n’est pas un jugement, juste une observation. Le plan a échoué rapidement, mais il n’y avait plus d’argent au programme pour des évolutions nécessaires. Un choix stratégique, c’est d’être beaucoup plus évolutif dans la durée. On pourrait imaginer 20000 la 1re année, puis 5000 la 2e année, puis 15000 les années suivantes. Ainsi, on a un site raisonnablement à jour durant 5 ans, pour la même somme globale de 70000. On peut parfaitement maintenir un site longtemps, comme l’expliquent très bien les Yellow Dolphins: <a href="https://yellowdolphins.com/2024/02/site-web-garanti-10-ans/">Garanti 10 ans! Comment un site web résiste au temps?</a> <h3 id="evolutions-dun-projet">Évolutions d’un projet</h3> En analogie avec ce qui dit d’un point de vue financier ci-dessus, avez-vous déjà remarqué que bien des sites vous impressionnent beaucoup à leur sortie, mais semblent insuffisants quelques mois plus tard? C’est, hélas, logique. Peut-on vraiment imaginer que tout était correct dès la rédaction d’un cahier des charges? Que l’on avait pensé à tout? Un choix plus stratégique consiste à travailler en différentes étapes, avec une contrainte forte. À la fin de chacune des étapes, le projet doit pouvoir être déployé en production, être parfaitement fonctionnel (quelque chose comme Scrum par exemple). Au début, le projet sera moins impressionnant. Dans la durée, il répondra vraiment à la réalité du moment et aux attentes des utilisateurs. <h3 id="considerations-techniques">Considérations techniques</h3> Avez-vous déjà remarqué que des nouveautés sortent presque tous les jours sur le web? Certaines semblent inévitables, d’autres plus futiles. Il y a quelques années, il fallait absolument son application. On constate aujourd’hui qu’il y a bien peu de raisons d’en développer une. Aujourd’hui, nous sommes en plein dans les questions d’intelligence artificielle. Qui l’aurait imaginé il y a quelques années? Une vision stratégique consiste à se fixer de grandes lignes: nous acceptons d’utiliser des technologies tierces si elles apportent un plus fort taux de lecture et nous gardons un site web comme base arrière solide et pérenne. Une vision programmatique demanderait plutôt la mise à jour de l’application qui avait coûté si cher et que l’on ne peut pas abandonner (mais que personne n’installe). Nous avons enterré tant de choses. Le cimetière du web est saturé de «nouveautés nécessaires pour lesquelles il fallait investir». Une visite entre les tombes de <a href="https://killedbygoogle.com/">Killed by Google</a> est édifiante. <h3 id="dependance-et-independance">Dépendance et indépendance</h3> Vos publications ont un certain succès, mais reposent entièrement sur un réseau social ou un média que vous ne contrôlez pas. Vous acceptez de dépendre à 100% de ces plateformes. Mais vous ne vous rendez plus compte que tout peut tomber d’un jour à l’autre. Ou que des services comme <del>Twitter</del> X ou Facebook peuvent partir complètement en vrille. Une vision stratégique demande de bien choisir un CMS ou un framework, de ne pas faire dépendre des fonctionnalités essentielles sur des outils non essentiels (le CRM qui repose sur le CMS&hellip;). Quand on voit l’<a href="https://siecledigital.fr/2025/01/07/suspension-des-services-de-wordpress-org-un-coup-dur-pour-la-communaute-open-source/">actualité dramatique de WordPress</a>, on se dit que le pire est toujours possible. Et de choisir des technologies ouvertes et pérennes. Dans votre programme, vous aviez prévu une application complexe, sans vous rendre compte que beaucoup de choses passent aujourd’hui par JSON et, pourquoi pas, des flux RSS. Je n’ai pas de programme, mais je suis toujours là. Peut-être que ma stratégie est bonne&hellip;</description></item><item><title>Google Analytics ou Search Console</title><link>https://nicolasfriedli.ch/blog/google-analytics-search-console/</link><pubDate>Wed, 15 Jan 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/google-analytics-search-console/</guid><description>Lorsqu’un site fonctionne bien, il est beaucoup plus intéressant de travailler un temps avec la Search Console de Google qu’avec des statistiques de fréquentation (Analytics chez Google). Évidemment, le recours à la Search Console n’exclut pas l’utilisation d’Analytics. Aujourd’hui, je n’utilise plus que <a href="https://plausible.io/">Plausible Analytics</a>, qui respectent la vie privée et la bande passante. Mais le raisonnement est le même que lors de la première publication de ce billet. <h2 id="les-statistiques-pour-un-site-qui-demarre">Les statistiques pour un site qui démarre</h2> Lors de la mise en ligne d’un site, le mandataire demande normalement l’installation d’un système de statistiques. Souvent (hélas), c’est l’outil de Google qui est choisi, par simplicité et par possibilité de comparaison. Dès lors, Analytics mesure l’activité sur le site. Dans la pratique très concrète, les petits sites institutionnels ou les vitrines d’entreprise font peu usage des données récoltées. Combien de fois ai-je installé Analytics sans que personne ne demande accès aux résultats? Je me rends tout de même régulièrement sur Analytics pour vérifier que tout se déroule comme prévu. Quelles pages reçoivent le plus de visites? D’où viennent-elles? Quels périphériques sont utilisés? Les statistiques permettent un contrôle efficace. Une nouvelle publication a bien attiré son monde, le partage sur les réseaux sociaux a produit des résultats, un lien dans une lettre de nouvelles a suscité la confiance des internautes. Tout cela reste bien léger au vu des possibilités d’un système de statistiques aussi complet que celui de Google. Une fois l’an, on me demande si le site fonctionne bien. Je donne un chiffre global&hellip; et tout continue comme avant. Lorsque la fréquentation du site et les effets produits sont vitaux pour l’institution ou l’entreprise, le recours aux données est très important. Mais dans les cas classiques de sites vitrines, c’est malheureusement un gadget de plus. <h2 id="la-console-de-recherche-pour-un-site-qui-fonctionne">La console de recherche pour un site qui fonctionne</h2> Dès qu’un site fonctionne bien, je préconise de passer par la <a href="https://search.google.com/search-console/about">Search Console</a>. Un site qui fonctionne bien, dans l’acception que j’en fais ici, c’est un site qui attire une part importante des internautes par les moteurs de recherche. La logique change alors du tout au tout. Je ne m’intéresse plus au site, au nombre d’internautes sur chaque page ou aux fluctuations quotidiennes. Je m’intéresse à ce qui se passe sur les moteurs de recherche. Quelles sont les requêtes pour lesquelles le site s’affiche? Quelles recherches précises produisent des clics? Pour que cela soit intéressant, il faut un nombre d’affichages important. Et alors le taux de clic devient une valeur significative. Un exemple: le site apparaît souvent dans les résultats pour une recherche donnée mais le taux de clic est très faible? Peut-être que le titre de la page (ou sa description affichée) est mauvais, peu signifiant, voire repoussant. Ou alors le site sort tellement bas dans la SERP (Search Engine Result Page ou page des résultats de recherche) que personne ne descend jusque-là. Voilà des données intéressantes. Impossible d’imaginer à chaque fois qui cherchera quoi? Quelle page sortira pour quelle requête? Et dans quelle position? Lors que l’on travaille dans le domaine des institutions et des PME (petites et moyennes entreprises), la consultation de la Search Console permet bien des découvertes. Et voilà que je découvre que la requête dont beaucoup s’amusaient est celle qui apporte le plus de visites bien réelles! Reste à analyser si cette recherche et ces visites sont pertinentes. Resteront-elles un phénomène marginal, qui s’estompera rapidement? Ou alors je découvre que recherches insoupçonnées par leur formulation ou leur fréquence. Et voilà que naissent des idées pour des prochains articles, pour des pages à améliorer, pour des pistes à explorer. <h2 id="statistiques--search-console-dans-la-duree">Statistiques &amp; Search Console dans la durée</h2> En principe, la découverte de recherches qui mènent fréquemment au site et un travail sérieux d’amélioration donnent des résultats dans les statistiques. Commencent alors les allers-retours entre ces deux outils complémentaires. Dans mon outil des statistiques, je pourrai surveiller si ces pages bien abouties fonctionnent. Si le parcours des internautes (flux) est conforme à ce qui a été prévu et construit patiemment. Dans Search Console, je pourrai vérifier si d’autres recherches proches de celles découvertes précédemment débarquent. Si les résultats montent dans les SERPs. Et si le taux de clic s’améliore de manière significative. Je connais bien un difficulté récurrente pour les institutions et les petites entreprises. Elles ne veulent pas se faire dicter ce qu’elles «doivent» dire par des données. Elles proposent des offres qu’elles estiment bonnes (c’est peut-être le cas) et ce n’est pas Google qui va leur expliquer comment les promouvoir. Elles ont des produits qu’elles trouvent excellents (c’est peut-être le cas) et elles savent mieux en parler qu’un vulgaire moteur de recherche. Au final, il y beaucoup d’énergie perdue à faire et refaire des sites en mettant son énergie et son argent sur du graphisme et des images. Au détriment, souvent, du contenu pur: le texte, la structure, la navigation, le maillage interne. J’en souris en attendant que cela change. Parce qu’une utilisation conséquente des données combinées des statistiques et de Search Console produit des résultats. Ils sont presque assurés si l’on travaille avec rigueur. Et surtout ils sont pérennes, contrairement aux <a href="https://blog.jim-nielsen.com/2024/blog-vs-social-posts/">pics de visites obtenus via les réseaux sociaux</a>.</description></item><item><title>Colorisation syntaxique avec Chroma dans Hugo</title><link>https://nicolasfriedli.ch/blog/hugo-chroma-colorisation-syntaxique/</link><pubDate>Sat, 11 Jan 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/hugo-chroma-colorisation-syntaxique/</guid><description>Je souhaite utiliser la colorisation syntaxique sur ce site. Elle existe par défaut dans Hugo, avec l’excellent Chroma. Mais je ne vais pas le faire sans certaines précautions: la pérennité (si je modifie mon thème), l’assurance de l’accessibilité (A11Y), l’existence de versions claire et sombre et l’optimisation des performances (webperf). Remarque: pour le moment, rien n’est activé sur ce site qui présente le code en blanc sur noir (ou noir sur blanc). Une lecture préalable de <a href="https://gohugo.io/content-management/syntax-highlighting/">Syntax highlighting</a> dans la documentation de Hugo est souhaitable. <h2 id="contraste-des-couleurs">Contraste des couleurs</h2> J’ai passé <a href="https://xyproto.github.io/splash/docs/longer/all.html">tous les thèmes disponibles dans Chroma</a> dans les <a href="https://wave.webaim.org/report#/https://xyproto.github.io/splash/docs/longer/all.html">WAVE Web Accessibility Evaluation Tools</a>. Ceux qui disposent d’un contraste suffisant pour être accessibles sont: <ul> <li>average</li> <li>borland</li> <li>bw</li> <li>doom-one</li> <li>doom-one2</li> <li>github-dark</li> <li>github</li> <li>modus-operandi</li> <li>modus-vivendi</li> <li>pygments</li> <li>rrt</li> <li>witchhazel</li> <li>xcode</li> </ul> J’exclus tous ceux qui ne sont pas accessibles (A11Y) par défaut. <h2 id="couleur-de-fond-definie">Couleur de fond définie</h2> Quand la couleur de fond de <code>pre</code> n’est pas définie, il y a un risque si je modifie ma charte de couleurs. Par défaut, ces thèmes ne sont pas assez pérennes pour que je les retienne: <ul> <li>hr_high_contrast</li> <li>hrdark</li> <li>onesenterprise</li> <li>pygments</li> </ul> Par rapport à la liste des thèmes accessibles, seul pygments est concerné. Je l’élimine. Il me reste donc comme thèmes accessibles et pérennes: <ul> <li>average</li> <li>borland</li> <li>bw</li> <li>doom-one</li> <li>doom-one2</li> <li>github-dark</li> <li>github</li> <li>modus-operandi</li> <li>modus-vivendi</li> <li>rrt</li> <li>witchhazel</li> <li>xcode</li> </ul> <h2 id="polices-a-chasse-fixe">Polices à chasse fixe</h2> Ce point ne concerne pas Chroma, mais mon utilisation d’Hugo et mes choix de polices. J’ai décidé de placer en priorité Roboto Mono comme police à chasse fixe (monospace). Mais si cette police est bien à largeur fixe, elle diffère légèrement entre version droite et version italique. C’est à mon avis une erreur! En conséquence, je refuse tous les thèmes qui comprennent des italiques, par exemple abap ou algol. Il me reste, de la liste précédente: <ul> <li>github</li> <li>modus-operandi</li> <li>modus-vivendi</li> <li>witchhazel</li> <li>xcode</li> </ul> <h2 id="mode-clair-light-et-mode-fonce-dark">Mode clair (light) et mode foncé (dark)</h2> Désormais, je dois me demander si je souhaite une même version pour les thèmes light et dark de mon site. Si je souhaite 1 même style (CSS) pour les 2 versions du site, je peux utiliser la syntaxe par CSS embarqué ou par feuilles de style externes. Autrement dit, les 2 options suivantes sont possibles dans <code>hugo.toml</code>: <pre tabindex="0"><code>noClasses = false &lt;- il faut générer 1 feuille de style externe noClasses = true &lt;- option par défaut </code></pre>Pour générer mon CSS externe, il faut lancer une commande du type: <pre tabindex="0"><code>hugo gen chromastyles --style github &gt; static/css/github.css </code></pre>Cette feuille de style est fonctionnelle, mais ne sera pas optimisée par la suite. J’en profite pour faire mieux ci-dessous. Si je souhaite des thèmes différents (light et dark), je dois générer 2 feuilles de style externes différentes: <pre tabindex="0"><code>noClasses = false &lt;- il faut générer 2 feuilles de style externes </code></pre>Puis, je génère les CSS dans <code>assets</code>: <pre tabindex="0"><code>hugo gen chromastyles --style modus-operandi &gt; assets/css/modus-operandi.css hugo gen chromastyles --style modus-vivendi &gt; assets/css/modus-vivendi.css </code></pre>Ensuite, un appel distinct selon que le thème est clair ou foncé: <pre tabindex="0"><code>{{ $modusoperandi := resources.Get &#34;css/modus-operandi.css&#34; | minify | fingerprint }} {{ $modisvivendi := resources.Get &#34;css/modus-vivendi.css&#34; | minify | fingerprint }} &lt;link rel=&#34;stylesheet&#34; href=&#34;{{ $modusoperandi.RelPermalink }}&#34; media=&#34;screen and (prefers-color-scheme: dark)&#34; &gt; &lt;link rel=&#34;stylesheet&#34; href=&#34;{{ $modisvivendi.RelPermalink }}&#34; media=&#34;screen and (prefers-color-scheme: light)&#34; &gt; </code></pre>Voir aussi: mon billet <a href="https://nicolasfriedli.ch/blog/css-minification-cache/">Feuilles de style minifiées et gestion du cache</a> pour comprendre les lignes ci-dessus. <h2 id="uniformite-des-couleurs">Uniformité des couleurs</h2> Quand j’utilise du code sans préciser un langage pour la colorisation syntaxique, je souhaite avoir exactement les mêmes couleurs qu’avec la colorisation activée. Donc, dans mon exemple, il faudrait aller chercher les codes couleur exacts des CSS générés et les appliquer à <code>pre</code>. Pour du code différent entre dark et light lorsque la colorisation n’est pas activée, quelque chose comme: <pre tabindex="0"><code>pre { background: #000; color: #FFF; @media (prefers-colors-scheme: dark ) { background: #FFF; color: #000; } } </code></pre><h2 id="validite-et-optimisation-du-css">Validité et optimisation du CSS</h2> La feuille de style générée avec <code>hugo gen chromastyle</code> est complète et commentée. Et c’est très bien ainsi pour faciliter sa modification (sujet que je ne traite pas ici). Le fichier <code>modus-operandi.css</code>: <pre tabindex="0"><code>/* Background */ .bg { color:#000;background-color:#fff; } /* PreWrapper */ .chroma { color:#000;background-color:#fff; } /* Other */ .chroma .x { } /* Error */ .chroma .err { } /* CodeLine */ .chroma .cl { } /* LineLink */ .chroma .lnlinks { outline:none;text-decoration:none;color:inherit } /* LineTableTD */ .chroma .lntd { vertical-align:top;padding:0;margin:0;border:0; } /* LineTable */ .chroma .lntable { border-spacing:0;padding:0;margin:0;border:0; } /* LineHighlight */ .chroma .hl { background-color:#e5e5e5 } /* LineNumbersTable */ .chroma .lnt { white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f } /* LineNumbers */ .chroma .ln { white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f } /* Line */ .chroma .line { display:flex; } /* Keyword */ .chroma .k { color:#5317ac } /* KeywordConstant */ .chroma .kc { color:#0000c0 } /* KeywordDeclaration */ .chroma .kd { color:#5317ac } /* KeywordNamespace */ .chroma .kn { color:#5317ac } /* KeywordPseudo */ .chroma .kp { color:#5317ac } /* KeywordReserved */ .chroma .kr { color:#5317ac } /* KeywordType */ .chroma .kt { color:#005a5f } /* Name */ .chroma .n { } /* NameAttribute */ .chroma .na { } /* NameBuiltin */ .chroma .nb { color:#8f0075 } /* NameBuiltinPseudo */ .chroma .bp { } /* NameClass */ .chroma .nc { } /* NameConstant */ .chroma .no { } /* NameDecorator */ .chroma .nd { } /* NameEntity */ .chroma .ni { } /* NameException */ .chroma .ne { } /* NameFunction */ .chroma .nf { color:#721045 } /* NameFunctionMagic */ .chroma .fm { } /* NameLabel */ .chroma .nl { } /* NameNamespace */ .chroma .nn { } /* NameOther */ .chroma .nx { } /* NameProperty */ .chroma .py { } /* NameTag */ .chroma .nt { } /* NameVariable */ .chroma .nv { color:#00538b } /* NameVariableClass */ .chroma .vc { } /* NameVariableGlobal */ .chroma .vg { } /* NameVariableInstance */ .chroma .vi { } /* NameVariableMagic */ .chroma .vm { } /* Literal */ .chroma .l { color:#0000c0 } /* LiteralDate */ .chroma .ld { color:#0000c0 } /* LiteralString */ .chroma .s { color:#2544bb } /* LiteralStringAffix */ .chroma .sa { color:#2544bb } /* LiteralStringBacktick */ .chroma .sb { color:#2544bb } /* LiteralStringChar */ .chroma .sc { color:#2544bb } /* LiteralStringDelimiter */ .chroma .dl { color:#2544bb } /* LiteralStringDoc */ .chroma .sd { color:#2544bb } /* LiteralStringDouble */ .chroma .s2 { color:#2544bb } /* LiteralStringEscape */ .chroma .se { color:#2544bb } /* LiteralStringHeredoc */ .chroma .sh { color:#2544bb } /* LiteralStringInterpol */ .chroma .si { color:#2544bb } /* LiteralStringOther */ .chroma .sx { color:#2544bb } /* LiteralStringRegex */ .chroma .sr { color:#2544bb } /* LiteralStringSingle */ .chroma .s1 { color:#2544bb } /* LiteralStringSymbol */ .chroma .ss { color:#2544bb } /* LiteralNumber */ .chroma .m { color:#0000c0 } /* LiteralNumberBin */ .chroma .mb { color:#0000c0 } /* LiteralNumberFloat */ .chroma .mf { color:#0000c0 } /* LiteralNumberHex */ .chroma .mh { color:#0000c0 } /* LiteralNumberInteger */ .chroma .mi { color:#0000c0 } /* LiteralNumberIntegerLong */ .chroma .il { color:#0000c0 } /* LiteralNumberOct */ .chroma .mo { color:#0000c0 } /* Operator */ .chroma .o { color:#00538b } /* OperatorWord */ .chroma .ow { color:#00538b } /* Punctuation */ .chroma .p { } /* Comment */ .chroma .c { color:#505050 } /* CommentHashbang */ .chroma .ch { color:#505050 } /* CommentMultiline */ .chroma .cm { color:#505050 } /* CommentSingle */ .chroma .c1 { color:#505050 } /* CommentSpecial */ .chroma .cs { color:#505050 } /* CommentPreproc */ .chroma .cp { color:#505050 } /* CommentPreprocFile */ .chroma .cpf { color:#505050 } /* Generic */ .chroma .g { } /* GenericDeleted */ .chroma .gd { } /* GenericEmph */ .chroma .ge { } /* GenericError */ .chroma .gr { } /* GenericHeading */ .chroma .gh { } /* GenericInserted */ .chroma .gi { } /* GenericOutput */ .chroma .go { } /* GenericPrompt */ .chroma .gp { } /* GenericStrong */ .chroma .gs { } /* GenericSubheading */ .chroma .gu { } /* GenericTraceback */ .chroma .gt { } /* GenericUnderline */ .chroma .gl { } /* TextWhitespace */ .chroma .w { } </code></pre>Avec le filtre <code>minify</code>, les commentaires sont supprimés, mais pas les instructions vides. On pourrait supprimer toutes les lignes avec des <code>{ }</code> avant le passage par la minification. Je regrette que <code>minify</code> ne supprime pas ces instructions vides! Nous aurions donc: <pre tabindex="0"><code>/* Background */ .bg { color:#000;background-color:#fff; } /* PreWrapper */ .chroma { color:#000;background-color:#fff; } /* LineLink */ .chroma .lnlinks { outline:none;text-decoration:none;color:inherit } /* LineTableTD */ .chroma .lntd { vertical-align:top;padding:0;margin:0;border:0; } /* LineTable */ .chroma .lntable { border-spacing:0;padding:0;margin:0;border:0; } /* LineHighlight */ .chroma .hl { background-color:#e5e5e5 } /* LineNumbersTable */ .chroma .lnt { white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f } /* LineNumbers */ .chroma .ln { white-space:pre;-webkit-user-select:none;user-select:none;margin-right:0.4em;padding:0 0.4em 0 0.4em;color:#7f7f7f } /* Line */ .chroma .line { display:flex; } /* Keyword */ .chroma .k { color:#5317ac } /* KeywordConstant */ .chroma .kc { color:#0000c0 } /* KeywordDeclaration */ .chroma .kd { color:#5317ac } /* KeywordNamespace */ .chroma .kn { color:#5317ac } /* KeywordPseudo */ .chroma .kp { color:#5317ac } /* KeywordReserved */ .chroma .kr { color:#5317ac } /* KeywordType */ .chroma .kt { color:#005a5f } /* NameBuiltin */ .chroma .nb { color:#8f0075 } /* NameFunction */ .chroma .nf { color:#721045 } /* NameVariable */ .chroma .nv { color:#00538b } /* Literal */ .chroma .l { color:#0000c0 } /* LiteralDate */ .chroma .ld { color:#0000c0 } /* LiteralString */ .chroma .s { color:#2544bb } /* LiteralStringAffix */ .chroma .sa { color:#2544bb } /* LiteralStringBacktick */ .chroma .sb { color:#2544bb } /* LiteralStringChar */ .chroma .sc { color:#2544bb } /* LiteralStringDelimiter */ .chroma .dl { color:#2544bb } /* LiteralStringDoc */ .chroma .sd { color:#2544bb } /* LiteralStringDouble */ .chroma .s2 { color:#2544bb } /* LiteralStringEscape */ .chroma .se { color:#2544bb } /* LiteralStringHeredoc */ .chroma .sh { color:#2544bb } /* LiteralStringInterpol */ .chroma .si { color:#2544bb } /* LiteralStringOther */ .chroma .sx { color:#2544bb } /* LiteralStringRegex */ .chroma .sr { color:#2544bb } /* LiteralStringSingle */ .chroma .s1 { color:#2544bb } /* LiteralStringSymbol */ .chroma .ss { color:#2544bb } /* LiteralNumber */ .chroma .m { color:#0000c0 } /* LiteralNumberBin */ .chroma .mb { color:#0000c0 } /* LiteralNumberFloat */ .chroma .mf { color:#0000c0 } /* LiteralNumberHex */ .chroma .mh { color:#0000c0 } /* LiteralNumberInteger */ .chroma .mi { color:#0000c0 } /* LiteralNumberIntegerLong */ .chroma .il { color:#0000c0 } /* LiteralNumberOct */ .chroma .mo { color:#0000c0 } /* Operator */ .chroma .o { color:#00538b } /* OperatorWord */ .chroma .ow { color:#00538b } /* Comment */ .chroma .c { color:#505050 } /* CommentHashbang */ .chroma .ch { color:#505050 } /* CommentMultiline */ .chroma .cm { color:#505050 } /* CommentSingle */ .chroma .c1 { color:#505050 } /* CommentSpecial */ .chroma .cs { color:#505050 } /* CommentPreproc */ .chroma .cp { color:#505050 } /* CommentPreprocFile */ .chroma .cpf { color:#505050 } </code></pre>Mais comme la même couleur est souvent utilisée, on peut valoir la peine de restructurer la feuille de style avec un outil comme <a href="https://css.github.io/csso/csso.html">CSSO</a>. En version bien mise en page: <pre tabindex="0"><code>.bg,.chroma { color: #000; background-color: #fff } .chroma .lnlinks { outline: 0; text-decoration: none; color: inherit } .chroma .lntd { vertical-align: top; padding: 0; margin: 0; border: 0 } .chroma .lntable { border-spacing: 0; padding: 0; margin: 0; border: 0 } .chroma .hl { background-color: #e5e5e5 } .chroma .ln,.chroma .lnt { white-space: pre; -webkit-user-select: none; user-select: none; margin-right: .4em; padding: 0 .4em; color: #7f7f7f } .chroma .line { display: flex } .chroma .k { color: #5317ac } .chroma .kc { color: #0000c0 } .chroma .kd,.chroma .kn,.chroma .kp,.chroma .kr { color: #5317ac } .chroma .kt { color: #005a5f } .chroma .nb { color: #8f0075 } .chroma .nf { color: #721045 } .chroma .nv { color: #00538b } .chroma .l,.chroma .ld { color: #0000c0 } .chroma .dl,.chroma .s,.chroma .s1,.chroma .s2,.chroma .sa,.chroma .sb,.chroma .sc,.chroma .sd,.chroma .se,.chroma .sh,.chroma .si,.chroma .sr,.chroma .ss,.chroma .sx { color: #2544bb } .chroma .il,.chroma .m,.chroma .mb,.chroma .mf,.chroma .mh,.chroma .mi,.chroma .mo { color: #0000c0 } .chroma .o,.chroma .ow { color: #00538b } .chroma .c,.chroma .c1,.chroma .ch,.chroma .cm,.chroma .cp,.chroma .cpf,.chroma .cs { color: #505050 } </code></pre>En version minifiée: <pre tabindex="0"><code>.bg,.chroma{color:#000;background-color:#fff}.chroma .lnlinks{outline:0;text-decoration:none;color:inherit}.chroma .lntd{vertical-align:top;padding:0;margin:0;border:0}.chroma .lntable{border-spacing:0;padding:0;margin:0;border:0}.chroma .hl{background-color:#e5e5e5}.chroma .ln,.chroma .lnt{white-space:pre;-webkit-user-select:none;user-select:none;margin-right:.4em;padding:0 .4em;color:#7f7f7f}.chroma .line{display:flex}.chroma .k{color:#5317ac}.chroma .kc{color:#0000c0}.chroma .kd,.chroma .kn,.chroma .kp,.chroma .kr{color:#5317ac}.chroma .kt{color:#005a5f}.chroma .nb{color:#8f0075}.chroma .nf{color:#721045}.chroma .nv{color:#00538b}.chroma .l,.chroma .ld{color:#0000c0}.chroma .dl,.chroma .s,.chroma .s1,.chroma .s2,.chroma .sa,.chroma .sb,.chroma .sc,.chroma .sd,.chroma .se,.chroma .sh,.chroma .si,.chroma .sr,.chroma .ss,.chroma .sx{color:#2544bb}.chroma .il,.chroma .m,.chroma .mb,.chroma .mf,.chroma .mh,.chroma .mi,.chroma .mo{color:#0000c0}.chroma .o,.chroma .ow{color:#00538b}.chroma .c,.chroma .c1,.chroma .ch,.chroma .cm,.chroma .cp,.chroma .cpf,.chroma .cs{color:#505050} </code></pre>Entre la version générée par <code>hugo gen</code> et la version finale, on économise 75% de poids! <hr> Cet article sera remis à une une fois ces recettes appliquées à mon site.</description></item><item><title>Adresses mail avec le signe + (plus)</title><link>https://nicolasfriedli.ch/blog/mail-plus/</link><pubDate>Sat, 04 Jan 2025 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/mail-plus/</guid><description>L’utilisation du signe <code>+</code> (plus) dans une adresse de messagerie permet de créer un nombre illimité d’alias. C’est intéressant pour la détection des fuites de données et le filtrage avancé de sa boîte de réception. Mais cette méthode a aussi ses limites. <h2 id="caracteres-autorises-et-interdits">Caractères autorisés (et interdits)</h2> La constitution d’une adresse mail répond à la fois à des normes et aux critères adoptés par son hébergeur. Les hébergeurs peuvent être plus restrictifs que les règles définies par l’IETF (Internet Engineering Task Force). La page Wikipédia sur les adresses de messagerie (en anglais) donne une excellente <a href="https://en.wikipedia.org/wiki/Email_address#Examples">liste d’exemples d’adresse valides et invalides</a>. La validité de ces adresses est celle des normes dans les <a href="https://fr.wikipedia.org/wiki/Request_for_comments">RFC (Request for comments)</a> de l’IETF. Ensuite, votre hébergeur peut restreindre ces choix. Par exemple, Infomaniak, l’excellent hébergeur de ce site: <a href="https://www.infomaniak.com/fr/support/faq/438/decouvrir-les-caracteres-admis-pour-une-adresse-mail">Découvrir les caractères admis pour une adresse mail</a>. Pour moi, une adresse bien pensée est constituée uniquement de: <ul> <li>Lettres minuscules. La partie à droite de l’arobase <code>@</code> (adresse du serveur) peut utiliser des minuscules comme des majuscules, c’est toujours équivalent. Les serveurs ne font en général pas de distinction entre majuscules et minuscules pour la partie à gauche de <code>@</code> (partie locale). Les variations de type <a href="https://fr.wikipedia.org/wiki/Camel_case">CamelCase</a> apportent plus de confusion que de clarté.</li> <li>Points. Ils remplacent les espaces (s’il est souhaité de rendre visible les «espaces» dans une adresse). Ils sont, par exemple, la séparation logique entre prénom et nom.</li> <li>Traits d’union. Je conseille de les utiliser seulement quand ils existent déjà dans la graphie courante. Par exemple, l’adresse mail de Jean-Alcide Nanchen pourrait être <code>jean-alcide.nanchen@gmail.com</code>.</li> </ul> En plus de ces 3 types de caractères, il existe le fameux signe <code>+</code> ou plus. L’idée est à la fois simple et géniale. Le serveur considère comme synonyme les adresses suivantes: <pre tabindex="0"><code>prenom.nom@frdl.ch prenom.nom+newsletter@frdl.ch prenom.nom+anti.spam@frdl.ch </code></pre>Les 3 courriers arriveront bien à l’adresse <code>prenom.nom@frdl.ch</code>. C’est utile car simple à mettre en œuvre, voici pourquoi. <h2 id="les-alias-mail">Les alias mail</h2> <h3 id="alias-classique">Alias «classique»</h3> Créer un alias mail, c’est équivalent à coller un nom supplémentaire sur sa boîte aux lettres. Par exemple, sous mon nom, je peux ajouter un autocollant «Association Libido Dièse». Les courriers adressés à cette remarquable association seront déposés dans ma boîte personnelle. Sur le serveur <code>frdl.ch</code>, je pourrais créer: <pre tabindex="0"><code>prenom.nom@frdl.ch &lt;- mon adresse libido.diese@frdl.ch &lt;- un alias </code></pre>Cela signifie que, avant de recevoir un courrier papier ou mail: <ul> <li>dans la vie physique, je dois créer un autocollant et l’apposer sur ma boîte aux lettres</li> <li>sur le serveur, je dois créer l’alias avant qu’il soit utilisable</li> </ul> <h3 id="alias-par--plus">Alias par <code>+</code> (plus)</h3> Pour reprendre l’analogie du courrier postal, il faut que l’adresse soit quelque chose comme: «Association Libido Dièse - Nicolas Friedli». En version serveur mail: <pre tabindex="0"><code>prenom.nom@frdl.ch &lt;- mon adresse prenom.nom+libido.diese@frdl.ch &lt;- un alias </code></pre>Cela signifie que: <ul> <li>dans la vie physique, je n’ai pas besoin d’ajouter un autocollant sur ma boîte aux lettres</li> <li>sur le serveur, je n’ai rien à créer pour que cela fonctionne (à condition que mon hébergeur gère bien les <code>+</code>)</li> </ul> C’est génial parce que je «crée» un alias au moment même de l’écriture de l’adresse. <h3 id="tracer-les-fuites-de-donnees">Tracer les fuites de données</h3> Par exemple, lorsque je m’abonne à une lettre de nouvelles, j’ajoute toujours un <code>+</code>. Et j’utilise une adresse Gmail. Donc, pour les lettres de nouvelles la commune de Pétaouchnok: <pre tabindex="0"><code>nicolas.friedli+petaouchnok@gmail.com </code></pre>Désormais, si je reçois un spam à cette adresse, je sais que la fuite de données provient de la commune Pétaouchnok. Peut-être qu’elle a donné mon adresse à des tiers (contrairement à sa promesse de ne pas le faire). Peut-être que son serveur a été piraté. <h3 id="trier-efficacement-ses-mails">Trier efficacement ses mails</h3> Comme <code>nicolas.friedli+petaouchnok@gmail.com</code> est désormais utilisée pour du spam, je peux ajouter un filtre qui balance automatiquement à la poubelle tout ce qui contient <code>+petaouchnok@</code>. Si je recouvre confiance en cette commune, je peux toujours me risquer à un réabonnement avec: <pre tabindex="0"><code>nicolas.friedli+le.retour.de.petaouchnok@gmail.com </code></pre>Mais je peux aussi utiliser d’autres alias utiles. Par exemple, pour déplacer automatiquement dans un répertoire donné: <pre tabindex="0"><code>prenom.nom+urgent@frdl.ch prenom.nom+reservation2025@frdl.ch </code></pre>À défaut de filtrer ou trier automatiquement, une recherche avec une adresse précise est diablement efficace. <h3 id="creer-des-comptes-multiples">Créer des comptes multiples</h3> Autre utilité des alias par <code>+</code>, la possibilité de créer plusieurs comptes: <ul> <li>tu joues à Brawl Stars et tu souhaites 2 comptes</li> <li>une administration exige une adresse différente pour chaque membre de la famille</li> <li>tu veux profiter d’une offre gratuite limitée&hellip;</li> </ul> <h2 id="limites-de-lutilisation-du-">Limites de l’utilisation du <code>+</code></h2> Maintenant que l’on a vu plein de belles choses à faire avec <code>+</code>, voici pourquoi tout n’est pas complètement rose. <h3 id="configuration-des-serveurs">Configuration des serveurs</h3> La règle <a href="https://checklists.opquast.com/fr/assurance-qualite-web/le-site-accepte-les-alias-mail-contenant-le-signe">Opquast 23</a> est claire: <blockquote> Le site accepte les alias mail contenant le signe +.</blockquote> La règle parle bien du serveur sur lequel vous souhaitez vous inscrire avec une adresse mail. C’est une mauvaise idée de ne pas l’accepter, mais ça arrive. Difficile de faire plier certaines entreprises et administrations. En passant, si votre hébergeur n’accepte pas les adresses avec <code>+</code>, changez d’hébergeur! <h3 id="changement-de-proprietaire">Changement de propriétaire</h3> Un «vrai» alias permet de rediriger ailleurs lorsque les propriétaires changent. Ce n’est pas le cas avec une adresse en <code>+</code> qui reste toujours liée à l’adresse de départ. Dans mon exemple de l’Association Libido Dièse, l’alias en <code>+</code> sera toujours lié aux mêmes prénom et nom: <pre tabindex="0"><code>prenom.nom@frdl.ch &lt;- mon adresse prenom.nom+libido.diese@frdl.ch &lt;- un alias </code></pre>Alors qu’un alias «classique» peut renvoyer ailleurs: <pre tabindex="0"><code>prenom.nom@frdl.ch &lt;- mon adresse libido.diese@frdl.ch &lt;- alias original vers prenom.nom@frdl.ch libido.diese@frdl.ch &lt;- alias modifié vers prenom2.nom2@frdl.ch libido.diese@frdl.ch &lt;- ou redirection vers libidodiese@gmail.com </code></pre>L’alias «classique» demande de la maintenance (création, suppression, gestion des redirections), mais est très souple. L’alias <code>+</code> ne demande aucun travail, mais offre moins de possibilités. <h3 id="malices-des-spammeurs-et-spammeuses">Malices des spammeurs et spammeuses</h3> Si j’étais spammeur, je m’empresserais de nettoyer tous les <code>+</code> pour limiter les possibilités de filtrage de mes victimes. C’est facile avec <a href="https://fr.wikipedia.org/wiki/Expression_r%C3%A9guli%C3%A8re">expression régulière</a>. Si vous ne savez pas ce que c’est, vous pouvez vous amuser avec <a href="https://regex101.com/">regular expressions 101</a>. Dans mon éditeur VS Code, j’efface ce qui correspond à <code>\+[^@]*</code>. En français: <blockquote> Sélectionne le <code>+</code> puis tous les caractères qui suivent à condition que ce ne soit pas un <code>@</code>. Puis remplace cette chaîne par&hellip; rien.</blockquote> Vous pouvez voir le résultat dans dans <a href="https://regexr.com/8an1s">regexr.com</a>. <h3 id="adresse-temporaire">Adresse temporaire</h3> Avec un alias classique, il est possible de créer un mail temporaire, qui sera détruit une fois devenu inutile. Par exemple, pour envoyer des sa candidature à un emploi précis: <pre tabindex="0"><code>postulation237@frdl.ch </code></pre>Une fois le délai passé cet alias est détruit. Alors que qu’avec les adresses en <code>+</code>, l’adresse originale est toujours dévoilée. Pour un même type d’usage: <pre tabindex="0"><code>rh+postulation237@frdl.ch </code></pre>D’une part l’adresse d’origine est dévoilée (<code>rh@frdl.ch</code>), d’autre part l’alias n’est pas désactivable une fois le délai passé et tous les messages envoyés à cette adresse arriveront bien dans la boîte des ressources humaines. Un alias classique permet aussi d’anonymiser l’adresse de destination. Personne ne pourra savoir où atterit l’adresse <code>qwertz@frdl.ch</code>, alors que <code>prenom.nom+qwertz@frdl.ch</code> dévoile sa destination. <h2 id="note-sur-les-adresses-gmail">Note sur les adresses Gmail</h2> En lisant des normes et pratiques pour rédiger cet article, je me suis souvenu d’une particularité de Gmail. Les points n’ont aucune importance dans les adresses <code>@gmail.com</code>. Ainsi, les mails envoyés à toutes ces adresses arriveront au même endroit: <pre tabindex="0"><code>prenom.nom@gmail.com prenomnom@gmail.com p.r.enom.n.om@gmail.com </code></pre>C’est plutôt intéressant du point de vue de la sécurité, parce qu’il est difficile d’usurper une identité par l’ajout de <code>.</code> (points). Et, bien entendu: Gmail permet l’utilisation des adresses en <code>+</code>. <hr> Je reçois volontiers un message avec vos cas d’utilisation intéressants. Le mail en <code>+</code> se trouve en pied de page. <hr> <h2 id="antispam">Antispam</h2> <a href="https://matthieuamiguet.ch/">Matthieu Amiguet</a> me signale à juste titre que pour lutter sérieusement contre le spam, il est bien d’utiliser un service dédié. Par exemple <a href="https://www.spamgourmet.com/">spamgourmet</a> qui permet de créer une adresse unique qui se détruit automatiquement après avoir mangé assez de messages. Il existe aussi l’idée de l’adresse jetable, qui cache complètement votre mail, quand vous vous abonnez à des newsletters dans des lecteurs de flux RSS en ligne. C’est le cas chez Inoreader, Feedbin et Feedly (au moins). Pour d’autres services, lancez une <a href="https://nicolasfriedli.ch/blog/recherche-google-avancee/">recherche Google</a> (ou autre) sur <code>mail jetable</code> ou <code>adresse mail unique</code>.</description></item><item><title>Recherches Google avancées</title><link>https://nicolasfriedli.ch/blog/recherche-google-avancee/</link><pubDate>Thu, 05 Dec 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/recherche-google-avancee/</guid><description>Le moteur de recherche Google est souvent utilisé de manière basique. Comme il est plutôt efficace, quelques mots suffisent souvent. Toutefois, quelques astuces permettent d’affiner ses recherches. La maîtrise des recherches est une compétence <del>utile</del> nécessaire pour effectuer une veille efficace. Un conseil: à chaque étape de cette page, faites des tests avec vos propres requêtes! C’est en utilisant ces critères que vous en comprendrez vraiment l’utilité (et les mémoriserez). <h2 id="documentation-de-google">Documentation de Google</h2> Le moteur de recherche propose des pages de <a href="https://support.google.com/websearch">documentation</a> intéressantes. Par exemple: <ul> <li><a href="https://support.google.com/websearch/answer/2466433">Affiner les recherches Google</a></li> <li><a href="https://support.google.com/websearch/answer/35890">Effectuer une recherche avancée sur Google</a></li> <li><a href="https://support.google.com/websearch/answer/13485060">Utiliser le filtre de langue des résultats dans la recherche Google</a></li> </ul> Si c’est toujours une bonne idée de lire les documentations officielles, je préfère vous donner rapidement les requêtes les plus utiles. Je signale qu’il existe un <a href="https://www.google.ch/advanced_search">formulaire de recherche avancée</a>, mais je n’aime pas l’utiliser. Les requêtes textuelles me parlent plus qu’un formulaire. <h2 id="operateurs-logiques">Opérateurs logiques</h2> <h3 id="rechercher-une-expression-et-une-autre-avec-and">Rechercher une expression et une autre avec <code>AND</code></h3> Par défaut, une recherche sans précisions particulières recherche tous les mots. Par exemple: <pre><code>Nicolas Friedli </code></pre> Je peux préciser explicitement que je souhaite tous ces mots avec: <pre><code>Nicolas+Friedli </code></pre> L’utilisation de <code>AND</code> au lieu de <code>+</code> est possible: <pre><code>Nicolas AND Friedli </code></pre> Ce type de recherche est celui que vous effectuez la plupart du temps. <h3 id="recherche-une-expression-ou-une-autre-avec-or">Recherche une expression ou une autre avec <code>OR</code></h3> Le ou n’est jamais explicite. Il faut donc le préciser dans sa recherche, avec une des syntaxes suivantes: <pre><code>Nicolas|Friedli Nicolas OR Friedli </code></pre> C’est peu utile ainsi. Je pourrais effectuer successivement les 2 recherches pour avoir le même résultat. Le <code>OR</code> n’est pas exclusif, ce qui signifie qu’il peut y avoir des résultats avec 1 mot, l’autre mot ou les 2. Mais c’est très puissant dans les recherches complexes dont on parlera ci-dessous. <h3 id="exclure-des-resultats-de-recherche-avec--">Exclure des résultats de recherche avec <code>-</code></h3> L’exclusion de résultat est intéressante pour éviter des résultats parasites. Il existe un Nicolas Friedli qui s’occupe de pieds. Donc, je pourrais faire une recherche comme: <pre><code>Nicolas Friedli -podologue -pédicure </code></pre> Comme il est possible de recherche plusieurs mots, il est possible d’en exclure plusieurs. Les exclusions sont très intéressantes quand on utilise des requêtes complexes pour les actualités Google. <h3 id="rechercher-un-motif-exact-avec--">Rechercher un motif exact avec <code>&quot; &quot;</code></h3> L’utilisation de guillemets permet la recherche d’une expression exacte. Ce qui signifie que les 2 requêtes suivantes donnent des résultats différents: <pre><code>&quot;Nicolas Friedli&quot; &quot;Friedli Nicolas&quot; </code></pre> Comme les algorithmes de recherche ont tendance à corriger automatiquement les requêtes, c’est un outil nécessaire dans certains cas. C’est particulièrement puissant quand un nom a une orthographe particulière. Le motif exact peut être un seul mot. Ainsi, si je veux recherche Nicaulas, j’entrerai: <pre><code>&quot;Nicaulas&quot; </code></pre> Et là, malgré les guillemets, Google me propose des résultats pour Nicolas. Je peux ensuite forcer la recherche avec le lien proposé: Essayez avec l’orthographe &ldquo;nicaulas&rdquo;. <h3 id="combinaisons-doperateurs-logiques">Combinaisons d’opérateurs logiques</h3> Pour effectuer des recherches d’actualité dans le domaine du protestantisme réformé, j’utilise: <pre><code>&quot;(église|paroisse) (protestante|réformée)&quot; </code></pre> Ce qui signifie que je recherche 4 expressions exactes: <pre><code>&quot;église protestante&quot; OR &quot;église réformée&quot; OR &quot;paroisse protestante&quot; OR &quot;paroisse réformée&quot; </code></pre> Mais j’évite les articles comprennent les mots église et paroisse seulement. <h2 id="recherche-dans-un-seul-site-avec-site">Recherche dans un seul site avec <code>site:</code></h2> C’est un des outils méconnus les plus puissants: la recherche sur un seul nom de domaine ou une partie de site. Un exemple tout simple: <pre><code>&quot;nicolas friedli&quot; site:reformes.ch </code></pre> C’est une combinaison d’une expression exacte (<code>&quot; &quot;</code>) et d’une limitation à un seul site. Une utilisation basique mais efficace de ce genre de requête, c’est: <pre><code>site:eliojaillet.ch </code></pre> Ainsi, le théologien vaudois éclectique verra comment s’affichent les pages de son site dans Google (et quelles pages sont indexées). Il n’est pas nécessaire d’utiliser un nom de domaine entier. Une extension seule est aussi possible. Par exemple: <pre><code>site:.fr &quot;Elio Jaillet&quot; </code></pre> Les négations sont aussi possibles: <pre><code>&quot;Elio Jaillet&quot; -site:eliojaillet.ch </code></pre> Et quand vous souhaitez effectuer une recherche sur un blog hébergé chez wordpress.com, utilisez quelque chose comme: <pre><code>site:sousdomaine.wordpress.com </code></pre> Ces recherches sont très (très très) utiles quand un site ne dispose pas de moteur de recherche ou que son moteur de recherche est médiocre. <h2 id="recherche-par-type-de-fichiers-avec-filetype">Recherche par type de fichiers avec <code>filetype:</code></h2> J’utilise surtout la recherche par type de fichiers pour m’attaquer aux PDF. Surtout quand ils ne sont pas référencés par le moteur de recherche interne ou que le moteur de recherche n’est pas assez bon. Un exemple concret: <pre><code>filetype:pdf site:ne.ch &quot;piste cyclable&quot; </code></pre> Avec ce que vous savez déjà, vous n’aurez aucune difficulté à comprendre ce que fait cette requête. Essayez avec votre propre nom: <pre><code>&quot;Prénom Nom&quot; OR &quot;Nom Prénom&quot; filetype:pdf site:.ch </code></pre> Un outil de veille très intéressant. <h2 id="1exemple-de-recherche-pour-des-sites-wordpress">1 exemple de recherche pour des sites WordPress</h2> Pour les sites WordPress, j’aime bien ajouter des limitations. En particulier quand ils comportent beaucoup de catégories et de tags. Par exemple, sur le site d’Armin Kressmann (qui avait conservé une ancienne version de ce document), la liste des articles: <pre><code>site:ethikos.ch -site:ethikos.ch/category -site:ethikos.ch/tag -site:ethikos.ch/page </code></pre> Et en version bien plus élégante: <pre><code>site:ethikos.ch -inurl:(category|tag|page) </code></pre> Il y a dans cette ligne les notions de <code>site:</code>, la négation <code>-</code>, le <code>|</code> (ou). Et j’ajoute le sélecteur <code>inurl</code> qui signale un motif dans l’adresse de la page (ou URL). <h2 id="utiliser-ses-recherches-pour-des-alertes-google">Utiliser ses recherches pour des alertes Google</h2> La construction d’une requête complexe peut prendre un peu de temps, mais elle est très utile pour les alertes Google. Je construis sans la tester une requête de veille: <pre><code>&quot;(église|paroisse) (protestante|réformée)&quot; site:.ch -site:eren.ch -site:eerv.ch </code></pre> Vous avez compris: <ul> <li>je souhaite une des 4 expressions dont j’ai parlé avant</li> <li>sur un site «en principe suisse» (en <code>.ch</code>)</li> <li>mais pas sur les sites de l’EREN ou de l’EERV</li> </ul> Ajoutez une requête de ce type dans les <a href="https://www.google.ch/alerts?hl=fr">alertes Google</a>, puis faites-vous envoyer un mail (ou abonnez-vous par RSS)! C’est redoutablement efficace. <hr> Évidemment, pour faire des tests sur votre propre site, il faut qu’il soit bien indexé par Google. C’est aussi un moyen de tester son référencement. <hr> Besoin de compléments? Problèmes à établir une requête précise? Souhait d’une formation? Contactez-moi!</description></item><item><title>Logique cumulative ou qualitative</title><link>https://nicolasfriedli.ch/blog/logique-cumulative-qualitative/</link><pubDate>Thu, 21 Nov 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/logique-cumulative-qualitative/</guid><description>Ce site est construit selon une logique de blog: j’accumule du contenu. Chaque nouvelle publication est ajoutée dans la même rubrique. Il existe quelques taxonomies qui permettent de lier les pages entre elles par thématiques. Mais je m’interroge et hésite à créer un site hiérarchique. Avec une idée derrière la tête: maintenir à jour un corpus de taille raisonnable. <h2 id="le-modele-cumulatif">Le modèle cumulatif</h2> Les sites cumulatifs par excellence sont les blogs et les sites d’actualités. L’intervention principale sur le site est l’ajout d’une nouvelle page. Et parfois l’ajout «à la volée» de nouvelles taxonomies. Si je qualifie ce modèle de «cumulatif», cela ne dit rien de la qualité des contenus publiés. Mais plutôt l’idée qu’une page en ligne est rarement modifiée. Le blog est efficace et pertinent pour mettre en ligne des contenus «terminés». Il n’y a pas de raison de les revoir à l’avenir, parce qu’ils ont été délivrés tels quels. Bien entendu, la correction de coquilles ou de liens est toujours possible. À mes yeux, le risque principal de ce type de publication est la cannibalisation des contenus. Je me vois mal publier 10 pages sur l’<a href="https://nicolasfriedli.ch/blog/police-optimisee-titres/">optimisation des polices d’écriture</a> au fil du temps. Si 9 billets sont dépassés, à quoi bon les conserver. Le message que donne un blog, c’est: <blockquote> Vous trouvez ici du contenu «dans son jus», tel qu’il a existé à un moment, et c’est ce qui fait sa saveur. Il n’est peut-être plus pertinent, mais ce n’est pas la question. Servez-vous si cela vous intéresse.</blockquote> <h2 id="le-modele-qualitatif">Le modèle qualitatif</h2> Les sites qualitatifs sont avant tout des documentations et des wiki. Les interventions sont souvent des corrections et améliorations de pages existantes. Généralement, les wiki ne contiennent pas de taxonomies. Et l’ajout de catégories dans les sites hiérarchiques (en arbre) est non trivial. Si je qualifie ce modèle de «qualitatif», cela ne signifie pas que chaque contenu sera de qualité. Mais plutôt que la qualité d’un contenu donné sera améliorée au fil du temps. Lorsque je documente du code, je constate que la logique du blog n’est pas toujours la bonne. Les outils changent et il y a un grand risque de garder en ligne des extraits caducs ou dépassés. Je préfère avoir 1 billet sur un sujet et le corriger quand nécessaire. Le message que donne un site qualitatif: <blockquote> Vous trouvez ici un contenu utilisable aujourd’hui. Son histoire n’est pas (immédiatement) visible. Mais ce qui compte, c’est sa pertinence actuelle.</blockquote> <h2 id="eviter-les-absolus">Éviter les absolus</h2> Bien évidemment, aucun de ces modèles n’est parfait. Certains billets de blog sont corrigés, maintenus, réactualisés, parfois avec une republication ou une redirection. Alors que le modèle hiérarchique n’empêche en rien l’ajoute régulier de contenus. Et il n’est pas certain que tous les articles seront parfaitement à jour. La question que je me pose, c’est celle de l’orientation fondamentale de mon site ou de sa ligne de conduite. Mon billet sur les <a href="https://nicolasfriedli.ch/blog/hugo-pages-soeurs-filles/">pages sœurs, filles et mère</a>, utilisées dans d’autres contextes, me titille. J’aimerais bien réussir à proposer des navigations contextuelles plus intéressantes que les seuls «articles en relation» de bas de page. <h2 id="avantages-et-desavantages-techniques">Avantages et désavantages techniques</h2> Techniquement, le modèle qualitatif me paraît offrir quelques avantages: <ul> <li>la possibilité de disposer d’un fil d’Ariane ou breadcrumb qui permet de se situer sur le site</li> <li>l’utilisation d’URL hiérarchiques est intéressante pour l’étude des données statistiques</li> <li>la structuration de «secteurs» permet d’envisager simplement des mises en pages différenciées</li> <li>la croissance organique du site est une manière de faire que j’apprécie</li> </ul> Mais ce modèle hiérarchique, en arbre, a aussi des limitations: <ul> <li>une page fait partie d’une seule rubrique, ce qui demande pas mal de réflexions du point de vue de l’architecture d’information</li> <li>l’utilisation des taxonomies est relativisée, alors que c’est un mode de pensée qui me convient</li> <li>l’automatisation des navigations fait toujours courir le risque de proposer moins de liens dans le corps du texte (pour éviter les doublets)</li> </ul> <hr> Je reçois volontiers vos retours et conseils par webmention ou par mail. Ou, mieux encore, dans un billet ajouté à votre propre blog.</description></item><item><title>Pages sœurs, filles et mère avec Hugo</title><link>https://nicolasfriedli.ch/blog/hugo-pages-soeurs-filles/</link><pubDate>Wed, 20 Nov 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/hugo-pages-soeurs-filles/</guid><description>Dans un site hiérarchique construit avec Hugo, il est facile de se créer des shortcodes ou des partials pour afficher une navigation contextuelle. Je considère que le site est construit avec des répertoires et des pages <code>_index.md</code> dans chaque répertoire. C’est idéal pour construire automatiquement le maillage interne d’un cocon sémantique «à l’ancienne»: <ul> <li>lien vers la page mère en haut de page</li> <li>lien vers les pages sœurs en bas de page</li> <li>et éventuellement des liens vers les pages filles dans le corps du texte (si ce n’est pas fait manuellement, ce qui est meilleur)</li> </ul> Des codes plus évolués sont disponibles dans certaines de <a href="https://github.com/nfriedli/">mes dépôts GitHub</a>. <h2 id="shortcode-ou-partial">Shortcode ou partial</h2> La distinction entre les 2 doit être claire pour vous avant de vous lancer. Si ce n’est pas le cas, il ne vaut pas la peine d’aller plus loin. Mieux vaut lire la documentation d’Hugo: <a href="https://gohugo.io/content-management/shortcodes/">Shortcodes</a> et <a href="https://gohugo.io/templates/partial/">Partial templates</a>. Un shortcode est appelé dans la source de la page en Markdown, avec un code de ce type, disponible pour les rédacteurs et rédactrices: <pre tabindex="0"><code>{{&lt; sisters &gt;}} </code></pre>Les shorcodes ont un avantage: ils peuvent être appelés n’importe où dans le contenu de la page (corps de l’article). Par exemple un liste de billets entre 2 paragraphes. Ils ont un inconvénient: il faut les appeler à chaque fois. Un partial est appelé dans un template de page, avec un code de type, disponibles pour les «programmeurs» et «programmeuses»: <pre tabindex="0"><code>{{ partial &#34;header&#34; . }} </code></pre>Les partials ont un avantage: ils peuvent être appelés systématique hors du contenu de la page (corps de l’article). Par exemple en pied de page ou comme liste de pages sous l’article. Ils ont un inconvénient: les variations au cas par cas ne sont pas triviales. <h2 id="pages-filles-sous-pages-ou-niveau-inferieur">Pages filles (sous-pages ou niveau inférieur)</h2> <h3 id="affichage-des-pages-filles-avec-un-shortcode">Affichage des pages filles avec un shortcode</h3> Un fichier dans <code>/layouts/shortcodes/subpages.html</code>: <pre tabindex="0"><code>&lt;ul&gt; {{ range page.Pages }} &lt;li&gt;&lt;a href=&#34;{{ .RelPermalink }}&#34;&gt;{{ .LinkTitle }}&lt;/a&gt;&lt;/li&gt; {{ end }} &lt;/ul&gt; </code></pre>On l’appelle par <code>{{&lt; subpages &gt;}}</code>. Comme il n’est pas certain que des pages filles existent, on peut ajouter une condition sur la présence de pages. Ou ne jamais utiliser ce shortcode quand il n’y a pas de filles. <h3 id="affichage-des-pages-filles-avec-un-partial">Affichage des pages filles avec un partial</h3> Un fichier dans <code>/layouts/partials/subpages.html</code>: <pre tabindex="0"><code>&lt;ul&gt; {{ range .Pages }} &lt;li&gt;&lt;a href=&#34;{{ .RelPermalink }}&#34;&gt;{{ .LinkTitle }}&lt;/a&gt;&lt;/li&gt; {{ end }} &lt;/ul&gt; </code></pre>On l’appelle par <code>{{ partial &quot;subpages&quot; . }}</code>. Avec le point qui transmet le <a href="https://www.regisphilibert.com/blog/2018/02/hugo-the-scope-the-context-and-the-dot/">contexte</a>! Comme il n’est pas certain que des pages filles existent, il faut ajouter une condition sur la présence de pages pour ne pas créer une liste vide. <h2 id="pages-surs-meme-niveau">Pages sœurs (même niveau)</h2> <h3 id="affichage-des-pages-surs-avec-un-shortcode">Affichage des pages sœurs avec un shortcode</h3> Un fichier dans <code>/layouts/shortcodes/sisters.html</code>: <pre tabindex="0"><code>{{ with page.Parent }} &lt;ul&gt; {{ range .Pages }} &lt;li&gt;&lt;a href=&#34;{{ .RelPermalink }}&#34;&gt;{{ .LinkTitle }}&lt;/a&gt;&lt;/li&gt; {{ end }} &lt;/ul&gt; {{ end }} </code></pre>On l’appelle par <code>{{&lt; sisters &gt;}}</code>. Quand une rubrique existe, c’est qu’elle comporte normalement plusieurs pages. Mais comme ce n’est pas une nécessité, le shortcode n’est appelé que quand il y a plusieurs pages. Il faut alors l’ajouter sur toutes les nouvelles pages. Je conseille d’ajouter des conditions (par exemple pour ne pas mettre un lien sur la page courante). <h3 id="affichage-des-pages-surs-avec-un-partial">Affichage des pages sœurs avec un partial</h3> Un fichier dans <code>/layouts/partials/sisters.html</code>: <pre tabindex="0"><code>{{ with .Parent }} &lt;ul&gt; {{ range .Pages }} &lt;li&gt; &lt;a href=&#34;{{ .RelPermalink }}&#34;&gt; {{ .LinkTitle }} &lt;/a&gt; &lt;/li&gt; {{ end }} &lt;/ul&gt; {{ end }} </code></pre>On l’appelle par <code>{{ partial &quot;sisters&quot; . }}</code>. Avec le point qui transmet le contexte! Quand une rubrique existe, c’est qu’elle comporte normalement plusieurs pages. Je conseille d’ajouter des conditions (par exemple pour ne pas mettre un lien sur la page courante). <h2 id="page-mere-repertoire-ou-niveau-superieur">Page mère (répertoire ou niveau supérieur)</h2> <h3 id="affichage-de-la-page-mere-avec-un-shortcode">Affichage de la page mère avec un shortcode</h3> Un fichier dans <code>/layouts/shortcodes/mother.html</code>: <pre tabindex="0"><code>{{ with page.Parent }} &lt;a href=&#34;{{ .RelPermalink }}&#34;&gt;{{ .LinkTitle }}&lt;/a&gt;&lt;/li&gt; {{ end }} </code></pre>On l’appelle par <code>{{&lt; mother &gt;}}</code>. L’utilisation de <code>with</code> ne provoquera l’affichage que si une page mère existe. <h3 id="affichage-de-la-page-mere-avec-un-partial">Affichage de la page mère avec un partial</h3> Un fichier dans <code>/layouts/partials/mother.html</code>: <pre tabindex="0"><code>{{ with .Parent }} &lt;a href=&#34;{{ .RelPermalink }}&#34;&gt;{{ .LinkTitle }}&lt;/a&gt;&lt;/li&gt; {{ end }} </code></pre>On l’appelle par <code>{{ partial &quot;mother&quot; . }}</code>. Avec le point qui transmet le contexte! L’utilisation de <code>with</code> ne provoquera l’affichage que si une page mère existe. <h2 id="conditions-utiles">Conditions utiles</h2> Je conseille d’ajouter certaines conditions d’affichage: <ul> <li>affichage des pages sœurs uniquement s’il y a en a plus de 2 (la page présente et une autre page)</li> <li>désactiver l’affichage de la page actuelle de la liste ou</li> <li>désactiver le lien de la page actuelle dans la liste</li> </ul> Et aussi, tester le nombre de pages avant d’ouvrir un liste <code>&lt;ul&gt;...&lt;/ul&gt;</code>. Un exemple concret, que je vous invite à essayer de comprendre à la lecture: <pre tabindex="0"><code>{{ with .Parent }} {{ if gt (len .Pages ) 2 }} &lt;aside&gt; &lt;strong&gt;Ces contenus peuvent aussi vous intéresser:&lt;/strong&gt; &lt;ul&gt; {{ range .Pages }} {{ if ne .Page page }} &lt;li&gt; &lt;a href=&#34;{{ .RelPermalink }}&#34;&gt; {{ .LinkTitle }} &lt;/a&gt; &lt;/li&gt; {{ end }} {{ end}} &lt;/ul&gt; &lt;/aside&gt; {{ end }} {{ end }} </code></pre>Je suis disponible pour vous aider à écrire vos conditions au cas par cas.</description></item><item><title>Philosophie d’optimisation raisonnable</title><link>https://nicolasfriedli.ch/blog/optimisation-raisonnable/</link><pubDate>Sat, 26 Oct 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/optimisation-raisonnable/</guid><description>À force de consulter des sites de développement, il est facile de se perdre dans des tests numériques et des solutions techniques. Mais il me paraît utile de formuler aussi les questions d’optimisation, de performance et d’éco-conception en langage naturel. Cette idée de langage humain m’est venue en consultant la documentation de <a href="https://github.com/tdewolff/minify">minify</a>. <code>minify</code> permet d’optimiser les pages produites par <a href="https://nicolasfriedli.ch/blog/site-statique-generateur-hugo/">Hugo</a>. Dans chaque passage, je proposerai des citations qui devraient rendre le contenu de cette page à des internautes non techniques. <h2 id="formuler-les-resultats-de-tests-en-langage-naturel">Formuler les résultats de tests en langage naturel</h2> <code>minify</code> propose une comparaison de performances (benchmark) pour différents outils. En première lecture, je peux comparer les résultats de <a href="https://github.com/tdewolff/minify?tab=readme-ov-file#compression-ratio-lower-is-better">taille</a> et définir un classement. Mais à y regarder de plus près, il n’est pas certain que ce classement soit toujours identique. Une moyenne des résultats n’est pas probante, parce qu’il faudrait prendre le meilleur outil dans un cas précis. L’épuisement guette. Maintenant, je formule la chose en langage humain ou naturel: <blockquote> Les 5 outils testés permettent de gagner entre 40% et 70% de taille de fichier de manière automatique. Pour un fichier donné, le 5 outils obtiennent des résultats analogues (à 1% près). Ils sont tous excellents.</blockquote> Vue ainsi, le classement n’a plus beaucoup de sens! Alors on peut ajouter la question du <a href="https://github.com/tdewolff/minify?tab=readme-ov-file#time-lower-is-better">temps</a> nécessaire à l’optiomisation. Et là, en langage naturel, il faudrait dire: <blockquote> Pour produire des fichiers de taille analogue, certains outils sont plusieurs centaines de fois plus lents que d’autres.</blockquote> C’est là que <code>minify</code> excelle. Il est certes peut-être moins efficace de 1%, mais jusqu’à 500 fois plus rapide. Il est alors question d’efficience, l’efficacité rapportée au coût (temporel). <h2 id="eviter-les-erreurs">Éviter les erreurs</h2> Il y a quelques semaines, j’ai découvert une image de 70MB(!) sur une page d’accueil d’un site. C’est un fichier gigantesque qui pose de vrais problèmes. Elle s’afficherait sans différence sensible en étant 500 fois plus légères. Quels que soient les efforts sur une telle page, tous est cassé par 1 fichier problématique. C’est pourquoi il faut toujours <a href="https://nicolasfriedli.ch/blog/tester-site/">tester régulièrement son site web</a>. J’ai découvert l’horreur par un contrôle régulier avec <a href="https://www.speedlify.dev/">speedlify</a> que je conseille. Donc, en français: <blockquote> Avant même de chercher à optimiser, il vaut la peine de détecter des erreurs manifestes qui annihilent tous les efforts</blockquote> <h2 id="se-demander-ce-qui-est-necessaire">Se demander ce qui est nécessaire</h2> Des tests montrent <a href="https://github.com/cnumr/best-practices/blob/main/chapters/BP_001_fr.md">que 70% des fonctionnalités demandées par les utilisateurs ne sont pas essentielles et que 45% ne sont jamais utilisées</a>. Dès lors, il faut se demander sérieusement ce qui est vraiment nécessaire. Le fichier qui coût le moins du point de vue de la performance est celui qui n’est pas hébergé sur un serveur, qui ne transite pas par le réseau et qui n’est pas interprété par le périphérique final. Avant d’utiliser une police d’écriture spécifique, je devrais me demander sur une <a href="https://nicolasfriedli.ch/blog/polices-systeme/">police disponible</a> n’est pas suffisante. <blockquote> Avant de passer à une phase d’optimisation, il vaut la peine de se poser la question de la nécessité des outils proposés. Un fichier qui n’est pas envoyé n’a aucun coût écologique ou temporel.</blockquote> Cette réflexion est valable pour les polices, pour les images, pour les encarts des réseaux sociaux. <h2 id="optimiser-avec-efficacite">Optimiser avec efficacité</h2> Si j’estime qu’une police spécifique est nécessaire, alors j’essaierai de faire les choses dans les règles de l’art. J’en parle dans <a href="https://nicolasfriedli.ch/blog/police-optimisee-titres/">Police optimisée pour les titres</a>. Dès que l’on entre dans cette phase d’optimisation, on peut se prendre au jeu et essayer d’être le plus efficace possible. C’est de bonne guerre. Mais quand les gains entre 2 techniques ou tactiques sont minimes, il faut dire: <blockquote> La meilleure efficacité est souhaitable, mais n’est pas toujours la meilleure solution.</blockquote> <h2 id="favoriser-lefficience">Favoriser l’efficience</h2> C’est pourquoi je cherche à toujours favoriser l’efficience. C’est ce que me propose <code>minify</code>, dont je parle en haut de page. Je n’ai rien à installer, rien à configurer, c’est rapide et j’obtiens un résultat excellent (mais pas forcément le meilleur possible). Donc: <blockquote> L’efficience (efficacité à moindre coût) est l’optimisation la plus raisonnable.</blockquote> C’est là que l’on passe de la pure question technique à une question philosophique. Quand on est dans des questions de rapports entre coût et résultats, on entre dans le domaine de l’appréciation. Et, finalement, du choix. <h2 id="samuser-du-snobisme">S’amuser du snobisme</h2> Comme la performance web me passionne, je cherche à toujours obtenir le meilleur résultat possible. C’est pourquoi <a href="https://nicolasfriedli.ch/about/">ce site est hyper rapide</a>. Mais, d’une certaine manière, utiliser une mise en page simpliste, renoncer aux images et ne pas utiliser de polices spécifiques est une forme de snobisme. Au fond, je m’enorgueillis d’obtenir des <a href="https://pagespeed.web.dev/analysis/https-nicolasfriedli-ch/zdziqsc5vj?form_factor=mobile">résultats parfaits dans PageSpeed Insights</a>. C’est une forme de snobisme. <blockquote> La volonté d’obtenir le meilleur résultat à tout prix est un exercice utile pour les développeurs. La compétition stimule la recherche. Mais c’est rarement un objectif de la pratique réelle.</blockquote> J’ai effectué des <a href="https://nicolasfriedli.ch/bio/">mandats dans des domaines très différents</a>. Mais la constante est que le meilleur résultat à tout prix n’est pas leur première préoccupation. Ensemble, nous obtenons des produits raisonnablement optimisés parce que nous prenons le temps de discuter des enjeux de fond. Nous arbitrons entre le souhaitable, l’utile, le nécessaire ou ce qu’il convient d’éviter à tout prix. Ces tensions et ces négociations nous font discuter de questions sérieuses. Et parfois philosophiques.</description></item><item><title>Mes règles d’utilisation des réseaux sociaux</title><link>https://nicolasfriedli.ch/blog/reseaux-sociaux-regles/</link><pubDate>Sun, 20 Oct 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/reseaux-sociaux-regles/</guid><description>Lorsque je donnais des formations aux réseaux sociaux il y a bien plus de 10 ans, je conseillais toujours aux internautes de réfléchir à leurs propres règles au calme. Quand un problème survient, il est trop tard pour mener une réflexion posée quant à la meilleure façon d’agir. Le point de départ de la discussion était presque toujours une question pratique sur la modération d’une page institutionnelle. Je donnais alors quelques règles simples. <h2 id="regles-de-moderation">Règles de modération</h2> Pour modérer correctement une page Facebook, un forum, un espace Discord, il faut poser des règles limpides. Et quand la modération se fait à plusieurs, il faut s’entendre sur ces règles. Quand il y a incohérence dans la modération, c’est la porte ouverte aux conflits. Les règles que je donnais comme point de départ étaient: <ul> <li>Le refus de toute attaque personnelle. La discussion porte sur des arguments, non sur des personnes.</li> <li>La suppression de tout ce qui contrevient à la loi. À faire sans délai et sans avertissement, mais avec possibilité de laisser une note.</li> <li>Le refus des répétitions. Ce n’est pas en répétant 10 ou 20 fois la même chose que ça devient vrai. Des internautes qui tournent en rond peuvent tuer un forum ou un page Facebook en lassant les autres.</li> <li>La suppression des contenus hors sujet. On ne laisse pas les vendeurs de savons bio poster leur annonce sur une page Facebook qui parle de droit du bail.</li> </ul> Quand il y a un souci, appliquez-les de la manière la plus mécanique possible! Ensuite, vous pouvez en débattre, les modifier, etc., mais sans urgence. <h2 id="reglages-de-confidentialite">Réglages de confidentialité</h2> Facebook permet de nombreux réglages de confidentialité. Qui a le droit de faire quoi? J’ai toujours adopté une posture pragmatique: tout ce qui est posté sur Facebook est public. Essayer de «protéger» des contenus est vain, parce que les options changeront, parce que vous aurez fait une erreur dans un règlage, parce qu’il y aura une faille technique. Cette politique de tout public est n’est pas une option de configuration, mais une attitude. C’est facile, clair, et ça fonctionne dans la durée: <blockquote> Si ce contenu ne peut pas être rendu public, alors ne le poste pas sur Facebook. Point.</blockquote> <h2 id="mes-bonnes-pratiques">Mes bonnes pratiques</h2> Je n’ai plus d’activité sur les réseaux sociaux. Désormais, à titre personnel, j’adopte les pratiques suivantes: <ol> <li>Je partage des liens, donc des contenus disponibles ailleurs sur le web.</li> <li>J’évite les interactions sous forme de simple clic (J’aime et compagnie).</li> <li>Je ne commente rien (ni sur ma page de profil, ni sur des comptes personnels, ni sur des pages).</li> <li>Je supprime les commentaires problématiques sur ma page de profil.</li> <li>Je nettoie régulièrement ma page de profil.</li> </ol> Pour un argumentaire intéressant sur le refus du Like et du commentaire court, je vous invite à lire Digital Minimalism: Choosing a Focused Life in a Noisy World de <a href="https://calnewport.com/">Cal Newport</a>. Pour commenter, envoyez-moi un mail!</description></item><item><title>Less is more</title><link>https://nicolasfriedli.ch/blog/less-is-more/</link><pubDate>Thu, 17 Oct 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/less-is-more/</guid><description>Moins, c’est plus! Un magnifique slogan. Mais moins de quoi pour plus de quoi? Je remets en ligne un ancien billet publié il y a quelques années. On ne va pas refaire la genèse de la phrase. Un détour sur la page Wikipédia en allemand <a href="https://de.wikipedia.org/wiki/Weniger_ist_mehr">Weniger ist mehr</a> est un point d’entrée intéressant pour toutes les propositions d’oxymores similaires. Laissons à <a href="https://fr.wikipedia.org/wiki/Ludwig_Mies_van_der_Rohe">Ludwig Mies van der Rohe</a> la popularisation de l’idée sans chercher à documenter les détails de sa genèse. Ce slogan me plaît, mais je me demande souvent pourquoi. Peut-être parce qu’il y a plusieurs manières de le comprendre et de l’appliquer : <ul> <li>Dans le milieu architectural, c’est le <a href="https://fr.wikipedia.org/wiki/Minimalisme_(art)">minimalisme</a>. Et, dans une certaine mesure, le <a href="https://fr.wikipedia.org/wiki/Brutalisme">brutalisme</a> ou le <a href="https://fr.wikipedia.org/wiki/Fonctionnalisme_(architecture)">fonctionnalisme</a>.</li> <li>Dans notre vie quotidienne, c’est ce qu’incarne Apple. Une entreprise qui plonge ses racines dans <a href="https://www.cultofmac.com/188753/the-braun-products-that-inspired-apples-iconic-designs-gallery/">The Braun Products That Inspired Apple’s Iconic Designs</a> et les principes du bon design de <a href="https://fr.wikipedia.org/wiki/Dieter_Rams">Dieter Rams</a>.</li> <li>Dans le domaine du web, ce sont les sites sites simples et lisibles (comme nicolasfriedli.ch).</li> <li>Dans le domaine du web encore, c’est la page <a href="https://justinjackson.ca/words_fr.html">Ceci est une page Web</a>.</li> </ul> Si j’essaie de reformuler, Less is more, ce peut être : <ul> <li>moins d’images, plus de contenu</li> <li>moins de textes, des images</li> <li>moins de détours, passer à l’essentiel</li> <li>moins de <a href="https://nicolasfriedli.ch/blog/metadiscours/">métadiscours</a>, plus de concret</li> <li>moins de fonctions, des fonctions utiles</li> <li>moins de graphisme, plus de design</li> <li>moins de déco, plus de typo (voir: <a href="https://ia.net/topics/the-web-is-all-about-typography-period">Web Design is 95% Typography</a>)</li> <li>moins de lourdeurs, plus d’efficacité</li> <li>moins d’explications, plus d’émotions</li> <li>moins de «toujours plus de la même chose», du changement (voir: <a href="https://www.lalibre.be/debats/opinions/2019/08/16/pourquoi-il-faut-relire-watzlawick-XGB3ZLOUNVH6VIDXF63BELGFL4/">Pourquoi il faut relire Watzlawick</a>)</li> <li>moins de planification, des faits</li> </ul> Je crois que j’aime bien cette expression, mais si je ne sais toujours pas ce qu’elle signifie. Pour la route, une citation de Terre des hommes d’Antoine de Saint-Exupéry: <blockquote> Il semble que la perfection soit atteinte non quand il n’y a plus rien à ajouter, mais quand il n’y a plus rien à retrancher. Au terme de son évolution, la machine se dissimule.</blockquote></description></item><item><title>Sur le protocole Gemini</title><link>https://nicolasfriedli.ch/blog/gemini/</link><pubDate>Thu, 19 Sep 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/gemini/</guid><description>Mes remarques sur le protocole Gemini qui propose une alternative au web devenu complexe, lourd et qui nous traque en permanence. Les observations de départ sont bonnes, mais le résultat ne me convainc pas. ⚠️ Ce billet ne parle pas du chatbot de Google! <h2 id="premiere-approche">Première approche</h2> Une explication simple (mais avec des d’erreurs): <blockquote> Gemini, c’est un site web très simple, avec des éléments HTML limités, qui demande peu de ressources, respecte votre vie privée et est facile à mettre en œuvre.</blockquote> Parce que dans la réalité, Gemini: <ul> <li>n’est pas sur le web (mais dans un «monde parallèle»)</li> <li>n’est pas codé en HTML (mais dans un Markdown simplifé)</li> <li>n’est pas trivial à mettre en œuvre</li> </ul> Ce passage résume tout le problème. Présenté en une phrase, ça fait rêver. Mais dès que l’on entre dans les détails, ça devient complexe à vulgariser. <h2 id="presentation-de-gemini">Présentation de Gemini</h2> Pour comprendre techniquement Gemini, il faut se rendre à l’adresse: <a href="gemini://geminiprotocol.net/docs/specification.gmi">gemini: //geminiprotocol.net/docs/specification.gmi</a> Clic. Rien ne se passe. Comme Gemini n’est pas le web, le navigateur habituel ne permet pas d’ouvrir la page. Une adresse qui commence par <code>gemini://</code>, ce n’est pas fait pour un navigateur web. Dans Firefox, Safari ou Chrome, il faut choisir une version web du site. Dans le cas présent, cette version <code>https://</code> existe: <a href="https://geminiprotocol.net/docs/specification.gmi">https://geminiprotocol.net/docs/specification.gmi</a> Et là, un site apparaît. Mais pas besoin de le lire pour le moment. <h3 id="un-protocole">Un protocole</h3> Gemini, c’est donc un protocole: <code>gemini://</code>. Un protocole de communication, c’est un ensemble de règles de fonctionnement entre un serveur et un client (ici un navigateur). Les informations qui transitent <code>gemini://</code> sont très limitées pour éviter le flicage, la publicité ciblée, etc. Il vous faudra donc un navigateur spécial capable d’utiliser ce protocole. Par exemple <a href="https://gmi.skyjake.fi/lagrange/">Lagrange</a> en version graphique. Stéphane Bortzmeyer en dit bien plus dans la première partie de: <a href="https://www.bortzmeyer.org/gemini.html">Le protocole Gemini, revenir à du simple et sûr pour distribuer l’information en ligne?</a>. <h3 id="une-syntaxe">Une syntaxe</h3> Gemini, c’est aussi une syntaxe: gemtext. Pour faire simple, c’est un <a href="https://commonmark.org/">Markdown</a> simplifié qui conserve: <ul> <li>des paragraphes sans formatage</li> <li>des listes à puces (non imbriquées)</li> <li>des titres (sur 3 niveaux)</li> <li>des liens (seuls sur une ligne)</li> <li>des citations</li> <li>du texte préformaté</li> </ul> La page transférée, c’est un fichier <code>.gmi</code>, et rien d’autre. Il n’y a pas de feuille de style CSS, pas de JavaScript, pas même de métadonnées (comme une date de publication). Une page, c’est donc un seul fichier envoyé, puis la mise en page sera faite par le navigateur (s’il le souhaite). <h2 id="ce-que-je-retiens-de-gemini">Ce que je retiens de Gemini</h2> Je reprends ces lignes d’une note écrite il y a quelques années, parce que rien n’a vraiment changé. <ul> <li>L’importance du texte sur le web. Le texte est et reste un magnifique véhicule de contenu, surtout quand il est bien structuré par des intertitres. Il peut être lu sur n’importe quel périphérique, agrandi, copié-collé, dit par une synthèse vocale, etc.</li> <li>Les liens sur une seule ligne. L’obligation de proposer des liens sur une ligne (sans autre contenu), valorise l’hypertexte. En les mettant ainsi en valeur, ils sont facilement visibles. Les URL publiées seules incitent à créer des adresses immédiatement compréhensibles. Et on évitera peut-être les terribles: cliquez ici.</li> <li>L’absence de menus. En imposant tous les liens dans le corps de la page (il n’existe rien d’autre que le corps de la page), le rapport entre contenus et pages cibles est valorisé. Les méga menus, palliatifs de mauvaises structures de site, sont bannis de fait.</li> <li>La mise ne page côté client. C’est le navigateur qui esthétise la page, et j’adore ça. Je souhaite que les internautes installent de bonnes polices sur leurs systèmes et configurent leurs navigateurs. Le web aurait tout intérêt à utiliser un peu plus les <a href="https://nicolasfriedli.ch/blog/polices-systeme/">polices déjà installées</a> sur les périphériques.</li> <li>Le retour du vieux web. Après quelques tests de Gemini, je remarque combien il est perturbant de ne pas disposer de moteur de recherche. La navigation se fait de proche en proche; les favoris (bookmarks) reprennent tout leur sens.</li> </ul> <h2 id="pourquoi-gemini-ne-me-convient-pas">Pourquoi Gemini ne me convient pas</h2> Pourtant, après un nouvel essai, je ne suis toujours pas convaincu. J’ai installé un serveur <a href="https://github.com/mbrubeck/agate">Agate</a> en 3 minutes sur un Raspeberry Pi et mis un site en ligne. Et ça fonctionne. Du côté du serveur, la promesse de simplicité est tenue. En revanche, l’installation d’un navigateur n’est pas aussi facile. Sur mon ordinateur Linux, c’est bon. Sur Android et iOS, il n’est pas possible de passer par les outils d’installation «normaux». Faire reposer la complexité sur les internautes ne me convient pas! En naviguant dans l’écosystème Gemini, j’ai trouvé beaucoup de serveurs et navigateurs non maintenus. On a l’impression que tout est en test, comme il y a quelques années. Est-ce que Gemini est vraiment léger? Est-ce que ce site en version Gemini sur mon Raspberry serait plus léger que la version HTML hébergée chez Infomaniak? Est-ce qu’il est vraiment pertinent d’installer un navigateur graphique de plus? Et quand je lis Daniel Stenberg dans <a href="https://daniel.haxx.se/blog/2023/05/28/the-gemini-protocol-seen-by-this-http-client-person/">The Gemini protocol seen by this HTTP client person</a>, je me dis que la simplicité affichée n’est pas la réalité. Quand l’auteur de <a href="https://curl.se/">curl://</a>, un des logiciels les plus utilisés au monde, soulève ce genre de questions, il me semble qu’il faut l’écouter. Dans certains cas, Gemini est aussi un moyen de fuir ses responsabilités. Proposer un site principal pourri, avec du JavaScript inutile partout, des traqueurs et des images qui clignotent. Puis publier une capsule Gemini à côté (avec très peu de contenus) pour afficher sa mesure et sa sobriété. Faire un bon site principal (unique) serait une meilleure idée. Ploum (Lionel Dricot) est une des rares personnes à avoir complètement assumé le passage à Gemini. Il en parle dans <a href="https://ploum.net/2022-12-04-fin-du-blog-et-derniere-version.html">La fin d’un blog et la dernière version de ploum.net</a>. Mais en pratique, c’est bien sa version web que je lis…</description></item><item><title>Notes sur les textes faciles à lire et à comprendre & le langage clair</title><link>https://nicolasfriedli.ch/blog/falc-plain-ia/</link><pubDate>Mon, 02 Sep 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/falc-plain-ia/</guid><description>Des notes et des liens sur les textes faciles à lire et à comprendre (FALC), sur le langage clair (PLAIN) et l’accessibilité (A11Y). Ce billet (ni facile, ni clair&hellip;) sera revu en fonction de mes découvertes et de vos remarques. Certains sujets seront développés dans d’autres articles en fonction de la demande. <h2 id="mise-en-bouche">Mise en bouche</h2> Extrait du Premier chant de l’Art poétique de Nicolas Boileau: <blockquote> Il est certains esprits dont les sombres pensées Sont d’un nuage épais toujours embarrassées; Le jour de la raison ne le saurait percer. Avant donc que d’écrire, apprenez à penser. Selon que notre idée est plus ou moins obscure, L’expression la suit, ou moins nette, ou plus pure. Ce que l’on conçoit bien s’énonce clairement, Et les mots pour le dire arrivent aisément.</blockquote> <h2 id="contenus-en-falc">Contenus en FALC</h2> Voici 2 exemples réussis qui m’ont incité à aller plus loin: <ul> <li>La ville de La Chaux-de-Fonds propose une <a href="https://www.chaux-de-fonds.ch/ecoles-formations/ecole-obligatoire/documents-liens">brochure scolaire d’information aux parents en FALC</a></li> <li>Le Festival de bande dessinée de Lausanne (BDFIL) propose une <a href="https://bdfil.ch/falc/">présentation en FALC</a></li> </ul> Ces deux contenus me paraissent exemplaires. Ils donnent des informations précises et rapides. Je les trouve plus efficaces que les contenus «normaux». <h2 id="pour-demarrer">Pour démarrer</h2> <ul> <li><a href="https://www.unapei.org/publication/linformation-pour-tous-regles-europeennes-pour-une-information-facile-a-lire-et-a-comprendre/">L’information pour tous: Règles européennes pour une information facile à lire et à comprendre</a></li> <li>la conférence <a href="https://www.paris-web.fr/2023/conference/-le-contenu-doit-etre-redige-de-la-maniere-la-plus-claire-et-la-plus-simple-possible-la-question-des-1">Le contenu doit être rédigé de la manière la plus claire et la plus simple possible: les textes dans l’accessibilité numérique</a> donnée par Morgane Hauguel à Paris Web 2023</li> <li>ou celle de MiXiT 2024 par la même Morgane Hauguel: <a href="https://mixitconf.org/2024/ce-que-l-on-concoit-bien-s-ecrit-clairement-les-textes-et-l-accessibilite-numerique">Ce que l’on conçoit bien s’écrit clairement: les textes et l’accessibilité numérique</a></li> <li>le billet <a href="https://blog.whoz.me/non-classe/le-contenu-doit-etre-redige-clairement-retour-sur-la-conference-paris-web-2023/">Le contenu doit être rédigé clairement: retour sur la conférence Paris Web 2023</a> est un excellent complément</li> <li>dans les propositions de liens du billet précédent: <ul> <li><a href="http://www.languefrancaise.cfwb.be/index.php?eID=tx_nawsecuredl&amp;u=0&amp;g=0&amp;hash=7e8d6eebd9532a4185ac73e38cae4507a05048c3&amp;file=fileadmin/sites/sgll/upload/lf_super_editor/publicat/collection-guide/ecrire-pour-etre-lu__interactif_.pdf">Écrire pour être lu. Comment rédiger des textes administratifs faciles à comprendre</a> (Wallonie)</li> <li><a href="https://mcc.gouv.qc.ca/fileadmin/documents/publications/spl/rediger_simplement.pdf">Rédiger&hellip; simplement. Principes et recommandations pour une langue administrative de qualité</a> (Québec)</li> </ul> </li> </ul> <h2 id="analyse-de-lisibilite">Analyse de lisibilité</h2> <ul> <li><a href="https://www.scolarius.com/">Scholarius</a> est un outil gratuit d’analyse de la lisibilité des textes en français</li> <li>Microsoft Word semble propose le <a href="https://fr.wikipedia.org/wiki/Tests_de_lisibilit%C3%A9_Flesch-Kincaid">score Fleisch-Kincaid</a> dans ses statistiques</li> <li><a href="#yoast">Yoast</a> pour WordPress donne d’office un score de lisibilité dans les statistiques de la page</li> </ul> <h2 id="accessibilite">Accessibilité</h2> Les écritures simplifiées font partie du domaine plus large de l’accessibilité. Dans le domaine du web, je considère que l’accessibilité a au moins 4 composantes: <ul> <li>l’accessibilité du contenu (dont on parle sur cette page)</li> <li>la lisibilité du contenu (choix de la police, taille, contraste, interligne, longueur de lignes, etc.)</li> <li>la structure du site (architecture d’information, navigation, complexité des pages, etc.)</li> <li>la technique (validité du code, sémantique des balises HTML, ARIA, etc.)</li> </ul> <h2 id="simplification-par-ia">Simplification par IA</h2> Mes recherches sont en cours suite à la demande d’une administration pour la simplification de certains contenus administratifs. Je ne parle pas ici des questions de confidentialité, des questions écologiques, des problèmes éthiques, etc. <ul> <li> La qualité du travail dépend de qualité des demandes adressées (prompts). Je propose quelques pistes de prompts. </li> <li> Une intelligence artificielle (IA) comme ChatGPT permet de simplifier des textes de manière efficace. Elle est souvent meilleure à la simplification qu’à la génération. Il faut tout faire pour éviter les délires et hallucinations, par exemple ainsi: <pre><code>Il ne faut rien ajouter au contenu de départ. </code></pre> </li> <li> On peut ajouter les règles principales qui doivent être appliquées au texte: <pre><code>Réécrire le texte en langage clair (PLAIN) ou facile à lire et à comprendre (FALC) Passer les phrases à la forme active. S’adresse aux personnes en «vous». Simplifier les mots complexes (ou les expliquer entre parenthèses) </code></pre> </li> <li> Au départ, on peut demander à ChatGPT de calculer le score Fleisch-Kincaid. Puis demander un nouveau calcul en fin de travail. </li> <li> Affiner le travail en cours de route: <pre><code>Passer les énumérations en listes à puces Mettre en gras les idées les plus importantes </code></pre> Et pourquoi pas relancer: <pre><code>Le texte doit être encore plus simple </code></pre> </li> <li> On peut aussi demander des mises en forme: <pre><code>Saut de ligne à la fin de chaque phrase (mais pas de saut de paragraphe) </code></pre> </li> </ul> D’après mes premiers tests, ChatGPT (version gratuite) permet d’excellents résultats. C’est rapide et précis. <h2 id="yoast">Conseils de Yoast</h2> L’extension de référencement Yoast SEO propose un certain nombre de critères de lisiblité. S’ils peuvent favoriser le référencement, certains sont positifs pour l’accessibilité. Notamment: <ul> <li>la structuration de la page par des intertitres</li> <li>la limitation de la longueur des paragraphes</li> <li>la limitation de la longueur des phrases</li> <li>la rédaction à l’actif</li> <li>la réduction du nombre de mots complexes</li> </ul> Je trouve intéressante cette convergence (logique) entre accessibilité et référencement.</description></item><item><title>Notes sur la création d’un site d’urgence</title><link>https://nicolasfriedli.ch/blog/site-urgence/</link><pubDate>Mon, 03 Jun 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/site-urgence/</guid><description>Entre les pannes de serveur, les incertitudes concernant l’approvisionnement énergétique, les pics d’affluence et les catastrophes naturelles, nous avons toutes les raisons de penser qu’il y aura bien une urgence un jour ou l’autre. L’urgence, par définition, comporte sa part d’imprévisible. Mais ce n’est pas une raison pour ne pas s’y préparer. <h2 id="travail-de-max-bock">Travail de Max Böck</h2> Le développeur autrichien Max Böck a déjà très bien balisé le terrain. Je me suis inspiré de ces réflexions et ses solutions pour rédiger ce billet. Je vous conseille en particulier la lecture de ses articles: <ul> <li><a href="https://mxb.dev/blog/hurricane-web/">The Hurricane Web</a> qui pose les problèmes à la suite de l’ouragan Florence</li> <li><a href="https://mxb.dev/blog/emergency-website-kit/">The Emergency Website Kit</a> qui propose une solution technique complète viable</li> </ul> Par la suite, je développe ces thématiques à ma sauce. <h2 id="types-durgences">Types d’urgences</h2> Il me semble qu’il existe 3 types d’urgences dont je vous donne une typologie. <h3 id="crash-du-serveur">Crash du serveur</h3> Votre serveur tombe en panne et votre site n’est plus fonctionnel. L’hébergeur subit une avarie, votre serveur de nom de domaine est cassé, la base de données hébergée chez vous est en panne, etc. Qu’importe, votre site ne peut pas être consulté. En fonction de la réalité du bug, il faudra renvoyer les internautes ailleurs. Dans ce cas, un site d’urgence préexistant est une bénédiction. Il y a déjà un lien à donner aux médias et à publier sur les réseaux sociaux. <h3 id="faiblesse-des-infrastructures">Faiblesse des infrastructures</h3> Les réseaux sont affaiblis. Une grande panne électrique, une inondation ou un ouragan mettent à mal les réseaux. Les internautes consulteront le web avec un faible débit, en grand nombre sur les antennes relais encore fonctionnelles. La légereté du site sera un critère déterminant pour le rendre accessible dans de mauvaises conditions. Un site simple et léger à afficher videra moins rapidement les batteries des utilisateurs et utilisatrices qui peinent à recharger leurs téléphones. <h3 id="affluence-extraordinaire">Affluence extraordinaire</h3> Un nombre exceptionnel d’internautes consulte votre site sur une courte période. Une annonce sanitaire comme celles de la crise du Coronavirus, des résultats d’élections ou l’ouverture d’une billetterie peuvent provoquer un nombre de visites considérable. Les équipes techniques disent souvent que tout est prévu&hellip; mais les sites tombent régulièrement. Ces pics d’affluence sont souvent prévisibles quelques jours ou quelques jours à l’avance. Mais la solution prévue est-elle suffisante? <h3 id="tout-en-meme-temps">Tout en même temps</h3> Ces différents cas peuvent s’accumuler, mieux vaut mettre toutes les chances de son côté. Une grande innodation peut parfaitement faire tomber l’infrastructure locale (il faut arrêter le serveur), affaiblir les réseaux (l’alimentation électrique des relais est coupée) et provoquer un pic d’affluence (toutes les personnes qui subissent les pannes essaient de trouver des informations au même moment). Pour répondre à ce scénario catastrophe, il vaut la peine d’envisager une solution technique radicale. <h2 id="choix-techniques">Choix techniques</h2> Il me semble que la réponse à apporter exige les choix suivants: <ul> <li>réserver un domaine de secours chez un autre prestataire que le domaine courant</li> <li>héberger ses serveurs de nom (DNS) dans une autre région géographique</li> <li>disposer d’un serveur prêt à l’emploi à distance</li> <li>être capable d’administrer le site dans passer par son adresse mail courante</li> </ul> Pour tenir la charge, je conseille: <ul> <li>un <a href="https://nicolasfriedli.ch/blog/site-statique-generateur-hugo/">site statique</a></li> <li>des pages légères</li> <li>la suppression tièrces parties inutiles en cas d’urgence: polices d’écritures distantes, plugins des réseaux sociaux ou images «décoratives», voire l’outil statistique s’il charge le même serveur</li> </ul> Quand une très forte affluence est prévisible, plutôt que de remplacer le site, je propose: <ul> <li>de publier une page statique en tant que page accueil</li> <li>puis de renvoyer au site normal pour la petite proporition d’internautes qui cherche d’autres informations</li> </ul> Je travaille généralement avec Hugo, mais tous les générateurs de sites statiques peuvent convenir, à condition d’un résultat léger. La page peut aussi être créée à la main, dans un éditeur de texte. <h2 id="exemple-de-realisation">Exemple de réalisation</h2> Pour une ville suisse qui prenait ses précaution suite aux incertitudes énergétiques suite à l’invasion russe en Ukraine, j’ai élaboré un site de secours. Avec les servicess de la ville, nous avons pris le temps, paradoxalement, de ne pas travailler dans l’urgence. Le résultat: <ul> <li>un site en ligne (mais volontairement non référencé), dont le nom de domaine est distinct du site principal et réservé chez un autre prestataire</li> <li>une gestion des contenus sur GitHub</li> <li>un hébergement sur le CDN CloudFlare qui peut encaisser d’énormes charges</li> </ul> Au quotidien, ce site existe. Il est utilisé comme système de liens (à la Linktree). Les internautes ne s’aperçoivent pas son potentiel dans les cas particuliers. Quand c’est nécessaire, le site officiel de la ville est basculé sur le site d’urgence (si les DNS fonctionnent encore) ou les liens sont envoyés dans les réseaux sociaux. Un message apparaît avec les informations immédiatement utiles. Il a été activé une fois, pendant quelques heures, pour pallier l’absence du site officiel durant une migration technique. Évidemment, pour que cela fonctionne, il est important que les équipes de communication disposent d’une documentation sérieuse pour prendre en main la solution sans hésitation et en toute confiance. <hr> Je dispose d’une version <a href="https://gohugo.io/">Hugo</a> du site d’urgence de Max Böck qui peut être déployée très rapidement.</description></item><item><title>Améliorer son référencement local</title><link>https://nicolasfriedli.ch/blog/referencement-local/</link><pubDate>Wed, 22 May 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/referencement-local/</guid><description>Lorsque des pages web présentent des lieux patrimoniaux, des institutions, des entreprises et des commerces locaux, il vaut la peine d’aider les moteurs de recherche à les situer géographiquement. On parle alors de référencement local (local SEO) qui est une «sous-discipline» du référencement (SEO). Pour illustrer quelques principes, je prends l’exemple du Temple de Colombier que je vois de ma fenêtre en rédigeant ces lignes. <h2 id="une-adresse-par-page">Une adresse par page</h2> Pour faciliter le référencement de votre page, il est important de présenter une page par adresse. Le regroupement de plusieurs lieux sur une même page est mauvais pour votre référencement. Qu’il s’agisse de lieux de culte ou de succursales administratives importe peu. Le principe 1 lieu = 1 page est utile en plus d’être efficace. Par exemple pour proposer des liens internes au site, pour transmettre une information précise à un contact, pour donner sans équivoque un lieu de rendez-vous. Le titre de la page devrait être identique à celui du nom de l’établissement sur Google Maps. On y parvient en modifiant l’un, l’autre ou les deux. Attention aux adresses qui sont présentes dans le pied de toutes les pages du site et qui peuvent être pénalisantes. Même si les moteurs de recherche analysent bien les pages, c’est toujours une possibilité de confusion. <h2 id="adresse-complete">Adresse complète</h2> Sur la page de présentation d’un lieu ou sa page de contact, il vaut la peine d’ajouter une adresse complète, avec le pays si le nom de domaine ne le mentionne pas. De manière verticale: <pre tabindex="0"><code>nom du lieu rue + numéro NPA + localité pays </code></pre>Ou en ligne: <pre tabindex="0"><code>nom du lieu, rue + numéro, NPA + localité, pays </code></pre>En HTML, il serait juste de baliser le lieu ainsi: <pre tabindex="0"><code>&lt;address&gt; nom du lieu&lt;br&gt; rue + numéro&lt;br&gt; NPA + localité&lt;br&gt; pays &lt;/address&gt; </code></pre><h2 id="illustrations">Illustrations</h2> Je conseille la publication d’au moins 2 photographies, tant sur une page web de présentation que sur une fiche Google Maps. La photographie de l’extérieur permet aux personnes qui connaissent les lieux de s’assurer qu’elles sont sur la bonne page. Elle permet aux internautes qui ne connaissent pas les lieux de s’orienter facilement lors de leur visite. La photographie de l’intérieur permet de se préparer à une visite, de se demander si c’est le bon lieu pour une manifestation, etc. Elle permet, quand l’endroit est fermé, de savoir ce qui se trouve derrière la porte close. <h2 id="horaires-douverture">Horaires d’ouverture</h2> Les horaires d’ouvertures devraient être présents sur toute présentation de bâtiments patrimoniaux, de musées, d’entreprises, etc. Si c’est fermé, il est aussi utile de le dire! Je conseille de présenter les horaires de la manière la plus simple possible. Au besoin, je vous invite à modifier les ouvertures pour gagner en simplicité et en clarté. Par exemple, pour un lieu patrimonial comme le temple que je cite en exemple: <pre tabindex="0"><code>ouvert tous les jours de 8:00 à 18:00 </code></pre><h2 id="modifier-une-fiche-google-maps">Modifier une fiche Google Maps</h2> Il est possible de suggérer des modifications sur une fiche dont on n’a pas la responsabilité. Toute personne qui visite un lieu patrimonial ou culturel peut améliorer sa présentation. Je conseille en particulier de corriger: <ul> <li>le nom du lieu s’il n’est pas clair</li> <li>la catégorie si elle est fausse ou vague</li> <li>les horaires d’ouverture du bâtiment</li> <li>l’adresse ou la position du repère</li> <li>le site web</li> <li>le numéro de téléphone</li> <li>etc.</li> </ul> Si la fiche ne dispose pas d’images, il est bienvenu d’ajouter au moins une photographie extérieure. Elle facilite l’identification de du bâtiment, de l’église, du commerce, du bureau, etc. Et si possible une photographie de l’intérieur. Il est aussi possible de signaler des photos qui ne correspondent pas au lieu. <h2 id="prendre-possession-dune-fiche-google-maps">Prendre possession d’une fiche Google Maps</h2> Toute personne qui a la responsabilité d’un lieu devrait <a href="https://www.google.com/intl/fr_ch/business/">prendre la main sur sa fiche d’établissement</a>. Google My Business le nom de l’interface d’administration des fiches Google Maps. Quand un lieu est déjà visible dans Google Maps, il existe un lien pour revendiquer un établissement. Un contrôle sera effectué pour s’assurer de la légitimité de la demande. La procédure est simple et rapide par téléphone; elle est plus lente par courrier postal. Google My Business ouvre de nouvelles possibilités pour la gestion de contenu. Notamment: <ul> <li>la gestion précise des horaires d’ouverture (y compris les annonces de jours fériés)</li> <li>la publication d’événements</li> <li>une meilleure gestion des catégories</li> <li>plus de possibilités avec les images</li> <li>des interaction avec les internautes</li> <li>la possibilité de préciser les zones desservies</li> </ul> Concernant les horaires d’ouverture, il vaut la peine corriger dès que possible, plutôt que d’attendre qu’une personne devant une porte close propose sa correction (et son commentaire déçu). <h2 id="coherence-des-donnees">Cohérence des données</h2> Pour fonctionner correctement, les moteurs de recherche doivent trouver des données cohérentes entre pages du site web et fiches Google Maps. Ils procèdent par recoupements. Quand un lieu est mal affiché ou semble incomplet, c’est souvent que les informations sur son site «officiel» sont inutilisables. La mise à jour d’informations dans Google Maps ou My Business a un impact sur le référencement local des lieux. La cohérence est particulièrement importante pour: <ul> <li>le nom du lieu et</li> <li>l’adresse postale exacte</li> </ul> Un bon indice de cohérence est l’affichage de pages web directement dans la fiche Google Maps. Si la page de présentation de votre site apparaît en haut de liste, c’est que la correspondance est évidente pour le moteur de recherche. Quand les résultats ne sont pas cohérents, il faut modifier soit le site, soit la fiche Google Maps. Autre exemple, cette <a href="https://www.google.com/search?q=Temple+de+Colombier">recherche du Temple de Colombier</a> fera apparaître à la fois la page du site et la fiche Google Maps. Parfait! <h2 id="proposer-des-liens-reciproques">Proposer des liens réciproques</h2> Sur la page de web de présentation de son site web, je conseille d’ajouter un lien vers Google Maps. Pour faire les choses au mieux: <ul> <li>il vaut la peine de renvoyer au lieu: <a href="https://maps.app.goo.gl/cg27QmcYEoTuH4dy8">Temple de Colombier</a></li> <li>plutôt qu’à son adresse: <a href="https://maps.app.goo.gl/N5sPL2113hBE4u9cA">Rue du Château 3a, 2013 Colombier</a></li> </ul> En cliquant sur les 2 liens, on n’arrive pas exactement au même contenu. C’est particulièrement important si vous souhaitez afficher une carte sur votre site. Sur la fiche Google Maps, il vaut la peine d’ajouter un <a href="https://www.eren.ch/barc/batiments/temple-de-colombier/">lien direct</a> vers le lieu en question. Ou, à défaut, un lien vers le <a href="https://www.eren.ch/barc/">la page d’accueil de l’institution</a> qui a la responsabilité de l’endroit. <hr> Je reçois avec plaisir vos retours d’expériences, vos proposition d’améliorations et vos questions.</description></item><item><title>Lire et relire les classiques du web</title><link>https://nicolasfriedli.ch/blog/lire-classiques-web/</link><pubDate>Sat, 11 May 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/lire-classiques-web/</guid><description>Dans son livre Pourquoi lire les classiques?, Italo Calvino propose 14 thèses pour définir ce qu’est un «classique». Ce <a href="https://www.radiofrance.fr/franceinter/podcasts/les-80-de-nicolas-demorand/pourquoi-lire-les-classiques-4967560">podcast</a> de 80 secondes donne quelques pistes. Il me semble qu’il vaut la peine de faire la même démarche avec des textes importants pour le web. Ils ne sont peut-être plus d’actualité sur certains points techniques, le web est peut-être devenu autre chose que ce qu’il était à l’époque de leur publication, mais ils disent toujours quelque chose de pertinent. Ci-dessous, je vous propose quelques classiques sur le web. Et je vous dit pourquoi ils faut toujours encore les lire. <h2 id="les-idees-de-linventeur-du-web">Les idées de l’inventeur du web</h2> Dans sa note personnelle, <a href="https://www.w3.org/DesignIssues/Principles.html">Principles of Design</a>, Tim Berners-Lee, expose les principes de conception du web dont il est un des inventeurs. Notamment: <ul> <li>la simplicité</li> <li>la modularité</li> <li>le principe de moindre puissance</li> </ul> Ces sujets reviennent périodiquement, quand l’impression que le web devient trop complexe ou trop lourd. Il vaut la peine de lutter contre les excès et revenir à ce texte fondateur pour s’en inspirer. Avec le passage à la version 5 de HTML, d’autres principes de conception ont aussi été rédigés, par d’autres personnes. Le document <a href="https://www.w3.org/TR/html-design-principles/">HTML Design Principles</a> insiste en particulier sur: <ul> <li>l’utilité pour résoudre de vrais problèmes</li> <li>l’interopérabilité (et le refus de toute complexité non nécessaire)</li> <li>l’accès universel (dont l’accessibilité)</li> </ul> Il serait bienvenu que les développeurs et développeuses relisent ces lignes avant de créer des usines à gaz. <h2 id="sur-le-web-independant">Sur le web indépendant</h2> En 1997 déjà, le <a href="https://www.uzine.net/article60.html">Manifeste du Web indépendant</a> dénonçait la publicité agressive, ainsi que le fichage et le ciblage des internautes. La richesse du web se trouvait (et se trouve toujours) dans des milliers de sites indépendants et artisanaux qui ne cherchent pas le profit avant tout. Ce texte est encore plus pertinent aujourd’hui, alors que de grands acteurs cherchent uniquement à capter un maximum de temps d’attention. Nous sommes entrés dans le monde du <a href="https://www.monde-diplomatique.fr/2019/01/ZUBOFF/59443">capitalisme de surveillance</a>. La relecture régulière de ce manifeste est bienvenue. <h2 id="sur-le-design-web">Sur le design web</h2> Dans son texte <a href="https://alistapart.com/article/dao/">A Dao of Web Design</a> (en français: <a href="https://www.pompage.net/traduction/dao">Le tao du design Web</a>), John Allstrop parlait abondamment des feuilles de style. Pour moi, l’élément central était: <blockquote> If you use style sheets properly, to suggest the appearance of a page, not to control the appearance of a page, and you don’t rely on your style sheet to convey information, then your pages will “work” fine in any browser, past or future.</blockquote> On pourrait traduire ces thèses ainsi (je mets en gras): <blockquote> Si vous utilisez les feuilles de style correctement, pour suggérer l’apparence d’une page, mais ne pas contrôler son apparence, et que vous ne comptez pas sur votre feuille de style pour transmettre de l’information, vos pages fonctionneront très bien dans n’importe quel navigateur, passé comme futur.</blockquote> Ce passage est fondamental. Malgré la diversité des périphériques et des formats d’écran, des agences de communication — en fait, des graphistes&hellip; — cherchent toujours à faire des mises en pages au pixel près. C’est parfaitement contraire à l’esprit du web, ça coûte très cher et c’est souvent peu pérenne ni efficace. J’essaie d’appliquer ce principe dans mon billet sur l’<a href="https://nicolasfriedli.ch/blog/polices-systeme/">utilisation des polices système</a>. <h2 id="essence-dune-page-ou-dun-site-web">Essence d’une page ou d’un site web</h2> Certaines pages simples ont été mises en ligne. En premier lieu <a href="https://justinjackson.ca/words.html">This is a web page</a> et sa traduction <a href="https://justinjackson.ca/words_fr.html">Ceci est une page Web</a>. Le web, ce sont simplement des mots qui s’ajoutent les uns aux autres pour former des contenus pertinents. J’avais été passionné à ma première lecture de cette page. L’auteur l’a rédigée, je l’ai lue, c’est la magie du web. Point. D’autres ont publié des mini sites (d’une seule) page comme <a href="https://motherfuckingwebsite.com/">This is a motherfucking website</a>. Il a été complété par d’autres, par exemple <a href="http://bettermotherfuckingwebsite.com/">This is still a motherfucking website</a> et <a href="https://perfectmotherfuckingwebsite.com/">This is the final motherfucking website</a>. Sur un ton satirique et grossier, ces personnes ont jeté des pavés dans la mare d’un web qui se perd dans des raffinements techniques et esthétiques. C’est délicieux. <h2 id="ce-qui-est-vraiment-utile">Ce qui est vraiment utile</h2> Le développeur autrichien Max Böck a publié <a href="https://mxb.dev/blog/hurricane-web/">The Hurricane Web</a>. Lors de l’ouragan Florence, il est devenu difficile de consulter le web; des infrastructures étaient hors service et recharger son téléphone n’était pas une évidence. La National Public Radio a proposé <a href="https://text.npr.org/">ses actualités en pur texte</a>. Au final, cette page est aussi bonne, sinon meilleure, que le site normal. Avec son <a href="https://mxb.dev/blog/emergency-website-kit/">The Emergency Website Kit</a>, Max Böck a proposé un outil clé en main pour publier un site d’urgence minimal et performant. Il a présenté les idées principales dans une conférence web; la vidéo est disponible dans son article. J’ai souvent consulté cette page, notamment lorsque j’ai élaboré un site d’urgence pour une ville suisse. Dans <a href="https://shkspr.mobi/blog/2021/01/the-unreasonable-effectiveness-of-simple-html/">The unreasonable effectiveness of simple HTML</a>, Terence Eden donne un exemple vécu de pertinence d’un web simple pour des personnes en situation de précarité. <h2 id="sur-lecoconception">Sur l’écoconception</h2> L’article <a href="https://solar.lowtechmagazine.com/2018/09/how-to-build-a-low-tech-website/">How to Build a Low-tech Website?</a> détaille la création et la mise en œuvre d’un site alimenté par une solution technique minimale. Une de ses originalités, il fonctionne à l’énergie solaire et peut parfaitement tomber en rade si le temps est mauvais durant une longue période. Le fond de page indique la charge des batteries au moment de la consultation! Une version française existe: <a href="https://solar.lowtechmagazine.com/fr/2018/09/how-to-build-a-low-tech-website/">Comment créer un site web basse technologie</a>. <h2 id="et-aussi">Et aussi</h2> Je vais peut-être ajouter d’autres catégories ou d’autres sites. En attendant, je cite ces autres classiques qui comptent: <ul> <li><a href="https://brutalist-web.design/">Guidelines for Brutalist Web Design</a></li> <li><a href="https://ploum.net/comment-jai-appris-a-ne-plus-men-faire-et-a-aimer-le-web/index.html">Comment j’ai appris à ne plus m’en faire et à aimer le Web</a></li> <li><a href="https://ploum.net/2023-06-15-merdification.html">De la merdification des choses</a></li> <li><a href="https://matthiasott.com/articles/into-the-personal-website-verse">Into the Personal-Website-Verse</a></li> </ul> Bonnes lectures! <hr> Le site <a href="https://esif.dev/">Educational Sensational Inspirational Foundational</a> de Zach Leatherman propose une sélection d’articles mis en ligne entre 1998 et 2023. Certains sont techniques, d’autres plus réflexifs, mais tous gardent une belle actualité. Quelques-uns sont cités sur cette page.</description></item><item><title>Croissance organique d’un site web</title><link>https://nicolasfriedli.ch/blog/croissance-organique/</link><pubDate>Wed, 01 May 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/croissance-organique/</guid><description>Partir de rien pour créer un site web peut être une démarche difficile. La «solution» est trop souvent la reprise d’un organigramme pour créer une première structure qu’il faudra ensuite remplir. Mais un organigramme est ce qui définit — comme son nom l’indique — l’organisation interne. Savoir comment quelque chose fonctionne est rarement ce qui intéresse les internautes en premier lieu. Savoir ce que l’organisation produit d’utile est le plus important. C’est ce qui est recherché dans la vie réelle, comme en attestent les requêtes dans les moteurs de recherche. Dans sa conférence <a href="https://www.writethedocs.org/videos/portland/2021/always-complete-never-finished-daniele-procida/">Always complete, never finished</a>, Daniele Procida propose de faire grandir un corpus documentaire de manière organique. <h2 id="traduction">Traduction</h2> Le titre de la conférence, repris d’un slogan, signifie évidemment: <blockquote> Toujours entier, jamais terminé.</blockquote> Mais pour s’approcher de l’esprit de la chose, il faudrait plutôt traduire par: <blockquote> Toujours cohérent, jamais terminé.</blockquote> Daniele Procida prend l’exemple de la croissance d’une plante. À n’importe quelle étape de sa croissance, un haricot est un haricot. Même s’il n’est jamais terminé, il ne manque jamais rien. En tout temps, la plante est complète et cohérente. <h2 id="problemes-dun-plan">Problèmes d’un plan</h2> Le même auteur a proposé le cadre de travail Diataxis. Ce qu’il ajoute dans sa conférence, c’est que ce concept est souvent compris comme un plan. Mais il n’a jamais été conçu comme tel. Le problème d’un plan ou d’une hiérarchie, c’est qu’il impose une masse de pages à remplir. Pour reprendre l’image organique, on pourrait dire qu’un plan, c’est un arbre de très grande taille, mais sans aucune feuille. Ce corpus de pages sera peu utile avant d’être terminé. C’est un peu le principe du tout ou rien. Plus on envisage un grand site, plus on estime le plan nécessaire. Alors qu’au contraire, il faudrait le laisser croître naturellement. Un plan n’est jamais nécessaire à cause de la taille prévue d’un site. Un plan est «nécessaire» uniquement pour rassurer celles et ceux qui sont en charge du projet. Ce qu’affirme Daniele Procida, c’est que faire le travail est la partie facile. La partie difficile, c’est de savoir quoi faire. Avec un plan, on se donne tellement de travail à faire que l’on ne sait pas comment avancer, que l’on se démoralise. Et, en fin de compte, on ne fait rien. <h2 id="methode">Méthode</h2> Avec la méthode de la croissance organique, il est toujours assez simple de passer à l’étape suivante. Le travail est toujours adapté à la taille actuelle du corpus. Quand je décide d’avancer, je choisis quelque chose de petit (un paragraphe ou une page) et je l’améliore. Je le reformule, je supprime l’inutile, j’ajoute le nécessaire. Si ce «quelque chose» devient trop grand, je le divise en unité plus petite (une nouvelle structure interne à la page, de nouvelles pages, une nouvelle section du site). Toute la méthode est là. C’est sa force et sa faiblesse. Le plus difficile, ce n’est pas d’intégrer cette méthodologie, mais de s’y tenir. En raisonnant ainsi, on ne pense plus en termes de solutions ou de grands projets, mais d’amélioration continue. Les moments de réflexions de fond sont plus rares, laissant la place à de petites progressions, régulières et utiles. <h2 id="avantages-dune-croissance-organique">Avantages d’une croissance organique</h2> L’avantage de la croissance organique sur les plans et les organigrammes, c’est qu’elle ne met pas l’accent sur ce qui manque. On a tous parcouru des sites avec de grands menus… mais plein de pages en construction. En procédant ainsi, on crée de la frustration, tant pour les internautes que pour les responsables de la publication. Alors que quand une chose manque (encore), mais que cette lacune n’est pas mise en évidence, elle ne pose pas de problèmes. C’est seulement une lacune temporaire. Pour que cela fonctionne, il faut publier tôt et souvent. Pas besoin d’attendre qu’une page soit parfaite, il suffit qu’elle soit acceptable. Elle sera améliorée dans la durée. Corollaire: les améliorations se feront aussi en connaissance des retours reçus. C’est un travail ancré dans la réalité du terrain plutôt que caché dans les secrets des bureaux. <h2 id="strategie--programme">Stratégie &amp; programme</h2> Quand des responsables de sites veulent aller trop vite et plonger dans des structures complexes, je fais tout pour les faire adopter une croissance organique. Le plan a beau être superbe, on se perdra en route. Ensemble, nous prenons alors le contenu d’une page, nous l’améliorons, puis nous la séparons en plusieurs pages. Ainsi, le principe de la croissance organique a déjà été expérimenté avec succès. Nous parlons alors de stratégie de croissance et supprimons toute idée de programme. Je leur cite quelques phrases de Introduction à la pensée complexe d’Edgar Morin: <blockquote> La notion de stratégie s’oppose à celle de programme. Un programme, c’est une séquence d’actions prédéterminées qui doit fonctionner dans des circonstances qui en permettent l’accomplissement. Si les circonstances extérieures ne sont pas favorables, le programme s’arrête ou échoue. […] la stratégie, elle, élabore un ou plusieurs scénarios. Dès le début, elle se prépare, s’il y a du nouveau et de l’inattendu, à l’intégrer pour modifier ou enrichir son action.</blockquote> Parce que le nouveau et l’inattendu, ça arrive tous les jours, dans le domaine du web comme ailleurs. Alors on me dit que c’est très bien, que l’on peut procéder par croissance organique. Puis quelqu’un se lève et demande qui crée le plan pour la prochaine rencontre. <hr> Après la publication de ce billet, j’ai reçu des commentaires. Ils appellent ces remarques: <ul> <li>L’idée de «publier tôt et souvent» est la bonne. J’aurais pu garder ce brouillon dans mes tiroirs durant des semaines, le relire, le corriger, mais je n’aurais pas eu l’apport des retours externes.</li> <li>L’idée de «reformuler, supprimer l’inutile et ajouter le nécessaire» est celle que j’utilise pour faire évoluer cette page</li> <li>J’ajoute ci-dessous un passage sur le développement logiciel.</li> </ul> <hr> <h2 id="developpement-logiciel-agile">Développement logiciel agile</h2> C’est à dessein que je n’avais pas parlé de développement logiciel ou de documentation technique dans mon premier jet de cette page. Pourtant, un commentaire sur les <a href="https://fr.wikipedia.org/wiki/M%C3%A9thode_agile">méthodes agiles</a> était bienvenu. Il existe des traits communs entre la croissance organique et le développement. Dans le <a href="https://agilemanifesto.org/iso/fr/manifesto.html">Manifeste pour le développement agile de logiciels</a>, on trouve notamment: <blockquote> L’adaptation au changement plus que le suivi d’un plan.</blockquote> Le développement agile insiste beaucoup sur les interactions dans les équipes de développement et avec les clientes et clients. Alors que, dans l’absolu, une croissance organique de site peut être réalisée par une personne seule, y compris pour un site personnel. Ce qui retient mon attention en relisant le manifeste, c’est: <blockquote> Un logiciel opérationnel est la principale mesure d’avancement.</blockquote> C’est un critère fondamental. À toutes les étapes de son développement, un logiciel doit fonctionner (ou, du moins, le code doit compiler). Reprise dans le domaine de la création de sites, c’est l’idée qu’en tout temps un site est complet, cohérent, utile. Le problème d’un site bourré de pages affichées comme «en construction» est qu’il peut être en ligne et donner l’impression de fonctionner. Cette tolérance est malheureusement source de beaucoup de problèmes. Alors qu’une erreur de code empêche simplement la compilation, une page vide de sens ne retourne aucun message d’erreur.</description></item><item><title>Garanti sans ChatGPT (ou pas)</title><link>https://nicolasfriedli.ch/blog/garanti-sans-chatgpt/</link><pubDate>Wed, 24 Apr 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/garanti-sans-chatgpt/</guid><description>Ce site est rédigé par Nicolas Friedli et non par ChatGPT (ou une autre intelligence artificielle). Je pourrais le préciser en bas de page, comme de nombreux sites qui se déclarent not by AI. Toutefois, je ne suis pas certain de la pertinence de la mention et j’y renonce. <h2 id="seul-le-resultat-compte">Seul le résultat compte</h2> Il me semble que ce qui plaît dans les initiatives sans intelligence artificielle, c’est l’aspect artisanal et humain de la chose. Mais le contenu humain n’est pas toujours meilleur que le produit d’une machine. Mettre ses mains dans le pétrin ne signifie pas encore que le pain sera bon. Ce que je veux, c’est du bon pain. C’est surtout très nostalgique, comme pour s’accrocher encore un peu à un monde que l’on comprenait. J’y vois l’idée que le contenu «maison» sera meilleur que sa version industrielle. On a bien envie d’y croire, mais il faudrait aussi tester à l’aveugle. Un discours de fin d’année plein de références personnelles est bien mieux que celui qu’aurait écrit ChatGPT. Mais pour ce bon discours, combien d’autres médiocres, pas plus intéressants que ce qu’auraient produit des intelligences artificielles? Le site <a href="https://notbyai.fyi/">not by AI</a> propose d’ajouter un badge qui atteste de la production humaine des contenus. Dans un passage un peu caché du site, je lis (traduction DeepL): <blockquote> Sans professionnels formés ou détecteurs d’IA (intelligence artificielle), il est presque impossible de distinguer votre contenu humain du contenu généré par l’IA. L’utilisation des badges not by AI aide votre public à reconnaître votre approche centrée sur l’humain afin qu’il comprenne que votre contenu vient vraiment de vous et n’est pas copié-collé à partir d’une IA générative comme ChatGPT, Claude ou Gemini.</blockquote> En tant que personnes humaines, vous comprenez toute la subtilité de la chose&hellip; Le pain de boulangerie a le même goût que celui de <a href="https://fr.wikipedia.org/wiki/L%27Aile_ou_la_Cuisse">l’usine Tricatel</a> d’en face. Il faut donc rappeler aux acheteurs et acheteuses qu’il est artisanal (sans être meilleur). On a envie de sourire de la démarche, mais tout n’est pas si simple. <h2 id="citer-ses-sources">Citer ses sources</h2> J’ai appris, durant mes études, à toujours citer mes sources. Je fais de même sur le web par des liens contextuels qui renvoient aux contenus utilisés. Je respecte les licences. Et là, c’est le drame&hellip; Avec ChatGPT, dans son modèle gratuit, impossible de connaître les sources utilisées. Un LLM (<a href="https://fr.wikipedia.org/wiki/Grand_mod%C3%A8le_de_langage">grand modèle la langage</a>) utilise des quantités hallucinantes de données pour se construire, mais ne nous dit jamais d’où provient quoi. Alors les soucis légaux débarquent, parce que <a href="https://sebsauvage.net/links/?pvvJZA">ces outils utilisent des données sous droits d’auteur</a>. On n’en est qu’aux débuts. De ce point de vue, not by AI a raison (toujours DeepL pour la traduction): <blockquote> L’intelligence artificielle (IA) est formée à partir de contenus créés par l’homme. Si les humains cessent de produire de nouveaux contenus et s’appuient uniquement sur l’IA, les contenus en ligne dans le monde entier risquent de devenir répétitifs et stagnants.</blockquote> Quand on ne cite plus ses sources et que l’on construit tout à partir de l’existant, on produit quelque chose sans originalité et, peut-être, dans l’illégalité. Il faudrait alors plaider pour une initiative inverse: que toutes les pages rédigées à coup de ChatGPT (et autres outils similaires) le déclarent. Cela ne fait pas des contenus générés automatiquement des mauvais contenus en soi, mais cela signifie qu’ils sont à la fois «mainstream» et potentiellement problématiques du point de vue du droit. C’est une excellente raison de ne pas utiliser ChatGPT pour générer des contenus prétendument nouveaux. Il y en a quelques autres. <h2 id="bonnes-raisons-dajouter-une-mention-not-by-ai">Bonnes raisons d’ajouter une mention not by AI</h2> Une personne qui souhaite mettre en avant ses capacités rédactionnelles aura tout intérêt à signaler que c’est bien elle qui écrit, et non une intelligence artificielle. Lorsque le résultat doit être absolument fiable (par exemple dans des cas de textes juridiques, des règlements, etc.), il vaut le coup d’écrire not by IA, mais il faut alors assumer les pages publiées comme des références validées. Finalement, je concevrais très bien de préciser not by IA sur un site qui cherche à limiter son empreinte écologique. À quoi bon proposer un site simple et léger si l’artillerie lourde est utilisée pour produire des textes de quelques paragraphes qui peuvent être écrits en peu de temps. Vous avez compris, je ne m’engage à rien au sujet de l’utilisation de ChatGPT ou toute autre intelligence artificielle. Je ne les utilise pas pour produire les contenus de ce site. Je n’ai pas l’intention de les utiliser à l’avenir, mais c’est une possibilité que je refuse de m’interdire par principe. Le «not-by-IA-washing» ne m’intéresse pas. C’est une démarche marketing avant tout. Et ce sont les contenus qui comptent. <hr> Celles et ceux qui souhaitent démontrer leur maîtrise de ChatGPT pourraient mettre une bannière inverse. Quelque chose comme: «les textes de ce site ont été entièrement rédigés par une IA». Il vaudrait alors la peine d’insister sur sa capacité à écrire des «prompts» (les «demandes» à l’IA) utiles et efficaces.</description></item><item><title>Utiliser des polices système</title><link>https://nicolasfriedli.ch/blog/polices-systeme/</link><pubDate>Mon, 22 Apr 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/polices-systeme/</guid><description>L’utilisation de polices du système d’exploitation (system font stack) permet une cohérence graphique sans téléchargements. Mais la diversité des plateformes rend le travail relativement complexe. <h2 id="problematique">Problématique</h2> Dans son billet <a href="https://pimpmytype.com/web-safe-fonts/">Are Web-Safe Fonts still relevant in 2024?</a>, Oliver Schöndorfer se demande si l’utilisation de polices système universelles est toujours pertinente aujourd’hui. Sa question est bonne, parce que les systèmes d’exploitation sont nombreux. Toutefois, sa réponse est imparfaite. Il part du fait qu’il n’existe plus de polices présentes sur tous les périphériques. Arial et Times New Roman avaient une disponibilité de virtuellement 100%, ce n’est plus vrai pour le système Android. Les questions suivantes devraient toujours être posées: <ul> <li>Est-ce qu’une police précise est nécessaire pour ce site web?</li> <li>Est-ce qu’un choix de polices proches est suffisant?</li> <li>Faut-il laisser le choix de la police au système d’exploitation?</li> <li>Faut-il laisser le choix de la police aux internautes?</li> <li>Est-ce que les enjeux d’écologie et de performance permettent de télécharger plusieurs fichiers?</li> </ul> <h2 id="necessite-dune-police-precise-corporate-identity">Nécessité d’une police précise (corporate identity)</h2> Quand une police doit être utilisée, il n’y a pas d’autre choix que de demander au navigateur de la télécharger. En pratique, ce sont plusieurs fichiers qui vont être envoyés, en général: <ul> <li>une police «normale»</li> <li>une police grasse</li> <li>une police italique</li> <li>une police grasse italique</li> </ul> Les fichiers seront mis à disposition par une directive CSS <code>@font-face</code> et ceux qui sont nécessaires seront téléchargés. Lorsque ce cas se présente, il fait veilleur à une optimisation des fichiers et des chargements: <ul> <li>bon format de fichier (<code>woff2</code>)</li> <li>blocage ou non de l’affichage (<code>font-display</code>)</li> <li>préchargement (<code>preload</code>)</li> <li>suppression des jeux de caractères inutiles</li> <li>une gestion du cache pertinente (<code>immutable</code>)</li> <li>utilisation de polices variables si disponibles</li> </ul> En général, il devrait être possible de s’en tirer autour de 100kB pour un jeu de police complet. Pour en savoir plus sur cette thématique complexe, le billet <a href="https://www.zachleat.com/web/comprehensive-webfonts/">A Comprehensive Guide to Font Loading Strategies</a> de Zach Leatherman est un point de départ précieux. Quand ce chargement permet de répondre à une contrainte précise, c’est très bien. Mais je reste surpris par le nombre de sites qui téléchargent de tas de fichiers qui sont sans rapport avec la charte graphique de l’entreprise ou l’institution. Dans ces cas là, il y aurait peut-être mieux à faire. <h2 id="choix-de-polices-system-font-stack">Choix de polices (system font stack)</h2> Une font stack est une liste de polices possibles. Autrement dit, le site suggère des polices au navigateur; il choisit la première de la liste disponible localement et l’affiche. Le site <a href="https://modernfontstacks.com/">Modern Font Stacks</a> propose des «piles de polices» toutes faites qui fonctionnent bien partout. Par exemple: <pre tabindex="0"><code>font-family: Inter, Roboto, &#34;Helvetica Neue&#34;, &#34;Arial Nova&#34;, &#34;Nimbus Sans&#34;, Arial, sans-serif; </code></pre>Ce qui se passe: <ul> <li>Inter s’affiche si elle a été installée par l’internaute.</li> <li><del>Sinon Roboto s’affiche sur Android (où elle est toujours disponible). Ou ailleurs si elle a été installée.</del> En fait, Roboto s’affiche sur Android par <code>sans-serif</code> (dernier point ci-dessous).</li> <li>Sinon Helvetica Neue s’affiche sur Apple (où elle est toujours disponible). Ou ailleurs si elle a été installée.</li> <li>&hellip;</li> <li>Sinon Arial s’affiche sur Windows (où elle est toujours disponible). Ou presque partout ailleurs.</li> <li>Finalement, si aucune n’est disponible, c’est la police de substitution, choisie par le navigateur ou l’internaute qui apparaît.</li> </ul> Franchement, il me parait acceptable d’afficher une des polices sans empattement présentes, que les internautes connaissent. Dans tel cas, il n’y a aucune bande passante utilisée et aucune latence. Pour tous les textes courants, c’est un excellent choix. <h2 id="polices-universelles-web-safe-fonts">Polices universelles (web safe fonts)</h2> Comme Oliver Schöndorfer le signale, Arial et Times New Roman ne sont plus disponibles partout. Mais il est facile de contourner le problème. Si l’idée est d’obtenir simplement une police banale sans empattement, la directive CSS suivante suffit: <pre tabindex="0"><code>font-family: sans-serif; </code></pre>Et avec empattement: <pre tabindex="0"><code>font-family: serif; </code></pre>Cela va peut-être manquer un peu d’originalité, mais c’est léger. Si les internautes n’ont pas configuré leur navigateur n’importe comment, ce sera très lisible. J’estime que c’est toujours une bonne solution. Les polices universelles aujourd’hui ne sont plus identifiables par un nom précis; ce sont simplement les écritures par défaut du système d’exploitation. <h2 id="la-police-dinterface-system-ui">La police d’interface (system-ui)</h2> Depuis quelque temps, il est possible d’utiliser une police spéciale. C’est celle du système d’exploitation. Elle ne peut pas être modifiée dans le navigateur par les internautes, contrairement aux précédentes. C’est tout simple: <pre tabindex="0"><code>font-family: system-ui, sans-serif; </code></pre>La directive <code>sans-serif</code> reste à disposition si le navigateur &ndash; cas très rare &ndash; ne comprenait pas la directive <code>system-ui</code>. Avec une police système, c’est une écriture parfaitement en phase avec le système utilisé qui sera choisie. C’est celle de l’interface, d’où UI (user interface). Au final, l’apparence laisse encore moins d’originalité que <code>sans-serif</code>, mais ce sont souvent des polices de grande qualité qui sont utilisées. Le résultat est excellent. <h2 id="peripheriques-apple">Périphériques Apple</h2> Les périphériques Apple ont la particularité d’utiliser des directives spéciales comme la police UI. Sur les systèmes récents, c’est l’excellente police San Francisco qui sera choisie. Elle est élégante et dispose d’une large gamme de graisses et des tailles optiques. Franchement, il n’y a pas à hésiter à utiliser: <pre tabindex="0"><code>font-family: ui-sans-serif, sans-serif; </code></pre>La même logique existe pour les autres types de polices. Donc, pour des périphériques Apple: <pre tabindex="0"><code>html { font-family: ui-sans-serif, sans-serif; } blockquote, h1, h2, h3 { font-family: ui-serif, serif; } code, pre { font-family: ui-monospace, monospace; } </code></pre>Tout le texte est sans empattement, sauf les citations et les titres avec empattement et le code en chasse fixe. <h2 id="peripheriques-android-et-linux">Périphériques Android et Linux</h2> Pour Android, Roboto est toujours disponible. Elle s’affiche par les directives <code>system-ui</code> ou <code>sans-serif</code>, mais pas par <code>Roboto</code>! Pour Linux, Roboto est presque toujours disponible et Noto Sans aussi. Donc, pour le corps du texte: <pre tabindex="0"><code>html { font-family: system-ui, sans-serif; } Et pour les citations et intertitres: blockquote, h1, h2, h3 { font-family: &#34;Noto Serif&#34;, serif; } Et pour le code: code, pre { font-family: &#34;Noto Sans Mono&#34;, &#34;Roboto Mono&#34;, monospace; } </code></pre>Attention, avec Linux, il est possible de modifier <code>system-ui</code>, ce qui ne donne aucune certitude quant à la police choisie. Mais on peut supposer que les internautes utilisent des fontes lisibles sur leur système. <h2 id="peripheriques-windows">Périphériques Windows</h2> Pour Windows, c’est un peu plus complexe, car différentes versions, avec des polices différentes, cohabitent. Mais il serait possible d’utiliser des polices «universelles», par exemple: <pre tabindex="0"><code>html { font-family: Arial, sans-serif; } blockquote, h1, h2, h3 { font-family: Georgia, &#34;Times New Roman&#34;, serif; } code, pre { font-family: Consolas, monospace; } </code></pre>Mon souci avec Windows, c’est que je n’aime pas Segoe UI pour les titres. Et c’est la police <code>system-ui</code> pour certaines versions du système. Mais Segoe UI est meilleure qu’Arial pour le texte. J’essaie de tirer cela au clair dans ma proposition. <h2 id="proposition">Proposition</h2> Évidemment, il faut que la feuille de style CSS fonctionne pour tous les systèmes. En haut de la pile, il est possible d’ajouter des polices que je souhaiteras voir afficher. Je pourrais utiliser, pour un site comme le mien, quelque chose comme: <pre tabindex="0"><code>html { font-family: &#34;Fira Sans&#34;, &#34;Public Sans&#34;, ui-sans-serif, Inter, Roboto, system-ui, sans-serif; } code, pre { font-family: &#34;JetBrains Mono&#34;, &#34;Hack&#34;, ui-monospace, &#34;Roboto Mono&#34;, Menlo, Consolas, monospace; } </code></pre>La logique est: <ul> <li>les premières lignes suggèrent des polices</li> <li>puis une directive règle le cas pour tous les périphériques Apple</li> <li>puis des propositions pour la majorité des Linux</li> <li>puis on laisse le système se débrouiller</li> </ul> En adoptant une telle démarche, on prend une posture de suggestion de présentation. J’en parle dans <a href="https://nicolasfriedli.ch/blog/lire-classiques-web/#sur-le-design-web">Lire et relire les classiques du web</a>. <h2 id="en-conclusion">En conclusion</h2> Il existe aujourd’hui d’autres manières de concilier écologie, esthétique et performance qu’en utilisant des polices dites «web safe» comme Arial et Times New Roman. Entre les polices système (<code>sans-serif</code>, etc.), les nouvelles directives (comme <code>system-ui</code>), je pense qu’il n’est vraiment pas nécessaire d’envoyer systématiquement des fichiers à chaque internaute. Sur ce site, malgré l’utilisation de chasse fixe (code) dans le texte, je renonce à l’idée d’envoyer des polices. Les déclarations exactes de ma feuille de style sont toujours disponibles chez GitHub dans le fichier <a href="https://github.com/nfriedli/nicolasfriedli.ch/blob/main/assets/css/all.css"><code>all.css</code></a>. <hr> J’attends avec impatience l’arrivée de la directive <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/@media/prefers-reduced-data"><code>prefers-reduced-data</code></a> qui permettra(it) de gérer les choses beaucoup plus simplement. <hr> À ma connaissance, la police la plus légère actuellement disponible est <a href="https://vercel.com/font">Geist</a>. Un seul fichier permet de remplacer les 4 variations dont je parlais ci-dessus. Une fois passée par <a href="https://github.com/zachleat/glyphhanger">Glyphhanger</a>, elle pèse environ 20 kB. Toutefois, la version elle ne dispose pas d’un vrai italique, mais d’une version oblique. <hr> Ajout du 30 avril 2024. Les polices système (San Franciso, Segoe UI et Roboto) sont excellentes pour les personnes dyslexiques. Elles sont bien meilleures que plusieurs polices prétendument optimisées. Je vous conseille vivement la lecture et le visionnage de <a href="https://pimpmytype.com/dyslexia-fonts/">Dyslexia friendly fonts: Are they any good?</a>.</description></item><item><title>Introduction aux flux RSS et Atom</title><link>https://nicolasfriedli.ch/blog/rss-introduction/</link><pubDate>Fri, 12 Apr 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/rss-introduction/</guid><description>Les flux RSS (Really Simple Syndication) existent depuis 25 ans. Ils sont simples, efficaces et fiables, mais ils restent méconnus par beaucoup d’internautes pour qui c’est un truc de spécialistes. Deux remarques introductives: <ul> <li>prendre en main les flux RSS et constituer une première liste de sites prend un peu de temps (mais permet d’en gagner beaucoup par la suite)</li> <li>je ne ferai pas de distinction entre RSS et Atom (Atom Syndication Format) qui sont identiques à l’utilisation</li> </ul> <h2 id="ca-sert-a-quoi">Ça sert à quoi</h2> Pour commencer ce petit parcours, j’ai demandé à ma femme <a href="https://dianefriedli.ch/">Diane Friedli</a> de me dire spontanément comment elle définirait les RSS: <blockquote> Les flux RSS, ça te permet de savoir qu’il y a des nouveautés sur les sites qui t’intéressent sans avoir besoin d’aller voir chacun d’eux.</blockquote> Ma définition, un peu plus complète, mais moins limpide: <blockquote> Les flux RSS permettent de s’abonner aux nouvelles publications de sites choisis. Ils sont consultés dans un logiciel spécifique (agrégateur) qui permet de gérer ses lectures. Les nouveautés s’affichent de manière chronologique ou selon un classement personnel. C’est une méthode de consultation fiable, rapide, écologique et anonyme.</blockquote> Pour répondre à la question spécifique de l’utilité: <blockquote> Les flux RSS permettent d’organiser facilement une veille personnalisée et systématique.</blockquote> <h2 id="comment-ca-se-presente-pratique">Comment ça se présente (pratique)</h2> Voici ce qui se passe quand je me connecte à mon agrégateur de flux: <ul> <li>je vois la liste des nouvelles publications depuis ma dernière connexion</li> <li>l’instant, j’ai 47 nouvelles publications issues des 340 sites j’ai décidé de suivre</li> <li>ces nouveautés sont réparties dans des rubriques (selon ma propre organisation): <ul> <li>4 billets publiés sur des blogs protestants</li> <li>2 dans ma rubrique culture</li> <li>2 dans ma rubrique web en français</li> <li>6 dans ma rubrique consacrée aux médias</li> <li>etc.</li> </ul> </li> <li>je vais les consulter soit de manière globale, soit par rubrique: <ul> <li>je vais parcourir les 32 publications de ma rubrique web en anglais</li> <li>puis les 15 restantes de manière antéchronologique</li> </ul> </li> <li>quand un article m’intéresse, mais que je n’ai pas le temps de le lire, je vais le stocker dans «Lire plus tard»</li> <li>à la fin de ma visite, j’aurai en principe tout lu (sauf les publications à lire plus tard)</li> <li>parfois, je ne fais que survoler des articles (mais je sais de quoi ils parlent et ça me suffit)</li> <li>j’ai aussi la possibilité de laisser des articles non lus pour ma prochaine visite (comme dans une boîte mail)</li> </ul> Autrement dit, ce matin, c’est comme si j’avais parcouru 340 sites pour chercher les (éventuelles) nouvelles publications. Puis que je les avais classées par catégories, puis que je les avais survolées (ou lues). Enfin que j’avais enregistrées celles que je souhaitais conserver pour plus tard en un lieu accessible de tous mes périphériques (ordinateur, téléphone ou tablette). Franchement, nous avons mieux à faire que parcourir des centaines de sites, dont beaucoup n’ont pas de nouveautés depuis hier ou la semaine dernière. Les logiciels font ça mieux que nous. <h2 id="comment-ca-fonctionne-technique">Comment ça fonctionne (technique)</h2> Les flux RSS sont des fichiers qui ne sont pas faits pour être lus directement par vous et moi, mais pour être transformés et affichés par des logiciels comme des agrégateurs. Ce qui fait leur force, c’est qu’ils sont bien codifiés (et peuvent être <a href="https://validator.w3.org/feed/check.cgi?url=https%3A%2F%2Fnicolasfriedli.ch%2Findex.xml">validés</a> comme celui de ce site). Ils ressemblent à quelque chose comme ceci: <pre tabindex="0"><code>titre du site description date de dernière modification lien (page d’accueil) billet de blog 1: titre description (ou contenu complet) date de publication lien ... billet de blog 10: titre description (ou contenu complet) date de publication lien </code></pre>Ce formalisme permet: <dl> <dt>rapidité</dt> <dd>c’est un fichier léger à télécharger et simple à analyser (c’est pourquoi un agrégateur peut vérifier des centaines de sites en quelques secondes)</dd> <dt>écologie</dt> <dd>ce fichier léger minimise les ressources utilisées et il évite de se rendre sur un site web, beaucoup plus lourd, s’il n’y a pas de nouveauté à consulter</dd> <dt>fiabilité</dt> <dd>la lecture d’un fichier bien formaté est beaucoup plus fiable que la consultation humaine d’un site pour découvrir des nouveautés (qui ne sont pas toujours visibles en page d’accueil)</dd> </dl> <h2 id="pourquoi-cest-genial">Pourquoi c’est génial</h2> Comme l’écrivait Thierry Crouzet dans <a href="https://tcrouzet.com/books/la-mecanique-du-texte/">La mécanique du texte</a>: <blockquote> Le RSS est presque trop génial. [&hellip;] Il laisse imaginer un monde où chacun serait sa propre agence de presse, où chacun recevrait les informations sélectionnées par lui. Ce serait en quelque sorte un monde trop beau, et trop peu rentable.</blockquote> Un système tout simple permet de lire de l’actualité sans passer par un moteur de recherche ni par un réseau social. Des sources peuvent être ajoutées ou supprimées en tout temps. Et surtout, la lecture n’est pas polluée par des algorithmes qui: <ul> <li>censurent des contenus (selon des critères souvent douteux)</li> <li>proposent des tris ridicules (ce qui fait réagir est toujours mis en évidence)</li> <li>suggèrent des nouveautés sans arrêt (même quand tout est lu, il ne faut pas que les internautes repartent)</li> </ul> Voilà ce que permettent les flux RSS: <ul> <li>la consultation de ce que je souhaite (et tout ce que je souhaite)</li> <li>la possibilité de trier les contenus selon mes préférences</li> <li>le droit d’arriver au bout de ma liste de lectures (et seulement de celles voulues)</li> </ul> <h2 id="comment-lire-des-fluxrss">Comment lire des flux RSS</h2> Je conseille l’utilisation d’un agrégateur en ligne, parce qu’il permet de reprendre la lecture au même endroit, quel que soit le périphérique utilisé. J’utilise <a href="https://www.inoreader.com/">Inoreader</a> en version pro. C’est à mon avis le meilleur lecteur en termes de possibilités, même si l’interface est parfois un peu tordue. La version basique gratuite permet de suivre jusqu’à 150 sites. Un agrégateur très utilisé est <a href="https://feedly.com/news-reader">Feedly</a>. Je ne le recommande que dans sa version gratuite, limitée à 3 répertoires et 100 sites. J’ai utilisé la version payante il y a quelques années, mais mes tests avec la dernière version Pro+ et son intelligence artificielle ne sont pas concluants. J’ai beaucoup de bons échos de <a href="https://feedbin.com/">Feedbin</a>, un agrégateur simple avec quelques options intéressantes. Je l’ai testé, mais il me manquait quelques possibilités plus pointues. Uniquement en version payante; à prix raisonnable. On peut aussi installer un logiciel sur son propre serveur (par exemple <a href="https://tontof.net/kriss/feed/">KrISS feed</a>), utiliser un logiciel dédié sur son ordinateur (par exemple <a href="https://support.mozilla.org/en-US/products/thunderbird/news-feeds-rss-blogs-and-social-thunderbird">Thunderbird</a>) ou publier des flux RSS dans WordPress (par exemple <a href="https://wordpress.org/documentation/article/rss-block/">RSS Block</a>). <h2 id="pourquoi-cest-irremplacable">Pourquoi c’est irremplaçable</h2> À mon avis, les flux RSS sont irremplaçables: <ul> <li> Ils permettent un abonnement ou un désabonnement complètement anonyme par défaut, alors que les lettres de nouvelles (newsletter) donnent une adresse ou demandent des efforts pour cacher la sienne. Aucune crainte de ne pas pouvoir se désabonner ou de recevoir du spam. </li> <li> Ils permettent une veille exhaustive. Je peux partir 2 semaines en vacances et lire tous les billets publiés en mon absence. C’est presque impossible sur les réseaux sociaux. </li> <li> Ils respectent mes propres règles du jeu. Je peux les trier dans l’ordre souhaité, les filtrer, marquer des articles lus ou non lus, créer des hiérarchies, etc. Des automatismes bien conçus sont souvent meilleurs qui des intelligences artificielles qui ne cherchent qu’à impressionner. </li> <li> La liste des flux auxquels je suis abonné peut être exportée facilement. Je peux la sauvegarder, la partager à d’autres, l’importer dans un autre logiciel, etc. La liberté, c’est de pouvoir changer de plateforme et d’outil librement. </li> <li> La présentation unifiée permet une lecture rapide et agréable, même quand des flux proviennent de sites peu accessibles ou inconfortables. La légèreté des flux permet d’oublier la lenteur des sites qui les produisent. Plutôt que l’originalité, c’est l’efficacité qui compte. </li> </ul> <hr> Dans son excellente newsletter <a href="https://buttondown.email/ownyourweb">Own Your Web</a>, Matthias Ott propose <a href="https://buttondown.email/ownyourweb/archive/issue-09/">Issue 9: We ❤️ RSS</a>. Il vaut la peine de suivre les liens proposés pour approfondir le sujet. Les internautes qui ne maîtrisent pas assez l’anglais auront intérêt à lire au moins l’article <a href="https://timkadlec.com/remembers/2023-02-23-investing-in-rss/">Investing in RSS</a> de Tim Kadlec en traduction automatique. <hr> Cory Doctorow a publié le 16 octobre 2024 un billet de qualité sur les flux RSS comme résistance à la <a href="https://ploum.net/2023-06-15-merdification.html">merdification des choses</a>: <a href="https://pluralistic.net/2024/10/16/keep-it-really-simple-stupid/">You should be using an RSS reader</a>.</description></item><item><title>Configuration d’Hugo</title><link>https://nicolasfriedli.ch/blog/hugo-configuration/</link><pubDate>Fri, 05 Apr 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/hugo-configuration/</guid><description>La configuration d’Hugo est simple quand on part de zéro, mais souvent complexe lorsqu’un thème existant est repris. Il est bon de connaître certains concepts de base pour se débrouiller ensuite. <h2 id="fichier-minimal">Fichier minimal</h2> Hugo a besoin d’un fichier de configuration pour fonctionner. Par défaut, il s’agit de <code>hugo.toml</code> à la racine du projet. L’ancien fichier par défaut était <code>config.toml</code> (qui fonctionne toujours). Le plus petit fichier suffisant en <a href="https://toml.io/en/">TOML</a> (Tom’s Obvious Minimal Language): <pre tabindex="0"><code>baseURL = &#34;https://nicolasfriedli.ch/&#34; title = &#34;Nicolas Friedli&#34; languageCode = &#34;fr&#34; </code></pre>Il pourrait être écrit en <a href="https://yaml.org/">YAML</a> (YAML Ain’t Markup Language): <pre tabindex="0"><code>baseURL: https://nicolasfriedli.ch/ title: Nicolas Friedli languageCode: fr </code></pre>Ou en <a href="http://www.json.org/json-en.html">JSON</a> (JavaScript Object Notation): <pre tabindex="0"><code>{ &#34;baseURL&#34;: &#34;https://nicolasfriedli.ch/&#34;, &#34;title&#34;: &#34;Nicolas Friedli&#34;, &#34;languageCode&#34;: &#34;fr&#34; } </code></pre><h2 id="preference-personnelle-pour-toml">Préférence personnelle pour TOML</h2> J’utilise TOML dans les fichiers de configuration, pour son excellent équilibre entre sa facilité de rédaction et sa fiabilité. YAML pose parfois des problèmes comme le soulignent Ruud van Asseldonk dans <a href="https://ruudvanasseldonk.com/2023/01/11/the-yaml-document-from-hell">The yaml document from hell</a> ou Chris Coyier dans <a href="https://chriscoyier.net/2023/01/27/yaml-json-toml/">Yaml, JSON, Toml</a>. JSON n’est pas un format très agréable à rédiger. Mais il n’est pas prévu pour cela. <h2 id="configuration-specifique-pour-mon-site">Configuration spécifique pour mon site</h2> L’adresse et le titre du site: <pre tabindex="0"><code>baseURL = &#34;https://nicolasfriedli.ch/&#34; title = &#34;Nicolas Friedli&#34; </code></pre>Le code de langue et la langue par défaut (que je configure même sur un site monolingue): <pre tabindex="0"><code>languageCode = &#34;fr&#34; defaultContentLanguage = &#34;fr&#34; </code></pre>Une sécurité si un nom de fichier source comprend un caractère problématique. Ou si j’utilise des taxonomies qui génèrent automatiquement des URL. <pre tabindex="0"><code>removePathAccents = true </code></pre>Je désactive ce que je n’utilise pas. J’ai désactivé les taxonomies, pour éviter de créer des pages de catégories ou de tags sans l’avoir choisi. Il est ainsi possible de renseigner (déjà) des catégories et tags dans les sources, mais de ne pas les afficher (pour le moment). Le fichier robots.txt est écrit à la main, dans <code>/static/</code>. Donc: <pre tabindex="0"><code>disableKinds = [ &#34;taxonomy&#34;, &#34;term&#34;, &#34;robotsTXT&#34;] </code></pre>Le répertoire final est vidé avant compilation. La compilation est toujours complète. Et j’utilise les dates de Git (par exemple pour la dernière modification dans <code>sitemap.xml</code>). Finalement, je ne génère pas de fichier <code>lock</code>. <pre tabindex="0"><code>cleanDestinationDir = true disableFastRender = true enableGitInfo = true noBuildLock = true </code></pre>Je configure un copyright, mon nom et mon mail qui seront repris dans le flux RSS: <pre tabindex="0"><code>copyright = &#34;Creative Commons BY-SA&#34; [params.author] name = &#34;Nicolas Friedli&#34; email = &#34;hello+rss@nicolasfriedli.ch&#34; </code></pre>Pas besoin de statistiques des balises HTML et des attributs <code>class</code> et <code>id</code> utilisés: <pre tabindex="0"><code>[build] writeStats = false </code></pre>Les <code>id</code> des titres <code>h2</code>, <code>h3</code>, etc., sont propres. C’est surtout important quand on génère une table des matières interne à la page: <pre tabindex="0"><code>[markup.goldmark.parser] autoHeadingIDType = &#34;github-ascii&#34; </code></pre>Les fichiers de sortie sont minifiés. Je supprime les attributs par défaut qui ne sont plus utiles en HTML5. Mais je conserve les guillemets et les sauts de lignes par souci de lisibilité. Voici la configuration: <pre tabindex="0"><code>[minify] minifyOutput = true [minify.tdewolff.html] keepDefaultAttrVals = false keepQuotes = true keepWhitespace = true </code></pre>Je décide de générer un RSS global, pour tout le site. Je l’active donc pour la racine, mais pas pour les sections: <pre tabindex="0"><code>[outputs] home = [&#34;HTML&#34;, &#34;RSS&#34;] section = [&#34;HTML&#34;] </code></pre>Finalement, je gère les relations entre billets par taxonomie: <pre tabindex="0"><code>[related] includeNewer = true threshold = 50 toLower = true [[related.indices]] name = &#34;categories&#34; weight = 80 </code></pre>La <a href="https://github.com/nfriedli/nicolasfriedli.ch/blob/main/hugo.toml">version courante</a>, qui peut différer des exemples de cette page, est toujours disponible chez GitHub. <h2 id="pas-de-theme">Pas de thème</h2> Celles et ceux qui connaissent un peu Hugo remarqueront que mon fichier de configuration n’utilise pas de thème: <pre tabindex="0"><code>theme = &#34;monthemehugo&#34; </code></pre>Je n’utilise que le répertoire <code>/layouts/</code> pour mes modèles de pages, mes shortcodes, etc. Aucun thème existant n’est utilisé pour mon site. Si les layouts permettent de surcharger les fichiers d’un thème activé. Ils peuvent aussi être utilisés seuls. Ils ne surchargent rien, mais sont suffisants. Au passage, je trouve que l’apprentissage des logiques d’Hugo est meilleur si un thème n’est pas activé dès le début. C’est un conseil que je donne aux personnes qui débutent: commencez par créer vos layouts, puis activez un thème si nécessaire. <h2 id="modularisation-de-la-configuration">Modularisation de la configuration</h2> Le fichier de configuration peut être séparé en plusieurs petits fichiers. Je vois peu d’intérêt à le faire avec le mien qui fait quelques dizaines de lignes. Mais ce peut être intéressant si <code>hugo.toml</code> devient trop long ou trop complexe. Pour modulariser la configuration, il faut placer les différents fichiers dans <code>/config/</code>. Le nom de fichier est alors la section de configuration. Par exemple, la minification dans mon fichier unique est: <pre tabindex="0"><code>[minify] minifyOutput = true [minify.tdewolff.html] keepDefaultAttrVals = false keepQuotes = true keepWhitespace = true </code></pre>Déplacée dans /config/minify.toml/, elle devient: <pre tabindex="0"><code>minifyOutput = true [tdewolff.html] keepDefaultAttrVals = false keepQuotes = true keepWhitespace = true </code></pre>La séparation en différents fichiers me paraît très utile dans certains cas: <ul> <li>quand un site est multilingue, la <a href="https://gohugo.io/content-management/multilingual/#configure-languages">configuration des langues</a> dans un fichier dédié me semble pertinente (surtout s’il y a des paramètres par langue, etc.)</li> <li>quand un site a un grand menu de navigation, un fichier dédié est une bonne idée</li> <li>et bien entendu quand certaines parties de configuration sont réutilisées telles quelles dans différents projets</li> </ul> Surtout, la séparation en fichier permet de proposer des portions de configurations plus simples à des personnes qui interviennent sur le site. Les responsables de la partie rédactionnelle éditeront plus facilement un fichier de menu qu’une configuration monolithique. <h2 id="configuration-par-environnement">Configuration par environnement</h2> Finalement, différentes versions de configuration sont applicables selon l’environnement. Un exemple simple, pour la minification: <ul> <li>dans <code>/config/_default/hugo.toml</code>: aucune option de minification mentionnée</li> <li>dans <code>/config/production/hugo.toml</code>: les quelques lignes sur la minification de mon fichier</li> </ul> Ainsi, durant le développement, les fichiers ne sont jamais minifiés. Alors que lors de la compilation ils le sont. Par défaut, hugo server est en environnement de développement et hugo en environnement de production. D’autres environnements sont utilisables et les variables peuvent être passées à la compilation. Ce sont des finesses inutiles pour un site aussi léger que le mien.</description></item><item><title>Police optimisée pour les titres</title><link>https://nicolasfriedli.ch/blog/police-optimisee-titres/</link><pubDate>Sat, 30 Mar 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/police-optimisee-titres/</guid><description>Voici la stratégie j’applique sur mon site pour disposer d’une belle police pour les titres et les intertitres sans prétériter la performance. Cette solution n’est plus utilisée sur ce site, mais toutes les explications restent valables. <h2 id="optimisation-de-la-police">Optimisation de la police</h2> J’ai choisi d’utiliser <a href="https://ateliertriay.github.io/bricolage/">Bricolage Grotesque</a> pour les titres (<code>h1</code>, <code>h2</code>, etc.) de mon blog. C’est une police variable, ce qui signifie qu’elle dispose de beaucoup de variantes, mais qu’elle est aussi assez lourde. Elle peut varier de taille optique, de largeur et de poids (<code>opsz</code>, <code>wdth</code> et <code>wght</code>). Le téléchargement du fichier de départ se passe dans le <a href="https://github.com/ateliertriay/bricolage/tree/main">dépôt GitHub</a> ou chez <a href="https://fonts.google.com/specimen/Bricolage+Grotesque">Google Fonts</a>. Pour être certain d’avoir un fichier léger, je vais convertir un fichier <code>ttf</code> en format <code>woff2</code>. Ce format est accepté par tous les navigateurs. Je ne souhaite pas de version variable sur mon site pour une question de poids. Comme tous mes titres sont en gras, je choisis la version statique <code>bold</code> (pour éviter la variation <code>wght</code>) et je prends celle en 48px (pour éviter la variation <code>opsz</code>). Je limite la gamme de caractères à l’alphabet latin. Avec le génial <a href="https://github.com/zachleat/glyphhanger">Glyphhanger</a> de l’excellent Zach Leatherman: <pre tabindex="0"><code>glyphhanger --formats=woff2 --subset=BricolageGrotesque_48pt-Bold.ttf --LATIN </code></pre>La taille du fichier passe de 79kB à 25kB. Je le renomme en <code>bricolage.woff2</code> pour la suite. Si le truc de Glyphanger semble trop compliqué, <a href="https://gwfh.mranftl.com/fonts/bricolage-grotesque?subsets=latin">Google Webfonfs Helper</a> ou le <a href="https://www.fontsquirrel.com/tools/webfont-generator">Webfont Generator de Font Squirrel</a> permettent de simplifier le travail. <h2 id="affichage-par-la-feuille-de-style-css">Affichage par la feuille de style CSS</h2> Désormais, il faut utiliser ce fichier dans les règles de l’art pour que tout se passe bien. Dans ma feuille de style, j’ai des règles de ce type (<a href="https://github.com/nfriedli/nicolasfriedli.ch/blob/main/assets/css/screen.css">feuille de style complète dans GitHub</a>): <pre tabindex="0"><code>:root { --font-main: ui-sans-serif, Roboto, system-ui, sans-serif; } html { font-family: var(--font-main); } </code></pre>J’ajoute ceci pour les 3 premiers niveaux de titres: <pre tabindex="0"><code>:root { --font-title: BricolageGrotesque, var(--font-main); } h1, h2, h3 { font-family: var(--font-title); } </code></pre>Ce qui signifie que, si Bricolage Grotesque n’est pas disponible, ce sera la même police que celle du texte qui sera utilisée. On évite ainsi de mauvaises surprises. Et maintenant, on appelle la police que j’ai placée dans <code>/fonts/</code>: <pre tabindex="0"><code>@font-face { font-display: swap; font-family: BricolageGrotesque; font-style: normal; font-weight: 700; src: url(&#34;/fonts/bricolage.woff2&#34;) format(&#34;woff2&#34;); } </code></pre>Avec un site généré par Hugo, on placera le fichier source dans <code>/static/fonts/</code>. <h2 id="strategie-de-chargement-et-de-cache">Stratégie de chargement et de cache</h2> Si je dois être certain que le site ne soit jamais ralenti par le chargement de police, je peux choisir un affichage optionnel avec: <pre tabindex="0"><code>font-display: optional; </code></pre>Si ma feuille de style était dans un fichier externe, je pourrais lancer le chargement avant même la disponibilité du CSS: <pre tabindex="0"><code>&lt;link rel=&#34;preload&#34; href=&#34;/fonts/bricolage.woff2&#34; as=&#34;font&#34; type=&#34;font/woff2&#34; crossorigin&gt; </code></pre>Et dans tous les cas, j’ajoute une règle de cache dans le fichier <code>.htaccess</code>, pour tous les fichiers de type <code>woff2</code>: <pre tabindex="0"><code>&lt;filesMatch &#34;.(woff2)$&#34;&gt; Header set Cache-Control &#34;max-age=63072000,immutable&#34; &lt;/filesMatch&gt; </code></pre>Ou, quand j’utilise Netlify, une règle dans <code>_headers</code> appliquée pour un répertoire plutôt qu’un type de fichiers: <pre tabindex="0"><code>/fonts/* Cache-Control: max-age=63072000,immutable </code></pre>Ces règles de cache signifient que le fichier restera en mémoire durant une année et ne sera pas rechargé. Pour des informations très précises sur la gestion du cache, je conseille <a href="https://www.youtube.com/watch?v=qVQjGwm_mmw">Cache Rules Everything</a> par Harry Roberts. <h2 id="ameliorer-votre-site">Améliorer votre site</h2> La même politique peut s’appliquer pour toutes les polices de votre site. Vous pouvez entreprendre une même démarche en vous inspirant des travaux de Zach Leatherman: <ul> <li><a href="https://beyondtellerrand.com/events/dusseldorf-2019/speakers/zach-leatherman">The Scoville Scale of Web Font Loading Opinions</a></li> <li><a href="https://www.zachleat.com/web/comprehensive-webfonts/">A Comprehensive Guide to Font Loading Strategies</a></li> </ul> Mais quand plusieurs polices entrent en jeu, d’autres questions se posent. Par exemple: <ul> <li>quels fichiers précharger (<code>preload</code>) pour ne pas faire de transferts inutiles?</li> <li>quelle police afficher de quelle manière (<code>optional</code> ou <code>swap</code>)?</li> <li>quelle pertinence d’une feuille de style externe uniquement pour les chargements de polices?</li> </ul> Dans tous les cas, essayez d’éviter les services tiers comme Google Fonts. Ils posent des problèmes de confidentialité, de fiabilité et de performance. Et comme ils proposent un cache très court, ils gaspillent pas mal de ressources en transferts inutiles.</description></item><item><title>Sans commentaire!</title><link>https://nicolasfriedli.ch/blog/sans-commentaire/</link><pubDate>Tue, 26 Mar 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/sans-commentaire/</guid><description>J’ai décidé de ne pas activer de système de commentaires sur ce site. En 2024, les commentaires sur les blogs personnels posent plus de problèmes qu’ils n’en résolvent. Pour des raisons de simplicité technique, de performances, d’écologie et de pertinence, je vous laisse m’écrire par mail. <h2 id="un-blog-selon-wikipedia">Un blog selon Wikipédia</h2> Commentaires ou pas? L’article <a href="https://fr.wikipedia.org/wiki/Blog">Blog de Wikipédia</a> ne tranche pas: <blockquote> [les articles] sont la plupart du temps ouverts aux commentaires des lecteurs [et lectrices]. [&hellip;] car chaque visiteur [ou visiteuse] d’un blog peut laisser des commentaires sur le blog lui-même, ou bien contacter le blogueur [ou la blogueuse] par courriel.</blockquote> À mon humble avis, la question des commentaires n’est pas définitoire d’un blog. Ce qui fait un blog, c’est l’accumulation de publications personnelles datées et signées. Tout le reste est accessoire. Toutefois, les commentaires ouverts sont souvent disponibles. Ils ont fait partie de l’histoire des blogs, mais me semblent aujourd’hui dépassés. <h2 id="contraintes-techniques-et-performance">Contraintes techniques et performance</h2> Ce site est <a href="https://nicolasfriedli.ch/blog/site-statique-generateur-hugo/">statique et généré par Hugo</a>. Je ne souhaite pas l’alourdir pour permettre des commentaires. Je ne souhaite pas installer et maintenir un système comme WordPress, Drupal, SPIP, typo3 ou autre. Je souhaite encore moins ajouter un système externe, comme Disqus, qui pose des problèmes de confidentialité et de poids des pages. La rapidité et la légèreté sont un choix. Il serait malvenu de proposer un site plus lourd et plus lent à une large majorité d’internautes qui ne commenteront jamais, au bénéfice de celles et ceux qui pourraient commenter. L’absence de commentaires est un choix pragmatique, tant pour mon travail de gestion du site que pour le confort des lecteurs et lectrices. <h2 id="spam-et-ecologie">Spam et écologie</h2> Il existe toutefois de bons outils pour gérer le spam dans les commentaires. En premier lieu <a href="https://akismet.com/fr/">Akismet</a> proposé par Automattic, l’entreprise qui développe WordPress. La qualité du filtrage est excellente. Les indésirables ne passent pas la rampe. Si la question de la modération du spam est résolue, l’aperçu des statistiques d’Akismet fait froid dans le dos. Sur beaucoup de sites, le taux de spam est supérieur à 90% des messages reçus. En d’autres termes, 9 messages sur 10 envoyés sont inscrits dans la base de données, puis traités par un service externe, pour être finalement envoyés à la poubelle. D’un point de vue écologique, c’est indécent. Les blogueurs et blogueuses devraient toujours se poser la question de la pertinence des commentaires ouverts. Certes, c’est agréable d’avoir un retour positif, mais ça n’en vaut pas toujours le prix. En fin de compte, c’est parce que beaucoup (trop) de sites permettent des commentaires que des outils de spam sont développés. Le paradoxe, c’est que l’efficacité d’Akismet entretient la publication de messages indésirables et le gâchis de ressources. Si l’outil était mauvais, les commentaires seraient fermés (ou réservés aux personnes inscrites) et les indésirables n’existeraient plus depuis longtemps. <h2 id="lieux-de-discussion">Lieux de discussion</h2> Les lieux pour commenter se sont multipliés. Il y avait les blogs et les forums. Il y a aujourd’hui les réseaux sociaux publics (Facebook, Instagram, Mastodon, Twitter/X), les plateformes de diffusion vidéo (Twitch, YouTube), les services privés (Discord, Slack), les messageries instantanées (Telegram, WhatsApp) pour ne citer que quelques exemples. Quoi que l’on fasse de nos blogs, les contenus pourront toujours être discutés ailleurs et il ne sera jamais possible de suivre tous les débats. Même avec un système de commentaires activé, ce n’est plus «sous le billet» que se passe l’essentiel des interactions. Dans mon monde de rêve, toutes les interactions se feraient par un nouvel article de blog. Un billet m’a interpellé, m’a déplu ou m’a déçu, j’en écris un autre sur mon site. Se crée alors un réseau, sans coordination et sans modération centrale. Ainsi chaque site personnel est de fait un lieu de discussion. <h2 id="commentaires-sans-interet">Commentaires sans intérêt</h2> Je ne peux terminer ce billet sans passer par le constat qui fâche. Les interactions sont de moins en moins intéressantes, sur les blogs comme ailleurs. Le schéma suivant est triste à pleurer: <blockquote> Merci Nicolas pour ce super billet. <blockquote> Avec plaisir, Sophie.</blockquote></blockquote> puis, interaction suivante: <blockquote> Belle réflexion, amitiés. <blockquote> Merci cher Pierre.</blockquote></blockquote> Les pouces levés, les cœurs et autres «interactions légères» ont tué le commentaire construit. D’ailleurs, les réseaux sociaux ne prévoient qu’un lien par publication (avec prévisualisation), voilà qui en dit long sur ce qui est attendu. Lorsque j’avais encore des commentaires sur des sites, c’était avant tout pour flatter mon propre ego. Mais plus pour apprendre quelque chose ou relancer ma réflexion. Si vous avez quelque chose à me dire, mon adresse est disponible sur ma page de contact. Et si votre messagerie est correctement configurée, il suffit de cliquer sur <a href="mailto:hello+2025@nicolasfriedli.ch?subject=Re%3A%20Sans%20commentaire!">Répondre par mail</a> pour avoir un message au titre déjà rédigé.</description></item><item><title>Enseignements du framework Diátaxis</title><link>https://nicolasfriedli.ch/blog/diataxis-introduction/</link><pubDate>Mon, 25 Mar 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/diataxis-introduction/</guid><description>Conçu par un spécialiste de documentation technique, le cadre de travail Diátaxis permet d’améliorer la qualité de ses pages web dans d’autres domaines que le code logiciel. <h2 id="diataxis-en-bref">Diátaxis en bref</h2> Le framework <a href="https://diataxis.fr/">Diátaxis</a> propose des principes pour une approche systématique de la rédaction de documentation technique. Je pense qu’il peut être utilisé pour toute forme de documentation. Il a été développé par Daniele Procida. Par la structure qu’il propose, il facilite l’utilisation de la documentation pour les internautes et la maintenance pour les rédacteurs et rédactrices. Les 4 types de contenus de toute documentation sont regroupés en 2 axes: <ul> <li>les tutoriels sont orientés vers l’apprentissage et sont utiles à l’action</li> <li>les guides how-to sont sont orientés vers l’application et sont utiles à l’action</li> <li>les références sont orientés vers l’application et sont utiles à l’action à la connaissance</li> <li>les explications sont orientées vers l’apprentissage et sont utiles à la connaissance</li> </ul> En plus du site de référence, je conseille les vidéos suivantes pour en apprendre plus: <ul> <li>découverte de l’outil: <a href="https://www.youtube.com/watch?v=t4vKPhjcMZg">What nobody tells you about documentation</a></li> <li>atelier: <a href="https://www.youtube.com/watch?v=710uQqIqsWk">Python Docs Community Workshop: Introduction to Diataxis</a></li> <li>sur la croissance d’un corpus: <a href="https://www.youtube.com/watch?v=Wc7n7uIg4AM">Always complete, never finished</a></li> </ul> Voici ce qui m’a intéressé (et convaincu) dans la démarche. <h2 id="regrouper-par-categories">Regrouper par catégories</h2> Le classement des contenus en 4 catégories permet de hiérarchiser l’information et de rapprocher ce qui doit l’être. Une structure propre est une condition nécessaire pour naviguer efficacement dans une documentation d’une certaine taille. Le moteur de recherche ou l’index alphabétique ne remplaceront jamais une bonne structure. La chronologie d’un blog ou les liens très nombreux d’un wiki ne permettent pas non plus d’aider les internautes à comprendre comment est structurée la documentation. Sur ce thème, je conseille aussi la conférence <a href="https://www.writethedocs.org/videos/na/2017/building-navigation-for-your-doc-site-5-best-practices-tom-johnson/">Building navigation for your doc site: 5 best practices</a> par Tom Johnson. Elle est complémentaire au travail de Daniele Procida. En passant, je fais remarquer qu’une taxonomie est presque toujours pensée comme un arbre. Mais elle devrait d’abord être pensée comme un moyen de regroupement. C’est ensuite seulement qu’elle peut prendre la forme d’un arbre (ou pas). Le groupement par proximité est premier. À terme, dans un corpus qui grandit, si les regroupements ne sont pas clairs, c’est la gabegie assurée. <h2 id="publics-cibles-et-personnes-differentes">Publics cibles et personnes différentes</h2> Les 4 catégories de Diátaxis s’adressent à plusieurs publics cibles et à des personnes différentes. Un exemple tout simple: <ul> <li>le tutoriel de la mousse au chocolat sur YouTube est fait pour les enfants qui n’ont jamais cuisiné (mais qui veulent faire une surprise à leurs parents)</li> <li>la recette de la mousse au chocolat est un guide how-to destiné aux personnes qui cuisinent (vous et moi)</li> <li>l’explication sur la chimie de la mousse au chocolat est destinée aux personnes curieuses (mais qui ne cuisinent pas forcément)</li> </ul> En première approche, on pourrait dire que chaque public cible peut être intéressé par 1 ou 2 catégories. C’est une manière de voir les choses, mais je pense qu’elle est erronée. Une personne peut être intéressée à 1, 2, 3 ou 4 catégories de contenu. <h2 id="temporalite-differente-pour-les-memes-personnes">Temporalité différente pour les mêmes personnes</h2> Il faudrait plutôt dire que chaque personne peut être intéressée par les 4 catégories, mais à des moments différents. La notion de temporalité est plus intéressante, parce qu’évolutive. Les enfants qui ont suivi le tutoriel pour leur première mousse au chocolat utiliseront peut-être une recette (sans passer par un tuto) pour leur prochaine création. Et je parie que les ados pourraient bien lire quelque chose sur la cuisine moléculaire. Pour moi, cette notion de moment est la plus grande force de Diátaxis. Une même personne a besoin de contenus différents en fonction de sa tâche du moment. Parce que les besoins varient en fonction du temps, la structure doit être particulièrement propre. <h2 id="rigueur-et-non-linearite">Rigueur et non-linéarité</h2> Le plus grand risque avec cet outil, c’est de penser qu’il y a une évolution «linéaire» entre les différentes catégories. D’abord un tuto, puis un how-to, etc. C’est faux! Les parcours peuvent être multiples. Je vous passe toutes les navigations possibles entre les différents éléments d’une documentation, que ce soit de la cuisine, de la programmation, le pilotage d’un avion ou le vélo (des exemples de Procida). La structure doit être assez claire pour permettre de sauter sans hésitation d’un type de contenu à l’autre à un moment précis. J’ai besoin de ceci, je sais que je vais trouver la réponse là! Depuis que j’ai écouté et lu Procida, je vois souvent les choses sous un autre angle. Je combats désormais souvent ma tentation d’introduire des «motifs antipédagogiques» (introduire des éléments d’explication dans un tutoriel, par exemple), sans toujours y parvenir. <hr> Je suis convaincu que derrière le paradoxe de l’utilisation d’un outil technique pour des contenus non techniques se cachent pas mal de pistes pour améliorer l’efficacité des publications sur le web. Je suis intéressé pour tous vos retours sur Diátaxis pour des documentations généralistes.</description></item><item><title>Données structurées pour un blog personnel</title><link>https://nicolasfriedli.ch/blog/json-ld-blog/</link><pubDate>Thu, 21 Mar 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/json-ld-blog/</guid><description>Les données structurées permettent de simplifier le travail des moteurs de recherche et d’améliorer la précision des informations fournies. Après quelques généralités, je vous dis ce que j’ai implémenté sur ce site généré avec Hugo. <h2 id="json-for-linking-data-et-schemaorg">JSON for Linking Data et Schema.org</h2> JSON-LD (JSON for Linking Data) est un format recommandé pour intégrer des données structurées dans une page HTML. Comme son nom l’indique, il utilise la syntaxe JSON (JavaScript Object Notation) répandue dans le domaine du web. En HTML, des métadonnées existent déjà, mais elles sont des balises simples, sans structure. Par exemple: <pre tabindex="0"><code>&lt;meta name=&#34;author&#34; content=&#34;Nicolas Friedli&#34;&gt; </code></pre>Mais qui est ce «Nicolas Friedli»? Impossible d’en dire plus dans les métadonnées habituelles. <a href="https://json-ld.org/">JSON-LD</a> permet de structurer les données et propose une grammaire. <a href="https://schema.org/">Schema.org</a> — une initiative commune de Google, Microsoft, Yahoo et Yandex — développe un vocabulaire pour remplir ces champs JSON. Tout l’enjeu désormais, c’est de donner des informations utiles, ni trop ni trop peu. <h2 id="donnees-en-page-daccueil">Données en page d’accueil</h2> Sur la page d’accueil de ce site, je tiens à ajouter quelques métadonnées pour: <ul> <li>définir clairement le nom du site</li> <li>identifier son auteur sans hésitation</li> </ul> Il est possible de générer des petits fichiers avec <a href="https://jsonld.com/">Steal Our JSON-LD</a>, mais j’ai préféré le faire à la main en lisant la documentation de Schema.org. <h3 id="nom-du-site">Nom du site</h3> En suivant les indications de <a href="https://developers.google.com/search/docs/appearance/site-names?hl=fr">Fournir un nom de site pour la recherche Google</a>, je pourrais écrire: <pre tabindex="0"><code>{ &#34;@context&#34;: &#34;http://schema.org&#34;, &#34;@type&#34;: &#34;WebSite&#34;, &#34;name&#34;: &#34;Nicolas Friedli&#34;, &#34;url&#34;: &#34;https://nicolasfriedli.ch/&#34; } </code></pre><h3 id="auteur-du-site">Auteur du site</h3> Comme c’est un site personnel, il me paraît intéressant d’en dire plus sur l’auteur. Je pourrais écrire: <pre tabindex="0"><code>{ &#34;@context&#34;: &#34;http://www.schema.org&#34;, &#34;@type&#34;: &#34;person&#34;, &#34;name&#34;: &#34;Nicolas Friedli&#34;, &#34;address&#34;: { &#34;@type&#34;: &#34;PostalAddress&#34;, &#34;streetAddress&#34;: &#34;Rue du Château 3&#34;, &#34;addressLocality&#34;: &#34;Colombier&#34;, &#34;addressRegion&#34;: &#34;Neuchâtel&#34;, &#34;postalCode&#34;: &#34;2013&#34;, &#34;addressCountry&#34;: &#34;CH&#34; }, &#34;email&#34;: &#34;hello@nicolasfriedli.ch&#34;, &#34;telephone&#34;: &#34;+41793443382&#34; } </code></pre>Donc, nous avons désormais 2 ensembles JSON. Le premier a un seul niveau, le second est plus structuré (champ <code>address</code>). <h3 id="structure-simple">Structure simple</h3> Mais ce qui est vraiment intéressant, c’est de lier la notion d’auteur au site. Comme le nom du site est le même que le nom de l’auteur, je prends un autre exemple pour ce passage. Voici ce qui se trouvait en page d’accueil de l’<a href="https://theologique.ch/">annuaire protestant theologique.ch</a> (version simplifiée): <pre tabindex="0"><code>{ &#34;@context&#34;: &#34;http://schema.org&#34;, &#34;@type&#34;: &#34;WebSite&#34;, &#34;name&#34;: &#34;Annuaire protestant&#34;, &#34;alternateName&#34;: &#34;theologique.ch&#34;, &#34;url&#34;: &#34;https://theologique.ch/&#34;, &#34;author&#34;: { &#34;@context&#34;: &#34;https://schema.org&#34;, &#34;@type&#34;: &#34;Person&#34;, &#34;name&#34;: &#34;Nicolas Friedli&#34;, &#34;url&#34;: &#34;https://nicolasfriedli.ch/&#34; } } </code></pre>En français: <blockquote> Ce site s’appelle «Annuaire protestant», et aussi «theologique.ch». Il est disponible à l’adresse <code>https://theologique.ch/</code>. Il a pour auteur Nicolas Friedli, celui du site <code>https://nicolasfriedli.ch/</code>.</blockquote> C’est clair, non? <h3 id="schema-complet">Schéma complet</h3> Pour mon blog, j’ai essayé de créer un JSON un peu plus complet: <pre tabindex="0"><code>{ &#34;@context&#34;: &#34;http://schema.org&#34;, &#34;@type&#34;: &#34;WebSite&#34;, &#34;name&#34;: &#34;Nicolas Friedli&#34;, &#34;alternateName&#34;: &#34;NF&#34;, &#34;description&#34;: &#34;Consultant web à Neuchâtel (Suisse).&#34;, &#34;url&#34;: &#34;https://nicolasfriedli.ch/&#34;, &#34;image&#34;: &#34;/images/nicolas-friedli.jpg&#34;, &#34;author&#34;: { &#34;@context&#34;: &#34;https://schema.org&#34;, &#34;@type&#34;: &#34;Person&#34;, &#34;name&#34;: &#34;Nicolas Friedli&#34;, &#34;alternateName&#34;: &#34;NF&#34;, &#34;givenName&#34;: &#34;Nicolas&#34;, &#34;familyName&#34;: &#34;Friedli&#34;, &#34;jobTitle&#34;: &#34;Consultant web&#34;, &#34;address&#34;: { &#34;@type&#34;: &#34;PostalAddress&#34;, &#34;streetAddress&#34;: &#34;Rue du Château 3&#34;, &#34;postalCode&#34;: &#34;2013&#34;, &#34;addressLocality&#34;: &#34;Colombier&#34;, &#34;addressRegion&#34;: &#34;Neuchâtel&#34;, &#34;addressCountry&#34;: &#34;CH&#34; }, &#34;email&#34;: &#34;hello@nicolasfriedli.ch&#34;, &#34;image&#34;: &#34;/images/nicolas-friedli.jpg&#34;, &#34;telephone&#34;: [ &#34;+41328414874&#34;, &#34;+41793443382&#34; ], &#34;spouse&#34;: { &#34;@context&#34;: &#34;https://schema.org&#34;, &#34;@type&#34;: &#34;Person&#34;, &#34;name&#34;: &#34;Diane Friedli&#34;, &#34;url&#34;: &#34;https://dianefriedli.ch/&#34; }, &#34;url&#34;: &#34;https://nicolasfriedli.ch/&#34;, &#34;sameAs&#34;: [ &#34;https://github.com/nfriedli/&#34;, &#34;https://keybase.io/nicolasfriedli&#34; ], &#34;nationality&#34;: &#34;Suisse&#34;, &#34;alumniOf&#34;: { &#34;@type&#34;: &#34;CollegeOrUniversity&#34;, &#34;name&#34;: &#34;Université de Neuchâtel&#34; } } } </code></pre>L’interprétation du contenu devrait être simple. Donc je ne commente pas en détail, mais signale que l’URL du site est la même que celle de l’auteur. Ce balisage est conforme à Schema.org, même il est rarement utilisé ainsi. <h3 id="integration-statique-dans-hugo">Intégration statique dans Hugo</h3> Pour intégrer cela dans Hugo, c’est trivial, parce que ces données sont statiques. Un fichier <code>schema.json</code> est placé dans le répertoire <code>/data/</code>. Il est accessible par la variable <code>site.Data.schema</code>. Donc, pour ne l’afficher que sur la page d’accueil, ce sera quelque chose comme: <pre tabindex="0"><code>{{ if .IsHome }} &lt;script type=&#34;application/ld+json&#34;&gt; {{ site.Data.schema }} &lt;/script&gt; {{ end }} </code></pre>Tous les détails sont toujours disponibles dans les <a href="https://github.com/nfriedli/nicolasfriedli.ch/">sources du site sur GitHub</a>. <h2 id="pour-les-billets-de-blog">Pour les billets de blog</h2> Pour les billets de blog, je souhaite donner quelques informations aux moteurs de recherche: <ul> <li>distinguer clairement la date de publication de la date de dernière modification (non trivial en HTML)</li> <li>donner le titre du billet, pour éviter l’ambiguïté entre <code>h1</code>et <code>title</code></li> <li>signifier que le contenu est gratuit</li> <li>compter le nombre de mots</li> </ul> <h3 id="structure-du-json-ld">Structure du JSON-LD</h3> Voici comment je le formule avec les variables Hugo: <pre tabindex="0"><code>{ &#34;@context&#34;: &#34;https://schema.org&#34;, &#34;@type&#34;: &#34;BlogPosting&#34;, &#34;headline&#34;: &#34;{{ .Title }}&#34;, &#34;wordCount&#34;: &#34;{{ .WordCount }}&#34;, {{ with .PublishDate }} &#34;datePublished&#34;: &#34;{{ .Format &#34;2006-01-02&#34; }}&#34;, {{ end }} {{ with .Lastmod }} &#34;dateModified&#34;: &#34;{{ .Format &#34;2006-01-02&#34; }}&#34;, {{ end }} &#34;author&#34;: [{ &#34;@type&#34;: &#34;Person&#34;, &#34;name&#34;: &#34;Nicolas Friedli&#34;, &#34;url&#34;: &#34;https://nicolasfriedli.ch/&#34; }], &#34;isAccessibleForFree&#34;: true } </code></pre>La version courante est elle aussi toujours disponible dans les sources. <h3 id="integration-dynamique-dans-hugo">Intégration dynamique dans Hugo</h3> Pour l’intégrer dans Hugo, vu que c’est quelque chose de dynamique, je déclare un bloc sur toutes les pages du site, mais le laisse vide par défaut: <pre tabindex="0"><code>{{ block &#34;json-ld&#34; . }}{{ end }} </code></pre>Puis, uniquement pour les articles de blog, je redéfinis (ou surcharge) le bloc dans le modèle <code>blog/single.html</code>: <pre tabindex="0"><code>{{ define &#34;json-ld&#34; }} &lt;script type=&#34;application/ld+json&#34;&gt; { &#34;@context&#34;: &#34;https://schema.org&#34;, &#34;@type&#34;: &#34;BlogPosting&#34;, ... } &lt;/script&gt; {{ end }} </code></pre>L’existence du bloc <code>json-ld</code> sur toutes les pages permettrait d’injecter d’autres données à d’autres endroits du site. <h2 id="construction-a-la-main">Construction à la main</h2> En passant la page d’accueil ou un billet de blog de ce site dans le <a href="https://validator.schema.org/">validateur Schema.org</a>, les données structurées sont rendues lisibles. Elles me semblent suffisantes. Il reste à voir comment elles seront prises en compte par les moteurs de recherche dans la durée. En construisant ces schémas à la main, j’ai pu me rendre compte du potentiel de Schema.org pour documenter autre chose que des billets de blog. C’est ce que j’ai utilisé sur le site Églises ouvertes en Suisse romande (ce site n’existe plus). Beaucoup de sites utilisent JSON-LD, souvent en excès (et dans le dos des propriétaires). Je suis très réservé par la quantité astronomique de données structurées que propose l’extension de référencement Yoast SEO. C’est un peu comme si le site était réécrit 2 fois sur chacune de ses pages. Si je vois bien l’intérêt de la chose pour un site commercial ou tout site qui cherche à <a href="https://developers.google.com/search/docs/appearance/structured-data/search-gallery?hl=fr">modifier l’apparence des résultats de recherche</a> pour être plus visible, je pense que c’est inutile pour un blog ou un simple site personnel.</description></item><item><title>Mon premier JSON Schema</title><link>https://nicolasfriedli.ch/blog/json-schema/</link><pubDate>Mon, 18 Mar 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/json-schema/</guid><description>Le format JSON (JavaScript Object Notation) est un des plus utilisés sur le web. Il est léger et permet d’échanger des données. Je propose la rédaction d’un JSON Schema pour formaliser les contenus, à partir d’un l’exemple concret de données que j’utilise déjà. <h2 id="un-json-tout-simple">Un JSON tout simple</h2> Pour un site patrimonial qui liste les églises protestantes ouvertes en Suisse romande, j’ai utilisé dès le début des données formatées en JSON. Chaque bâtiment a son propre fichier, assez lisible, qui ressemble à ceci: <pre tabindex="0"><code>{ &#34;title&#34;: &#34;Temple de Colombier&#34;, &#34;site&#34;: &#34;https://www.eren.ch/barc/batiments/temple-de-colombier/&#34;, &#34;maps&#34;: &#34;https://goo.gl/maps/3KSuvNTqXsdSFmnc9&#34;, &#34;rue&#34;: &#34;Rue du Château 3a&#34;, &#34;npa&#34;: 2013, &#34;localite&#34;: &#34;Colombier&#34;, &#34;commune&#34;: &#34;Milvignes&#34;, &#34;canton&#34;: &#34;Neuchâtel&#34;, &#34;latitude&#34;: 46.9666066, &#34;longitude&#34;: 6.8623137, &#34;ouverture&#34;: &#34;7/7&#34;, &#34;horaire&#34;: &#34;8:00-20:00&#34;, &#34;pbc&#34;: &#34;B&#34;, &#34;vitraux&#34;: [&#34;Pierre-Eugène Bouvier&#34;] } </code></pre>J’ai ajouté les champs de données au fur et à mesure de la création du site, ne sachant pas quelles informations j’allais découvrir dans mes recherches. <h2 id="un-json-plus-structure">Un JSON plus structuré</h2> S’il fallait modifier quelque chose, je structurerais peut-être les données un peu plus fortement, par exemple ainsi: <pre tabindex="0"><code>{ &#34;title&#34;: &#34;Temple de Colombier&#34;, &#34;liens&#34;: { &#34;site&#34;: &#34;https://www.eren.ch/barc/batiments/temple-de-colombier/&#34;, &#34;maps&#34;: &#34;https://goo.gl/maps/3KSuvNTqXsdSFmnc9&#34; }, &#34;adresse&#34;: { &#34;rue&#34;: &#34;Rue du Château 3a&#34;, &#34;npa&#34;: 2013, &#34;localite&#34;: &#34;Colombier&#34;, &#34;commune&#34;: &#34;Milvignes&#34;, &#34;canton&#34;: &#34;Neuchâtel&#34; }, &#34;coordonnes&#34;: { &#34;latitude&#34;: 46.9666066, &#34;longitude&#34;: 6.8623137 }, &#34;ouverture&#34;: { &#34;jours&#34;: &#34;7/7&#34;, &#34;horaire&#34;: &#34;8:00-20:00&#34; }, &#34;patrimoine&#34;: { &#34;pbc&#34;: &#34;B&#34;, &#34;vitraux&#34;: [&#34;Pierre-Eugène Bouvier&#34;] } } </code></pre>C’est très théorique, parce qu’en voyant le résultat, je ne suis pas certain que ça apporterait beaucoup. Le «JSON tout simple» est donc celui que je conserve pour produire le site et sur lequel portent les exemples qui suivant. <h2 id="objectifs-du-schema-json">Objectifs du schéma JSON</h2> Si le <a href="https://www.json.org/json-fr.html">format JSON</a> est strict du point de vue le la forme, il laisse toute liberté pour les contenus. Un <a href="https://json-schema.org/">JSON Schema</a> permet de fixer des règles pour la création d’un contenu JSON. Le schéma que je vais créer doit notamment servir à vérifier: <ul> <li>qu’un certain nombre de données soient présentes (titre, adresse complète, coordonnée et horaires d’ouverture)</li> <li>qu’il soit possible de faire un lien vers une page externe ou une fiche Google Maps</li> <li>que les numéros postaux soient des nombres de 4 chiffres</li> <li>que les coordonnées aient des valeurs raisonnables pour la Suisse romande</li> <li>qu’il ne soit pas possible d’ajouter d’autres données</li> </ul> Ainsi je pourrai vérifier la validité de mon corpus d’édifices en une seule commande, <a href="https://github.com/santhosh-tekuri/jsonschema">par exemple avec JSONSchema</a>. Ou tester un contenu directement en ligne avec <a href="https://www.jsonschemavalidator.net/">JSON Schema Validator</a>. <h2 id="creation-dun-schema-json">Création d’un schéma JSON</h2> L’utilisation de JSON est complètement libre, mais un <a href="https://json-schema.org/">JSON Schema</a> permet de fixer des règles et de valider des contenus informatiquement. Pour ma culture générale, j’ai créé un schéma pour Églises ouvertes en Suisse romande (site abandonné). Je le copie intégralement, même si c’est un peu long. Puis je commente certaines parties dans la suite du billet. La version courante était disponible sur le site eglises-ouvertes.ch. Elle reste disponible dans de le <a href="https://github.com/nfriedli/eglises-ouvertes/blob/main/static/schema.json">dépôt GitHub nfriedli/eglises-ouvertes</a>. <pre tabindex="0"><code>{ &#34;$schema&#34;: &#34;https://json-schema.org/draft/2020-12/schema&#34;, &#34;$id&#34;: &#34;https://eglises-ouvertes.ch/schema.json&#34;, &#34;title&#34;: &#34;église ouverte&#34;, &#34;description&#34;: &#34;description complète d’une des Églises ouvertes de Suisse romande&#34;, &#34;type&#34;: &#34;object&#34;, &#34;properties&#34;: { &#34;title&#34;: { &#34;description&#34;: &#34;nom du bâtiment&#34;, &#34;type&#34;: &#34;string&#34; }, &#34;nomCourt&#34;: { &#34;description&#34;: &#34;version simplifiée du nom du bâtiment&#34;, &#34;type&#34;: &#34;string&#34; }, &#34;site&#34;: { &#34;description&#34;: &#34;page de présentation du bâtiment (horaire d’ouverture impératif)&#34;, &#34;type&#34;: &#34;string&#34; }, &#34;maps&#34;: { &#34;description&#34;: &#34;fiche Google Mas du bâtiment (horaire d’ouverture impératif)&#34;, &#34;type&#34;: &#34;string&#34; }, &#34;rue&#34;: { &#34;description&#34;: &#34;rue avec numéro&#34;, &#34;type&#34;: &#34;string&#34; }, &#34;localite&#34;: { &#34;description&#34;: &#34;village dans une plus grande commune&#34;, &#34;type&#34;: &#34;string&#34; }, &#34;commune&#34;: { &#34;type&#34;: &#34;string&#34; }, &#34;npa&#34;: { &#34;description&#34;: &#34;numéro postal d’acheminement&#34;, &#34;type&#34;: &#34;integer&#34;, &#34;minimum&#34;: 1000, &#34;maximum&#34;: 9999 }, &#34;canton&#34;: { &#34;description&#34;: &#34;un canton de Suisse romande&#34;, &#34;enum&#34;: [&#34;Berne&#34;, &#34;Fribourg&#34;, &#34;Genève&#34;, &#34;Jura&#34;, &#34;Neuchâtel&#34;, &#34;Valais&#34;, &#34;Vaud&#34; ] }, &#34;latitude&#34;: { &#34;type&#34;: &#34;number&#34;, &#34;minimum&#34;: 45, &#34;maximum&#34;: 48 }, &#34;longitude&#34;: { &#34;type&#34;: &#34;number&#34;, &#34;minimum&#34;: 5, &#34;maximum&#34;: 11 }, &#34;ouverture&#34;: { &#34;description&#34;: &#34;jours d’ouverture (souvent 7/7)&#34;, &#34;type&#34;: &#34;string&#34; }, &#34;horaire&#34;: { &#34;description&#34;: &#34;heures d’ouverture (parfois 24/24)&#34;, &#34;type&#34;: &#34;string&#34; }, &#34;pbc&#34;: { &#34;description&#34;: &#34;patrimoine des biens culturels suisses&#34;, &#34;enum&#34;: [ &#34;A&#34;, &#34;B&#34; ] }, &#34;vitraux&#34;: { &#34;description&#34;: &#34;nom d’artiste&#34;, &#34;type&#34;: &#34;array&#34;, &#34;items&#34;: { &#34;type&#34;: &#34;string&#34; } } }, &#34;anyOf&#34;: [ { &#34;required&#34;: [ &#34;site&#34; ]}, { &#34;required&#34;: [ &#34;maps&#34; ]} ], &#34;required&#34;: [ &#34;title&#34;, &#34;rue&#34;, &#34;npa&#34;, &#34;commune&#34;, &#34;canton&#34;, &#34;latitude&#34;, &#34;longitude&#34;, &#34;ouverture&#34;, &#34;horaire&#34; ], &#34;additionalProperties&#34;: false } </code></pre><h3 id="validation-des-champs">Validation des champs</h3> En début de fichier, ce sont des champs qui demandent des chaînes de caractères (du texte libre). Cela n’appelle pas de commentaires particuliers. Pour le numéro postal d’acheminement, j’impose un nombre de 4 chiffres entre 1000 et 9999. On pourrait limiter aux NPA de Suisse romande, mais c’est très bien ainsi: <pre tabindex="0"><code>&#34;npa&#34;: { &#34;description&#34;: &#34;numéro postal d’acheminement&#34;, &#34;type&#34;: &#34;integer&#34;, &#34;minimum&#34;: 1000, &#34;maximum&#34;: 9999 } </code></pre>Pour le canton, on limite le choix aux cantons romands (ou avec une partie romande) et il ne peut y en avoir qu’un: <pre tabindex="0"><code>&#34;canton&#34;: { &#34;description&#34;: &#34;un canton de Suisse romande&#34;, &#34;enum&#34;: [&#34;Berne&#34;, &#34;Fribourg&#34;, &#34;Genève&#34;, &#34;Jura&#34;, &#34;Neuchâtel&#34;, &#34;Valais&#34;, &#34;Vaud&#34; ] }, </code></pre>La latitude et la longitude sont limitées dans des valeurs proches de celles de la Suisse: <pre tabindex="0"><code>&#34;latitude&#34;: { &#34;type&#34;: &#34;number&#34;, &#34;minimum&#34;: 45, &#34;maximum&#34;: 48 }, &#34;longitude&#34;: { &#34;type&#34;: &#34;number&#34;, &#34;minimum&#34;: 5, &#34;maximum&#34;: 11 } </code></pre>Si elle est précisée, l’inscription à l’<a href="https://www.bak.admin.ch/bak/fr/home/baukultur/archaeologie-und-denkmalpflege/inventare/kgs-inventar.html">Inventaire des biens culturels d’importance nationale et régionale (PBC)</a> peut prendre la valeur A ou la valeur B: <pre tabindex="0"><code>&#34;pbc&#34;: { &#34;description&#34;: &#34;patrimoine des biens culturels suisses&#34;, &#34;enum&#34;: [ &#34;A&#34;, &#34;B&#34; ] } </code></pre>Les artistes ayant créé des vitraux peuvent être plusieurs pour un seul édifice: <pre tabindex="0"><code>&#34;vitraux&#34;: { &#34;description&#34;: &#34;nom d’artiste&#34;, &#34;type&#34;: &#34;array&#34;, &#34;items&#34;: { &#34;type&#34;: &#34;string&#34; } } </code></pre><h3 id="conditions-de-validation">Conditions de validation</h3> Au-delà de la validation champ par champ, des conditions plus globales sont déclarées. En premier lieu, certaines données sont nécessaires et il faut s’assurer de leur existence: <pre tabindex="0"><code>&#34;required&#34;: [ &#34;title&#34;, &#34;rue&#34;, &#34;npa&#34;, &#34;commune&#34;, &#34;canton&#34;, &#34;latitude&#34;, &#34;longitude&#34;, &#34;ouverture&#34;, &#34;horaire&#34; ] </code></pre>Beaucoup plus intéressant, l’obligation de la présence d’un site cible ou d’une fiche Google Maps (ou les deux): <pre tabindex="0"><code>&#34;anyOf&#34;: [ { &#34;required&#34;: [ &#34;site&#34; ]}, { &#34;required&#34;: [ &#34;maps&#34; ]} ] </code></pre>Finalement, l’interdiction d’ajouter des champs autres que ceux déclarés dans le schéma: <pre tabindex="0"><code>&#34;additionalProperties&#34;: false </code></pre><h2 id="assurances-formelles-et-validite-des-contenus">Assurances formelles et validité des contenus</h2> C’était mon premier essai de rédaction d’un schéma JSON. J’ai trouvé l’exercice plutôt intéressant. C’est toujours amusant de lire une référence technique sur un écran et d’écrire le fichier de code sur l’autre. Il faudrait aller un peu plus loin pour certaines données, par exemple avec des <a href="https://json-schema.org/understanding-json-schema/reference/regular_expressions#regular-expressions">expressions régulières</a> pour valider des plages horaires. Mais je m’arrête là pour le moment. L’enjeu bien réel derrière cet exercice, c’est que la validité formelle ne dit rien de la validité réelle des contenus. Elle assure la présence de contenus, non leur justesse. Il y a quelque chose de paradoxal à formaliser des données alors que les informations n’existent souvent pas en ligne. Le rachitisme du défunt Églises ouvertes en Suisse romande est une conséquence directe de la paresse de celles et ceux qui pourraient publier des contenus utiles. Mais pas une question de format de données. <hr> On me signale la <a href="https://jsoning.com/">plateforme JSONing</a> gratuite, créée par <a href="https://github.com/cyrilbois">Cyril Bois</a>. Elle permet notamment la <a href="https://jsoning.com/jsonschema/">création automatisée de JSON Schemas</a> à partir de sources JSON.</description></item><item><title>Création & affichage d’une page web</title><link>https://nicolasfriedli.ch/blog/creation-affichage-page-web/</link><pubDate>Sun, 17 Mar 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/creation-affichage-page-web/</guid><description>Dans le monde des Bisnounours: j’entre une adresse et le site est à l’écran. Mais dans la vraie vie, à chaque fois qu’une page s’affiche dans un navigateur, des centaines d’opérations ont eu lieu avant pour établir la connexion au serveur, pour générer la page sur le serveur, pour transférer des tas de fichiers, pour mettre en forme le résultat final. Note. Ce billet est une vulgarisation du sujet. Je fais l’impasse sur plusieurs étapes, je simplifie le propos et je commets des erreurs dans la chronologie des choses. Ces approximations ont une visée pédagogique; ce sont les grands principes qui comptent. <h2 id="se-rendre-sur-le-serveur">Se rendre sur le serveur</h2> L’adresse <code>https://nicolasfriedli.ch/blog/creation-affichage-page-web/</code> est saisie dans un navigateur ou un lien vers elle est suivi. Voici ce qui se passe: <ul> <li>Le navigateur va interroger un serveur de noms (DNS) pour savoir à quelle adresse IP correspond le nom de domaine <code>nicolasfriedli.ch</code>, par exemple <code>128.65.195.39</code>. Le modem, le périphérique ou le navigateur vont garder ce résultat en mémoire un certain temps.</li> <li>Puis le navigateur va demander la création d’une connexion sécurisée <code>https</code> et va vérifier la validité d’un certificat, stocker des informations de chiffrement, etc. Ici aussi, des informations sont conservées dans la durée.</li> </ul> ✅ Désormais, le navigateur est prêt. <h2 id="creation-de-la-page-sur-le-serveur">Création de la page sur le serveur</h2> Ce que demande le navigateur au serveur, c’est une page HTML (et rien d’autre pour le moment). Voici ce qui va se passer dans 3 cas distincts. <h3 id="avec-un-cms-comme-wordpress">Avec un CMS comme WordPress</h3> L’outil de gestion de contenu (CMS) va effectuer les opération suivantes: <ul> <li>recherche dans une base de données à quel numéro de billet correspond <code>/blog/creation-affichage-page-web</code></li> <li>recherche du contenu billet dans une autre table de base de données</li> <li>à partir de là, recherche du nom de l’auteur ou de l’autrice, recherche des différentes taxonomies utilisées</li> <li>recherche des informations sur le menu du site</li> <li>recherche des contenus des widgets</li> <li>recherche de la liste des derniers billets publiés</li> <li>et si le blog utilise des commentaires, recherche de tous les commentaires attribués au billet</li> <li>et peut être aussi les derniers commentaires sur tout le site pour les afficher en barre latérale</li> <li>etc.</li> </ul> Puis il va lire les gabarits de mise en page (templates) et assembler toutes les données reçues dans un seul fichier HTML. Il est enfin prêt à répondre au navigateur. Toutes ces opérations ont lieu pour chaque page du site et à chaque visite! ✅ Le HTML est envoyé. <h3 id="quand-le-cms-utilise-un-systeme-de-cache">Quand le CMS utilise un système de cache</h3> Afin de minimiser le travail inutile, un système de cache peut être utilisé. Il n’est malheureusement pas présent par défaut chez WordPress. Le principe est simple. Quand une page est demandée: <ul> <li>si la page existe déjà sur le serveur et si elle n’est pas trop ancienne, elle est envoyée telle quelle au navigateur</li> <li>si la page n’existe pas encore ou si elle est trop ancienne, elle est créée (en suivant toutes les étapes vues au point précédent) et stockée</li> </ul> Les opérations sur le serveur ne sont pas moins nombreuses, mais elles ne sont pas réalisées à chaque visite. Si le principe est simple, la mise en pratique est beaucoup plus compliquée. Par exemple, lorsque la barre latérale d’un site liste les derniers billets et que le titre du dernier billet est modifié, il faut invalider le cache de toutes les pages (alors que seuls quelques mots d’une page ont changé). Pour imaginer les enjeux pratiques: <a href="https://www.geeksforgeeks.org/cache-invalidation-and-the-methods-to-invalidate-cache/">Cache Invalidation and the Methods to Invalidate Cache</a>. ✅ Le HTML est envoyé. <h3 id="avec-un-site-statique">Avec un site statique</h3> Quand une page est demandée: <ul> <li>elle existe déjà et est livrée telle quelle</li> <li>sauf si le navigateur demande une page qui n’existe pas ou plus (une erreur 404 est retournée)</li> </ul> ✅ Le HTML est envoyé. <h2 id="affichage-de-la-page-dans-le-navigateur">Affichage de la page dans le navigateur</h2> Site dynamique, site statique, qu’importe désormais, le navigateur a reçu son fichier HTML. Il pourra donc se lancer dans l’affichage de la page. <h3 id="telechargement-des-ressources">Téléchargement des ressources</h3> Dans un premier lieu, le code HTML est intégralement lu et tous les fichiers nécessaires à la page sont demandés au serveur: <ul> <li>feuilles de style CSS (le modèle de mise en page)</li> <li>images</li> <li>code JavaScript</li> </ul> Le processus de création continue. <h3 id="creation-de-la-page">Création de la page</h3> Désormais, le navigateur utilise la structure (HTML) et la présentation (CSS) pour créer visuellement la page. Selon les informations qu’il aura trouvées dans le fichier CSS, il va charger de nouvelles ressources (par exemple des polices d’écriture particulières ou des images de fond). Si ces polices d’écriture se trouvent sur un autre nom de domaine, il va devoir refaire la requête DNS et la vérification des certificats de sécurité si ces données ne sont pas en mémoire. Le processus de création continue. <h3 id="interpretation-du-javascript">Interprétation du JavaScript</h3> Le code JavaScript est interprété. Le «logiciel navigateur» exécute un «logiciel JavaScript» pour avancer dans la création de la page. Ce code peur servir à: <ul> <li>afficher un menu dynamique</li> <li>envoyer des statistiques à un service tiers</li> <li>chercher des données utiles pour affichage sur la page</li> </ul> Mais aussi à inclure des widgets des réseaux sociaux, qui eux-mêmes vont rechercher plus de JavaScript, du code HTML et CSS, etc. ✅ En principe, la page est terminée. <h3 id="quelques-donnees-statistiques">Quelques données statistiques</h3> Le Web Almanac 2022 donne les résultats de tests pour plus de 8 millions de sites. Quelques résultats extraits de la rubrique <a href="https://almanac.httparchive.org/en/2022/page-weight">Page Weight</a>: <ul> <li>quand 1 page s’affiche, ce n’est pas 1 seul fichier qui voyage sur les réseaux, mais 70 (mesure médiane)</li> <li>et ce sont plus de 2MB de données qui sont envoyées</li> <li>en valeur médiane, ce sont 22 images pour une seule page</li> <li>et 20 fichiers en JavaScript (qui devront tous être exécutés dans le navigateur)</li> <li>le poids des pages web a été multiplié par 6 en 10 ans</li> </ul> Le souci que nous avons aujourd’hui, c’est que les serveurs, les réseaux et les périphériques (ordinateur, tablette, téléphone, etc.) sont devenus si performants que l’on ne voit plus tout ce qui y transite et tous les calculs effectués. Pour maintenir un niveau de performance correct, au vu de la lourdeur des sites, il faut changer plus souvent de matériel. Écologiquement, c’est lamentable. <h2 id="apres-la-visite">Après la visite</h2> Lors de l’envoi des différentes ressources au navigateur, le serveur devrait lui transmettre des informations de conservation. C’est un cache local du navigateur, différent de celui qui peut être utilisé dans les CMS. Par exemple: <ul> <li>l’image du logo de l’entreprise, qui s’affiche en haut à gauche de la page, peut être conservée durant 1 mois</li> <li>le feuille de style CSS est valable 1 semaines</li> <li>le polices d’écriture (si elles ne sont pas chargées chez Google Fonts), peuvent être conservées durant 6 mois</li> </ul> Ainsi, tous les fichiers ne sont pas chargés à chaque visite, ce qui est serait un gâchis immense. Malheureusement, beaucoup de sites gèrent mal le cache ou ne l’utilisent pas du tout. <h2 id="difference-entre-statique-et-dynamique">Différence entre statique et dynamique</h2> Pour faire simple, une page web, telle que nous la voyons, ne préexiste jamais. Une page est toujours assemblée dans le navigateur à partir de HTML, de CSS, de JavaScript et des fichiers multimédia. Mais: <ul> <li>avec un site statique, tout ce qui peut l’être est déjà prêt et optimisé sur le serveur</li> <li>avec un site dynamique, toute une machinerie se met en route sur le serveur pour chaque page et chaque internaute</li> </ul> Le vrai problème avec les sites dynamiques, quel que soit l’outil (WordPress, Drupal, Typo3, etc.), c’est quand ils motorisent des sites vitrines qui évoluent peu. À quoi bon calculer chaque page pour chaque internaute si rien de change d’une personne à l’autre. C’est de la bande passante et de l’énergie jetées par les fenêtres. Mais rien n’est perdu. Il reste de nombreuses de possibilités de faire un site lent et peu écologique avec un générateur de sites statiques, car <a href="https://jamstatic.fr/2020/10/05/la-jamstack-n-est-rapide-que-si-vous-la-rendez-rapide/">La Jamstack n’est rapide que si vous y veillez</a>. Tout est envisageable pour publier des images trop grandes, saturer le site de JavaScript, le pourrir de tierces parties inutiles et mal gérer son cache.</description></item><item><title>Site statique, générateur de site & Hugo</title><link>https://nicolasfriedli.ch/blog/site-statique-generateur-hugo/</link><pubDate>Sat, 16 Mar 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/site-statique-generateur-hugo/</guid><description>Ce site est motorisé par Hugo, je vous dis pourquoi j’ai choisi ce générateur de sites statiques. Mais avant, je vous dis pourquoi je pense qu’un générateur de sites statiques est une bonne idée. Et avant, je vous dis pourquoi un site statique – même généré à la main – est intéressant. Bon voyage dans ce billet en 3 étapes. Note. Ce billet suppose que vous savez déjà ce qu’est un site statique. <h2 id="pourquoi-un-site-statique">Pourquoi un site statique?</h2> Un site statique envoie au client les contenus exacts qui existent déjà sur le serveur, sans modifications autres qu’une éventuelle compression à la volée. Voici ce que je considère comme les principales forces des sites statiques: <ul> <li> Un site statique est pérenne. S’il fonctionne un jour, il fonctionnera de la même manière le lendemain. Le site restera valable tant que les navigateurs sauront interpréter HTML, CSS et JavaScript. Les navigateurs arrivent toujours à se débrouiller du vieux code ou ils n’arrêteront pas de le comprendre soudainement. </li> <li> Un site statique est performant par nature. Parce que le contenu qui sera envoyé est déjà prêt sur le serveur, il n’est pas possible de faire plus léger. </li> <li> Un site statique est écologique, parce qu’il ne demande pas de calculs inutiles au serveur ni la présence de la base de données. Ils sont construits une fois pour toutes. Bien évidemment, il sera encore plus écologique chez un hébergeur écoresponsable, sans envoyer des vidéos inutiles, avec des images correctement dimensionnées, en faisant l’impasse sur les plugins des réseaux sociaux ou les statiques gourmandes en énergie, avec des polices système, etc. De </li> <li> Une sauvegarde d’un site statique existe quelque part. Si le code est géré par sur GitHub par exemple, il est probable que des copies se trouvent sur au moins un ordinateur, sur le serveur de GitHub et sur le serveur Apache de l’hébergeur. Même sans système de gestion de versions, il existe probablement un site local et un site distant. En gros, à part si tout est géré à distance par FTP, il existe une sauvegarde exacte du site. </li> <li> L’historique du site est entièrement disponible si le développement utilise un outil comme Git (distant ou local). </li> <li> La sécurité d’un site statique est assurée. Il n’offre pas d’accès à une interface d’administration distante, il ne stocke pas de données, etc. </li> <li> Finalement, un site statique est portable. Sa migration d’un serveur à un autre se résume à la copier de fichiers. En cas de problème, c’est une démarche facile et rapide; le temps étant proportionnel à la masse de données à copier. </li> </ul> Mais avant de mettre son site sur un serveur, il faut le créer. Passons au point suivant. <h2 id="pourquoi-un-generateur-de-sites-statiques">Pourquoi un générateur de sites statiques?</h2> Fondamentalement, un générateur de sites statiques ou SSG (static site generator) est un outil qui permet d’automatiser des tâches répétitives. Il existe <a href="https://jamstack.org/generators/">des centaines de générateurs de sites</a>, avec différentes visées et dans différents langages. Mais voici quelques généralités sur le sujet: <ul> <li> Un générateur de sites statiques permet de simplifier la rédaction de contenus. L’utilisation de Markdown ou un autre <a href="https://fr.wikipedia.org/wiki/Langage_de_balisage_l%C3%A9ger">langage de balisage léger</a> facilite et accélère le travail laborieux de saisie de code HTML. </li> <li> La mise en page est automatisée par un système de gabarits (templates), par exemple en réutilisant le même entête ou le même pied sur chaque du site. Et en répercutant chaque modification sur toutes les pages. </li> <li> Les tâches répétitives sont réalisées par une machine plutôt que par un cerveau humain. Un ordinateur sera beaucoup plus efficace et fiable que vous et moi pour créer une liste de pages d’un répertoire triée par dates, pour générer un fichier RSS ou Atom valide, pour exporter les contenus de tout le site en format JSON pour un moteur de recherche, etc. </li> <li> Des optimisations sur les fichiers texte (HTML, CSS, JavaScript, XML, etc.) sont effectuées à la génération: minification, nettoyage, concaténation, etc. </li> <li> Les images sont redimmensionnées, allégées, modifiées au moment de la création du site. Le travail fastidieux de création d’<a href="https://developer.mozilla.org/fr/docs/Learn/HTML/Multimedia_and_embedding/Responsive_images">images adaptatives</a> est effectuée par une machine. </li> <li> Le développement avec un générateur des sites statiques rend agréable la prévisualisation du site en local. C’est aussi possible sans SGG, mais souvent moins agréable. </li> <li> D’autres automatisations existent, comme la colorisation sytaxique du code pour en simplifier la lecture, la génération d’images pour les réseaux sociaux, l’activation d’un moteur de recherche interne, etc. </li> </ul> Beaucoup d’outils permettent tout ou partie de ces opérations (et d’autres). Parmi ceux que j’ai utilisés et utilises encore: <a href="https://www.11ty.dev/">Eleventy</a> (11ty), <a href="https://www.sphinx-doc.org/en/master/">Sphinx</a> ou <a href="https://squidfunk.github.io/mkdocs-material/">Material for MkDocs</a>. Mais il y a surtout Hugo, qui motorise ce site et pas mal d’autres que j’ai créés. Passons au point suivant. <h2 id="pourquoi-jai-choisi-hugo">Pourquoi j’ai choisi Hugo?</h2> <a href="https://gohugo.io/">Hugo</a> est donc un des principaux générateurs de site statiques. Il est plutôt généraliste et je le choisis a priori pour mes projets (sans exclure d’autres outils pour des développements plus spécifiques). Voici ce qui m’a convaincu chez Hugo: <ul> <li> L’installation est triviale, par la copie d’un seul fichier exécutable. Il ne demande aucun écosystème préalable (par exemple Python ou Node). Il peut être utilisé sur un ordinateur sans droits d’administration. Corollaire: le logiciel est pérenne car sans dépendances. Il pourrait toujours générer le site dans plusieurs années et peut être stocké dans le répertoire des sources du site. </li> <li> Il est conçu selon une logique «classique» que je trouve pertinente dans la très grande majorité des cas. Il existe des types implicites comme des listes (qui proposent les contenus des répertoires et sous-répertoires) et des pages simples (qui sont le contenu). Le fichier de configuration est un simple fichier de configuration. La séparation entre les templates et les contenus est évidente. </li> <li> La gestion du multilinguisme est aboutie et disponible par défaut. C’est très important quand on travaille en Suisse. </li> <li> Les taxonomies et les relations entre les pages sont très performantes. Notamment la notion de related que j’utilise par exemple dans mon projet d’<a href="https://nicolasfriedli.ch/blog/annuaire-protestant/">annuaire protestant en ligne</a>. </li> <li> La conception monolithique du logiciel fait que tout est inclus (batteries included). C’est parfois considéré comme une limitation, par rapport à un système modulaire (plugins), mais c’est un avantage dans la très grande majorité des cas. </li> <li> Hugo est très rapide à la compilation. Il y a débat pour savoir sur c’est le générateur le plus rapide, mais je m’en balance. Je sais qu’il me permet de travailler le code ou le contenu sur un écran et voir le résultat en temps réel sur mon second écran. C’est tout ce que je souhaite. </li> <li> Il permet par défaut des optimisations raisonnables dans la minification des fichiers texte et le travail sur les images. Sans être forcément le plus performant, son rapport entre le résultat et l’investissement (en temps de compilation ou en complexité de développement) est excellent. C’est l’efficience dont je parle dans <a href="https://nicolasfriedli.ch/blog/optimisation-raisonnable/">Philosophie d’optimisation raisonnable </a>. </li> <li> Finalement, Hugo dispose d’une bonne communauté, tant du point de vue de la quantité d’informations disponibles que de la qualité des rapports entre personnes. </li> </ul> Le code de plusieurs projets que je développe avec Hugo est disponibles dans <a href="https://github.com/nfriedli/">mon compte GitHub</a>. C’est le cas des <a href="https://github.com/nfriedli/">sources de ce site</a>. <hr> Je pense que ce billet sera complété ou revu régulièrement. Il y a des choses auxquelles je n’ai pas pensé; d’autres que je pense assez marginales pour ne pas en parler aujourd’hui. Mais tous vos retours sont bienvenus pour essayer de l’améliorer.</description></item><item><title>Feuilles de style minifiées et gestion du cache</title><link>https://nicolasfriedli.ch/blog/css-minification-cache/</link><pubDate>Fri, 15 Mar 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/css-minification-cache/</guid><description>Ce que j’applique en général pour la minification et la mise en cache des feuilles de style. C’est une optimisation raisonnable qui utilise certaines fonctions natives d’Hugo mais évite trop de complexité. <h2 id="utiliser-une-feuille-de-style-externe">Utiliser une feuille de style externe</h2> La version la plus simple pour déclarer une feuille de style CSS, c’est un appel dans l’entête HTML: <pre tabindex="0"><code>&lt;link rel=&#34;stylesheet&#34; href=&#34;/css/style.css&#34;&gt; </code></pre>Pour que la feuille de style se trouve bien à l’endroit référencé après une compilation par Hugo, on la place dans: <code>/static/css/style.css</code>. Le fichier est seulement copié, sans aucune modification, et placé dans le répertoire du site compilé: <code>/public/css/style.css</code>. C’est le principe de fonctionnement pour les <a href="https://gohugo.io/getting-started/directory-structure/#static">fichiers statiques</a> chez Hugo. Tout ce qui se trouve dans le répertoire <code>/static/</code> est copié tel quel, avec la même hiérarchie, dans <code>/public/</code>. <h2 id="minification-des-css-par-hugo">Minification des CSS par Hugo</h2> C’est une bonne idée de minifier les feuilles de style. La copie seule est alors insuffisante (à moins de placer un fichier minifié par un outil tiers dans <code>/static/</code>, évidemment) Je place donc la feuille de style de départ dans <code>/assets/css/screen.css</code>. Comme son nom l’indique, elle est spécifique à l’affichage sur un écran. Le répertoire <code>/assets/</code> permet d’effectuer des opérations sur les fichiers qu’il contient. Ici: <pre tabindex="0"><code>{{ $screen := resources.Get &#34;css/screen.css&#34; | minify }} &lt;link rel=&#34;stylesheet&#34; href=&#34;{{ $screen.RelPermalink }}&#34; media=&#34;screen&#34;&gt; </code></pre>La première ligne va chercher le fichier, relativement au répertoire, <code>/assets/</code> et le minifie. J’utilise pour cela un filtre. La seconde ligne appelle le fichier final en HTML. Le fichier produit sera <code>/public/css/screen.min.css</code>. Je procède de même pour la feuille de style dédiée à l’impression: <pre tabindex="0"><code>{{ $print := resources.Get &#34;css/print.css&#34; | minify }} &lt;link rel=&#34;stylesheet&#34; href=&#34;{{ $print.RelPermalink }}&#34; media=&#34;print&#34;&gt; </code></pre>Le fichier produit se trouvera au même endroit que celui dédié à l’impression. Son nom portera, lui aussi, la trace de la minification par <code>.min.</code>. <h2 id="fingerprint-et-cache-long">Fingerprint et cache long</h2> Il est possible de mettre en cache les feuilles de style pour une très longue durée. C’est pourquoi je souhaite que le nom de fichier final soit unique. C’est facile avec <a href="https://gohugo.io/hugo-pipes/fingerprint/">fingerprint</a>: <pre tabindex="0"><code>{{ $screen := resources.Get &#34;css/screen.css&#34; | minify | fingerprint }} &lt;link rel=&#34;stylesheet&#34; href=&#34;{{ $screen.RelPermalink }}&#34; media=&#34;screen&#34;&gt; </code></pre>Ainsi, le nom final sera quelque chose comme: <pre tabindex="0"><code>/css/screen.min.215a9ff1ab8351ee4d0a3c644904e7ab4945a1fa3d70197a0735fc3e43195476.css` </code></pre>Double avantage de la démarche: <ul> <li>la certitude que la feuille de style qui s’applique à la page actuelle est toujours la bonne (et jamais une autre CSS en mémoire dans le navigateur)</li> <li>la possibilité de proposer une durée de cache très longue pour ne jamais recharger la feuille de style si elle existe déjà dans le navigateur</li> </ul> Cela se passe dans <code>.htaccess</code> avec un serveur Apache: <pre tabindex="0"><code>&lt;filesMatch &#34;.(css)$&#34;&gt; Header set Cache-Control &#34;max-age=63072000,immutable&#34; &lt;/filesMatch&gt; </code></pre>Ou dans <code>_headers</code> chez Netlify: <pre tabindex="0"><code>/css/* Cache-Control: max-age=63072000,immutable </code></pre>Tant que le style n’a pas été modifié, le fichier n’est pas téléchargé. C’est clair et efficace. <h2 id="integrer-la-feuille-de-style">Intégrer la feuille de style</h2> Sur ce site, j’intégre le CSS dans le code HTML. C’est favorable lors de la première visite d’une page: <pre tabindex="0"><code>{{ $screen := resources.Get &#34;css/screen.css&#34; }} &lt;style media=&#34;screen&#34;&gt;{{ $screen | safeCSS }}&lt;/style&gt; </code></pre>Mais c’est potentiellement contre-productif si l’internaute lit plusieurs pages ou revient sur le site. Toutefois, le gain d’une solution ou de l’autre est toujours minime sur un site léger comme le mien. Quand le style est intégré, on pourrait aller plus loin et nettoyer chaque page de ses styles inutiles. C’est ce que fait Max Böck avec son <a href="https://mxb.dev/blog/emergency-website-kit/">site d’urgence avec Eleventy (11ty)</a>. C’est impossible avec Hugo sans outils externes et le gain est marginal. <h2 id="outils-hugo-non-utilises-sur-mon-blog">Outils Hugo non utilisés sur mon blog</h2> Il me semble que les options choisies sont pertinentes et suffisantes pour ce site. Mais Hugo propose d’autres possibilités. Par exemple: <ul> <li>Réunir des feuilles de style avec <a href="https://gohugo.io/hugo-pipes/bundling/">Concat</a>. C’est inutile puisque je ne n’ai qu’un fichier (par type de média).</li> <li>Ajouter une vérification par <a href="https://gohugo.io/hugo-pipes/fingerprint/#usage">Subresource Integrity</a>. C’est pertinent si l’on dépose ses CSS sur un serveur tiers (par exemple un CDN) et que l’on veut être certain qu’elles n’ont pas été modifiées.</li> <li>Traiter la feuille de style avec SASS par la commande <a href="https://gohugo.io/hugo-pipes/transpile-sass-to-css/">ToCSS</a>. Je préfère l’utilisation des variables CSS. La version de SASS embarquée dans Hugo n’est plus mise à jour. Et la version Dart exige des dépendances externes.</li> <li><a href="https://zwbetz.com/how-to-use-purgecss-with-hugo/">Supprimer les styles non utilisés avec PurgeCSS</a> comme le propose Zachary Wade Betz. C’est utile sur un site avec une grande feuille de style (par exemple un framework CSS), mais pas ici.</li> </ul></description></item><item><title>Proposer un annuaire protestant en ligne</title><link>https://nicolasfriedli.ch/blog/annuaire-protestant/</link><pubDate>Mon, 04 Mar 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/annuaire-protestant/</guid><description>Avec theologique.ch, je propose un annuaire protestant (réformé) francophone en ligne. C’est un outil et non une finalité en soi. Voici quelques raisons qui m’ont poussé à créer ce site. Cet annuaire n’a pas rencontré son public et n’est plus en ligne! <h2 id="etablir-un-etat-des-lieux">Établir un état des lieux</h2> Il y a presque 10 ans, j’avais proposé un recensement lors des Assises du web protestant romand. L’<a href="https://theologique.ch/">annuaire protestant theologique.ch</a> que je fournis aujourd’hui est une version plus développée de ce qui avait été fait à ce moment-là. Des discussions existent, à différents niveaux décisionnels, pour savoir quelles présences en ligne il faut envisager. Il me paraît impensable d’imaginer des choses nouvelles ou différentes sans connaître ce qui existe actuellement. L’état des lieux que constitue theologique.ch est une brique nécessaire, mais insuffisante pour réfléchir aux questions de présence sur le web. <h2 id="evaluer-le-web-protestant-francophone">Évaluer le web protestant francophone</h2> Pour construire theologique.ch, j’ai parcouru tous les sites référencés (et bien d’autres). Pour chacun, j’ai navigué assez pour rédiger une description sommaire. Ce travail m’a permis une redécouverte du web protestant réformé francophone que je connais un peu mieux qu’avant. Même si je n’ai pas systématiquement <a href="https://nicolasfriedli.ch/blog/tester-site/">testé les sites</a> consultés, quelques minutes de navigation et de lecture sur chacun d’eux me donnent un bon aperçu de leur état (contenu, menus, voire performances ou accessibilité). Cela m’est utile en tant que webmaster de certains sites protestants, pour savoir comment ils se positionnent par rapport au panorama général. <h2 id="trouver-des-sites-sans-moteur-de-recherche">Trouver des sites sans moteur de recherche</h2> Pourquoi construire un annuaire alors que les moteurs de recherche, Google en premier lieu, sont aujourd’hui si performants? À mes yeux, la réponse est évidente: je n’aurais jamais réussi à construire un annuaire sans liens sur certains sites consultés. Quelle que soit l’efficacité des moteurs de recherche, ils ne donneront presque jamais certains sites de theologique.ch dans les résultats de recherche (SERP). Sauf, bien entendu, si l’on sait quel site on veut trouver a priori. La présence de liens est un formidable moyen de rendre visibles des sites que l’on estime pertinents dans un contexte donné. J’ai découvert ces sites sur des pages de liens, dans des blogrolls, dans des pages de partenariats ou dans le corps du texte. Toutefois, il m’en reste encore à découvrir, par vos suggestions. <h2 id="favoriser-la-decouverte">Favoriser la découverte</h2> Sur chaque page de l’annuaire qui présente un site, il existe plusieurs actions possibles: <ul> <li>le clic sur le site en question (qui s’ouvre dans une nouvelle page)</li> <li>le retour à l’accueil</li> <li>le clic sur la (ou les) catégorie(s) du site</li> <li>la consultation d’autres sites proposés</li> </ul> theologique.ch rend visibles d’autres propositions pertinentes, en fonction du contexte. C’est la raison pour laquelle je n’ajoute pas de moteur de recherche sur le site pour le moment. De plus, je suis convaincu que cette mise en relation est favorable pour les moteurs de recherche. Je signale que le lien sortant vers le site cible est toujours visible en tant qu’URL simplifiée, afin d’aider à la mémorisation des noms de domaine qui existent. <h2 id="travailler-avec-hugo">Travailler avec Hugo</h2> Le <a href="https://gohugo.io/">générateur de sites statiques Hugo</a> motorise theologique.ch. J’avais envie de travailler avec les taxonomies et les liens de type à voir aussi ou peut aussi vous intéresser. Hugo dispose de possibilités intéressantes dans ce domaine avec <a href="https://gohugo.io/methods/pages/related/">Related</a>. Chaque page qui propose un site est classée: <ul> <li>dans une ou plusieurs rubriques (tags), toutes disponibles sur la page d’accueil</li> <li>avec un ou plusieurs précisions (keywords), comme le type de site ou sa localisation, pour améliorer les choix des sites en lien, mais pas affichés</li> <li>avec parfois une entrée supplémentaire (editors), pour créer une relation forte quand une même entité ou personne édite plusieurs sites</li> </ul> En JSON, cela se présente ainsi: <pre tabindex="0"><code>{ &#34;title&#34;: &#34;Cèdres Formation&#34;, &#34;site&#34;: &#34;https://cedresformation.ch/&#34;, &#34;tags&#34;: [&#34;formation&#34;,&#34;spiritualité&#34;], &#34;keywords&#34;: [&#34;vaud&#34;], &#34;editors&#34;: [&#34;cedres&#34;] } </code></pre>Ensuite, une pondération de ces 3 taxonomies permet d’afficher une liste de suggestions, limitée à 5 sites. Avec une telle méthode, j’espère faire émerger des propositions de mise en relations auxquelles je ne penserais pas spontanément. Et j’espère aussi pouvoir classer beaucoup de sites sans m’égarer dans l’élaboration de menus complexes (et difficiles à maintenir). <h2 id="faciliter-le-partage-de-liens">Faciliter le partage de liens</h2> Même si j’ai découvert des sites par des liens sur d’autres, le maillage du protestantisme réformé francophone reste lacunaire. Il me semble que theologique.ch est une esquisse de solution simple et efficace. Chaque site qui fait un lien vers la page d’accueil de theologique.ch ou n’importe quelle page de l’annuaire renforce au final l’ensemble des sites référencés. Je ne peux que conseiller à toutes les personnes qui administrent des sites d’ajouter un renvoi vers theologique.ch dans leur blogroll, sur leur page de liens ou dans un contenu éditorial. Mais je ne demanderai jamais de lien en retour pour ajouter un site dans l’annuaire. <h2 id="en-resume">En résumé</h2> Ce que je retire de la création de theologique.ch: <ol> <li>Mieux vaut un annuaire incomplet que pas d’annuaire du tout.</li> <li>En recherchant des informations utiles sur des sites (pour rédiger les descriptions), j’ai appris beaucoup sur l’état du web protestant réformé francophone.</li> <li>Les moteurs de recherche ne remplacent pas les vrais liens.</li> <li>Les liens contextuels apportent plus que des listes simples «plates».</li> <li>Hugo permet une gestion performante des taxonomies.</li> <li>Mieux vaut des liens vers un site centralisé que pas de liens du tout.</li> </ol></description></item><item><title>Conseils d’utilisation des QR codes</title><link>https://nicolasfriedli.ch/blog/conseils-qr-code/</link><pubDate>Wed, 14 Feb 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/conseils-qr-code/</guid><description>Les arnaques aux QR codes semblent se multiplier. Les médias généralistes en parlent et donnent quelques conseils, souvent aux utilisateurs et utilisatrices (par exemple: <a href="https://www.rts.ch/info/sciences-tech/14581852-les-arnaques-aux-qr-codes-se-multiplient-depuis-quelques-mois.html">Les arnaques aux QR codes se multiplient depuis quelques mois</a>). Pourtant, j’estime que l’effort de sécurisation et de fiabilité doit aussi être fait du côté des personnes qui créent les codes. Je parle en priorité des codes qui dirigent vers une page web, mais plein d’autres utilisations sont possibles. La page <a href="https://www.ncsc.admin.ch/ncsc/fr/home/infos-fuer/infos-private/aktuelle-themen/qr-code-anwendungen-und-risiken.html">Codes QR – applications et risques</a> sur le site de la Confédération suisse donne quelques exemples d’utilisations et de problèmes potentiels. <h2 id="petits-et-grands-problemes">Petits et grands problèmes</h2> Si un code qui ne fonctionne pas comme prévu est toujours un problème, il faut tout de même hiérarchiser les soucis: Parfois, un QR code ne fonctionne pas. Il renvoie à une adresse (URL) qui n’existe pas ou plus. C’est frustrant, décevant, l’image de l’institution en prend un coup. Les conséquences sont toutefois limitées. Dans d’autres cas, le QR code renvoie à la mauvaise adresse. Soit l’adresse a toujours été problématique, soit la destination (via une redirection) a été modifiée, intentionnellement ou non. Difficile de mesurer les conséquences: un détournement peut être amusant, insultant, sans intérêt, mauvais pour l’image, choquant, provocant, etc. Finalement, un QR code est utilisé pour une arnaque. Le code de départ est remplacé ou le système de redirection piraté, et les internautes arrivent sur un faux site qui cherche à voler des informations. Le code n’est qu’un maillon de la chaîne d’un système organisé. Les conséquences peuvent être importantes et on sort du domaine technique pour entrer dans les questions de loi et de justice. <h2 id="conseils-lors-de-lutilisation">Conseils lors de l’utilisation</h2> Les utilisateurs et utilisatrices de QR codes ont intérêt à adopter quelques réflexes utiles. <h3 id="avant-de-scanner">Avant de scanner</h3> Il faut vérifier aussi bien que possible si le code n’a pas été remplacé par un autre. Un autocollant posé sur un ancien code est suspect, sans être forcément frauduleux. Il vaut également la peine de se poser la question de la pertinence du code. Si on vous promet l’accès à un wifi gratuit en pleine rue, sur un petit autocollant collé sur un lampadaire, il n’est pas toujours judicieux de le scanner. <h3 id="apres-avoir-scanne-mais-avant-de-cliquer">Après avoir scanné mais avant de cliquer</h3> Une fois le code scanné, le téléphone propose l’ouverture d’un lien, l’acceptation d’un réseau wifi, un paiement sur Twint, etc. Il est possible de contrôler la destination du code à ce moment-là. Quand une institution officielle propose un QR code, je trouve qu’elle devrait toujours renvoyer à son nom de domaine. <h3 id="en-arrivant-sur-le-site">En arrivant sur le site</h3> Si le clic a été effectué mais que le site de destination semble bizarre, il est encore temps d’arrêter les frais. En particulier quand des informations personnelles ou de paiement sont demandées ou quand une application est proposée à l’installation (surtout si elle n’avait pas été mentionnée dans le texte qui accompagne souvent le code). <h2 id="conseils-lors-de-la-creation">Conseils lors de la création</h2> Les conseils précédents sont destinés aux utilisateurs et utilisatrices. Les suivants sont destinés à celles et ceux qui créent et rendent publics des QR codes. <h3 id="utiliser-son-propre-nom-de-domaine">Utiliser son propre nom de domaine</h3> Je pense que l’utilisation de raccourcisseurs d’URL est souvent une mauvaise idée. Infomaniak vient de lancer son service <a href="https://chk.infomaniak.com/">chk.me</a>. Personne ne pourra savoir quelle sera l’URL finale qui se cache derrière cette version courte. L’utilisation de son propre nom de domaine est une garantie de sécurité. Il peut être utilisé de 2 manières: <ul> <li>en renvoyant à une URL directe (peut-être longue), en générant un code dans un outil tiers ou directement dans son navigateur</li> <li>en renvoyant à une URL spécifique (souvent plus courte), redirigée par <code>.htaccess</code>, son outil de gestion de contenu (par exemple <a href="https://fr.wordpress.org/plugins/redirection/">Redirection</a> pour WordPress) voire par son propre système de redirection</li> </ul> C’est sans discussion la solution la plus simple et la plus efficace. En complément, je propose de toujours écrire en toutes lettres l’adresse vers laquelle le code est censé renvoyer. <h3 id="proposer-un-support-non-accessible">Proposer un support non accessible</h3> Quand un code est affiché quelque part, tout est bon pour le rendre non accessible directement: <ul> <li>affichage dans une vitrine ou derrière une vitre</li> <li>affichage sur un écran ou en image projetée</li> <li>affichage dans un endroit inaccessible (en hauteur, derrière un guichet, au plafond, etc.)</li> </ul> <h3 id="rendre-la-substitution-complexe">Rendre la substitution complexe</h3> Si la modification d’un QR code est très difficile, la génération d’un autre code et la substitution sont très simples (sauf quand le support est difficilement accessible). Plutôt que d’imprimer seulement un petit autocollant sur fond blanc, on peut imprimer le code sur un papier à entête officiel de l’institution, et pourquoi pas y ajouter une marque au tampon encreur. D’autres pistes existent comme le papier holographique ou la gravure sur une plaque métallique. Comme pour l’argent liquide, c’est la complexité et le coût de la falsification qui la rendront moins intéressante. <h3 id="modifier-lurl-finale-plutot-que-remplacer">Modifier l’URL finale plutôt que remplacer</h3> Parfois, des adresses changent. Plutôt que de coller un nouveau code (suspect) sur l’ancien, il est préférable de modifier l’URL finale. C’est une démarche facile avec son propre nom de domaine et des redirections. Ainsi, le support ne sera pas modifié par ajouts successifs. De plus, c’est pertinent dans le cas où un QR code est utilisé à plusieurs endroits. Plutôt que de faire modifier le support à un moment précis, la redirection est instantanée et généralisée. <h3 id="verifier-regulierement-le-fonctionnement">Vérifier régulièrement le fonctionnement</h3> Quand un code est utilisé par une organisation, une institution ou une entreprise, je conseille de demander aux membres et employé·es de le vérifier régulièrement. Un scan rapide permet de s’assurer qu’il fonctionne toujours et qu’il renvoie au bon endroit. C’est de plus une bonne incitation à utiliser régulièrement cet outil. <h3 id="supprimer-proprement-les-codes-invalides">Supprimer proprement les codes invalides</h3> Finalement, quand une page de destination est désactivée, il faut agir intelligemment: <ul> <li>s’il est certain que le QR code n’était affiché qu’en un endroit, il peut être simplement supprimé</li> <li>mais quand le code était utilisé à plusieurs endroits, il vaut mieux conserver une redirection, par exemple vers une page générique qui annonce sa désactivation (ou à défaut sur la page d’accueil de son site)</li> </ul> D’un point de vue technique, je pense que toutes les URL courtes (sur son nom de domaine) ne devraient jamais être utilisées pour renvoyer ailleurs après une désactivation. En version courte: nouvelle redirection oui, réutilisation non. C’est le principe d’un identifiant unique (UID). <hr> Ajout du 15 mars 2024. Quelques jours après la publication de ce billet, ma commune de Milvignes publiait sur son site un <a href="https://web.archive.org/web/20240313084500/https://www.milvignes.ch/communications/detail/probleme-avec-les-qr-codes-du-milvignes-infos-de-mars-2024-ne-pas-les-utiliser">problème de QR codes</a>. Elle avait utilisé un système de redirection (qr.codes ou qr.io) payant plutôt que de renvoyer directement à son propre nom de domaine. La période d’essai était expirée; les codes invalides&hellip; <hr> Ajout du 29 juillet 2024. Dans son billet <a href="https://shkspr.mobi/blog/2024/07/qr-code-hijacking-attempts-are-pretty-inept/">QR Code Hijacking Attempts Are Pretty Inept</a>, Terence Eden montre quelques exemples de fraudes, puis insiste sur une URL officielle. On ne le dira jamais assez: votre nom de domaine est capital. <hr> Ajout du 16 janvier 2024. À partir de sa version 0.141.0, le générateur de sites statiques Hugo (utilisé ici) permet de créer des codes à la volée. Si je veux créer un code avec l’adresse de mon site, je tape quelque chose comme: <pre tabindex="0"><code>{{&lt; qr text=&#34;https://nicolasfriedli.ch&#34; /&gt;}} </code></pre>Sans passer par un service tiers, j’obtiens une image légère, hébergée sur mon propre site et pérenne, à l’exemple des permaliens de bas de page.</description></item><item><title>Tester un site web</title><link>https://nicolasfriedli.ch/blog/tester-site/</link><pubDate>Tue, 13 Feb 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/tester-site/</guid><description>Il n’est pas rare que l’on me demande ce que je pense d’un site web personnel ou professionnel. Une petite phrase lâchée dans une discussion informelle: <blockquote> J’ai un nouveau site, est-ce que tu jettes un coup d’œil et tu me dis ce que tu en penses?</blockquote> Voici quelques tests que je vais effectuer sans délai pour me faire une idée. Car je ne vais pas me contenter de regarder le site et de naviguer sur quelques pages. L’ordre des tests dépendra de ce que je vais trouver dans mes investigations. <h2 id="ouvrir-le-site">Ouvrir le site</h2> Dans un premier temps, je vais me rendre sur le site, sur sa page d’accueil. Je vais jeter un premier regard rapide, m’intéresser à la taille de la police, aux contrastes, à la mise en page, etc. afin de voir si tout semble normal. En principe, jusqu’ici, tout va plutôt bien. Puis je vais désactiver le cache du navigateur et limiter la bande passante. Je vais contrôler le poids des ressources qu’il télécharge et leur provenance au rechargement de la page. J’aurai une idée de la vitesse d’affichage. Il n’est pas rare que des lenteurs et des lourdeurs soient déjà perceptibles. <h2 id="lancer-pagespeed-insights">Lancer PageSpeed Insights</h2> Ensuite, je vais coller l’adresse du site dans <a href="https://pagespeed.web.dev/">PageSpeed Insights</a>. Si les 4 résultats sont verts, c’est bon signe. Si certains résultats sont orange, ils deviendront naturellement des points d’attention. Si des résultats sont rouges, je vais focaliser mes investigations dans ces domaines avant tout. <h2 id="regarder-letat-du-referencement">Regarder l’état du référencement</h2> Puis je me rendrai dans Google et effectuerai une recherche du type <code>site:nicolasfriedli.ch</code>. Ainsi j’aurai une idée: <ul> <li>du nombre de pages référencées</li> <li>de la qualité de l’affichage des résultats de recherche (SERP)</li> </ul> Si le site est très récent et qu’il n’est pas affiché, je le signalerai. Si le site est ancien et peu présent (ou mal affiché), je lancerai la thématique du référencement. À quoi bon un site, même excellent, que l’on ne trouve pas. <h2 id="naviguer-sur-plusieurs-peripheriques">Naviguer sur plusieurs périphériques</h2> Par la suite, je vais ouvrir le site sur plusieurs ordinateurs, avec des écrans de plusieurs tailles, différents systèmes d’exploitation et navigateurs. Je vais y naviguer sur ma tablette et sur mon smartphone. Je vais redimensionner la fenêtre manuellement, essayer de zoomer le texte, vérifier des contrastes. J’essaierai de m’y rendre à plusieurs moments de la journée, parce qu’un site n’est pas le même en plein soleil ou dans la pénombre. <h2 id="tester-la-navigation-au-clavier-et-laccessibilite">Tester la navigation au clavier et l’accessibilité</h2> Je vais retourner sur la page d’accueil et tenter de naviguer en utilisant mon seul clavier. Je verrai si l’utilisation des menus est fluide, si l’ordre des liens est correct, s’ils sont visibles à la sélection, etc. C’est un test d’accessibilité (A11Y) basique, que je vais compléter par un passage dans <a href="https://wave.webaim.org/">WAVE Web Accessibility Evaluation Tools</a> pour contrôler la structure de la page, les textes alternatifs des images, etc. <h2 id="lire-quelques-contenus">Lire quelques contenus</h2> Si je trouve un page à fort contenu, je vais la lire intégralement. Je pourrai me rendre compte en pratique de la lisibilité de la police choisie (sur plusieurs systèmes d’exploitation), des choix de contraste, de la mise en évidence des liens, de l’usage des intertitres et des listes. Je vérifierai aussi si les lignes de textes ne sont pas trop longues ou trop courtes, si l’interligne est pertinent. Si, à la moitié de la page, j’ai une impression de fatigue, je suppose que d’autres internautes l’auront aussi. <h2 id="se-faire-une-idee-du-bilan-carbone">Se faire une idée du bilan carbone</h2> Par la suite, je vais tester le bilan carbone du site dans <a href="https://www.websitecarbon.com/">Website Carbon Calculator</a>. À vrai dire, j’aurai déjà une idée du résultat en fonction de tous les tests précédents, mais cette vérification n’est pas de trop. C’est un test que je trouve particulièrement important pour tous les sites qui parlent de ressources, d’écologie, de respect de la Création, etc. Un peu de cohérence ne fait jamais de mal. <h2 id="controler-la-validite-du-code">Contrôler la validité du code</h2> Un passage par les validateurs du World Wide Web Consortium (W3C) me permettra de vérifier l’état du code: <ul> <li><a href="https://validator.w3.org/">validation HTML</a></li> <li><a href="https://jigsaw.w3.org/css-validator/">validation CSS</a></li> <li><a href="https://validator.w3.org/feed/">validation RSS ou Atom</a></li> </ul> Avec le dernier test, je contrôlerai si un flux RSS ou Atom peut être découvert automatiquement. Et s’il est absent, je me demanderai s’il serait pertinent d’en proposer un. <h2 id="parcourir-lentier-du-site">Parcourir l’entier du site</h2> Par la suite, je lancerai encore un outil qui parcourt l’entier du site (crawl), par exemple <a href="https://www.screamingfrog.co.uk/seo-spider/">SEO Spider Tool</a>. Je découvrirai les éventuels liens morts, les répétitions fautives dans les titres ou les descriptions, etc. Un site en ligne depuis longtemps et avec beaucoup de pages aura souvent plus de liens morts qu’un site tout frais. Mais cette vue d’ensemble permet souvent de découvrir des scories qu’il est facile de corriger. <h2 id="passer-aux-regles-opquast">Passer aux règles Opquast</h2> Si tout s’est bien passé jusque là, je vérifierai certaines <a href="https://checklists.opquast.com/fr/assurance-qualite-web/">règles Opquast</a>. En particulier celles que je trouve les plus pertinentes sur ce site précis sur lequel j’aurai déjà passé quelques minutes. Par exemple, si le site présente beaucoup d’adresses de contact, je contrôlerai leur contenu. Si le site est en plusieurs langues, je regarderai la gestion du multilinguisme. <h2 id="envoyer-un-retour">Envoyer un retour</h2> Cette petite analyse n’est pas un audit au sens strict. Je ne vais donc pas rendre un document complet qui détaille tous les points. En fonction de ce que j’ai vu dans mon parcours, je choisirai sur quoi portera mon retour. J’essaierai toujours de dire le plus simplement possible: <ul> <li>ce qui m’a plu dans le site testé</li> <li>les problèmes les plus importants qu’il pose</li> </ul> Envie d’essayer? Testez vous-même votre site par les différentes étapes proposées. Ou prenez le risque de me demander de «jeter un coup d’œil rapide».</description></item><item><title>htaccess chez Infomaniak</title><link>https://nicolasfriedli.ch/blog/htaccess/</link><pubDate>Mon, 12 Feb 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/htaccess/</guid><description>Pour des sites générés avec Hugo et hébergés chez Infomaniak, voici le <code>.htaccess</code> type que j’utilise. C’est une version découpée en plusieurs parties avec des commentaires. L’encodage et la langue par défaut sont directement envoyés en entête: <pre tabindex="0"><code>AddDefaultCharset UTF-8 DefaultLanguage fr-ch </code></pre>Si la page est appelée en <code>http</code> ou s’il elle commence par <code>www</code>, on renvoie à un version en <code>https</code> sans <code>www</code> (voir <a href="https://checklists.opquast.com/fr/assurance-qualite-web/toutes-les-pages-utilisent-le-protocole-https">Opquast 192</a> et <a href="https://checklists.opquast.com/fr/assurance-qualite-web/ladresse-du-site-fonctionne-avec-et-sans-prefixe-www">Opquast 211</a>). On renvoie tout sur la page d’accueil et on impose le nom de domaine (plutôt que s’utiliser <code>HTTP_HOST</code>): <pre tabindex="0"><code>RewriteCond %{HTTPS} off [OR] RewriteCond %{HTTP_HOST} ^www. [NC] RewriteRule ^(.*)$ https://nicolasfriedli.ch/$1 [R=301,L] </code></pre>On envoie des entêtes pour la sécurité du site. La première ligne existe <a href="https://www.infomaniak.com/fr/support/faq/2133/gerer-hsts-dun-site-webhebergement">par défaut chez Infomaniak</a>, mais en version trop limitée pour le soumettre à <a href="https://hstspreload.org/">HSTS preload</a>. Le reste peut être testé chez <a href="https://securityheaders.com/">Security Headers</a>. <pre tabindex="0"><code>Header always set Strict-Transport-Security &#34;max-age=63072000; includeSubDomains; preload&#34; Header always set X-Content-Type-Options &#34;nosniff&#34; Header always set X-Frame-Options &#34;DENY&#34; Header always set X-XSS-Protection &#34;1;mode=block&#34; Header always set Referrer-Policy &#34;same-origin&#34; Header always set X-Permitted-Cross-Domain-Policies &#34;none&#34; </code></pre>En cas d’erreur, on renvoie logiquement une erreur 404, mais pas de page personnalisée pour le moment (voir <a href="https://checklists.opquast.com/fr/assurance-qualite-web/le-serveur-envoie-une-page-derreur-404-personnalisee">Opquast 216</a>): <pre tabindex="0"><code>ErrorDocument 404 https://nicolasfriedli.ch/ </code></pre>On redirige le flux RSS de WordPress (qui a été utilisé ici) vers le flux produit par Hugo. C’est une redirection permanente: <pre tabindex="0"><code>Redirect 301 /feed/ /index.xml </code></pre>Je choisis de gérer le cache (voir <a href="https://checklists.opquast.com/fr/assurance-qualite-web/le-serveur-envoie-les-informations-permettant-la-mise-en-cache-des-contenus">Opquast 220</a>) très simplement, par extension de fichier. Les images reçoivent un cache de 1 mois: <pre tabindex="0"><code>&lt;filesMatch &#34;.(jpg|jpeg|png|gif|ico|svg|webp|avif)$&#34;&gt; Header set Cache-Control &#34;max-age=2592000,public&#34; &lt;/filesMatch&gt; </code></pre>Pour les feuilles de style et les polices d’écriture locales, je choisis un cache <code>immutable</code>. Ce qui signifie que ces fichiers ne seront jamais rechargés par le navigateur durant 2 ans. Il faut utiliser un numéro de version (cache busting) pour ne pas se planter. Avec Hugo, j’utilise un identifiant unique (fingerprint) pour les feuilles de style CSS externes. Pour les polices d’écriture, je conseille de passer par <a href="https://gwfh.mranftl.com/fonts">google-webfonts-helper</a> qui donne toujours des noms de fichier avec numéro de version. Voici la directive: <pre tabindex="0"><code>&lt;filesMatch &#34;.(css|woff2)$&#34;&gt; Header set Cache-Control &#34;max-age=63072000,immutable&#34; &lt;/filesMatch&gt; </code></pre>Le <a href="https://github.com/nfriedli/nicolasfriedli.ch/blob/main/static/.htaccess"><code>.htaccess</code> utilisé pour ce site</a> peut être repris presque sans modifications, mais n’oubliez pas de changer le nom de domaine ou d’utiliser <code>HTTP_HOST</code>. Avant de modifier un fichier <code>.htaccess</code> en ligne, il faut s’assurer de pouvoir y accéder par un autre moyen (par exemple par FTP). Si Wordpress est utilisé pour modifier un tel fichier, en cas d’erreur il ne sera plus du tout accessible (et votre site non plus).</description></item><item><title>Mode sombre en quelques lignes de CSS</title><link>https://nicolasfriedli.ch/blog/dark-mode/</link><pubDate>Sat, 10 Feb 2024 00:00:00 +0000</pubDate><author>hello+rss@nicolasfriedli.ch (Nicolas Friedli)</author><guid>https://nicolasfriedli.ch/blog/dark-mode/</guid><description>En quelques lignes de CSS, il est possible d’activer un mode sombre automatique sur son site. La version aboutie est celle que j’utilise pour plusieurs projets. C’est simple et fiable. <h2 id="version-minimale">Version minimale</h2> Le plus simple, c’est: <pre tabindex="0"><code>root { color-scheme: light dark; } </code></pre>Si les couleurs d’arrière-plan, de texte, des liens, etc., n’ont pas été définies, c’est parfaitement fonctionnel. Il suffit de signaler au navigateur qu’il a le droit de s’afficher en clair (light) ou en foncé (dark) selon les préférences de l’internaute. Si aucune préférence a été fixée, c’est le mode light qui sera choisi. Il est aussi possible de passer au mode sombre sans fixer aucune couleur, mais sans bascule automatique en fonction des préférences: <pre tabindex="0"><code>root { color-scheme: dark; } </code></pre>Au lieu de préciser le schéma de couleur dans la feuille de style CSS, il peut être annoncé dans le code HTML de la page: <pre tabindex="0"><code>&lt;meta name=&#34;color-scheme&#34; content=&#34;dark light&#34;&gt; </code></pre>Dans certains cas, c’est préférable, car le navigateur a cette information avant même de charger la feuille de style. Mais c’est là une question de détails. <h2 id="version-aboutie-mais-simplissime">Version aboutie (mais simplissime)</h2> Dès que des couleurs sont choisies, il faut de la cohérence pour éviter du texte foncé sur fond foncé (ou clair sur clair). La feuille de style la plus simple pour gérer cela: <pre tabindex="0"><code>:root { color-scheme: light dark; --background: #FFF; --text: #333; } @media (prefers-color-scheme: dark) { :root { --background: #000; --text: #DDD; } } html { background: var(--background); color: var(--text); } a { color: inherit; } </code></pre>Le code est simple: <ul> <li>Le navigateur peut choisir le mode light ou le mode dark</li> <li>Une couleur de fond et une couleur de texte sont déclarées en variables CSS</li> <li>Si la préférence du navigateur est le mode sombre, les variables sont modifiées.</li> <li>Le fond et le texte sont déclarés pour tout le document.</li> <li>Les liens prennent la même couleur que le texte.</li> </ul> La même chose est possible sans variables, de la manière suivante: <pre tabindex="0"><code>:root { color-scheme: light dark; } html { background: #FFF;; color: #333; } @media (prefers-color-scheme: dark) { html { background: #000; color: #DDD; } } a { color: inherit; } </code></pre><h2 id="autres-methodes">Autres méthodes</h2> Des feuilles de style distinctes, une pour le sombre, une pour le clair, avec un appel différencié. Ce peut être intéressant sur les thèmes qui sont très différents, mais sinon les variables CSS paraissent plus efficaces. Exemple: <pre tabindex="0"><code>&lt;link media=&#34;(prefers-color-scheme: light)&#34; href=&#34;light.css&#34; rel=&#34;stylesheet&#34;&gt; &lt;link media=&#34;(prefers-color-scheme: dark)&#34; href=&#34;dark.css&#34; rel=&#34;stylesheet&#34;&gt; </code></pre>Un changement de couleur avec du JavaScript comme le propose Max Böck dans <a href="https://mxb.dev/blog/color-theme-switcher/">Color Theme Switcher</a>. C’est très élégant, ça ouvre des perspectives, mais c’est bien plus complexe que quelques lignes de CSS. L’utilisation de la fonction <a href="https://developer.mozilla.org/en-US/docs/Web/CSS/filter-function/invert"><code>invert()</code></a> permet, comme son nom l’indique, d’inverser des valeurs. Cette méthode ne me convient pas. Je pense que l’on peut choisir ses couleurs plus finement qu’en les inversant simplement (et elle pose des problèmes avec les images). Plutôt que cette méthode par <code>invert()</code>, je procéderais plutôt ainsi s’il fallait simplement inverser les valeurs: <pre tabindex="0"><code>:root { color-scheme: light dark; --light: #FFF; --dark: #222; } html { background: var(--light); color: var(--dark); } @media (prefers-color-scheme: dark) { :html { --background: var(--dark); --text: var(--light); } } a { color: inherit; } </code></pre><h2 id="choix-du-mode-par-le-site">Choix du mode par le site</h2> Dans les exemples précédents, c’est l’internaute qui choisit un thème clair ou un thème foncé. Si le site accepte les 2 modes, c’est bien aux utilisateurs et utilisatrices que le choix incombe. Mais&hellip; Une règle <code>no-preference</code> a été envisagée, mais elle n’a jamais été implémentée dans un seul navigateur. Au final, elle a simplement été <a href="https://github.com/w3c/csswg-drafts/issues/3857#issuecomment-634779976">supprimée de la spécification technique</a>. C’est bien dommage. Parce que si un·e internaute n’a pas fait de choix, c’est le thème light qui est tout de même considéré comme son choix! En d’autres termes, en tant que responsable de site, je ne peux pas proposer, en pur CSS, un site qui s’affiche: <ul> <li>en mode sombre par défaut</li> <li>en mode clair si et seulement si l’internaute a fait un choix explicite</li> </ul> Pour disposer d’un mode sombre par défaut avec une possibilité de passer au mode clair sur demande, il faudra obligatoirement passer par un petit développement (par exemple le Color Theme Switcher mentionné plus haut).</description></item></channel></rss>