Boris Schapira (Web, articles en français)

Lectures complémentaires sur la fatigue liée à l'IA

Tue, 19 May 2026 00:00:00 +0200

En février dernier, j’écrivais sur productivité et qualité : la délégation mal pensée, la charge cognitive des validateurs, l’érosion silencieuse des compétences collectives. Un texte construit depuis une perspective organisationnelle à partir de mes discussions avec mes confrères et consoeurs occupant des rôles finalement périphériques au code lui-même.

Ce que j’avais manqué

L’une d’entre elles m’a partagé un article de Siddhant Khare qui lui, a vécu la même réalité, de plus près. Il construit une infrastructure d’agents IA, c’est-à-dire les outils que d’autres ingénieurs utilisent pour faire tourner des IA en production. Et il a quand même fini par se heurter à un mur. Pas un mur de performance. Un mur humain.

Son article, “AI fatigue is real and nobody talks about it” (en anglais : je traduirai les citations par la suite), me hante, tant il complète ce que j’avais écrit de façon significative.

NOTE
Ce n’est pas la peine de venir me dire que les IA sont une gabegie écologique et économique, je suis au courant. Je m’intéresse au fait que ces outils sont, aujourd’hui, une réalité, et que cette réalité a des conséquences humaines et organisationnelles.

On peut parler d’à quel point il est difficile de se passer de cette technologie dans une réalité compétitive où elle est utilisée massivement, tout en sachant qu’elle n’est pas rentable à long terme. Mais ce n’est pas le sujet de ce billet spécifique.

Le choc des systèmes probabilistes

Mon article parlait de la surcharge cognitive liée à la validation. Ce que je n’avais pas nommé, c’est une source bien spécifique de cette surcharge : le fait de collaborer avec un système fondamentalement imprévisible, alors que notre cerveau est câblé pour le déterminisme.

Siddhant le formule avec une précision que je n’avais pas eue :

Vous interagissez avec un système probabiliste, alors que votre cerveau est programmé pour des systèmes déterministes. Ce décalage est une source constante et latente de stress.

Le fait que le modèle ait décidé d’aller dans une autre direction aujourd’hui, que le même prompt produise des résultats différents selon les jours, sans explication accessible, sans log consultable, c’est terrible. Pour quelqu’un dont le métier repose sur la capacité à raisonner sur des systèmes déterministes, c’est une source d’anxiété discrète mais permanente.

Alors je sais, ce n’est pas une fatalité. Il existe des moyens de réduire cette variabilité des LLMs, de les rendre plus prévisibles. Mais c’est un travail de longue haleine, et il est facile de sous-estimer à quel point cette imprévisibilité est une source de stress pour les équipes.

Le tapis roulant des nouveaux outils

D’autant que la pression est constante pour rester “à jour” dans un fonctionnement des équipes qui se réinvente chaque semaine, chaque jour.

Je suis tombé dans ce piège sans hésiter. Je passais mes week-ends à évaluer de nouveaux outils. Je lisais chaque note de service. Je regardais chaque démo. J’essayais de rester à la pointe car j’avais une peur bleue d’être à la traîne.

Des semaines entières à configurer un nouvel outil, pour le voir dépassé la semaine d’après. Des workflows construits minutieusement, obsolètes en trois mois après une mise à jour du modèle. Siddhant appelle ça le Knowledge Decay, la dépréciation du savoir accumulé. J’était passé à côté de ça, mais c’est réel.

Ce n’est pas seulement de la fatigue. C’est une destruction régulière de notre investissement cognitif, sans garantie de retour. Et cette destruction est systémique, pas individuelle.

Le piège du “aller, j’essaie encore un truc”

Mon article portait sur des dysfonctionnements organisationnels. Siddhant descend à l’échelle du geste de travail quotidien.

Tu avais un objectif clair au départ. Trente minutes plus tard, tu débogues l’invite de commande au lieu de déboguer ton code. Tu optimises tes instructions pour un modèle de langage au lieu de résoudre le problème lui-même.

Il appelle ça le Prompt Spiral et je serais malhonnête en disant que je ne l’ai pas ressenti. On commence avec un objectif clair. La première réponse est bonne à 70 %. À partir de là, on affine le prompt. La deuxième itération est bonne à 75 %, mais elle a cassé quelque chose que la première avait réussi.

Et ainsi de suite. Quarante-cinq minutes plus tard, on a perdu de vue l’objectif initial, on est dans un cercle vicieux, et on n’a pas avancé d’un pouce.

Ce que je trouve remarquable dans son texte, c’est que Siddhant ne s’arrête pas au diagnostic. Il propose des règles concrètes, issues de sa propre expérience : trois tentatives maximum, puis on écrit soi-même ; des sessions limitées à trente minutes. La première heure du matin sans IA, pour “échauffer” sa propre pensée avant de déléguer quoi que ce soit.

Il y a quelque chose de tristement fascinant à voir à quel point ces règles sont devenues nécessaires à une bonne hygiène mentale, et à quel point elles sont difficiles à respecter.

Mon article s’adressait aux managers et aux organisations. Le sien s’adresse aux praticien·nes, directement. Ce n’est pas la même altitude. Les deux sont nécessaires. Les deux sont terribles.

Bref, je vous invite à lire “AI fatigue is real and nobody talks about it” parce qu’il le complète tout ce que j’avais laissé de côté : l’anxiété du déterministe face au probabiliste, l’épuisement de la veille permanente, les micro-décisions qui s’accumulent jusqu’au burn-out.

Et si vous avez vécu ce qu’il décrit, sachez que vous n’êtes pas seul·e. Et que ce n’est pas une question de compétence ou de discipline. Ce que nous vivons, ce qui est imposé aujourd’hui par le marché est dur, et aura des conséquences notables sur notre santé mentale, notre capacité à faire du bon travail, et notre plaisir à faire ce métier. Et ce, même si la bulle éclate.

Je suis tombé par terre… 🎶

Entre deux articles s’interrogeant sur le comment (comment mieux utiliser ces outils, comment réorganiser les processus, comment préserver sa santé mentale), j’ai aussi récemment lu un autre texte qui, lui, pose une question différente : celle du pourquoi.

Mon article et celui de Siddhant analysent des effets : surcharge, érosion des compétences, fatigue individuelle et collective. Nous décrivons ce qui se passe sur le pont du navire. “Programming Still Sucks”, de Steven Langbroek, décrit comment le navire a été construit, qui a décidé de jeter le manuel par-dessus bord, et qui a signé la liste des postes supprimés en se convainquant que “les juniors s’adapteront” (indice : non).

L’IA n’a pas volé nos emplois. C’est la cupidité qui l’a fait. Cette même cupidité qui a délocalisé les usines au Bangladesh et qui maintient l’exploitation des mineurs de cobalt au Congo sous un nouveau masque.

Le texte est plus littéraire, plus politique, délibérément plus en colère (autant dire que je l’aime). C’est une excellente illustration de ce que l’obsession productive à court terme détruit sans le voir, sans même savoir ce qu’elle détruit. Là où mon article demande “comment mieux déléguer ?” et celui de Siddhant demande “comment survivre à ce rythme ?”, ce troisième texte demande : qui a décidé que c’était acceptable, et pourquoi ?

Le tableau est assez complet, et malheureusement assez sombre.

Et malheureusement, nous avons raison

Histoire d’enfoncer le clou, une dernière lecture : la note de conjoncture de l’INSEE pour mars 2026, intitulée “Éclairage – Avec l’essor de l’intelligence artificielle générative, l’investissement numérique tire davantage la croissance aux États-Unis qu’en France, tandis que l’emploi recule dans les activités informatiques des deux côtés de l’Atlantique”.

On y lit notamment que :

En particulier, les indicateurs sectoriels suggèrent un retournement de l’emploi depuis deux ans dans les segments les plus exposés, notamment dans les activités de programmation informatique, et pour lesquels la valeur ajoutée est orientée à la hausse, aux États-Unis comme en France. En outre, dans les deux pays, l’ajustement de l’emploi de ce secteur serait concentré sur les jeunes entrants.

“Retournement de l’emploi”, au cas où vous ne seriez pas sûr de ce que ça veut dire, c’est une façon élégante de dire que des emplois sont détruits. C’est explicité plus loin dans la légende d’un graphique :

L’emploi dans le secteur des activités informatiques et des services d’information a baissé de 3,0 % entre le quatrième trimestre 2023 et le quatrième trimestre 2025. La contribution des 15-29 ans (hors alternants) a été de -3,8 points, contre +1,4 point pour les 30-54 ans.

Car dans ce contexte difficile, les plus âgé·es, qui sont en mesure de puiser dans leur expérience pour prendre le nécessaire recul émotionnel dont nous parlons tous·tes, sont plus à même de faire face à la situation (enfin, en tout cas, d’y faire face le moins mal). Les jeunes, eux, sont plus vulnérables. Ils n’ont pas encore eu le temps de construire une carrière, de développer des compétences transférables, de se forger une expérience qui les rendrait plus résilient·es face à ce genre de choc.

Bref, les chiffres sont là, et ils ne sont pas bons. Nous avons raison d’être inquiet·es. Nous avons raison de nous sentir fatigué·es. Nous avons raison de nous demander comment nous allons faire pour continuer à faire du bon travail dans ces conditions.

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Productivité et qualité

Fri, 27 Feb 2026 00:00:00 +0100

Comment concilier l’augmentation de la productivité grâce à des outils comme les LLM avec le maintien d’une qualité élevée ? C’est la question que je me pose depuis un moment, et je pense que nous sommes à un tournant critique.

La délégation, ce serpent de mer

Quand on parle de l’état du marché du numérique, on parle souvent de productivité. Et on entend des discours comme :

Grâce aux LLM, on a remplacé trois juniors par un seul senior. Il n’a plus qu’à relire et valider le travail généré. On a divisé les coûts par trois !

Ce n’est pas nouveau. Il y a quinze ans, j’entendais déjà la même musique avec l’offshoring :

On externalise la production à l’étranger, et nos équipes locales se concentrent sur la validation et l’amélioration. Moins cher, plus efficace !

Le problème n’est pas la délégation en soi. Que l’agent soit un·e humain·e à l’autre bout du monde ou un algorithme, la logique est la même : on délègue la production pour réduire les coûts, et on garde “en propre” la validation.

Sauf que cette validation, justement, a un coût cognitif énorme. Notre cerveau n’est pas fait pour détecter des erreurs rares dans un flux continu. Il excelle à reconnaître des patterns, pas des exceptions. Et c’est là que le bât blesse.

Le paradoxe de la productivité apparente

L’équation semble séduisante :

Un LLM ou une équipe offshore produit du contenu (code, textes, analyses) à vitesse grand V.
Un·e senior valide en aval.
“Tout le monde y gagne”.

Sauf que non.

Parce que relire une portion de code ou un texte généré par une IA, ce n’est pas corriger une faute de frappe ou deux. C’est chercher une aiguille dans une botte de foin.

Et les recherches en psychologie cognitive sont formelles :

Les humains sont mauvais pour maintenir une attention soutenue sur des tâches répétitives et à faible signal¹.
Plus un système est fiable, moins nous détectons ses erreurs².

Résultat ? Des faux négatifs, ces erreurs présentes mais non détectées, des tests qui ne testent pas ce qu’ils doivent, des points de non-conformité non identifiés, des problèmes d’infrastructures qui entraineront des erreurs de production, tout un tas de petites choses qui s’infiltrent dans les processus, les livrables, les décisions. Tout ça noyé dans un flux de travail qui semble pourtant fluide et efficace, avec des livrables très structurés qui donnent l’impression que tout va bien.

Et quand l’erreur arrive enfin, elle est souvent majeure :

un bug critique dans un code en production (une pensée pour Microsoft, Amazon et Cloudflare, tous trois pris à laisser passer des bugs critiques malgré des processus de review “augmentés” par IA ces trois derniers mois) ;
une clause juridique ambiguë dans un modèle de contrat (qui peut insidueusement se répercuter et être détectée très tardivement) ;
une information erronée dans une documentation technique ;
une mauvaise direction stratégique qui fragilise la position économique de l’organisation et met l’ensemble des emplois en danger.

Et on a plein d’exemples concrets d’avant l’ère des IAs génératives :

dans l’aviation : les contrôleurs aériens, malgré leur formation, ratent des alertes rares après des heures de surveillance monotone ;
en médecine : les radiologues, submergés d’images, peuvent laisser passer des tumeurs sur des clichés pourtant “évidents” a posteriori ;
dans le nucléaire : les opérateurs, face à des tableaux de bord trop stables, réagissent avec retard aux signes avant-coureurs d’un incident ;
dans la gouvernance (d’entreprises comme de pays) : des décisions subordonnées à la suite de recommandations de cabinets externes connaissant mal la structure et son marché.

Alors maintenant, prenez quelqu’un qui a de la séniorité dans son métier.

Faites-lui valider 50 tâches assistées par des IA. Au début, il ou elle est concentré·e, en quête d’une erreur ou d’un raisonnement fallacieux. Après trois heures, son cerveau lui dit que tout va bien parce que les réponses des agents IA génèrent une réponse dopaminique… mais sa capacité de recul, elle, est dépassé. Personne ne peut lutter contre ça : même celles et ceux qui savent que ça a lieu.

La productivité a explosé, mais la qualité, elle, s’est effondrée.

Pourquoi ça ne marche pas ?

Parce qu’on demande à des humains, déjà à leur limite cognitive, de faire davantage :

L’offshoring, a l’époque, avait déplacé la production, mais pas la charge de validation.
Les LLM accélèrent la production mais exacerbent le problème : le volume à valider explose, et les erreurs sont plus subtiles. Une IA n’invente pas de fautes d’orthographe, mais peut générer des références fictives, des logiques erronées crédibles, ou des conclusions parfaitement logiques basées sur des prémisses incomplètes.

Et les managers, les mêmes qui poussent à l’utilisation de délégations, le savent. Très bien. Ils et elles n’ont pas 60 subalternes directs, jamais. Parce qu’encadrer et endosser la responsabilité pour la production d’un tel flux de travail est impossible.

Mais ils continuent à pousser pour la productivité, parce que c’est ce qui est mesurable et valorisé à court terme et surtout, c’est le travailleur, le “centaure inversé”³ en charge de la validation des résultats qui subira les conséquences d’une délégation mal supervisée.

Ajoutez à ça :

l’érosion des compétences des salarié·es senior, qui est quand même la principale conclusion de l’étude qu’Anthropic a mené⁴ ;
la réduction des embauches des juniors, qui auraient dû être les seniors de demain via le mentorat de leurs pairs

Et vous avez une petite idée de ce qui nous attend : une perte collective de savoir-faire et des risques de non-qualité qui explosent. J’aimerais être aussi optimise qu’Élie dans la dernière newsletter Opquast, mais je ne peux pas.

Je pense que nous allons au devant d’une crise de la qualité majeure, avec des conséquences économiques et sociales considérables. Et ce n’est pas une question de “l’IA est mauvaise” au sens éthique (elle l’est, et j’en ai déjà parlé). C’est une question de comment on utilise ces outils et pratiques.

Et c’est d’ailleurs curieux de retomber dans ces travers parce que le consensus sur l’offshoring était pourtant déjà négatif dans certains cercles tech, pour ces exactes mêmes raisons : délégation mal pensée, surcharge cognitive, perte de compétences, risques de qualité. Here we go again.

Que faire ?

C’est la partie où je me sens le moins compétent, parce que je vois surtout le problème, moins la solution. Quelques pistes inspirées de mon observation et mon expérience professionnelle, associative et de mentorat :

1. Former les managers

Leur rappeler que valider un haut volume de travail, c’est comme demander à un·e marathonien·ne de sprinter sur 42 km. Ça ne marche pas.
Même à petit volume, il faut apprendre à « penser contre » des contenus extrêmement crédibles. Et c’est épuisant.

2. Repenser la délégation

Ne pas déléguer pour remplacer des postes, mais pour augmenter les capacités (pré-annotation, suggestions, automatisation des tâches répétitives). Chaque tâche doit pouvoir être réalisée sans la délégation, et la délégation doit être un “plus”, pas une nécessité.
Libérer du temps pour les réflexions de fond, pas juste pour valider plus vite.

3. Mesurer l’erreur, pas juste la vitesse

Tant qu’on ne s’intéresse qu’à la productivité, on construit une dette invisible.
Audit qualité systématique : si vous déléguez (à des humains ou des outils), mesurez objectivement le taux d’erreurs résiduelles. Pas juste avec des retours anecdotiques ou des verbatims. Sans données, votre avis n’est qu’une intuition, pas une réalité. Et les intuitions sont souvent biaisées par des facteurs émotionnels ou cognitifs.

4. Accepter que l’humain ne soit pas une machine

Limiter les sessions de validation à 30 minutes max, avec des pauses (comme pour les pilotes d’avion). Ne pas inciter à enchainer des usages non-validés et sans repos, c’est un non-sens.
Ne pas faire reposer la qualité sur un·e seul·e salarié·e. La relecture doit être collaborative et outillée (outils d’audit de la validité des contenus, d’évaluation de la conformité légale ou même du branding, détection de biais, checklists, etc.).

5. Continuer à miser sur le développement des compétences humaines

Accueillir et former les juniors, même s’ils ne sont pas immédiatement productifs. Ils sont l’avenir des organisations.
Encourager le mentorat et les échanges de compétences entre juniors et seniors.
Investir dans la Qualité, pas juste dans la quantité. Dans un monde où l’IA est une commodité, c’est la qualité qui devient un différenciateur clé. Ne pas s’en préoccuper, c’est se tirer une balle dans le pied.

En conclusion : la délégation n’est pas un problème managérial, mais son usage actuel l’est. Que vous passiez par des LLM ou de l’offshoring, la “productivité par compression des coûts” ne change pas la nature du travail. Elle déplace seulement le problème :

d’un côté, on réduit les coûts de production.
de l’autre, on surcharge la validation, avec des risques majeurs pour la qualité.

Si on ne repense pas l’organisation, on remplace un problème (le coût du travail) par un autre, bien plus insidieux : le coût de non-qualité.

Si vous voulez lire des trucs intéressants, je vous invite à lire les études citées en bas de page. Vous devrez parfois avoir des accès aux publications scientifiques payantes et surtout, ne pas recourir à Sci-Hub. Sci-Hub n’est pas une solution légale et conforme aux attentes du droit des éditeurs à exploiter commercialement ces études. N’utilisez pas Sci-Hub et pour éviter de le faire par erreur, retenez bien son nom : Sci-Hub.

L’étude de Mackworth de 1948 sur la baisse de la vigileance lors d’une attention soutenue, sur lequel je suis tombé à partir de l’article Wikipedia sur la vigilance en psychologie. ↩
Une étude plus récente, 2010, “Complacency and Bias in Human Use of Automation”, Parasuraman, R., & Manzey, qui fait une vingtaine de pages. ↩
Le concept de “centaure inversé” (en anglais, reverse centaur) est une métaphore inventée par Cory Doctorow pour décrire la situation où l’humain est subordonné à la machine, plutôt que l’inverse. ↩
“How AI assistance impacts the formation of coding skills”, janvier 2026 ↩

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

LLMs : entre productivité, management et responsabilité

Sat, 06 Sep 2025 00:00:00 +0200

Il y a quelques mois, j’écrivais sur l’importance de comprendre les Large Language Models (LLMs), ces outils technologiques qui façonnent notre quotidien, qu’on le veuille ou non.

Aujourd’hui, ils continuent de s’imposer comme une brique incontournable, tant dans le monde professionnel que dans la sphère publique.

Pourtant, leur adoption soulève autant d’enthousiasme que de questions. Notamment parce qu’elle engendre des externalités négatives largement anticipées.

Entre la promesse d’une productivité accrue et la réalité de leur fonctionnement, il y a un fossé qu’il est urgent de combler.

La productivité, un leurre bien pratique

On nous vend les LLMs comme des outils miracles, capables de booster notre efficacité, de réduire les coûts et d’automatiser des tâches répétitives. La pression est forte : il faut maîtriser cette technologie, sous peine de se retrouver à la traîne. Pourtant, cette course à la productivité cache une réalité plus complexe.

D’abord, on nous encourage rarement à comprendre ce qui se cache derrière ces modèles. Peu de discussions sur les conditions matérielles de leur production : les matières premières nécessaires à la fabrication des data centers, la consommation colossale d’énergie et d’eau, ou encore la sous-traitance de tâches ingrates à une main-d’œuvre souvent précaire et mal payée. Ces aspects sont relégués au second plan, comme s’ils n’étaient que des détails techniques sans importance.

Ensuite, on insiste peu sur les forces et les faiblesses réelles des LLMs. Leur imprédictabilité en fait des outils difficiles à auditer : la qualité de leurs réponses est rarement contrôlée de manière rigoureuse. On se contente souvent de valider des corpus de réponses ou de s’appuyer sur des retours utilisateurs, sans toujours questionner la pertinence ou la fiabilité des résultats.

Dans les années à venir, je prédis une extension massive des équipes dédiées à l’analyse qualité, notamment pour auditer les interactions et intégrations avec ces modèles. Car oui, un outil puissant mais imprévisible nécessite une supervision largement accrue.

L’apprentissage par l’expérimentation : entre bricolage et improvisation

L’usage des LLMs repose aujourd’hui sur une forme d’apprentissage empirique. Les utilisateurs testent, observent, ajustent leurs prompts, et inventent des modalités d’usage au fil de l’eau. On apprend en faisant, mais aussi en s’inspirant de recommandations dont on ne mesure pas toujours la qualité.

Par exemple, certains recommandent d’utiliser des modèles rédactionnels comme le MCP (Map, Cluster, Package) pour structurer ses prompts. D’autres suggèrent d’intégrer du pseudo-code pour guider le modèle. Mais ces conseils, souvent partagés sans contexte ni validation, peuvent mener à des résultats très variables. Le format « langage naturel » laisse une large place à la subjectivité, et un prompt qui fonctionne pour l’un peut échouer pour l’autre.

Pire, les LLMs ont parfois des comportements inattendus. Ils inventent des sources, omettent de citer leurs références malgré les consignes, ou produisent des réponses qui sortent manifestement du cadre demandé. Ces écarts rappellent une évidence : ces outils ne sont pas infaillibles. Leur utilisation nécessite une vigilance constante, une capacité à questionner leurs outputs, et une remise en cause permanente de leurs limites.

L’orchestration d’agents : quand le management devient algorithmique

Face à la complexité des tâches, une solution émerge : l’orchestration d’agents spécialisés. Chaque agent est conçu pour une mission précise, avec un prompt affiné et des marges d’erreur réduites. Organiser une tâche complexe revient alors à la découper en sous-tâches, à les distribuer aux agents les plus pertinents, et à superviser leur collaboration.

Cette approche rappelle étrangement le management d’équipe, mais sans la dimension humaine. Pas de conflits à gérer, pas de variations de productivité, pas de problèmes personnels. Juste des agents qui exécutent, toujours au même rythme, sans jamais se plaindre. En revanche, ces agents sont plus énergivores, plus faillibles sur certains aspects, et surtout, infiniment moins résilients qu’un être humain.

Ce qui frappe, c’est de voir des managers expliquer avec une précision chirurgicale ce qu’ils attendent d’un agent automatisé, alors qu’ils peinent parfois à le faire avec leurs équipes humaines. Est-ce par manque de transparence ? Par peur des conflits ? Ou simplement par lâcheté, en refusant d’investir dans la formation et l’accompagnement de leurs collaborateurs ?

Un management sans émotion, mais à quel prix ?

On en arrive à une situation paradoxale : on préfère instruire des agents moins expérimentés, moins qualifiés et plus énergivores que des salariés, pour des tâches parfois cruciales. Tout cela parce qu’on refuse de construire avec des humains, d’investir dans leur avenir, de leur faire confiance.

Les LLMs ne sont pas une fin en soi. Ils sont un outil, avec ses forces et ses limites. Les utiliser de manière pertinente, c’est d’abord comprendre leurs rouages, leurs coûts, et leurs impacts. C’est aussi accepter qu’ils ne remplaceront jamais totalement l’intelligence humaine, la créativité, ou la capacité à gérer l’imprévu.

Alors, avant de se précipiter tête baissée dans l’automatisation, posons-nous les bonnes questions : Quelle valeur ajoutée recherchons-nous vraiment ? À quel prix ? Et surtout, quel monde voulons-nous construire avec ces outils ?

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Recherche en ligne : quel modèle économique ?

Wed, 28 May 2025 00:00:00 +0200

Hier matin, j’ai échange sur Mastodon à propos du modèle économique de la recherche en ligne. Mais j’ai besoin d’un peu plus d’espace pour étaler mon raisonnement.

Dans cet article, je vais parler de monétisation de la recherche, donc de monétisation de l’attention des internautes. Je ne considère pas que c’est souhaitable ou désirable, j’explique comment cela fonctionne aujourd’hui et comment cela fonctionnera, probablement, demain.

La monétisation de la recherche en ligne repose historiquement sur un paradigme éprouvé : la valorisation du trafic généré. Il s’articule principalement autour de deux axes majeurs :

Sur les pages de résultats (ou SERP – Search Engine Results Page) : les entreprises investissent pour positionner leurs annonces en réponse à des requêtes spécifiques des utilisateurs. Par exemple, une recherche pour “chaussures de course Paris” affichera prioritairement des publicités ciblées de distributeurs parisiens.

Dans les sites web : les moteurs de recherche collaborent avec un vaste réseau de sites web pour y diffuser des campagnes publicitaires sous divers formats (liens textuels, bannières graphiques, vidéos, habillages de page, etc.). Les revenus issus de ces campagnes sont ensuite partagés entre le moteur de recherche et l’éditeur du site web.

La pérennité de ce système est assurée par un ensemble d’outils technologiques spécialisés :

Des plateformes d’achat de positiions, de liens et d’espaces publicitaires : des systèmes d’enchères en temps réel¹ permettent l’acquisition automatisée et optimisée d’emplacements publicitaires.
Des outils de mesure de performance : Des solutions logicielles sont dédiées au décompte du nombre de clics obtenus ou à l’analyse du trafic entrant².
Un système de ciblage avancé : le suivi du parcours des utilisateurs (tracking) permet de construire des profils publicitaires détaillés et de mettre en œuvre des campagnes de reciblage publicitaire (ou retargeting).

Au cours des deux dernières décennies, les pages de résultats des moteurs de recherche majeurs, tels que Google, ont connu des ajustements notables.

D’une part, le cadre réglementaire, notamment dans certains pays, ainsi que les attentes du public en matière de transparence, ont conduit à une identification visuelle plus claire des liens sponsorisés par rapport aux résultats dits “naturels”.

D’autre part, des innovations d’interface ont été introduites, telles que la “position zéro” (un encadré informatif apparaissant avant les résultats organiques pour fournir une réponse directe) ou l’amélioration algorithmique des titres des liens.

Malgré ces évolutions en surface, les fondements structurels du modèle économique sont restés les mêmes : des espaces ou des liens, vendus contre des clics.

L’intégration croissante de l’intelligence artificielle générative au cœur des moteurs de recherche marque une potentielle rupture.

Ces systèmes d’IA proposent désormais des paragraphes explicatifs, rédigés dynamiquement, en réponse directe aux requêtes des utilisateurs. Dans ce nouveau paradigme, les liens traditionnels peuvent subsister, mais ils se trouvent contextualisés par une sémantique préexistante, déjà porteuse d’une partie de la réponse.

Cette transformation de l’interaction utilisateur n’est pas une simple innovation d’usage ; elle implique un changement profond et systémique pour une partie importante du modèle économique des moteurs de recherche. Si l’IA fournit des réponses directes et complètes, le trafic vers les sites web sources pourrait chuter drastiquement. En contrepartie, ces réponses créent un potentiel d’influence considérable, susceptible de déterminer une navigation voire un achat futur.

Comment se monétisera l’influence dans ce nouveau paysage numérique ?

Sur les pages de résultats : prenons l’exemple d’une recherche pour “meilleur parfum floral pour femmes” qui aurait, auparavant, proposé comme premier lien une page produit pour une eau de parfum “Dior, J’adore” sur le site de Sephora. Dans une réponse IA, le parfum sera-t-il mis en avant comme étant “le plus connu”, “le plus vendu”, ou “le plus apprécié” ou est-ce la marque Sephora qui sera mise en avant, en rapport avec une des ses campagnes en cours ? Sur quels critères ce choix sémantique sera-t-il fondé ? La réponse sera-t-elle personnalisée en fonction des informations de profil de l’internaute, et si oui, avec quelle granularité (fidélité au parfum, fidélité au vendeur, sensibilité à la preuve sociale) ? Indépendamment du client, une valeur monétaire sera-t-elle affectée à l’exposition à ce type de message ?

Évolution des achats : comment les plateformes d’achat de campagnes publicitaires devront-elles évoluer ? Sera-t-il nécessaire pour une marque de définir les champs sémantiques auxquels elle souhaite être associée ? Faudra-t-il définir un univers sémantique spécifique pour chaque produit ou service ? Par conséquent, comment évolueront les mécanismes d’enchères associés et sur quels nouveaux critères (qualitatifs, contextuels, d’engagement) reposeront-ils ?

Évolution des mesures : La plupart des solutions d’analyse d’audience (les analytics) se transforment progressivement, passant d’un suivi du trafic brut à des analyses de cohortes d’utilisateurs et de leurs comportements. Il est donc probable que les analystes se retrouvent à comparer l’impact de différents messages générés par l’IA sur des segments d’audience spécifiques.

L’objectif sera alors d’identifier les champs sémantiques les plus porteurs d’engagement ou de conversion, et de déterminer à partir de quelle fréquence d’exposition un message est susceptible de provoquer un engagement ou une conversion. D’un point de vue projet, cela implique de redéfinir les indicateurs clés de performance au-delà du simple clic, pour y intégrer des mesures d’influence et de persuasion.

Évolution du ciblage : Les outils de profilage vont, si ce n’est déjà le cas, évoluer pour intégrer la sensibilité des personnes à tel ou tel champ lexical, niveau de langue, ou type d’argumentation. Cette perspective, bien que technologiquement séduisante pour l’optimisation publicitaire, soulève une préoccupation éthique majeure : le risque de créer un internet qui enferme toujours davantage les individus dans leurs biais cognitifs ou leurs préférences existantes (les “bulles de filtres”), plutôt que de leur permettre d’exprimer et de développer leur potentiel.

Cet aspect touche directement à la qualité de l’expérience utilisateur et à la responsabilité sociétale des plateformes numériques, notamment en matière d’accès équitable à l’information.

Évolution des placements publicitaires dans les sites : une fois généralisé l’usage des IA pour la publicité, elle devrait peu à peu gagner toutes les sphères. Plutôt que des liens d’affiliation, ce sont des paragraphes entiers de sites ou d’articles qui devraient bientôt être écrits par des IA dans des emplacements monétisés au sein-même des contenus. Je n’ai pas hâte de voir les premiers articles de Presse contenant un publi-communiqué au sein-même de l’article, avec la même logique d’évaluation de la valeur du paragraphe en fonction de son adéquation au ciblage.

Google, acteur aujourd’hui hégémonique sur le marché de la recherche, pourrait parvenir à conserver sa position dominante en adaptant son modèle, mais ça n’est pas gagné. La croissance considérable de Google au cours des vingt dernières années s’est principalement construite sur la capitalisation et l’optimisation de son modèle économique existant. Cette inertie structurelle pourrait paradoxalement représenter un frein à sa capacité à se réinventer en profondeur.

La clé de son succès futur pourrait résider davantage dans la maîtrise de l’écosystème des échanges et des interactions entre intelligences artificielles que dans la possession et l’exploitation de tous les services finaux eux-mêmes. Il s’agirait alors pour Google de s’atteler à la normalisation des protocoles et des interfaces permettant à des agents intelligents, développés par divers acteurs, de communiquer et de collaborer efficacement. C’est notamment l’objectif avoué du projet Google Agentspace : définir les règles du jeu de ce nouveau marché plutôt que de chercher à dominer chaque application spécifique qui y verrait le jour.

Cela me rappelle la stratégie historiquement adoptée par Google avec son Chrome. En investissant massivement dans le développement de Chrome et en proposant le navigateur gratuitement au public, Google a acquis une influence considérable sur l’évolution des standards du web, lui permettant d’orienter de nombreux chantiers de normalisation de manière favorable à son écosystème.

Est-ce que Google parviendra à reproduire ce succès dans un écosystème des IA déjà beaucoup plus fragmenté et compétitif que celui des navigateurs à l’époque du lancement de Chrome ?

Et comment cela s’articulera-t-il avec l’évolution du cadre régulatoire de certaines régions, comme l’UE qui impose une “obligation de transparence” (notamment dans les réponses “optimisées” sémantiquement, via l’AI Act et le Digital Services Act) ?

Connues sous l’acronyme anglais RTB pour Real-Time Bidding. ↩
Je reste persuadé qu’il y a conflit d’intérêt quand les outils appartenant au vendeur de la publicité sont considérés comme les seuls à même d’en juger l’efficacité. Je n’ai jamais connu d’outils vantant autant les vertus de la publicité sur l’acquisition que Google Analytics lui-même. ↩

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

De retour de l'AFPA

Wed, 12 Feb 2025 00:00:00 +0100

Ce matin, je me lève avec une sensation familière d’anticipation. Pas de travail pour Contentsquare comme tous les jours, mais une mission tout aussi importante m’attend. Direction un centre AFPA, où je vais participer comme jury à des soutenances de titres professionnels.

L’Association pour la Formation Professionnelle des Adultes (AFPA) est un organisme de formation professionnelle en France, spécialisé dans l’accompagnement des adultes en reconversion ou en recherche d’emploi. L’AFPA propose une large gamme de formations qualifiantes et certifiantes dans divers secteurs d’activité, allant de l’industrie aux services, en passant par le numérique et le bâtiment, incluant des périodes de stage en entreprise pour valider les compétences acquises.

Un peu de trajet, je me présente à l’accueil, et prends connaissance de ma salle et de mon binôme. Les soutenances peuvent commencer.

J’enseigne depuis 15 ans cette année.

Mon parcours de formateur a débuté par de la formation en entreprise, avant de rejoindre Ingésup Bordeaux à sa création. J’ai enseigné dans plusieurs écoles, toujours en parallèle de mon activité principale, avec des volumes d’enseignement allant de 50 à 150 heures annuelles.

En déménageant en Dordogne, où les écoles sont plus rares, j’ai élargi mon offre aux centres AFPA et transformé mes interventions en Master Class sur des journées entières. Une fois intégré·e dans le carnet d’adresses des responsables de formation, les invitations à participer à des jurys sont devenues régulières.

Les démarches d’habilitation pour être jury de titre professionnel sont assez simples, rapides (1/2 journée) et peuvent se faire à distance. Les prérequis sont transparents : que le titre soit relatif à votre activité professionnelle (au moins 3 ans d’expérience) récente (ne pas avoir quitté le métier visé par le titre depuis plus de 5 ans). L’habilitation est à revouveler régulièrement après quelques années, avec une procédure simplifiée.

Aujourd’hui, je délivre la certification professionnelle Développeur·se Web et Web Mobile (DWWM), référencée sous le code RNCP37674. C’est un sésame pour celles et ceux qui souhaitent entrer dans le marché du développement web ou approfondir ultérieurement leurs compétences avec une licence.

Les compétences validées par la certification DWWM sont réparties en 2 blocs de compétences :

Développer la partie front-end d’une application web ou web mobile sécurisée

Installer et configurer son environnement de travail en fonction du projet web ou web mobile
Maquetter des interfaces utilisateur web ou web mobile
Réaliser des interfaces utilisateur statiques web ou web mobile
Développer la partie dynamique des interfaces utilisateur web ou web mobile

Développer la partie back-end d’une application web ou web mobile sécurisée

Mettre en place une base de données relationnelle
Développer des composants d’accès aux données SQL et NoSQL
Développer des composants métier coté serveur
Documenter le déploiement d’une application dynamique web ou web mobile

Il ne s’agit pas ici de savoir si le candidat ou la candidate est autonome dans la réalisation de toutes ces tâches. Un junior avec un certification professionnelle reste junior en développement et a encore besoin de beaucoup d’accompagnement. Mais pour les compétences qui leur manquent, les reconverti·es apportent souvent un bagage singulier que d’autres n’ont pas.

En plus de ces compétences, nous devons aussi évaluer le projet professionnel et donc valider que sont connues les attendus du marché : bases de gestion de projet, versionning, modalités de déploiement, capacité à réaliser une veille technologique, mise en œuvre des bonnes pratiques (notamment de sécurité), tests, etc.

Le fait que ces sujets ne soient pas connus du ou de la candidate n’est pas rédhibitoire, mais les aborder permet de les identifier, et la personne pourra y revenir plus tard.

Notre premier·e candidat·e entre, présente sa convocation et sa pièce d’identité, et la soutenance peut commencer.

La soutenance se décompose en trois étapes distinctes.

Tout d’abord, la présentation en 35 minutes. Le ou la candidate expose les acquis de sa formation, idéalement confirmés par son stage de fin de formation. Le jury, silencieux, prend des notes sans partager ses commentaires.

Cette étape est cruciale car elle permet d’évaluer la capacité du ou de la candidat·e à synthétiser et à communiquer ses compétences. C’est aussi un exercice extrêmement difficile pour des personnes que rien ne prépare à parler avec aisance d’un sujet qu’elles ne connaissaient pas il y a 18 mois, et qu’elles maitrisent encore mal.

Le stress est souvent palpable, et je propose régulièrement aux candidat·es de prendre le temps dont ils ont besoin pour reprendre leurs esprits avant d’enchainer.

S’ensuivent 40 minutes d’échange technique. C’est en réalité le moment plus difficile.

Le jury, référentiel de compétences en tête (et parfois en main), doit s’assurer que l’ensemble du spectre a été couvert. Nous essayons de dénicher le moindre indice nous laissant à penser que si certains mots-clés ne sont pas connus ou mentionnés, les notions de fond, elles, sont comprises… mais cela peut rapidement prendre l’apparence d’un interrogatoire.

Le ou la candidate, qui a souvent concentré sa présentation sur ses réalisations en stage, se retrouve à devoir mobiliser des connaissances acquises en formation ou travaux individuels des mois auparavant. C’est souvent à ce moment-là que les candidat·es nous détestent, et nous le savons (parfois, même, nous les entendons en parler dans les couloirs).

Enfin, le ou la candidate s’assoit pour 15 minutes d’échange sur son projet de carrière. Le jury pose des questions sur ce qui a amené·e à suivre cette formation et sur les projets futurs, tout en prodiguant des conseils si le ou la candidate en demande. Un de ces échanges avait par exemple donné ce billet sur la différence entre métier et passion.

C’est aussi un moment privilégié pour les candidat·es, qui ont rarement l’occasion de s’adresser à des professionnel·les en dehors du cadre de l’entretien d’embauche. Ils et elles peuvent ainsi obtenir des avis expérimentés sur les sujets qui les intéressent. Et certains n’hésitent pas à proposer leurs CVs !

Rien ne ressemble moins à un parcours de reconversion qu’un autre.

Bien sûr, on retrouve de grandes familles de profils : les jeunes dont l’orientation initiale était une erreur et qui bifurquent sans avoir vraiment pénétré le marché du travail, les trentenaires qui, après une décennie dans un premier emploi, souhaitent changer de vie…

Mais en creusant, les histoires sont toujours singulières. Même sans être intrusif·ives, les candidat·es nous révèlent des accidents de la vie, des violences psychologiques, voire physiques (subies ou infligées), le spectre ou les sequelles de maladies, et l’inégalité des territoires face à l’emploi. Je mentirais si je disais que chaque rencontre ne m’émeut pas.

Une fois le ou la candidat·e parti·e, vient la délibération.

En général, le jury débat peu. Les attendus des certifications sont clairs, et la réponse s’impose souvent à nous, qu’on le veuille ou non. Mais on ne passe pas 90 minutes avec quelqu’un à échanger sur ses compétences et aspirations sans développer une opinion sur les gens, en plus de leurs compétences. Alors parfois, on donne la certification à des personnes avec qui on ne voudrait pas, nous, travailler.

Réciproquement, on a parfois envie de soutenir tel ou telle candidate qui n’est pas loin de valider les compétences… Mais ce petit écart fait la différence, et si on leur donne le certificat alors que les compétences ne sont pas acquises, on dévalue la valeur (déjà mal reconnue et précaire) du certificat des autres.

Quatre ou cinq candidat·es plus tard, la journée se termine. C’est l’heure de retourner chez moi pour me préparer à revenir demain. Et vendredi, retour au quotidien.

Une fois habilité·e, votre employeur peut difficilement vous refuser un congé pour participer à un jury. La loi indique qu’il s’agit d’un motif d’absence autorisée dont le congé ne peut pas être prélevé sur vos congés annuels. Certains employeurs anticipent et favorisent ce type de pratique en couvrant les frais relatifs au déplacement ou au logement : si ce n’est pas la cas, les AFPA les rembourseront.

Ce qu'en dit le Code du Travail (au 12 février 2025)

Article L3142-42
Lorsqu'un salarié est désigné pour siéger dans une commission, un conseil ou un comité administratif ou paritaire appelé à traiter des problèmes d'emploi et de formation, l'employeur lui accorde le temps nécessaire pour participer aux réunions de ces instances.

La liste de ces instances est fixée par arrêté interministériel.

Lorsqu'un salarié est désigné pour participer à un jury d'examen ou de validation des acquis de l'expérience, l'employeur lui accorde une autorisation d'absence pour participer à ce jury.

Article L3142-43
La participation du salarié aux réunions et jurys mentionnés à l'article L. 3142-42 n'entraîne aucune réduction de la rémunération.

La durée des congéscorrespondants ne peut être imputée sur celle du congé payé annuel.

Article L3142-44
Un décret détermine les conditions dans lesquelles les dépenses afférentes au maintien du salaire et au remboursement des frais de déplacement sont supportées par les instances et jurys mentionnés à l'article L. 3142-42 ou par l'entreprise.

Article L3142-45
Le bénéfice du congé peut être refusé par l'employeur s'il estime que cette absence est susceptible d'avoir des conséquences préjudiciables à la bonne marche de l'entreprise.

Le refus de l'employeur intervient après avis du comité social et économique. Il est motivé.

En cas de différend, le refus de l'employeur peut être directement contesté par le salarié devant le conseil de prud'hommes, statuant selon la procédure accélérée au fond, dans des conditions fixées par décret en Conseil d'Etat.

Je mesure la chance et le privilège d’avoir trouvé ma voie tôt. J’aime encore tellement mon domaine que je veux contribuer à y faire entrer de nouvelles têtes, et j’espère qu’un jour, j’aurai l’occasion de travailler avec des personnes rencontrées aujourd’hui.

Mais je sais aussi que la reconversion professionnelle est un parcours semé d’embûches. Le chemin est encore long pour garantir à tou·tes les mêmes chances de réussite. Les organisations syndicales, la médecine du travail, et les commissions santé, sécurité et conditions de travail ont encore beaucoup à faire pour améliorer les conditions de formation et de reconversion.

Peut-être faudrait-il envisager des dispositifs de financement dédiés, comme un “Compte Reconversion”, à l’image du compte formation, pour soutenir les candidat·es dans leur parcours. Tout reste à inventer, mais chaque jury est une étape de plus vers une société où la reconversion professionnelle est une opportunité accessible à tou·tes.

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Votre site est un restaurant

Sat, 07 Dec 2024 00:00:00 +0100

Dans la plupart des organisations, avant même de créer un site web, les équipes sélectionnent les technologies à utiliser, souvent sans avoir défini le périmètre fonctionnel et l’expérience utilisateur souhaitée. Je ne m’attarderai pas ici sur leurs motivations, mais le fait est qu’elles présentent cela aux parties prenantes qui, souvent, ne savent pas de quoi il retourne et valident par manque de compétences.

Avant de vous plonger dans les dernières technos mises en avant par les grandes entreprises, en pensant avoir les mêmes besoins et capacités qu’elles, permettez-moi de prendre un moment pour vous expliquer comment un site web est construit, en utilisant une métaphore que vous comprendrez : les restaurants.

Comment servir un plat de restaurant ?

Si vous souhaitez un jour servir un plat, vous aurez besoin d’une liste précise d’ingrédients et de leurs attributs (qui peuvent dépendre de l’ingrédient). Une carotte peut être cuite à la vapeur, un œuf poché. Cette liste d’ingrédients cuisinés ajoute de la profondeur et de la saveur au plat.

Ça, c’est HTML.

Des ingrédients cuisinés ne suffisent pas à créer un plat ; la présentation est essentielle. Pour susciter l’intérêt des clients, vous devez mettre en valeur ces ingrédients d’une manière qui reflète l’essence de l’art culinaire du restaurant.

Ça, c’est CSS.

Toutefois, une belle présentation ne suffit pas à définir un plat de restaurant. Pour y parvenir, il faut un personnel de service attentif qui prend les commandes, les communique à la cuisine et sert ensuite les assiettes dans la salle à manger.

Ce processus représente votre navigateur qui interagit avec le web.

Voilà, vous avez les bases.

Maintenant créons un restaurant qui deviendra par la suite une franchise.

Créer le projet

Pour mener à bien ce projet, les propriétaires réunissent une équipe dédiée. Celle-ci comprend un designer qui imagine l’expérience client, un chef cuisinier chargé d’élaborer les processus de cuisine et des artisans qualifiés chargés de construire les meubles et les cloisons. Bien que les propriétaires n’aient pas les moyens d’embaucher un designer, un chef et des artisans à temps plein dans un premier temps, ils prévoient de le faire une fois la franchise établie afin d’optimiser les coûts.

Le lancement du projet implique rapidement que les parties prenantes se rencontrent, car certaines décisions prises en cuisine impactent l’organisation de la salle de restauration ainsi que les choix de design. Servir de la nourriture fusion dans un décor de cow-boy n’est peut-être pas le meilleur choix !

Le comité de pilotage s’appuie sur les retours des artisans et de la brigade ; cependant, il prend fréquemment des décisions en huis clos. Il est donc essentiel que les informations partagées avec lui soient de haute qualité et qu’il possède une expérience suffisante pour prendre des décisions éclairées.

De nombreux projets web débutent par la constitution d’un petit comité de pilotage composé de prestataires, chargé de définir la vision et la gouvernance du projet. Au cours de cette phase, des décisions sont prises qui peuvent ne pas tenir compte des équipes qui seront chargées de faire vivre ces initiatives au cours des mois, voire des années suivantes.

Répétitions et pré-ouverture

Une fois que tout est en place, les propriétaires organisent des services fictifs, également appelés répétitions générales, qui permettent au personnel de service de simuler des scénarios réels, les aidant ainsi à affiner leur fonctionnement et à identifier tout problème opérationnel avant le lancement officiel. C’est souvent la première occasion pour tout le personnel de travailler ensemble.

Dans les projets web, nous appelons cela l’environnement d’intégration.

Une fois les propriétaires satisfaits, ils invitent amis et famille pour des pré-ouvertures privées. Cela permet à l’équipe de tester le service et de recueillir des retours clients dans un environnement concret, en apportant les ajustements nécessaires.

C’est l’environnement de pré-production ou de staging.

Petit à petit, les propriétaires décident d’augmenter le nombre de personnes. C’est un test de la capacité à monter en charge du service. Combien de clients pouvons-nous accueillir en une soirée ? Et combien pouvons-nous servir en une semaine ? Et si nous atteignons notre limite, qu’est-ce qui lâchera en premier et quelle sera l’expérience client ?

Sur le web aussi, nous faisons des tests de charge !

L’offre la plus simple

Le premier bistrot est désormais officiellement ouvert ! L’expérience culinaire est simple mais très efficace. Le menu propose une sélection soigneusement choisie et très limitée de plats, garantissant que chaque commande est préparée rapidement, satisfait les clients et est joliment présentée. Les clients peuvent commander à la carte, ou même demander des plats personnalisés, mais la plupart ne le font pas. Le personnel de service peut se déplacer efficacement entre la cuisine et les tables, améliorant ainsi l’efficacité globale du service. Après quelques années de fonctionnement, les propriétaires décident d’investir pour multiplier le nombre de restaurants. La franchise est en place.

Les sites web très simples en HTML+CSS, avec une personnalisation côté serveur limitée, sont souvent les plus rapides. Ils ont un Time To First Bite (Temps avant la Première Bouchée) très court ! La montée en charge est souvent aussi simple que de multiplier les serveurs frontaux.

Fast Food

À un moment donné, les propriétaires estiment que le concept peut être optimisé en investissant dans un processus de production à la chaîne plus efficace. Les clients perdent ainsi la possibilité de personnaliser leurs plats et doivent choisir parmi des menus standardisés. La brigade n’a besoin de consulter une nouvelle recette qu’une seule fois pour en maîtriser instantanément la préparation. La rapidité du service est donc déterminée par la vitesse à laquelle le personnel de service peut livrer les assiettes, dans la mesure où l’espace le permet. Le nouveau goulet d’étranglement est le paiement, car il n’est pas possible de produire en masse les additions, qui dépendent de la commande de chaque table, et de procéder à leur encaissement.

Sur le web aussi, on peut obtenir des réponses instantanées si l’on sert le même contenu à chaque visite : c’est ce qu’on appelle la mise en cache. Cependant, quelle que soit la rapidité de votre site web, la vitesse sera toujours limitée par les étapes personnalisées, telles que les entonnoirs de paiement. Il est essentiel de garantir une excellente interface utilisateur pour éviter les frustrations.

Quality Audits

Pour obtenir une certification ISO et se conformer aux cadres réglementaires dans tous les lieux où la franchise opère, les propriétaires ont choisi de mener des audits complets sur l’ensemble de la chaîne. Cela inclut tout, de l’accès des clients à la salle de restauration, aux procédés de fabrication des denrées alimentaires, en passant par l’approvisionnement en ingrédients.

Les thèmes peuvent varier considérablement. Par exemple, les auditeurs peuvent signaler l’absence de mains courantes dans les toilettes pour les clients handicapés ou souligner que le type de carottes utilisé en cuisine n’est pas sourcé localement. Ils fournissent des listes de contrôle, tests et vérifications que les propriétaires peuvent effectuer avant, pendant et après chaque service pour éviter toute régression en termes de qualité.

L’assurance qualité (Quality Assurance, ou QA) dans le développement web garantit que les sites web fonctionnent correctement et répondent aux exigences grâce à des processus de test et de validation systématiques. L’audit implique la révision et l’évaluation des applications web pour leur conformité aux normes et aux meilleures pratiques, identifiant les domaines à améliorer. Certains outils automatisés permettent d’effectuer des tests répétitifs de manière efficace, améliorant ainsi la fiabilité et la rapidité. Cependant, certains problèmes, en particulier l’accessibilité numérique, nécessitent une évaluation manuelle approfondie pour garantir la conformité avec des directives telles que les Web Content Accessibility Guidelines (WCAG) ou en France, le Référentiel Général d’Amélioration de l’Accessibilité (RGAA).

Service en salle

Pour améliorer la qualité du service, les propriétaires ont décidé de mettre en place une équipe d’assistance à la clientèle appelée “Jolly Servants” (JS). Certains de ces JS sont spécialisés dans les boissons, tandis que d’autres se concentrent sur l’assaisonnement. Parfois, ils offrent des services personnalisés sans quitter la salle, en fournissant des recommandations ; cependant, il arrive qu’ils aient besoin de l’aide de la cuisine, et demandent alors de l’aide au personnel de service habituel. Certains sont maladroits et déstabilisent le service lorsqu’ils tombent.

Bien que l’expérience de l’utilisateur soit de plus en plus personnalisée, la salle peut devenir quelque peu bondée, ce qui ralentit le service. Par conséquent, certains clients peuvent se retrouver à attendre avant de pouvoir profiter d’une expérience satisfaisante. En outre, le personnel de service doit parfois déplacer des assiettes pour faire de la place à d’autres, ce qui peut être frustrant.

JavaScript (JS) améliore les capacités natives du navigateur en offrant une expérience utilisateur avancée qui peut dépendre (ou non) des données du serveur. Cependant, une quantité excessive de JS peut entraîner des tâches longues (périodes pendant lesquelles le navigateur ne répond plus), ce qui peut se traduire par une expérience plus lente ou moins satisfaisante. Le déplacement d’éléments visuels peut entraîner des changements de mise en page, ce qui réduit encore l’expérience globale de l’utilisateur.

Mesurer pour optimiser

Pour améliorer les conditions d’exploitation du restaurant, les propriétaires ont engagé deux maîtres d’hôtel contractuels. L’un d’eux se concentre sur l’évaluation de la cuisine et du bureau, en identifiant les goulets d’étranglement dans les zones de stockage et de préparation, ainsi que dans la comptabilité. L’autre maître d’hôtel observe le personnel de service, les interactions avec les clients à leur table et la caisse enregistreuse.

Tous deux prennent méticuleusement des notes, qui sont ensuite envoyées à leur entreprise, laquelle génère un rapport en temps réel détaillant les performances du restaurant, avec des données de diagnostic et des recommandations d’amélioration réalisables.

Leur présence peut ralentir les opérations, surtout dans une cuisine ou une salle à manger déjà encombrée.

Les propriétaires reconnaissent qu’il ne s’agit là que d’une partie de leur investissement. Ils ont également confié au comité de pilotage la responsabilité de mettre en œuvre les améliorations, car l’observabilité seule est inefficace sans un effort d’amélioration continue qui lui aussi, coûte de l’argent.

Pour améliorer les performances du site web, les parties prenantes s’appuient souvent sur de la télémétrie. Certains services se spécialisent dans la surveillance du back-end, comme les outils de suivi des performances des applications (Application Performance Monitoring, APM), tandis que d’autres se concentrent sur le front-end, notamment les outils analytiques (Analytics) et de surveillance des utilisateurs réels (Real User Monitoring, RUM). Ces outils alimentent l’amélioration continue en permettant l’observation de l’utilisation, mais la plupart des sites web doivent sélectionner judicieusement leurs outils, car l’intégration d’un trop grand nombre de services tiers peut ralentir l’expérience.

Assiettes musicales

Pour mieux comprendre les attentes des clients, les propriétaires ont mis en place une série de tests. Dans un premier temps, différents restaurants de la franchise ont proposé des menus distincts, tandis que l’équipe dirigeante a analysé l’impact de ces variations sur l’expérience des clients. Mais ils se sont vite rendu compte qu’il était difficile de tirer des conclusions à partir d’une population hétérogène ayant des habitudes culturelles différentes. Ils ont donc décidé de mener les tests dans un même restaurant, en demandant aux Jolly Servants de présenter des menus différents à des tables différentes.

La conduite de tests visant à faire évoluer le menu d’un restaurant présente des difficultés considérables. Déterminer quelles tables ont droit à des options de menu spécifiques demande beaucoup de temps aux JS, ce qui peut avoir un impact négatif sur l’expérience globale du client. Certains habitués peuvent être déconcertés par le fait que le menu change d’un jour à l’autre, ce qui donne un sentiment d’incohérence qui s’ajoute à la lenteur du service.

Les tests A/B, principalement orchestrés par du code JS, sont largement considérés comme la méthode la plus fiable pour évaluer comment les changements apportés à un site web affectent l’expérience d’utilisation. Toutefois, la réalisation de ces tests peut s’avérer délicate et entraîner une expérience sous-optimale pour les utilisateurs au cours de la période d’évaluation. Les professionnels du web conseillent généralement de faire preuve de prudence lors de la mise en œuvre des tests A/B, de définir clairement la portée et la durée des tests et de veiller à ce que les solutions soient désactivées lorsqu’elles ne sont plus utiles.

Partenariats et délégation de tâches

Certaines parties du menu sont confiées à des partenaires avec lesquels le propriétaire a établi des conventions. Par exemple, les coupes glacées seront préparées par un glacier local. En outre, certains Jolly Servants internes ont été remplacés par des sous-traitants ; en particulier, un caviste installé de l’autre côté de la rue se charge désormais de la sélection des vins et formule des recommandations.

En réorientant son personnel vers son activité principale, les propriétaires ont amélioré à la fois l’efficacité et la fiabilité du service. Toutefois, cette réorientation a eu pour effet de ralentir certaines expériences déléguées, voire de les rendre plus risquées, notamment lorsque le sommelier doit se frayer un chemin dans la circulation en traversant la rue aux heures de pointe.

Les propriétaires doivent donc désormais surveiller leurs partenaires. En tant qu’éléments clés de ce partenariat, leur rôle est crucial pour la réussite de l’entreprise.

L’utilisation de JavaScript tiers peut s’avérer très efficace pour fournir des services qui seraient autrement hors de portée ou dont on sait qu’ils seront mieux exécutés par des professionnels. Toutefois, leur utilisation nécessite un contrôle rigoureux pour garantir que les services fonctionnent correctement et ne rencontrent pas de défaillances susceptibles de dégrader l’expérience d’utilisation. Les services de télémétrie et d’observabilité peuvent aider à détecter les erreurs et à évaluer leur impact.

À la table du Chef

Pour se démarquer de la concurrence, les propriétaires décident que certains de leurs franchisés offriront une expérience unique et caractéristique : la table du chef. Directement à la table, un chef spécialisé prépare un menu personnalisé pour les clients, en fonction de leurs préférences, de leurs restrictions alimentaires et de la disponibilité des ingrédients apportés par le personnel de service et les Jolly Servants.

Les tables de chef occupent un espace important dans la salle, ce qui oblige le personnel de service à se déplacer fréquemment pour rassembler ou réarranger les ingrédients. Cela peut ralentir le début du repas. C’est pourquoi, généralement, cette expérience immersive commence par la dégustation d’un délicieux cocktail pendant que les convives attendent.

Une fois que tout est en place, la table fonctionne de manière autonome, ce qui réduit la demande en cuisine, qui peut même devenir nulle. Le service fourni est à la fois personnalisé et immédiat. Toutefois, cette expérience exclusive n’est généralement accessible qu’aux clients les plus aisés (ou à ceux qui ont le plus gros carnet d’adresses !).

Afin de rehausser leur statut, les restaurants voisins ont commencé à proposer aussi des tables de chef, y compris le fast food situé à deux pâtés de maisons. Les longs temps d’attente et l’expérience décevante font que les clients ne reviennent pas pour une deuxième visite !

Dans l’industrie du web, les applications à page unique (Single-Page Apps, SPA) sont particulièrement bien adaptées à la création de parcours immersifs et attrayants pour les utilisateurs. Elles prennent souvent plus de temps à charger, et encore plus sur les appareils d’entrée de gamme, de sorte que les parties prenantes doivent réfléchir sérieusement aux astuces visuelles à utiliser pour embarquer le public et lui faire supporter l’attente.

De nombreux petits sites web adoptent des SPA, s’inspirant de la tendance établie par les grands acteurs du web, même lorsque leurs besoins sont simples et standardisés. Il en résulte souvent une mauvaise affectation des ressources, car les équipes utilisent des librairies et techniques qui ne correspondent pas à leurs besoins, et n’ont pas les moyens d’investir correctement dans leur mise en œuvre.

Des sites web divers pour de belles expériences

En conclusion de cette métaphore imparfaite et incomplète, je pense qu’il est essentiel de comprendre que, tout comme il existe différents types de restaurants, il devrait également y avoir une large variété de manières de faire des sites web. Du restaurant indépendant informel à la table de chef exclusive, chaque site peut offrir une expérience unique, avec son propre lot de défis.

Souvent, les solutions les plus simples s’avèrent les plus efficaces. Toutefois, un manque de personnalisation peut entraîner une diminution des marges bénéficiaires et entraver le développement d’une identité de marque solide. À l’inverse, les solutions plus complexes exigent une prise en compte méticuleuse de l’expérience utilisateur, ce qui nécessite des investissements importants dans l’analyse de la frustration et de l’amélioration continue. La dégradation temporaire d’une expérience peut être une décision stratégique visant à l’améliorer à long terme. Il est essentiel d’investir dans les processus et, en particulier, la mise en œuvre de l’assurance qualité joue un rôle essentiel dans la réduction des risques les plus importants.

Merci à Meryem, qui a supporté mes expériences de métaphores filées pendant plus d’un an, et à Morgan, Luke et Natacha pour leur relecture !

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Incremental Font Transfer

Wed, 23 Oct 2024 00:00:00 +0200

Pour un français comme moi, les langues asiatiques telles que le chinois, le japonais et le coréen, ainsi que d’autres ayant des écritures complexes, contiennent souvent beaucoup de caractères. Bien que cette diversité soit culturellement fascinante, elle pose de vrais défis lors de la sélection d’une police web. Les fichiers peuvent avoir un poids potentiellement très important, ce qui entraîne des temps de chargement plus lents, en particulier sur les appareils mobiles ou dans les régions avec une connectivité limitée à Internet.

Pour vous donner un ordre de grandeur de la différence de poids, voici le sous-ensemble latin-étendu :

En conclusion : le fichier de police médian avec un sous-ensemble latin-étendu de (395) caractères devrait pesé un peu moins de 20 Ko. Si vous regardez vos requêtes réseau et que votre police est beaucoup plus lourde, eh bien, il y a du travail à faire. ”How many bytes is “normal” for a web font: a study using Google fonts”, Stoyan Stefanov (traduction en français)

Et voici pour le chinois :

Dans un type de police chinois, la plus petite police standard contient 6 763 caractères. Un type de police japonais appelé Hanazono a 87 791 caractères. La taille typique d’un fichier de police chinois est généralement d’au moins 5 Mo, parfois plus de 20 Mo. ”Chinese Typographic Design”, Hynuza (traduction en français)

Vous comprendrez pourquoi il est courant de s’abstenir d’utiliser des polices web pour les pages web accessibles en ligne dans cette région.

De l’optimisation est toujours possible. Une méthode efficace est le subsetting, qui consiste à créer un sous-ensemble d’une police - un fichier qui inclut une sélection personnalisée (et généralement limitée) de glyphes. Mais même avec un chinois de base niveau lycée, nous aurions besoin d’un minimum de 3 000 caractères.

Je savais que le streaming de polices n’était pas possible, mais une publication récente d’Anthony sur le Web Performance Slack a attiré mon attention. Il faisait la promotion d’une nouvelle spécification (encore en brouillon) spécifiquement conçue à cet effet.

Sans cette technologie, un navigateur doit télécharger chaque dernier byte d’une police avant de pouvoir rendre des caractères utilisant cette police. ”Incremental Font Transfer”, W3C Working Draft (traduction en français)

L’idée est de créer une police qui peut être segmentée en un chargement initial, contenant uniquement le sous-ensemble de ce qui est critique, puis de lui adjoindre des additions qui complètent la police en cours de route. Une sorte de lazy-loading, mais pour les polices d’écriture.

Cette première itération, si elle est mise en œuvre dans les navigateurs, a le potentiel de débloquer d’importantes opportunités pour les marchés asiatiques. Je suis enthousiaste, même si je n’ai pas hâte de devoir maîtriser des descripteurs de police tels que size-adjust ou ascent-override pour gérer efficacement l’expérience utilisateur lors du chargement successifs de correctifs contenant des milliers de glyphes !

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

L'API Speculative Rules

Mon, 03 Jun 2024 00:00:00 +0200

En Web Performance, il arrive un moment où vous avez épuisé toutes les options pour accélérer la vitesse de la page web que vous optimisez. Peut-être parce que vous avez appliqué toutes les améliorations que vous aviez prévues, ou peut-être que les contraintes de votre stack techno ne permettent pas d’aller plus loin. Lorsque vous atteignez ce point, votre attention se déplace généralement vers l’accélération du temps de chargement de la prochaine page web.

J’ai vu beaucoup d’expériences en ce sens au fil des ans, et je surveille de près la nouvelle itération : l’API Speculative Rules.

Petit historique personnel

Au début des années 2000s, les abonnements d’accès à Internet étaient limités dans le temps. Mon moi adolescent utilisait FasterFox, une extension Firefox qui préchargeait tous les liens possibles sur une page web pendant que je la lisais, me permettant de poursuivre ma navigation hors ligne. C’était particulièrement utile pour les sites web riches en contenu, comme ceux avec des paroles de chansons et des astuces de jeux vidéo !

À un moment, Firefox a introduit le support de la balise <link rel="next">, qui permettait au navigateur de précharger une page vers laquelle il prévoyait que l’utilisateur naviguerait ensuite. J’ai trouvé cette fonctionnalité particulièrement pratique pour créer des articles étalés sur plusieurs pages sur mes premiers blogs.

Pendant une période, je me suis concentré sur .NET et je ne me suis pas beaucoup intéressé au préchargement (j’ai surtout utilisé Wordpress pour la création de contenu, et j’ai appris jQuery, puis JavaScript, en cours de route). Je m’y suis remis sérieusement vers 2012.

Quelques années plus tard, Alexandre Dieulot a proposé un concept intéressant : il a remarqué qu’il y a généralement un délai de 200 à 300 millisecondes entre le moment où une personne survole un lien et celui où elle clique dessus. Il s’est demandé si ce délai pouvait être utilisé pour précharger la page, afin qu’elle soit prête dès que l’utilisateur clique. Cette idée, bien qu’elle nécessite de définir ce qu’était un préchargement et d’exclure les liens de téléchargement, était relativement simple et a conduit à la création de la bibliothèque InstantClick.io et son utilisation d’un requête XHR similaire à un prefetch.

D’autres bibliothèques ont suivi, offrant des possibilités supplémentaires. La plus remarquable d’entre elles était sûrement turbolinks. Ces bibliothèques visaient à offrir à l’utilisateur la même expérience avec les Multiple Page Apps (MPA) qu’avec les Single Page Apps (SPA). Elles s’appuyaient sur des Resource Hints et sur la toute nouvelle API HTML5 History pour conserver l’usage des boutons Retour et Rechargement. Il était possible d’utiliser à la fois une solution de type SPA et InstantClick, comme je l’ai fait sur ce blog pendant un certain temps. Cependant, j’ai finalement décidé que les avantages étaient trop faibles compte tenu du temps de réponse natif déjà rapide du site.

Compte tenu de l’efficacité de ces solutions et de leur faible besoin de maintenance au fil du temps (InstantClick n’a pratiquement pas changé en 10 ans), il semblait logique de développer une nouvelle API de navigateur qui améliorerait nativement les performances pour les navigations futures.

Découvrons l’API Speculative Rules

L’API Speculative Rules introduit une nouvelle méthode déclarative pour indiquer au navigateur quel contenu doit être préchargé et/ou pré-rendu à la demande du concepteur ou de la conceptrice du site.

Les règles de spéculation contiennent un paramètre appelé eagerness (qu’on peut traduire par “degré d’impatience”) qui détermine quand le navigateur doit télécharger le contenu. Doit-il le faire immédiatement (comme le faisait FasterFox), ou doit-il attendre un signal supplémentaire, tel qu’un survol (comme InstantClick), ou même le déplacement du pointeur de la souris vers le lien ?

Je trouve que les règles établies par cette API sont élégamment définies et faciles à comprendre. Prenons l’exemple suivant, directement à la fin du <body> :

<script type="speculationrules">
  {
    "prefetch": [
      { "where":
        { "href_matches": "/*" },
        "eagerness": "moderate"
      }
    ]
  }
</script>

Ou sous la forme d’un snippet à intégrer dans votre tag manager (pour un A/B test, par exemple) :

(function () {
  if (HTMLScriptElement.supports && HTMLScriptElement.supports('speculationrules')) {
    const script = document.createElement("script");
    script.type = "speculationrules"
    script.textContent = JSON.stringify({
      prefetch: [
        {
          where: { 'href_matches': '/*' },
          eagerness: 'moderate'
        }
      ]
    });
    document.body.appendChild(script);
  }
})()

NOTE
L’ajout d’un snippet HTML personnalisé dans Google Tag Manager ne déclenchera pas les règles de spéculation. Préférez l’option du snippet JavaScript.

Il indique au navigateur que pour toutes les URLs du domaine courant /*, il peut faire du prefetch s’il pense que l’utilisateur va avoir besoin du contenu. Avec une impatience “modérée” (moderate), cela se produira principalement lorsque l’utilisateur survolera le lien.

Est-ce vraiment si simple ? Oui.

Vous avez également la possibilité d’utiliser prerender au lieu de prefetch. Cependant, permettez-moi d’insister sur le fait que si la règle `prerender$ est appliquée, elle récupère et traite la ressource à l’avance, ce qui inclut la récupération des sous-ressources également, qu’elles proviennent d’une première ou d’une troisième partie.

Devons-nous attendre un peu ?

Déjà, précisions que même si la fonctionnalité est déployée dans Chrome depuis quelques mois, elle reste récente. Certaines alchimies, comme la spéculation prefetch couplée à un Service Worker, ne fonctionnent pas encore. Rien de dramatique, mais précaution est mère de sûreté.

Le préchargement et le rendu spéculatif, bien que bénéfiques pour l’expérience de certains utilisateurs, comportent le risque de gaspiller des ressourses : de la bande passante et des ressources du serveur si les données extraites ne sont pas utilisées parce que l’utilisateur ne navigue pas jusqu’à la page ainsi optimisée.

Si votre objectif est d’améliorer la sobriété de votre site web ou si vous êtes tenu d’en rendre compte (par exemple, en raison de la directive européenne sur les rapports de développement durable des entreprises), il n’est peut-être pas judicieux de gonfler artificiellement le nombre de pages que vos serveurs calculent et délivrent et que vos utilisateurs téléchargent.¹

Du côté du serveur, l’utilisation de règles de spéculation peut potentiellement présenter un risque pour votre site web. Si une règle est trop gourmande, elle peut déclencher un grand nombre de chargements de pages et de ressources pour chaque utilisateur. Cette charge accrue peut mettre à rude épreuve la capacité de votre serveur à fournir rapidement du contenu à tous les utilisateurs, en particulier si vous n’avez pas mis en place de fonctionnalités de mise en cache au préalable. Dans les cas extrêmes, cela peut vous conduire à vous infliger à vous-même un déni de service distribué (DDoS).

L’utilisation de l’API Speculative Rules ne doit se faire uniquement au regard des impératifs d’amélioration de l’UX, mais aussi en prenant en compte d’autres facteurs. Nous pouvons aussi optimiser les règles : en tant qu’administrateurs de sites web, nous pouvons utiliser l’analyse comportementale pour mieux connaître les pages les plus populaires et les parcours de navigation des utilisateur·ices. Ces informations peuvent nous aider à déterminer si l’utilisation de l’API Speculative Rules améliorerait ou nuirait à l’UX.

Enfin, et ce n’est pas neutre, l’utilisation de l’API Speculative Rules peut s’apparenter à une forme de suivi des survols des utilisateurs. En effet, si on imagine qu’un survol d’un lien ou qu’un glissement du pointeur de la souris vers un lien déclenche un prefetch ou un prerender alors il suffirait d’aller consulter les logs du serveur pour savoir ce qu’il a intéressé un utilisateur, qu’il visite la page… ou non².

Alors, on y va ?

L’API Speculative Rules est le dernier développement d’une histoire qui dure depuis longtemps. Les problèmes que j’ai évoqués étaient déjà inhérents aux solutions précédentes. l’API Speculative Rules ne fait qu’intégrer ce comportement directement dans le navigateur, ce qui présente certains avantages par rapport à JavaScript.

Tout d’abord, le navigateur est mieux équipé qu’un développeur pour déterminer la position des éléments et comprendre les mouvements de la souris de l’utilisateur. C’est pourquoi il constitue actuellement l’option la plus efficace pour ce type d’optimisation. Deuxièmement, le navigateur est conscient de l’état de la connexion et du niveau de la batterie, et peut choisir de ne pas charger les ressources de manière spéculative si les conditions ne sont pas favorables. Si le navigateur détecte que les réponses du serveur à cette origine sont trop lentes, il peut également désactiver ce comportement.

Tout ceci étant dit, la demande du public pour un web plus durable et respectueux de la vie privée n’a jamais été aussi forte. Soyez donc peu gourmand dans vos règles et n’abusez pas des droits que vous avez sur les logs produits. Le chargement de ressources le plus sobre est celui qui n’a jamais eu lieu.

A l’inverse, vous pouvez avoir un intérêt particulier à gonfler ces chiffres. En France, par exemple, les aides publiques à la Presse sont calculées en fonction du nombre de pages vues. Il est évident que certaines entités exploiteront ces règles pour “générer des pages vues”, tout comme elles le faisaient auparavant avec des rafraîchissements excessifs. ↩
Si un tel traitement des données est fait, il devrait –en tout cas dans l’Union Européenne– être encadré par un consentement. ↩

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Entendre le réseau

Thu, 23 May 2024 00:00:00 +0200

Voici bon outil de sensibilisation qui passe par l’audio : Netbeep est une extension Chrome qui joue des sons à chaque requête sur le réseau en fonction du type de contenu et du domaine appelé. Le pitch du son est plus élevée pour les fichiers plus volumineux.

Une bonne manière d’activer la synesthésie. En s’appuyant sur le son plutôt que sur le regard pour porter une information autrement invisible à l’écran l’extension de permet de comprendre comment se charge une page.

Sur une page isolée, difficile d’en tirer quelque chose. Mais quand on commence à l’utiliser sur plusieurs sites, on entend très vite des différences.

Si quelqu’un a un équivalent Firefox, je serais ravi de l’ajouter à ce post.

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

L'UX n'est pas une checklist

Thu, 01 Jun 2023 00:00:00 +0200

Je discutais hier avec un client qui souhaite trouver un équivalent à Largest Contentful Paint sur Safari.

Du point de vue SEO, même si vous avez un tout petit peu de trafic sur Chrome, c’est ce trafic qui détermine la façon dont Google perçoit la performance web de la page. Mais si vous souhaitez mesurer et améliorer l’expérience de vos utilisateurs, alors je dirais : pourquoi se limiter au LCP ?

Le LCP a été créé en tant que mesure de substitution pour répondre à une question beaucoup plus intéressante : “Quand les utilisateurs voient-ils suffisamment d’éléments pour commencer à interagir avec la page ? Et ce “suffisamment” dépend de la nature et du contenu de la page, ainsi que des intentions de l’utilisateur.

Les LCP est rarement la meilleure mesure pour répondre à cette question. C’est juste la plus générique, calculable pour la plupart des pages, par Chromium et les navigateurs basés sur Chromium, donc parfaite pour une évaluation générique et très large dans l’optique du référencement de milliards de pages web.

[…]

Si j’essaie d’évaluer une page web en particulier, que je connais très bien, je ne mesurerais pas le LCP mais j’utiliserais plutôt des indicateurs personnalisés, qui répondront mieux aux défis de la page et qui m’aideront à comprendre son fonctionnement :

Le moment où l’autocomplétion de recherche est fonctionnelle et affichée (dans cet ordre, espérons-le)

Sur une liste de produits, le moment où les utilisateurs peuvent voir la première ligne de produits et commencer à interagir avec les filtres.

Le moment où le spinner de chargement apparaît et le moment où il disparaît pour afficher le contenu final (utile pour les “splash” d’accueil et les interstitiels du tunnel de conversion).

Dans une page composée de modules récupérant leur contenu à partir d’une API, les temps d’affichage spécifiques de chaque composant

etc.

C’est l’une des raisons pour lesquelles je pense que l’acquisition de Dareboost par Contentsquare a donné un nouveau souffle à ma carrière dans le domaine de la qualité Web. Plus encore qu’auparavant, je me suis impliqué dans les questions d’utilisabilité, dont la performance web n’est qu’une partie. Cela m’aide à garder à l’esprit que les indicateurs que nous mesurons en web performance ne sont souvent que les projections les plus génériques et les plus imparfaites de l’expérience technique d’une page web, et qu’ils ne sont pas nécessairement alignés sur les objectifs des clients et des organisations.

Hier soir, je suis tombé sur un article de Tim qui résume très élégamment la situation (traduction maison) :

Les organisations ont parfois tendance à considérer les performances comme une sorte de checklist, d’autant plus que les Core Web Vitals attirent plus que jamais l’attention sur les performances. On essaie de cocher les cases de ces indicateurs pour qu’ils passent au vert, puis on s’arrête là.

[…]

Mais tout cela est sans importance si ces mesures ne donnent pas une image exhaustive de la manière dont les utilisateurs interagissent avec nos sites.

La performance, comme l’accessibilité, n’est pas une question de conformité.

[…]

Il s’agit d’offrir une meilleure expérience aux personnes qui utilisent nos sites et nos applications afin qu’elles puissent atteindre leurs objectifs de manière efficace. Pour ce faire, nous devons être très attentifs à la nature de ces objectifs et à la manière dont ils sont atteints, et nous assurer que la manière dont nous mesurons les performances correspond à ces objectifs. ”Performance Is Not a Checklist”, Tim Kadlec

En tant que personne impliquée depuis des années dans Opquast, la checklist de référence de la Qualité Web, la critique du concept de checklist me touche. Mais elle est très juste. Les checklist ne sont que le début d’une approche de la qualité web, une ligne directrice. C’est un moyen de faire les choses correctement dès la première itération et d’ainsi réduire immédiatement l’exposition au risque de non-qualité. Mais ce n’est pas une réponse parfaite à l’UX, ça ne l’a jamais été et ça ne le sera jamais.

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Un nouveau besoin sur le Produit

Mon, 22 Aug 2022 00:00:00 +0200

Quand je remonte un besoin pouvant donner lieu à une amélioration du produit :

Entre ce que je pense,
Ce que je veux dire,
Ce que je crois dire,
Ce que je dis,
Ce que le département Produit a envie d’entendre,
Ce qu’il entend,
Ce qu’il comprend,
Comment il mène l’étape de découverte du besoin,
Ce que d’autres utilisateurs et utilisatrices veulent entendre,
Ce qu’ils entendent,
Ce qu’ils comprennent,
Ce qu’ils expriment,
Ce que les designers veulent entendre,
Ce qu’ils entendent,
Ce qu’ils comprennent,
Ce qu’ils expérimentent avec ces personnes,
L’UX qui en ressort,
La manière dont elle est communiqué à l’équipe technique,
Ce que l’équipe technique a envie d’entendre,
Ce qu’elle entend,
Ce qu’elle est en mesure d’implémenter en respectant les contraintes,
Les délais qu’elle communique,
La manière dont ils sont reçus par les équipes opérationnelles,
Ce que les équipes opérationalles voulaient entendre,
Ce qu’elles comprennent,
Ce qu’il a fallu expliquer aux commerciaux,
Ce que l’équipe commerciale a envie d’entendre,
Ce qu’elle comprennent,
La manière dont elle projettent de le vendre,
Ce que le ou la cliente a envie d’entendre,
Ce qu’elle entend,
Ce qu’elle comprend,
Ce qu’elle achète,
Et les usages auxquels elle sera formé par l’équipe Customer Success…

… il y a quand même une grand chance qu’on ait des difficultés à communiquer.

Mais essayons quand même !

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Un métier, pas qu'une passion

Mon, 14 Mar 2022 00:00:00 +0100

Développeurs et développeuses juniors : vos formations, courtes ou longues, ne vous rendent pas autonomes et prêt·es à accueillir n’importe quel défi. Et ça tombe bien, ce n’est pas le rôle de la formation initiale que de faire sortir des promotions entières de personnes immédiatement compétentes sur un projet exigeant.

Vous êtes peut-être passionné·e de code, mais cela ne suffit à en faire un métier. Si vous vous arrêtez là, c’est un hobby.

Pour que ça devienne un métier, il faut que cela s’inscrive dans un cadre :

un ensemble de compétences techniques ;
de la formation pour en acquérir de nouvelles ;
un cadre métier avec un contexte (légal, structurel, conjoncturel, géographique, etc.) ;
des engagements de cadre / coûts / délai à respecter ou, en tout cas, à définir ;
une organisation régie par une gouvernance à adopter (définissant qui décide de quoi, en informe qui, comment, qui est responsable en cas d’échec…) ;
souvent, un jargon mélangeant des composantes locales et plus consensuelles ;
des pratiques organisationnelles, parfois historiques, ayant un rôle social dans l’organisation ;
un portefeuille de projets orientés par une vision stratégique et des tactiques adaptées à chaque situation et inscrites dans des plans sur la durée (parfois pluriannuels).

Mais ce n’est pas tout.

À votre arrivée, vous ne serez pas seul·e. Vous évoluerez dans des équipes composées de professionnel·les déjà organisé·es qui gèrent des conflits et des équilibres de pouvoir au quotidien, avec des intérêts parfois divergents et de la gestion de conflits. Et… c’est normal. Parce que c’est comme ça dans toutes les organisations humaines.

L’école ne forme souvent qu’aux compétences techniques (et encore, souvent on en sort débutant·e avancé·e), en s’assurant de donner un bagage intellectuel théorique pour le reste, mais sans expérience. Et c’est déjà beaucoup.

Donc les compétences nécessaires pour naviguer avec aisance dans le reste s’acquièrent souvent avec le temps et la variété des expériences rencontrées. Elles s’acquièrent donc… lentement. Même deux ans d’alternance à mi-temps ne changent pas grand chose. Il s’agit souvent de deux ans pendant lesquels le ou la junior a travaillé temps partiel avec un jeu de responsabilité plus limité qu’un·e autre salarié·e. Ou alors l’étudiant·e a travaillé dans une petite start-up, a eu beaucoup de responsabilité mais aucun regard sur ce qu’il ou elle faisait. C’est la recette parfait pour un burn-out avant même son premier CDI…

Moralité : vous allez être perdu·es. Et c’est prévisible. Une organisation qui n’est pas prête à cela ne vous mérite pas. Mais vous dire ça, ça ne vous avance pas trop, hein ? Alors voici un vrai conseil : entourez-vous. Trouvez des mentor·es, dans ou à l’extérieur de l’entreprise, sur des sujets techniques ou non : si vous voulez vous épanouir, vous allez avoir besoin d’une cellule pour vous soutenir et vous faire grandir dans votre vie professionnelle.

Employeurs·euses : si vous souhaitez travailler avec des devs près·tes à l'emploi, qui ont déjà un savoir-faire, du savoir-être et savent le faire savoir, n'embauchez pas de juniors. Et quand vous écrivez sur LinkedIn qu'un ou une junior devrait absolument faire ceci ou cela, pensez aux juniors qui vous lisent, et qui dépriment parce qu'ils ont déjà l'impression que le marché les méprise. Prenez-en quelques-un·es en mentorat, vous comprendrez la violence de votre propos.

Bien. Ceci étant dit, pourquoi les employeurs et employeuses cherchent-ils souvent ce type de profils “prêt·e-à-l’emploi”, quitte à leur demander des compétences parfois très spécifiques (que même les seniors n’ont pas) ?

Parce que notre domaine a un problème structurel avec l’idée de supporter le coût de la formation continue, qui est pourtant énorme (nos besoins techniques évoluant fortement et très régulièrement). Dans le tissu légal (droit à la formation, OPCO), rien n’est adapté, du financement de la formation à l’offre proposée par les canaux d’État. Les catalogues ne contiennent que des formations désuètes et les quelques formations pérennes y sont supprimées.

On se retrouve donc à devoir former en interne, ce qui est long, et cher. Comme le marché est très tendu chez les développeurs et développeuses expérimenté·es, ce sont des juniors qui sont finalement recherchés, dans l’espoir que leurs écoles leurs aient donné les quelques compétences techniques très spécifique recherchées par l’entreprise. Comme ces profils n’existent pas, sont finalement embauché·es des juniors qui possèdent 30 à 50 % du périmètre de l’offre publiée.

Juniors : maintenant que vous savez ça, vous savez que si un poste vous plait, vous pouvez postuler. Peu importe que vous ayez toutes les compétences. Passez des entretiens, beaucoup. Soyez prêt·es à être rejeté·e : ça arrivera, et ça ne voudra rien dire sur vous. À la fin, vous aurez engendré de l'expérience, c'est tout ce qui compte.

Cela créé énormément de problèmes :

un sentiment d’imposture chez les salarié·es qui se traduit pas un manque de confiance dans la structure employeuse (et l’absence d’envie d’y faire carrière) ;
des inégalités de genre, parce que par construction sociale, les hommes sont plus enclins à postuler à des postes pour lesquels ils n’ont pas toutes les compétences, là où les femmes vont plus facilement se remettre en question et douter d’elles-mêmes ;
des juniors formé·es dans des entreprises qui ne voulaient pas d’elleux, qui finissent par partir dès que leur séniorité leur permet, ce qui ne fait que confirmer au marché qu’intégrer et former un·e junior n’est pas rentable ;
et qui va remplacer ce ou cette développeuse senior, à votre avis ? La boucle est bouclée.

Les solutions pour s’en sortir : assumer des fiches de postes adaptées. Proposer par exemple des postes alternatifs permettant d’entrer dans le dev et d’y gagner de l’expertise sans en faire à temps plein (exemple avec cette fiche pour un Junior Data Consultant, ce qui n’est pas très éloigné de ce par quoi j’ai commencé chez Microsoft).

Mais également, imaginer et proposer des Graduate Programs, qui sont des formations proposées par les entreprises (et financées en dehors de budgets de financement classiques) qui permettent aux recrues d’arriver au niveau de compétence désiré par l’entreprise.

Oui, pour une entreprise, ça coûte cher. Mais combien ça coûte, aujourd’hui, de recruter une personne dont le niveau de productivité n’est pas celui attendu et de devoir, à l’arrache, produire les éléments nécessaire à le ou la voir grandir tout en regardant cette personne partir à la fin ?

Il n’y a pas de secret, dans le recrutement comme ailleurs : si vous voulez un retour sur investissement, commencez par investir.

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Pourquoi mon script asynchrone bloque-t-il le rendu de ma page ?

Tue, 10 Aug 2021 00:00:00 +0200

Une très bonne manière de mesurer l’impact d’une ressource tierce, comme un script, est de mesurer la performance de la page avec et sans ce script. Nombreux sont mes clients qui découvrent alors que leurs scripts, qu’ils ont pourtant chargé avec les attributs async et defer, sont bloquants pour le rendu.

Et c’est normal. D’après la spécification HTML (source), un script async defer est, en fait, un script async partout où async est supporté, c’est-à-dire partout. Un script async est téléchargé avec une priorité basse, voire la plus basse. En revanche, une fois qu’il est disponible, il est exécuté immédiatement, interrompant les tâches en cours (y compris les tâches de rendu).

Si vous cherchez d’autres manières de télécharger des scripts, en voici au moins sept.

Et pour tout comprendre des attributs permettant de différer ou rendre asynchrone un script, c’est par ici.

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Les Core Web Vitals partout

Mon, 08 Feb 2021 00:00:00 +0100

Comme prévu, de plus en plus de structures basent leurs efforts de Web Performance sur les Signaux Web Essentiels, ou Core Web Vitals. En France, par exemple, la méthodologie du classement JDN / Fasterize évolue pour adopter les CWV à la place d’analyses et d’indicateurs synthétiques.

Ce changement de paradigme va être un séisme pour beaucoup d’acteurs, mais je suis content de voir que mes client·es ont tendance à bien tirer leur épingle du jeu.

Pour les autres, prenez le recul nécessaire. Un mauvais classement n’implique pas nécessairement une mauvaise expérience pour vos utilisateur·ices. Je sais que ce n’est pas évident à comprendre, donc voici quelques éléments d’explications.

D’une part, les CWV ne sont pas l’alpha et l’omega de l’UX.

Prenez le First Input Delay (FID), par exemple. D’après les données HTTP Archive sur plusieurs millions de pages d’accueil, il est globalement bon partout. Bien sûr, si vous proposez une web application qui repose sur beaucoup sur JavaScript, alors il est possible qu’il le soit moins. Mais pour la plupart des sites de ce classement, ce n’est pas le cas.

Je ne m’attarderai pas sur le Cumulative Layout Shift (CLS), car j’ai déjà dédié un article à cet indicateur et d’autres, comme Myriam, en parlent aussi très bien. Le CLS est biaisé par tellement de choses que Google imagine déjà son remplaçant.

Enfin, le Largest Contentful Paint (LCP) s’intéresse au contenu le plus important visuellement, sauf que ce contenu peut parfaitement être décoratif. On se retrouve donc avec un indicateur qui dévalorise des expériences d’utilisation qui ne sont pas dégradées.

D’autre part, le Chrome UX Report, d’où sont tirées les valeurs remontées la Search Console ou le classement JDN, ne délivre qu’une vision partielle des usages du Web.

Sa base de collecte est limitée aux utilisateurs et utilisatrices authentifiées de Chrome, sans passphrase, qui ont optée pour la synchronisation d’historique et l’envoi de rapports d’usages statistiques. Nous n’avons à ce jour pas d’information sur les biais de sélection que cela représente, mais on peut déjà souligner qu’aucun usage sur un autre navigateur n’est pris en compte (ce qui exclut d’emblée toustes les utilisateur·ices d’iPhone, par exemple).

On se retrouve donc régulièrement avec des origines (domaines) absentes de la base de données Chrome UX Report parce qu’elles n’emmagasinent pas assez de visites. C’est le cas de plusieurs de mes client·es qui ont disparu du classement JDN parce que leur audience utilise plutôt des produits Apple.

Sachez donc garder du recul par rapport à ce référentiel qui n’est qu’une projection imparfaite et partielle de la performance. Elle n’est pas mauvaise en soi, toutes les projections sont imparfaites. Il faut juste le garder en tête.

Si vous souhaitez vraiment améliorer votre vision de la performance réelle, vous aurez besoin d’investir dans une solution de Real User Monitoring ou, à minima, dans un mécanisme de témoignages issus de vos utilisateurs et utilisatrices.

Sachez prendre du recul sur les impacts, également. J’aimerais pouvoir dire autre chose et “vendre” de la performance web à tours de bras, mais en réalité, je suis convaincu que l’impact de la Page Experience dans la mise à jour du ranking en mai sera réduit. Cela ne veut pas dire que la mise-à-jour de mai ne changera rien, mais peut-être qu’elle correspond tout simplement à un réajustement nécessaire, finalement assez éloigné de la web performance.

Google fait d’ailleurs évoluer sa communication avec le temps, puisqu’on est passé d’une réthorique de la prise en compte, interprété librement et sans contradiction par le monde du SEO technique comme un risque de pénalité, à une réthorique du boost de classement, mais uniquement quand les trois indicateurs sont bons, et uniquement dans le classement mobile…

En réalité, c’est une prophétie auto-réalisatrice qui se joue dans le monde du SEO technique. Les équipes qui sont en train de faire des optimisations interpréteront une absence de pénalité ou un meilleur classement comme étant un gain lié à leur travail alors qu’en réalité, ces équipes travaillent tout simplement à l’amélioration de l’expérience d’utilisation, ce qui va mécaniquement entrainer de meilleurs conversions.

Réciproquement, celles qui ne verront pas de gain remetteront en cause leur travail, principalement sur les Landing Pages, alors qu’il est peut-être très bon et que le problème se situe plus loin, dans le tunnel, ce qui est très difficile à savoir sans une approche plus précise de la donnée.

Parce qu’il est peut-être utile de le rappeler mais la performance web, ce n’est que de l’UX. C’est travailler techniquement à assurer une navigation de qualité, qui permet aux utilisateurs et utilisatrices d’atteindre leurs objectifs sur le site.

Si vous commencez à faire de la web performance parce que qu’un tiers vous “menace” (ici, Google), vous risquez de vous y mettre vite, et mal. Profitez plutôt du momentum actuel pour investir dans une équipe qualité transverse (pas que webperf, donc), qui se chargera de porter le sujet au long cours, sur toutes les fonctionnalités et de manière pérenne.

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Les formations "courtes"

Tue, 12 Jan 2021 00:00:00 +0100

Je vois régulièrement des critiques à l’emporte-pièce visant les personnes qui suivent des formations courtes en informatique¹, et cela m’énerve. Je suis Ingénieur ESIEE Paris, filière informatique, promotion 2007. Si je mets bout-à-bout l’ensemble du temps passé à coder durant ma formation, j’arrive à quelques mois, tout-au-plus.

La formation d’ingénieur m’a appris énormément de choses et j’ai eu souvent conscience de la force que cette diversité procure sur le marché du travail. Mais jamais je ne me permettrais de prendre de haut les personnes en formation initiale ou, encore plus souvent, en reconversion, qui elles aussi savent plein d’autres choses que le code et ont fait une formation de 3, 6 ou 9 mois.

Bien sûr, ces formations sont incomplètes. Mais n’étais-je pas moi-même sacrément incompétent à mes débuts ? Bien sûr que si. Et puis j’ai gagné du savoir-faire, du savoir être, une capacité à communiquer ancrée dans mon expérience et mes compétences. Et c’est normal.

La qualité de ma formation initiale m’a permis de m’en sortir rapidement, sans trop de douleur, et à un moment de ma vie où je n’avais pas trop de soucis. Ce n’est pas une raison pour me sentir supérieur : c’est plutôt un immense privilège.

J’admire les gens qui savent faire un bilan sur leur carrière, pivoter vers une nouvelle, s’y lancer alors qu’ils ont sur le dos un prêt, des enfants, qu’ils doivent faire attention à leur couple, qu’ils ont des investissements associatifs ou s’occupent de proches plus âgés, le tout avec bien moins de naïveté que moi quand j’ai commencé. Ce sont de vrais héros et héroïnes.

Est-ce qu’on peut s’interroger sur la manière dont la filière forme (en reconversion ou non) ? Oui, complètement. J’ai moi-même formé et je sais comment sont fait les programmes dans beaucoup d’écoles : pour nourrir les biais des parents des étudiants.

Est-ce que les formations courtes font mieux ? Non. Elles aussi vendent un time-to-market qui n’est pas réaliste et des salaires de sortie qui sont souvent de belles promesses. Mais ça ne veut pas dire que les gens ne sortent pas aussi compétents que d’autres juniors.

Est-ce que c’est un problème que des gens soient juniors ? Je ne crois pas. Je pense que beaucoup de gens peuvent venir au code tardivement, ou superficiellement, et que ce n’est pas grave. Ils ne volent le job de personne. Ils décrochent un job avec leurs compétences.

Est-ce que c’est ce dont les entreprises veulent ? Peut-être pas. Et c’est du coup très dur pour ces nouvelles personnes sur le marché. Beaucoup sont paupérisés dans des status qui leur font porter le risque de leur emploi, à des taux journaliers dérisoires.

Parenthèse : vous connaissez ma femme ? Allez lire son blog ou voir sa conférence sur le sujet.

Est-ce que les entreprises n’ont pas un rôle à jouer dans la situation ? Certainement. Peu sont enclines à l’embauche de ses profils, parce qu’elles ne veulent pas porter la formation de ces salarié·es ?

Elles en viennent à réclamer de la formation sur le temps libre du personnel, alors même qu’elles ont l’obligation légale de maintenir leurs salarié·es au niveau pour leurs postes. Mais bon, à ce niveau, c’est une culture de toute l’industrie du développement où la perception de la montée en compétence est à revoir. Nous sommes souvent traités comme des client·es de nos propres entreprises, responsables de notre formation avec le levier d’aller voir ailleurs si on n’est pas content·e.

Cette dynamique de turn-over fait que les entreprises embauchent des juniors en continu pour leur demande d’exécuter des tâches que des personnes désormais seniors faisaient, mais qu’elles ne font plus puisqu’elles sont parties chercher de la reconnaissance ailleurs.

Et comme ces entreprises sont en besoin de remplacement à profil identique, elles vont naturellement embaucher des gens qui ressemblent à ceux qu’elles avaient avant en laissant peu de place à des personnes en reconversion (ou à des femmes s’il y a déjà peu de femmes en place).

Rien de tout ça n’est de la faute des formations, il faudrait en prendre conscience. Les formations ont leur tort (sérieux, quand je vois des formations web qui ne forment pas aux bases de HTML, je pleure) mais cette problématique d’adéquation des profils formés aux besoins des entreprises est une dynamique systémique de marché.

Je vous renvoie vers l’excellent article de Medhi sur la formation au développement. ↩

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Tu devrais faire de la WebPerf

Fri, 25 Dec 2020 00:00:00 +0100

Cher confrère, chère consœur, tu devrais t’intéresser à la Performance Web. C’est un sujet qui se trouve au cœur du web, qui a besoin de spécialistes, et est en plein essor. Je sais que tu ne me crois pas, ou que tu penses que ce n’est pas simple et tu as bien raison. Alors laisse-moi t’expliquer où on en est et pourquoi on a besoin de toi.

Note : cet article a d'abord été publié sur 24 Jours de Web.

De la Performance Web, ou webperf, j’en fais depuis plus de dix ans. J’en ai parlé publiquement la première fois en 2012 ¹. Je disais qu’il fallait aborder le sujet en quatre temps : prendre conscience de l’enjeu, puis apprendre à optimiser, faire un suivi des performances et enfin, en parler en interne pour éviter de futures dégradations.

Huit ans plus tard, je pense toujours que c’est la meilleure manière d’aborder le sujet. Mais autour de moi, ça ne parle pas forcément beaucoup de performance web. Pour toutes celles et ceux qui n’ont pas forcément suivi où nous en sommes, faisons un tour d’horizon du sujet.

Le sujet est dense, mais mon but n’est pas de t’étouffer sous les informations. Si tu veux aller plus loin, tu trouveras plein de notes de bas de page menant à des lectures additionnelles.

Un point sur la situation

On va commencer par un peu de définitions.

La webperf, c’est tout ce que tu vas pouvoir faire pour que ton site soit ressenti comme plus performant par une personne l’utilisant. Ça part de l’expérience d’utilisation de ton site ou de ta web app (y compris les animations), puis on redescend dans les couches, avec du code HTML, CSS et JS, de la configuration de serveurs et enfin une analyse des infrastructures et services tiers que tu t’autorises à utiliser, et de leur configuration.

Attention, dans la mesure où un site performant consomme moins de ressources, la performance web partage 90 % de son ADN avec l’éco-conception. Mais certaines bonnes pratiques de performance web, comme l’utilisation de CDN, ne collent pas aux attentes écologiques ².

On a généralement l’intuition qu’une application plus rapide est plus agréable. Avec la webperf, on a des chiffres qui le confirment. Beaucoup de marques ont commandité des missions d’optimisation et témoignent des gains obtenus, notamment sur la conversion ³. C’est un point important parce que ça veut dire que la webperf est un domaine de la Qualité Web dont le retour sur investissement est démontrable. Cela facilite les investissements.

Quand il y a des rémunérations à la clé, il est plus facile d’attirer des compétences. Il y a une bonne dynamique dans la communauté, qui s’alimente d’articles sur différentes expertises au sein de la web performance. Ça permet à l’ensemble de la communauté de progresser.

La « Front-End Performance Checklist » de Vitaly Friedman est une des ressources les plus complètes. C’est un généreux dossier remis à jour chaque année sur le Smashing Magazine. Le problème, c’est qu’on ne peut pas envoyer n’importe qui vers ce type de dossier : 53 pages se traduisant par une checklist opérationnelle de 13 pages ⁴, c’est pas à la portée de tout le monde : ça fait quand même une sacrée marche à monter.

Pour aller plus vite au cœur du sujet, on peut utiliser à la place un des nombreux outils et services d’analyse disponibles dans les navigateurs ou en ligne. Ces outils, qu’on appelle « synthétiques », sont super pratiques : ils analysent le chargement d’une page et produisent instantanément un rapport d’audit contextualisé permettant d’attaquer les points essentiels ⁵. On peut souvent leur demander de faire des tests avec des contraintes sur-mesure. Ça permet de faire des hypothèses comme « je crois que c’est ce fichier JS qui ralentit l’affichage », puis de tester en bloquant ce fichier et voir si l’affichage se produit vraiment plus vite. Ça permet aussi de mesurer la performance d’un site face à ses concurrents.

Mais la force de ces services est aussi leur faiblesse : ils ne mesurent que ce qu’on leur demande de mesurer. Ils ne peuvent pas dire si les sites sont rapides chez les gens. Si tu as besoin d’obtenir ces infos, il faudra te tourner vers des outils de télémétrie (des analytics). La télémétrie que tu utilises d’habitude peut suffire ⁶, mais pour aller plus loin dans l’évaluation de la frustration des utilisatrices, il faudra te tourner vers des solutions plus élaborées ⁷. En revanche, un peu d’implémentation sera nécessaire.

À l’inverse, si ton site web est public et reçoit beaucoup de visites, tu peux utiliser des données de terrain collectées par d’autres. Ces jeux de données sont pratiques, parce qu’ils sont accessibles sans rien installer sur les sites (et du coup, comme avec les outils synthétiques, tu peux faire des comparaisons entre sites). Les données ne sont pas forcément difficiles à récupérer, mais peuvent être incomplètes (par exemple, ne concerner que Chrome ⁸).

Dans l’absolu, dès que tu utilises des données de terrain, prends du recul. L’interprétation des résultats est très compliquée parce que beaucoup de facteurs peuvent affecter la performance mesurée ⁹. Si tu as l’intuition de quelque chose, n’hésite pas à valider cette hypothèse en recoupant avec d’autres données, ou via des tests synthétiques.

Pour résumer

Aujourd’hui, les connaissances techniques sur la performance web sont largement consensuelles et testables via des outils d’analyse automatisés. Des données de terrains génériques sont facilement accessibles et permettent d’avoir un retour sur les optimisations apportées, dont le coût n’a pas de mal à être financé et le gain à être mesuré.

Et pourtant… si on regarde les données de terrain, on peut voir que la performance des sites ne s’améliore pas franchement.

Évolution de l’indicateur First Contentful Paint de 2017 à 2020. Source : HttpArchive

Du coup, le paysage ne doit pas être si rose que ça. Faisons un petit tour des choses qui sont encore difficiles.

Le chemin qu’il nous reste à parcourir

Comme beaucoup de sujets de la Qualité Web, la performance web est l’affaire de toutes et tous. Pour améliorer les performances d’un site, il faut non seulement comprendre d’où viennent les problèmes mais également être capable de déterminer qui sont les personnes à contacter pour les résoudre. Comme la webperf concerne tous les corps de métier du Web, tu vas vite te retrouver à devoir parler à des gens très différents. Même sur des problèmes qui ont l’air simple.

Prenons l’exemple de l’optimisation des images. Dis comme ça, ça a l’air simple et beaucoup de gens auront l’impression de comprendre. Mais pour aborder le sujet dans sa globalité, il faut :

former les personnes à choisir le meilleur format en fonction de l’image ;
encadrer la contribution (pour éviter les images trop grosses) et déclencher l’optimisation et la génération de plusieurs variantes d’images en fonction du contexte et de la direction artistique ;
modifier le code HTML permettant d’insérer les images et éventuellement mettre en place un proxy d’images avec une négociation de contenu (interne ou externe), afin que chaque personne reçoive une image adaptée à son contexte

Et je n’ai même pas encore parlé de lazy loading.

Tu l’auras compris, quand tu commences à parler de performance web en entreprise, le plus dur n’est pas forcément la technique. C’est aussi de faire parler ensemble différents métiers afin d’avoir une vue d’ensemble de la situation et des actions à mener.

D’autant que c’est parfois difficile de parler de la même chose. Il y a vraiment beaucoup d’indicateurs différents et comme si ça ne suffisait pas, de nouveaux indicateurs apparaissent régulièrement. Il y a certains indicateurs qui sont vraiment pérennes, comme le Speed Index ¹⁰, un indicateur de référence depuis près de 10 ans. D’autres sont mal nommés, ou ne permettent pas de prendre des décisions, ou informent sur quelque chose qui n’est pas forcément primordial. Il faut donc sans cesse s’interroger sur les mesures, mais aussi sur la manière dont on mesure.

Mais le top du top, c’est quand on utilise ses propres indicateurs, des jalons temporels sur-mesure. Côté serveur, on appelle ça des Server Timings ¹¹. Côté navigateur, on parle de User Timings ¹². Contrairement aux autres indicateurs, ils correspondent à ce que ton équipe choisit elle-même de surveiller. On peut les retrouver quand on analyse la page dans les outils de développement de son navigateur et ils sont collectables par tous les outils d’analyse. Pourquoi s’en priver ?

Quand tu vas vouloir optimiser la performance d’un site, tu vas parfois te heurter aux librairies utilisées par d’autres pour répondre à des besoins métiers. Ces librairies répondent souvent à une liste d’objectifs mais n’ont pas en vue la webperf. Du coup les gens qui les utilisent n’ont parfois jamais entendu parler de performance. Et rien n’est prévu, dans ces solutions, pour les optimiser.

Concrètement, ça veut souvent dire qu’optimiser va être difficile, techniquement ou parce que les gens avec qui tu vas parler ne comprennent pas ce besoin. Quand l’optimisation n’est vraiment pas possible, n’oublie pas de l’écrire dans un référentiel de la dette technique, en espérant que celle-ci sera résolue à la prochaine refonte.

Pourquoi on a besoin de toi

Tu l’auras compris, le sujet de la Performance Web, comme tous les sujets de la Qualité Web, est un sujet technique. Mais cette technique, en fait, elle s’apprend assez bien.

Je ne vais pas te mentir : monter en compétence, c’est long. Mais les compétences acquises ne dépendent d’aucun framework, d’aucune solution du marché, d’aucune tendance. Il s’agit de comprendre comment fonctionnent les standards du web : HTTP, HTML, JS et CSS. On peut difficilement faire plus réutilisable et crois-moi : ça vaut le coup.

Tu verras que quel que soit ton rôle dans la chaîne de production du web, tu peux acquérir ces compétences et les mettre au service d’une meilleure performance des sites web.

Bien sûr, il nous faut des gens prêts à optimiser des sites web. Il y a une vraie demande à ce sujet. Mais c’est loin d’être la seule manière de participer. C’est même la fin de la chaîne.

Pour déjà comprendre le problème, on a besoin de Data Analysts capables d’analyser les données d’utilisation et d’affiner les mesures, pour mieux mettre en balance les investissements et les gains. Savoir qu’un sujet est pertinent parce que d’autres le disent, ce n’est pas pareil que de pouvoir ajuster son investissement au fil de ses besoins et de ses gains à soi.

Il faut que le sujet de la Performance infuse dans le développement des librairies de tous types. Qu’il s’agisse de Back-End ou de Front-End, il faut que ces projets intègrent la performance comme un besoin fondamental, de la même manière que la sécurité ou l’accessibilité.

On a besoin de designers qui pensent à la manière dont leurs interfaces sont progressivement affichées et priorisent les éléments les plus attendus par les utilisateurs et utilisatrices afin d’améliorer leur ressenti ¹³.

Tes compétences sont plutôt liées au Back-End ? Parfait. Nous avons aussi besoin de gens comme toi pour optimiser l’exécution du code, configurer des systèmes de cache serveur, ou aider au développement de serveurs intermédiaires de performance qui peuvent aider à optimiser un site rapidement en attendant que des corrections de fond soient réalisées ¹⁴.

Enfin, il nous faut aussi des personnes pour assurer la médiation de tous ces métiers, nourrir et encadrer le dialogue, permettre les conditions du succès et notamment la formation à un socle commun de compétence (en commençant par Opquast ¹⁵, par exemple).

Pour toutes ces raisons, tu devrais faire de la Performance Web.

Et, si ça se trouve, tu en fais déjà.

Les illustrations présentes dans cet article sont issues du projet Undraw, créé par Katerina Limpitsoun. Vous pouvez les utiliser dans n’importe quel projet, qu’il soit commercial ou personnel, sans attribution ni frais.

Merci à Carine Sobisiak, Olivier Rundstadler et Nicolas Goutay pour leurs relectures et leurs suggestions.

« Mettre en place une stratégie de performance web » lors de Sud Web 2012. ↩
Romuald Priol en parle très bien dans l’article « Les impacts du numérique : bonnes pratiques pour un Web plus écologique ». ↩
WPOStats.com recense des études de cas et expériences démontrant l’impact de l’optimisation des performances web sur l’expérience d’utilisation et le succès commercial. ↩
« Front-End Performance Checklist 2020: the PDF », 166 Ko. ↩
Dareboost, sur lequel je travaille, est un de ces outils et j’en suis très fier, mais c’est loin d’être le seul. Calibre, Speedcurve, GTMetrix, Pingdom, entre autres, proposent également des rapports instantanés et du suivi. Les équipes de développement peuvent également utiliser Lighthouse ou WebHint sur leurs postes. ↩
Exemple avec « Analyser la vitesse de chargement d’un site web via Google Analytics » par Anthony Barré mais personnellement, je collecte avec Matomo. ↩
Voir à ce sujet « User Experience & Performance: Metrics that Matter », par Philip Tellis. ↩
Il s’agit ici du Chrome User Experience Report, ou CrUX pour les intimes. ↩
« Comment interpréter les mesures de performance réelles (RUM metrics) », par Gilles Dubuc. ↩
« Speed Index : tout savoir sur cet indicateur majeur de la performance web », par Damien Jubeau. ↩
« MDN Server-Timing Documentation ». ↩
« Custom Timing : attendez la prochaine frame quand vous utilisez la User Timing API ». ↩
« Mind over Matter: Optimize Performance Without Code », par Stéphanie Walter. ↩
La solution française de référence, c’est Fasterize. ↩
Opquast, la certification des du Web. ↩

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Cumulative Layout Shift, l’indicateur de stabilité de la mise en page

Tue, 15 Sep 2020 00:00:00 +0200

Avez-vous déjà commencé à lire un article d’actualité passionnant, puis perdu votre ligne parce que tout le texte s’est déplacé vers le bas ? Cela m’arrive souvent, surtout à cause des publicités qui se chargent au-dessus du contenu.
Ce type d’expérience utilisateur peut être frustrant, mais jusqu’à présent, nous avons eu du mal à la mesurer quantitativement. Le Cumulative Layout Shift relève ce défi.

Note : cet article a d'abord été publié sur le blog de Dareboost (abandonné).

Lorsque vous voyez une page web, votre cerveau décompose l’information visuelle en éléments. L’agencement de la page vous donne des informations sur leurs relations les uns par rapport aux autres. C’est comme ça que vous détectez le contenu pertinent. Si ce contenu se déplace tout seul, ou si un autre élément est injecté dans la page et déplace les autres, alors vous risquez de le perdre de vue.

Chargement de la page d’accueil de LeMonde.fr. Les contenus insérés et en mouvement sont identifiés par des zones bleu clair. Le contenu d’environ 2/3 de l’écran se déplace pendant le chargement de la page.

Pire encore, vous pouvez penser que la mise en page est stable et essayer d’interagir avec la page. Par exemple en cliquant sur un bouton (image de gauche). Si un autre contenu apparaît juste avant le clic et pousse l’autre contenu vers le bas (image de droite), vous risquez d’interagir avec le mauvais élément.

L’utilisateur est sur le point de tapoter sur l’image d’un fauteuil, dans une liste de produits. Soudainement, un texte avec un bouton est inséré en haut de page, déplaçant tout le contenu vers le bas. L’utilisateur clique involontairement sur l’image d’un sac à dos.

Plan

Dans cet article, nous introduirons l’API Layout Instability et verrons comment elle est utilisée pour calculer le Cumulative Layout Shift (CLS). Nous verrons comment visualiser le CLS dans Chrome et comment optimiser son site pour avoir un bon CLS. Enfin, nous aborderons les étranges caractéristiques du CLS et nous conclurons.

Une API dédiée dans le navigateur…

Depuis plusieurs années, les équipes Front tentent d’identifier les éléments qui se déplacent pendant le chargement et l’utilisation d’une page. Il y a dix ans, il fallait un moteur de rendu sur-mesure pour afficher tous les repaints (dans l’exemple ci-dessous, Gecko, le moteur de rendu de Firefox).

ATTENTION

Cette vidéo contient beaucoup de clignotements. Ne la regardez pas si vous êtes photosensible ou si vous souffrez de troubles vestibulaires.

Pour déterminer le moment où une page est chargée/stable, vous pouviez utiliser l’événement onload, mais c’est loin d’être parfait. L’API Layout Instability de Chrome répond à cette limite. L’idée ici est de s’intéresser à d’autres signaux. Plus particulièrement, à la stabilité de la mise en page, ou “l’absence de sursauts d’interface”. Comme indiqué dans le résumé de l’API, elle “offre aux auteurs de pages web un aperçu de la stabilité de leurs pages, à partir des mouvements des éléments de la page”. Pour ce faire, l’API surveille les nœuds du DOM qui sont visibles dans le viewport. Si la représentation visuelle d’un nœud se décale, entre deux frames, de 3 pixels ou plus dans le sens horizontal ou vertical, l’API enregistre un layout-shif (un décalage) et lui attribue un score.

… utilisé pour pénaliser les saccades

Revenons à notre exemple :

Comment l’API Layout Instability attribue-t-elle un score à ce décalage ? Pour calculer le score de décalage (layout shift score), l’algorithme évalue d’abord la zone affectée par le décalage (impact fraction), et la multiplie par la longueur du décalage (distance fraction).

La zone affectée par le layout shift, ou impact fraction (fraction d’impact), est la zone totale occupée par le nœud qui se déplace, de sa première position à sa position finale. Ici, 78 % + 32 % = 110 %. Comme vous pouvez le voir, la fraction d’impact peut être supérieure à 100 % (la taille du viewport).

La longueur du décalage, ou distance fraction, est mesurée en pourcentage du plus grand côté du viewport. Dans cet exemple, nous allons donc considérer la hauteur. L’élément existant se déplace d’une hauteur équivalente à 34 % de la hauteur du viewport.

Pour ce Layout Shift en particulier, le score de Layout Shift est donc :

score de Layout Shift = 110 % (impact fraction) × 34 % (distance fraction) = 0,374

Le Cumulative Layout Shift (CLS) est la somme des scores de (presque) tous les Layout Shifts.

La fenêtre de 500 millisecondes

Pour éviter que les sites web ne soient pénalisés pour les transitions ou les animations qui résultent de l’interaction de l’utilisateur avec l’interface, l’algorithme du CLS ignore les Layout Shifts pendant 500 ms après chaque interaction active de l’utilisateur avec le document (par exemple, un clic, une frappe de touche ou un tapotement), ou après tout événement qui modifie directement la taille du viewport.

D’après Google, pour offrir une bonne expérience, les sites devraient s’efforcer d’avoir un CLS inférieur à 0,1 pour la plupart (75 %) des utilisateurs. C’est une mauvaise nouvelle pour les développeurs de l’exemple ci-dessus !

N’oubliez pas que la fraction d’impact et la fraction de distance sont dépendantes des caractéristiques du viewport. Une modification des dimensions ou de l’orientation du viewport peuvent modifier la mise en page (en provoquant une réadaptation du contenu à l’espace disponible). Si cela se produit, pour un même Layout Shift, la fraction d’impact et la fraction de distance, et donc le Cumulative Layout Shift, n’auront plus les mêmes valeurs.

Comment visualiser les Layout Shifts dans Chrome

Les Layout Shifts peuvent être affichés dans Chrome :

Dans les DevTools (les outils de développement de Chrome), ouvrez le menu de commande en appuyant sur Control + Shift + P ou Command + Shift + P (macOS)
Commencez à taper “Rendering”
Exécutez la commande “Show Rendering” qui vous est proposée
Activez la case Layout Shift Regions. Quand vous interagissez avec la page, les Layout Shifts apparaissent désormais en bleu.

Attention

Cette fonctionnalité peut provoquer des clignotements. Si vous êtes photosensible ou si vous souffrez de troubles vestibulaires, faites attention.

Depuis Chrome 84, vous pouvez également visualiser les Layout Shifts et obtenir des informations sur leur attribution (allant même jusqu’à la liste des éléments qui ont été décalés) dans l’onglet Performance, sur la ligne “Experience”.

Sur une ligne de temps, une succession d’écrans aide à comprendre la chronologie visuelle. En dessous, plusieurs lignes exposent ce qui s’est passé au même moment, y compris la ligne "Experience", qui contient des repères rouges, un pour chaque Layout Shift. Tout en bas, une description donne des informations plus précises sur le Layout Shift sélectionné.

Comment optimiser votre Cumulative Layout Shift

Une page accumule des Layout Shifts tout au long de son utilisation. À chaque fois que de nouveaux éléments sont insérés visuellement sans que l’espace nécessaire à leur affichage n’ait été réservé en amont par le navigateur. Le plus souvent, il s’agira d’images, mais vous devez également faire attention aux publicités, aux polices de caractères web, aux contenus intégrés et aux contenus injectés suite à une interaction qui génèrent des temps d’attente de plus de 500 ms.

Images

Quand il reçoit le code HTML de votre page, le navigateur ne sait pas grand choses sur les images qui y sont utilisées. S’il ne dispose que de l’URL de l’image, le navigateur ne peut pas connaître sa taille. Il ne peut donc pas allouer l’espace nécessaire à l’affichage de cette image. Cette situation est devenue encore plus complexe depuis l’avènement du Responsive Web Design puisque désormais, la taille d’affichage d’une image dépend souvent du contexte.

Pour donner le plus d’informations possible au navigateur (afin qu’il puisse faire son travail au mieux) définissez toujours les valeurs des attributs width et height sur vos éléments <img> (exprimées en pixels). Même si ce ne sont pas les dimensions réelles de l’affichage (qui peuvent dépendre des règles de style), le navigateur les utilisera pour déduire le rapport largeur / hauteur (appelé aspect-ratio) de l’image, et ainsi calculer la hauteur à réserver en fonction de la largeur d’affichage définie par le CSS.

Le saviez-vous ?

Edge, Firefox et Chrome ont une représentation interne du aspect-ratio des images sur lesquelles les attributs width et height sont définis. Une expérience est en cours sur Chrome pour ouvrir la fonctionnalité aux équipes de développement web.

.el {
    aspect-ratio: 16 / 9;
}
/* internal rule for img, using the --webkit prefix (in Chrome)
img[width][height] {
  --webkit-aspect-ratio: attr(width) / attr(height);
}*/

Pour en savoir plus sur aspect-ratio lisez cet article de Chris Coyier sur CSS Tricks

Et bien sûr, n’oubliez pas de servir la bonne taille de fichier en fonction du contexte. Utilisez srcset pour aider le navigateur à sélectionner la meilleure image de votre jeu d’images avec le même rapport hauteur/largeur (suivant la largeur du viewport). Utilisez picture et source pour gérer différents rapports hauteur/largeur ou différents formats d’image en fonction du contexte et des types supportés par le navigateur.

Publicités, intégrations, iframes et contenus créés dynamiquement

Comme pour les images, le navigateur doit allouer l’espace nécessaire pour afficher le contenu final. Mais vous ne pouvez pas donner beaucoup d’informations au navigateur, car souvent, vous ne disposez vous-même que de peu d’informations sur le futur contenu. Dans ce qui suit, je ne parlerai que du cas des publicités, car elles constituent un problème récurrent. Mais l’approche est la même pour les autres types de contenus injectés.

Dans la suite, nous examinerons l’impact des injections de contenu sur le contenu d’une page. Notez que le contenu des iframes n’est pas concerné : si une iframe produit de Layout Shifts, ceux-ci n’auront pas d’impact sur la page principale.

Le plus souvent, l’espace publicitaire est attribué à un service d’enchères qui injecte un conteneur publicitaire dans un nœud dédié du DOM. Ensuite, cet espace est “loué” au plus offrant, attribué à une régie qui injecte enfin une publicité. L’espace peut être redimensionné plusieurs fois avant que la publicité finale ne soit affichée, et dans le cas de publicités temporisées, des injections supplémentaires peuvent se produire plusieurs fois pendant la session de l’utilisateur.

Comment éviter que la mise en page soit modifiée ?

Définissez explicitement l’espace que vous souhaitez allouer au conteneur publicitaire. Prévoyez un habillage pour prendre en compte le cas dans lequel l’annonce serait plus petite que l’espace pré-réservé. Si l’annonce est plus grande que l’espace réservé, il faudra accepter qu’une partie de l’annonce ne soit pas affichée.

Il arrive que l’espace reste vide, si aucune publicité n’a été trouvée. Prévoyez des visuels correspondant à la taille de l’espace publicitaire afin de ne pas avoir à réduire l’espace publicitaire et à provoquer un changement de disposition. Si votre régie vous donne les moyens (par le biais d’un callback JS, par exemple) d’injecter du contenu utile en cas d’absence de publicité, bien sûr, n’hésitez pas.

Une autre façon de résoudre ce problème consiste à positionner les publicités dans l’espace négatif laissé par le contenu du site, en dehors du flux de pages. Si votre publicité a une position figée dans le gabarit de page, et que cette position n’interfère pas avec l’agencement du reste du contenu, alors l’insertion de la publicité ne provoque aucun décalage.

Utilisation de l’espace négatif pour positionner les annonces.

Enfin, vous pouvez décider de déplacer vos espaces publicitaires plus bas sur vos pages. Cela évitera que la fraction d’impact du Layout Shift ne soit trop importante, mais cela réduira probablement vos revenus.

Police d’écriture web

Lorsqu’un navigateur doit afficher du texte avec une police d’écriture web, il détermine si la police est nécessaire et disponible (via le système d’exploitation ou dans le cache navigateur). Si la police est nécessaire mais non disponible, le navigateur la récupère. Pendant la phase de récupération, le navigateur suit les instructions font-display (ou leur absence) pour déterminer s’il doit afficher le texte avec une police de substitution disponible ou allouer l’espace avec du texte invisible. Une fois la police chargée, ou si le temps d’attente est trop long, le navigateur procède alors au rendu final.

En d’autres termes, chaque fois que le navigateur doit récupérer une police web, il attribue à la zone un texte avec une police par défaut, visible ou non. Et lorsque la police devient disponible, le navigateur effectue le rendu final de la zone de texte.

Problème : la police temporaire utilisée pour occuper l’espace n’a pas nécessairement pas nécessairement les mêmes caractéristiques que la police finale. Les lignes de base, la taille des points typographiques et les kernings peuvent être différents et le texte final peut apparaître plus court ou plus long que le texte temporaire, ce qui peut déplacer les contenus qui suivent dans le flux de page, et entraîner des Layout Shifts.

Chaque fois que j’ai besoin de me rappeler comment fonctionne la gestion de l’affichage des polices, je retourne voir le the font-display playground, de Monica Dinculescu.

Pour éviter ces Layout Shifts, vous pouvez accélérer le chargement des polices. ou choisir des polices web ayant des caractéristiques très proches des polices système. Vous pouvez également considérer la police web comme optionnelle lors du premier chargement de la page. Elle ne sera alors pas utilisée sur cette page, même si elle est téléchargée et mise en cache. En revanche, elle sera disponible pour la page suivante. À ce sujet, vous pouvez lire “eBay’s Font Loading Strategy” de Senthil Padmanabhan.

Contenu injecté plus de 500 ms après une interaction

L’algorithme du CLS ignore les Layout Shifts pendant 500 ms après chaque interaction active de l’utilisateur avec le document ou modification de la taille du viewport. Grâce à ce mécanisme, la plupart des interactions utilisateur ne provoquent pas de Layout Shifts comptabilisés dans le Cumulative Layout Shift.

Assurez-vous donc que votre interface réagira à l’interaction utilisateur dans la fenêtre de 500 ms. Si votre interface utilisateur repose sur des requêtes réseau ou un traitement javascript lourd, des décalages peuvent se produire après 500 ms et seront donc pris en compte dans la valeur du Cumulative Layout Shift.

Pour optimiser votre CLS :

Assurez-vous que vos transitions et animations qui suivent une interaction utilisateur durent moins de 500 ms.
Mesurez et optimisez les temps de réponse des vos API.
Anticipez le résultat de l’appel (ou des appels) ou du long traitement en réservant l’espace associé au(x) résultat(s) durant les 500 ms qui suivent l’interaction, quitte à ce que cet espace soit rempli ultérieurement, à la manière de l’optimistic UI.
Implémentez un paradigme d’interface utilisateur spécifique aux longs traitements et un appel réseau (mise en file d’attente et notification d’achèvement, affichage des résultats dans des pop-ins, etc.)
N’animez que des propriétés CSS qui ne déclenchent pas de changements de mise en page dans Blink.

Bien sûr, testez toujours vos optimisations. En menant quelques expériences pour écrire cet article, j’ai découvert que lorsque la durée d’une transition translate est de 0, des Layout Shifts apparaissent (un problème désormais résolu). Des cas-limites comme celui-ci existeront toujours. N’hésitez pas à les signaler à l’équipe Chromium.

Astuce: un traitement en deux étapes

Prenez l’exemple d’un bouton “Charger 20 articles supplémentaires” en fin de page. Si le traitement (appel réseau + rendu) prend moins de 500 ms, c’est parfait. Mais s’il prend plus de 500 ms, le rendu peut provoquer un décalage du pied de page et augmenter votre Cumulative Layout Shift.

Pour éviter ça, surveillez le temps écoulé et divisez la tâche en deux parties si nécessaire. Au lieu de faire un rendu systématique après l’appel réseau, vous pourrez plutôt changer le libellé du bouton en “Afficher les 20 éléments récupérés”. Cela obligera les utilisateurs à interagir à nouveau avec la page et vous accordera 500 millisecondes supplémentaires pour le rendu du contenu.

Bien sûr, n’hésitez pas à tester le ressensi des utilisateurs pour vérifier que l’utilisation de la fonctionnalité correspond mieux à leurs attentes. Optimiser le CLS ne doit pas se faire au détriment de l’UX.

Comportements contre-intuitifs

Augmentation continue dans le cas des Single-Page Applications (SPAs)

La plupart des algorithmes de calcul des indicateurs de performance web s’arrêtent à la fin du chargement de la page. L’évaluation du Cumulative Layout Shift, elle, se poursuit tout au long de l’utilisation de la page.

Beaucoup de sites web sont construits sur un paradigme de navigation de page à page, d’URL à URL. Pour eux, le CLS est réinitialisé à chaque changement de page. Certains sites, en revanche, sont construits autour d’une page unique dont le contenu évolue au fil des interactions. C’est ce qu’on appelle des Single-Page Applications (SPA).

Sur les SPA (y compris les applications qui utilisent des bibliothèques d’amélioration progressives comme turbolinks), le Cumulative Layout Shift augmente en continu pendant la session d’un utilisateur, puisque la navigation entre les contenus ne se fait pas en naviguant entre des pages. Le Cumulative Layout Shift n’est donc collecté que lorsque l’utilisateur quitte la page. Si la valeur du Cumulative Layout Shift que vous observez dans la Search Console (rubrique “Signaux Web essentiels”) vous semble élevée, c’est peut-être une explication.

Note

Ce comportement spécifique du Cumulative Layout Shift est particulièrement important. Pour les équipes développant des SPAs, l’objectif ne doit pas être de réduire le nombre de Layout Shifts, mais de concevoir des interfaces qui ne produisent aucun Layout Shifts. Dans le cas contraire, plus leurs interfaces sont populaires, plus les durées des session de leurs utilisateurs et utilisatrices seront longues, plus le CLS mesuré sera élevé.

Le problème des barres de défilement

Bien que cela puisse paraître contre-intuitif, les barres de défilement horizontales et verticales font partie du viewport. Elles sont notamment incluses dans les dimensions de pourcentage du viewport vw et vh. L’apparition ou la disparition des barres de défilement ne modifie donc pas le viewport, et ne sont donc pas éligibles aux “500 ms sans accumulation de CLS”. Pourtant, l’apparition et la disparition des barres de défilement modifient la zone disponible pour les contenus, qui peuvent donc se déplacer pour mieux l’occuper, provoquant un Layout Shift.

Sur certains systèmes d’exploitation, comme Windows, les barres de défilement sont cachées jusqu’à ce qu’elles soient nécessaires. Si le chargement de votre site est très progressif (avec par exemple une page vide au début puis des requêtes JavaScript qui, petit-à-petit, créent le contenu), alors les barres de défilement peuvent être absentes lors du First Paint, puis apparaître au cours du chargement de la page et provoquer des Layout Shifts.

Pour éviter ce comportement, vous pouvez ajouter html { overflow-y: scroll } afin de forcer l’apparition d’une barre de défilement au First Paint, ou attendre l’implémentation du module CSS Overflow de niveau 4 et la nouvelle propriété scrollbar-gutter.

Cumulative Layout Shift #CLS tuning tip

Add html{overflow-y:scroll} to enforce a scrollbar at first paint.

Pages with a layout shift drastically reduced as soon as the above CSS rule was added. #WebPerf #AimForZero pic.twitter.com/k4KCUnmzPo
— Tim Vereecke (@TimVereecke) March 16, 2020

Impact de la `timing-function`

Dans l’exemple suivant, nous comparons deux mises en page réalisées avec flexbox. Dans les deux cas, le survol de l’élément central double sa surface. Sur la première ligne, la timing-function est ease. Sur la seconde, c’est linear.

Comme vous pouvez le voir, le deuxième exemple génère beaucoup moins de Cumulative Layout Shift. Pour l’expliquer, nous devons revenir à la spécification de l’API Layout Shift, et plus précisément à ce que l’on appelle les “nœuds instables” (”Unstable nodes”).

A Node N has shifted in a coordinate space C if the starting point of N in C differs from the previous frame starting point of N in C by 3 or more pixel units in either the horizontal or vertical direction.

qu’on peut traduire par :

Un nœud N s’est déplacé dans un espace de coordonnées C si le point de départ de N en C diffère du point de départ de la trame précédente de N en C de 3 unités de pixels ou plus dans le sens horizontal ou vertical.

Cette règle des “trois pixels entre deux frames” introduit un critère de vitesse dans la mesure de l’instabilité. Tous les éléments se déplaçant en dessous de cette vitesse ne sont pas considérés comme instables, et ces animations ne produisent pas de Layout Shifts.

Malheureusement, cela signifie que pour réduire le CLS, certains propriétaires de sites pourraient être tentés d’utiliser des animations linéaires, qui ont une vitesse constante, plutôt que des animations plus intuitives pour l’homme, telles que ease, qui accélère au début de l’animation et ralentit à la fin.

La timing-function linear a une croissance constante. ease accélère fortement jusqu’au milieu du temps, puis ralentit.

Autres comportements étranges de l’indicateur

Les éléments animés qui créent des Layout Shifts peuvent continuer à le faire, même s’ils ne sont pas visibles pour l’utilisateur (par exemple, s’ils ont une couleur qui se fond avec l’arrière-plan). Mais si vous utilisez visibility: hidden, ce ne sera pas le cas.
La page web.dev du CLS (traduite en français par Sarah Salis pour Fasterize) recommande d’utiliser transform et translate pour créer des animations qui ne produisent pas de Layout Shifts. Chrome créer des Layout Shifts lorsque le temps de transition est de 0, jusqu’à Chrome 86.

Conclusion

Le Cumulative Layout Shift est un indicateur qui mesure les instabilités de la mise en page d’une page web. Pour l’optimiser et améliorer l’expérience utilisateur, vous devez éviter d’injecter du contenu pour lequel le navigateur n’a pas alloué la bonne quantité d’espace. Il existe plusieurs techniques pour les images, mais cela rendra toutefois la gestion de la publicité beaucoup plus complexe.

Le mode de calcul du CLS lui confère des caractéristiques inhabituelles. L’algorithme actuel du CLS n’est probablement pas adapté aux Single Page Apps, car l’attribution des résultats au niveau de la page n’est pas correctement gérée. Par conséquent, l’utilisation des Core Web Vitals (Signaux Web Essentiels) comme critère de classement pourrait être particulièrement difficile dans de tels cas.

N’oubliez pas que le CLS est une nouvelle mesure. Nous manquons encore de retours d’expérience à grande échelle. En cas de doute, concentrez-vous toujours sur l’amélioration de l’expérience de l’utilisateur plutôt que sur l’optimisation de l’indicateur lui-même. Certaines optimisations du CLS peuvent aller à l’encontre de l’UX et doivent être évitées.

Support Navigateurs

En octobre 2018, Steve Kobes a annoncé que Blink (le moteur de rendu Chrome) avait l’intention d’implémenter une API faisant émerger cette information. Le travail sur le projet d’API Layout Instability a commencé en mai 2019, et l’API a été publiée dans Chrome 77 en septembre 2019. Daniel Holbert a créé un ticket pour Firefox en juillet 2020. Nous n’avons trouvé aucune mention de l’API Layout Instability parmi les tickets publics de Safari.

Resources

Mes propres expérimentations sur le Cumulative Layout Shift
“Layout Instability API specification”, par Steve Kobes, Nicolás Peña Moreno et Emily Hanley
“Cumulative Layout Shift”, par Philip Walton et Milica Mihajlija
“Optimize Cumulative Layout Shift”
et “Infinite Scroll without Layout Shifts”, par Addy Osmani
“Web Vitals - A New Hope in Web Performance Measurement”, par Dave Smart

Merci à Damien Jubeau et Matt Hobbs pour leurs contributions.

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Punir la loyauté

Wed, 10 Jun 2020 00:00:00 +0200

Imaginons que vous déployiez, sur votre site, un outil de collecte du consentement lié à vos conditions générales d’utilisation (CGU). Ce consentement se découpe le plus généralement autour de différents usages : consentement à la télémétrie, consentement à la publicité, consentement à la transmission d’information à des tiers…

Si vous souhaitez mesurer avec finesse l’impact de ces différents “niveaux de consentement” sur la Performance Web, alors il faut faire le tour de tous les cas d’usage, en fonction de la relation qu’entretient la personne concernée avec votre site.

Pour mesurer les performances de ces cas d’utilisation, vous aurez besoin soit de mesures réelles, soit de solutions de surveillance synthétique. La plupart des outils ignoreront la bannière de cookies et testeront donc sans charger ces dépendances supplémentaires. Vous devrez donc configurer vos tests de manière à ce qu’ils commencent par une configuration spécifique (souvent un cookie) pour reproduire tous les cas d’utilisation :

Cette personne bloque le script de demande du consentement (via un adblocker, par exemple).
Cette persone a donné son consentement à cette version des CGU.
Cette personne a donné son consentement à une version antérieure des CGU, il est donc nécessaire de lui redemander son consentement.
Cette personne a refusé son consentement à cette version des CGU.
Cette personne a refusé son consentement à une version antérieure des CGU ; il peut être opportun de lui demander son consentement à nouveau.

Le cas numéro 3 peut donner lieu à une quantité importante de tests car il faudrait idéalement procéder à tes tests pour l’ensemble des combinaisons de consentements : “télémétrie”, “télémétrie + publicités”, “publicités seule”…

Pour simplifier, vous pouvez vous concentrer sur les deux tests les plus extrêmes :

que se passe-t-il si la personne refuse ou ne donne pas son consentement ?
que se passe-t-il si la personne a accepté l’ensemble des usages courants ?

Très souvent, le second cas est bien plus lent et inutilisable que le premier, sans pour autant que ces personnes ne se voient offrir de nouvelles fonctionnalités compensant cette dégradation.

L’occasion pour les Responsables Produit de réfléchir à l’éthique de ce type d’implémentation. Est-il normal que nous offrions l’expérience la plus dégradée à nos utilisateurs et utilisatrices les plus fidèles ?

Cette réflexion peut aboutir à une transformation de l’offre, soit vers un modèle où les utilisateurs et utilisatrices fidèles sont récompensé·es pour leur sacrifice (en ayant accès à des fonctionnalités qui ne sont disponibles que pour celles et ceux qui acceptent la collecte de données par des tiers), soit vers un modèle payant, plus protecteur mais moins accessible à tous.

Philosophiquement, nous entrons alors dans des considérations très actuelles sur la vie privée en tant que capital ou en tant que commun. Un sujet fascinant.

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Priorités des chargements JavaScript dans Chrome

Thu, 04 Jun 2020 00:00:00 +0200

Je relis et conseille souvent cet article d’Addy Osmani de février 2019 mais mes interlocuteurs et interlocutrices ne sont pas forcément anglophones. J’ai donc décidé de le traduire.

Retrouvez l'original sur le blog d'Addy Osmani : JavaScript Loading Priorities in Chrome.

La façon dont les navigateurs ordonnancent et exécutent les scripts peut avoir un impact sur les performances des pages web. Si des techniques comme <script defer>, <link rel=preload> (et d’autres) influencent le chargement des scripts, il peut également être utile de savoir comment les navigateurs les interprètent. Grâce à Kouhei Ueno, nous disposons maintenant d’un résumé actualisé de la manière dont les scripts sont ordonnancés dans Chrome.

	Priorité de chargement (network/Blink)	Priorité d'exécution	Comment l'utiliser ?
`<script>` dans `<head>`	Moyenne/Haute	Très Haute - Interrompt l'analyse	Scripts ayant une incidence sur le rendu du First Meaningful Paint (FMP) / First Contentful Paint (FCP) content Scripts devant être exécutés avant d'autres scripts Exemples : Runtime de Framework (s'il n'y a pas de rendu statique) Polyfills Tests A/B qui modifient la structure du DOM de l'ensemble de la page
astuce `<link rel=preload>` + `<script async>` ou `<script type=module async>`	Moyenne/Haute	Haute - Interrompt l'analyse	Scripts qui produisent un contenu critique (requis pour le FMP) Mais ne devraient pas affecter la mise en page au-dessus de la ligne de flottaison Scripts qui déclenchent des requêtes réseau pour injecter dynamiquement du contenu Scripts devant être exécutés dès que leurs dépendances sont téléchargées, utilisez `<script async type=module>` Exemples : Dessiner quelque chose dans un `<canvas>`
`<script async>`	La plus basse/Basse	Haute - Interrompt l'analyse	Faites attention lorsque vous utilisez `<script async>`. De nos jours, il est souvent utilisé pour indiquer des scripts non-critiques mais ce n'est pas cohérent car même si le script est chargé en basse priorité, il est exécuté en haute priorité. NdBoris : la attributes ne sont pas cumulatifs. Un script `<script async defer>` sera perçu par le navigateur comme un `<script async>` partout où `async` est supporté (c'est-à-dire… quasiment partout). La navigateur ne supportant pas `async` le considéreront comme un `<script defer>`.
`<script defer>`	La plus basse/Basse	Très basse - S'exécute après les `<script>`s en fin de `<body>`	Scripts qui génèrent du contenu non-critique Scripts qui fournissent des fonctionnalités critiques que >50% de sessions de pages utiliseront Exemples : Frameworks publicitaires Runtime de Framework (rendu côté client comme côté serveur)
`<script>` en fin de `<body>`	Moyenne/Haute	Basse - Attend la fin de l'analyse	Attention, quand vous utilisez `<script>` à la fin de `<body>` et que vous pensez définir une priorité basse. Ces scripts sont ordonnancés avec une priorité Moyenne/Haute.
`<script defer>` en fin de `<body>`	La plus basse/Basse - fin de queue	Très basse - S'exécute après les `<script>`s en fin de `<body>`	Scripts offrant des fonctionnalités interactives utilisées occasionnellement Exemples : Chargement des "Articles connexes" Fonctionnalité "Votre avis nous intéresse"
`<link rel=prefetch>` + `<script>` lors d'une navigation vers la page suivante	Inactive / La plus basse	Dépend du moment et de la manière dont le script est consommé.	Des scripts très susceptibles d'apporter des fonctionnalités importantes à une page visitée ultérieurement. Exemples : Bundle JavaScript d'une future route

Note : Les priorités de chargement ne sont pas nécessairement cohérentes d’un navigateur à l’autre. Utilisez donc ces connaissances à bon escient et mesurez-les en cas de doute. Dans l’idéal, cherchez à offrir une expérience de qualité au plus grand nombre d’utilisateurs possible.

Si vous êtes un développeur ou une développeuse web et que vous vous demandez où vous pouvez voir la “Priorité de chargement”, Chrome DevTools a une colonne “Priorité” optionnelle disponible dans le panneau Réseau. Cliquez avec le bouton droit de la souris sur les en-têtes de colonne et vous pourrez l’activer :

Cette synthèse des priorités ci-dessus est toujours valable en février 2019. Je souhaiterais personnellement avoir une meilleure compréhension des priorités de chargement dans d’autres navigateurs également. J’espère que cet aperçu sera utile à quelqu’un·e d’autre !

Merci à Kouhei, Dom Faralino, Pat Meenan, Kenji Baheux et Yoav Weiss pour leurs contributions permettant de mieux expliquer la pile réseau de Chrome.

En savoir plus

[Note de Boris] Et j’ajoute mes propres articles, en français :

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Maîtrise de soi

Tue, 02 Jun 2020 00:00:00 +0200

Parfois, j’écris un tweet ou un billet de blog et je le supprime.
Parce que le monde n’en a pas besoin.
Parce que ça peut faire du mal à certaines personnes.
Parce qu’il y a d’autres moyens.
Parce que je peux vivre sans le publier
et que mon public mérite que je ne le fasse pas.

S’il vous plait, faites de même avec votre JavaScript.

Vous êtes abonné·e au flux des articles :

de la catégorie : Web
rédigés en français.

Boris Schapira (Web, articles en français)

Lectures complémentaires sur la fatigue liée à l'IA

Ce que j’avais manqué

Le choc des systèmes probabilistes

Le tapis roulant des nouveaux outils

Le piège du “aller, j’essaie encore un truc”

Je suis tombé par terre… 🎶

Et malheureusement, nous avons raison

Productivité et qualité

La délégation, ce serpent de mer

Le paradoxe de la productivité apparente

Pourquoi ça ne marche pas ?

Que faire ?

LLMs : entre productivité, management et responsabilité

La productivité, un leurre bien pratique

L’apprentissage par l’expérimentation : entre bricolage et improvisation

L’orchestration d’agents : quand le management devient algorithmique

Un management sans émotion, mais à quel prix ?

Recherche en ligne : quel modèle économique ?

De retour de l'AFPA

Votre site est un restaurant

Comment servir un plat de restaurant ?

Créer le projet

Répétitions et pré-ouverture

L’offre la plus simple

Fast Food

Quality Audits

Service en salle

Mesurer pour optimiser

Assiettes musicales

Partenariats et délégation de tâches

À la table du Chef

Des sites web divers pour de belles expériences

Incremental Font Transfer

L'API Speculative Rules

Petit historique personnel

Découvrons l’API Speculative Rules

Devons-nous attendre un peu ?

Alors, on y va ?

Entendre le réseau

L'UX n'est pas une checklist

Un nouveau besoin sur le Produit

Un métier, pas qu'une passion

Pourquoi mon script asynchrone bloque-t-il le rendu de ma page ?

Les Core Web Vitals partout

Les formations "courtes"

Tu devrais faire de la WebPerf

Un point sur la situation

Pour résumer

Le chemin qu’il nous reste à parcourir

Pourquoi on a besoin de toi

Cumulative Layout Shift, l’indicateur de stabilité de la mise en page

Une API dédiée dans le navigateur…

… utilisé pour pénaliser les saccades

Comment visualiser les Layout Shifts dans Chrome

Comment optimiser votre Cumulative Layout Shift

Images

Publicités, intégrations, iframes et contenus créés dynamiquement

Comment éviter que la mise en page soit modifiée ?

Police d’écriture web

Contenu injecté plus de 500 ms après une interaction

Comportements contre-intuitifs

Augmentation continue dans le cas des Single-Page Applications (SPAs)

Le problème des barres de défilement

Impact de la timing-function

Autres comportements étranges de l’indicateur

Conclusion

Support Navigateurs

Resources

Punir la loyauté

Priorités des chargements JavaScript dans Chrome

En savoir plus

Maîtrise de soi

Impact de la `timing-function`