Sur le web, le vrai enjeu n’est plus d’être lu, mais d’être compris en quelques secondes

En 1998, il aurait indexé environ 26 millions de pages web (26 000 000).
Aujourd’hui, le moteur de recherche auraient référencés des centaines de milliards de pages web (plusieurs x 100 000 000 000).
En tant que lecteur, le problème n’est plus de trouver une information, mais de savoir rapidement laquelle mérite notre attention.

Depuis des années, les bonnes pratiques sont connues : hiérarchie des titres, paragraphes courts, listes, images, vidéos, légendes… . Le lecteur, lui, recherche toujours plus à gagner du temps.

Les travaux de Jakob Nielsen montrent que ces trois techniques combinées peuvent même augmenter l’utilisabilité de 124 % par rapport à un texte traditionnel.

• réduire la longueur des textes
• + mettre en évidence les mots-clés
• + structurer l’information

FAUT-IL ALLER PLUS LOIN ?

Une piste consiste à proposer trois niveaux de lecture.

• Le premier grâce au texte courant, qui développe les idées
• Le second grâce au gras, qui fait ressortir les idées essentielles
• Le second grâce au surlignage, réservé aux messages que le lecteur doit retenir avant même de commencer sa lecture

Dans Building a Second Brain, Tiago Forte rapporte les propos de Benigno : « Je savais instinctivement qu’envoyer un long article à des amis ne servait généralement à rien. Mais lorsque le texte était surligné, ils pouvaient le parcourir rapidement.« 

Cette observation fait écho à mon expérience : partager une information intéressante tout en craignant qu’elle ne soit jamais lue. L’idée d’ajouter un niveau de lecture permettant d’aller directement à l’essentiel semble donc séduisante.
Mais est-il envisageable d’intégrer cette pratique dans un processus de production : est-ce une réelle opportunité ?

NOUVEAU NIVEAU DE LECTURE OU UNE COMPLEXITÉ INUTILE ?

Les recherches restent toutefois nuancées. Une étude de 2016 sur la lecture hypertexte montre que le surlignage seul n’améliore pas nécessairement la compréhension. En revanche, plusieurs travaux indiquent que les éléments mis en évidence attirent davantage l’attention visuelle et facilitent le retour sur les informations importantes.

Du gras + du surlignage ne rendent pas le lecteur plus intelligent.
Ils rendent les informations importantes plus faciles à repérer.

La question n’est donc peut-être pas de savoir si le surlignage est une bonne pratique. Ca pourrait l’être en théorie. La véritable question est de connaître sa valeur.

Ajouter un troisième niveau de lecture modifie le processus de production : les rédacteurs doivent désormais identifier les informations qui méritent d’être surlignées, définir des règles communes et maintenir cette cohérence dans le temps. Cet effort supplémentaire est-il compensé par un gain réel pour le lecteur ? le bénéfice apporté au lecteur justifie-t-il l’effort demandé aux équipes ?

Cet article propose de faire le tour des principales approches afin de comprendre non seulement comment elles s’écrivent, mais surtout pourquoi elles existent.

1. La User Story n’a jamais eu de format officiel

C’est probablement ma première surprise.

Le Guide Scrum ne parle jamais du format (« En tant que… Je veux… Afin de…« ). Il ne définit pas non plus ce qu’est une User Story.

Le guide décrit simplement le Product Backlog comme une liste ordonnée d’éléments représentant le travail nécessaire pour améliorer le produit. Ces éléments peuvent prendre différentes formes : fonctionnalités, corrections de bugs, améliorations techniques, recherches, expérimentations, etc.

La User Story est donc une pratique, pas une règle de Scrum, et change donc avec les pratiques, équipes et produits.

Son origine remonteraiy à Extreme Programming (XP), où Ron Jeffries la résumait par la règle des 3C.

La user-story XP (Extreme Programming) :

• Format card : une carte contenant quelques mots, pour encourager la synthèse
• Conversation : retrace les échanges entre les personnes concernées
• Confirmation : les critères permettant de vérifier que le besoin est satisfait sont indiqués

Autrement dit, la carte n’était jamais censée contenir toute la spécification. Elle servait avant tout à déclencher une conversation.

Au fil des années, d’autres approches sont apparues : Lean, Product Discovery, Design Thinking, SAFe, Kanban… Chacune a fait évoluer la manière d’exprimer un besoin.

C’est pourquoi il existe aujourd’hui une grande diversité de formats. Ils ne sont pas concurrents ; ils répondent simplement à des situations différentes.

2. Les grandes familles de User Stories

Il existe des dizaines de variantes. Ce tableau m’aide à comprendre dans quel contexte chacune apporte de sa valeur.

Ce tableau montre une chose essentielle : le choix d’un format dépend davantage du problème à résoudre que de Scrum lui-même.

Une équipe qui développe une plateforme SaaS, un logiciel métier ou un produit grand public ne rencontrera pas les mêmes besoins, elles n’utilisent donc pas exactement les mêmes formulations.

En réalité, il est rare qu’un Product Backlog ne contienne qu’un seul type de User Story. Une Story classique peut côtoyer un Spike, un bug ou une amélioration technique sans que cela pose le moindre problème.

L’objectif n’est pas d’uniformiser les intitulés, mais de rendre le backlog compréhensible et utile pour tous les acteurs du produit.

3. Qu’est ce qui compte réellement ?

À force de parler de modèles, il est facile d’oublier l’essentiel.

Une User Story n’a jamais eu vocation à devenir une mini-spécification fonctionnelle. Son rôle est plutôt de faciliter les échanges entre les personnes qui conçoivent, développent et utilisent le produit.

Qu’elle commence par « En tant que… », « Lorsque… » ou qu’elle ne suive aucun modèle particulier importe finalement assez peu.

Les questions les plus importantes sont :

• Le besoin est-il compris par toute l’équipe ?
• La valeur recherchée est-elle clairement identifiée ?
• Les critères d’acceptation permettent-ils de savoir quand le travail sera terminé ?
• La Story est-elle suffisamment petite pour être réalisée dans un délai raisonnable ?
• Favorise-t-elle les discussions plutôt que de les remplacer ?

Si la réponse est oui, alors la forme utilisée est la bonne.

En définitive, il n’existe pas une seule bonne manière d’écrire une User Story. Il existe des pratiques adaptées à des contextes différents.

C’est peut-être là la plus grande leçon à retenir : une User Story est un outil au service de la collaboration, pas un exercice de mise en forme. Les équipes les plus efficaces ne sont pas celles qui appliquent un modèle à la lettre, mais celles qui choisissent consciemment la manière de formuler leurs besoins pour mieux construire leur produit.

Un récapitulatif rapide du monde du digital, sur le mois d’avril, en une dizaine de points.

1. IA générative : passage en mode “outil métier”

Les usages quittent le stade expérimental pour s’intégrer dans les workflows (support client, rédaction, code). La question n’est plus “faut-il y aller ?” mais où créer de la valeur sans risque.

2. Sécurité & données : forte vigilance entreprise

Des cas comme l’interdiction de ChatGPT chez Samsung Electronics continuent d’influencer les politiques internes :
montée des guidelines IA + data governance

3. Explosion des copilotes dans les outils SaaS

Notion, Google, Microsoft… tous intègrent de l’IA.
Enjeu : éviter la dispersion des usages et garder une cohérence produit

4. UX : retour à la simplicité

Face à la surcharge d’IA, tendance à :

• interfaces plus claires
• moins de friction
  “moins de features, plus de compréhension”

5. No-code / low-code : maturité réelle

Les outils deviennent exploitables en production.
Opportunité forte pour :

• MVP rapides
• tests produit à faible coût

6. Data : fin du “tout collecter”

Pression réglementaire + coût infra →
priorité à la data utile et activable

7. SEO : mutation accélérée avec l’IA

Les moteurs évoluent vers des réponses générées.
Impact direct :

• baisse du trafic organique classique
• besoin de contenus différenciants

8. Product management : retour au business

Moins de focus sur les frameworks (comme OKR ou RICE), plus sur :
impact réel (revenu, usage, rétention)

9. Agilité : adaptation plutôt que dogme

Scrum pur recule au profit de modèles hybrides.
Le rôle du chef de projet évolue vers :

• facilitateur
• alignement stratégique

10. Collaboration : fatigue des outils

Trop d’outils → perte d’efficacité
tendance à :

• réduire
• centraliser
• simplifier

11. Design : montée du “AI-assisted design”

Les designers utilisent l’IA pour :

• générer des idées
• accélérer les wireframes
  mais gardent la décision finale

12. Développement : accélération mais dette potentielle

Le code généré par IA augmente la vitesse
mais crée :

• risques qualité
• besoin de review renforcée

13. Privacy & réglementation

Renforcement des règles (Europe notamment)
impact direct sur :

• tracking
• personnalisation
• marketing

14. Contenu : saturation + besoin d’authenticité

Avec l’IA :
explosion des contenus moyens
valeur accrue des contenus incarnés

15. Compétence clé : savoir orchestrer

La vraie compétence devient :
connecter outils, humains et stratégie

**Contrairement aux articles du blog Carnetweb.fr, que je pense et écris, cet observatoire est produit avec une AI que j’utilise comme ‘ouvrier’. La phase créative, elle, reste dans mes mains.**

On fera appel à Claude pour un travail intellectuel profond parfaitement adapté pour le codage, et à ChatGPT pour innover, créer et s’adapter en un clin d’œil.
A cela s’ajoute des questions de confidentialité et de changement de modèle économique :
– Confidentialité : approche « privacy by design » et confidentialité renforcée pour les offres professionnelles de Claude, alors que les données des utilisateurs peuvent être utilisées pour améliorer les modèles de ChatGPT (à moins de cocher la bonne case …).
– Modèle économique : en 2026 les publicité viennent d’apparaitre pour le utilisateurs Américains pour ChatGPT, alors que Claude affirme qu’il resterait 100%.

Tout cela fait réfléchir les utilisateurs, alors que le combat des IA continue.

Une histoire d’expression du besoin ?

La première version de cette image date des années 70, paraît-il. Pourtant l’image ne vieillit pas, et reste tellement représentative de ce qui peut se passer durant la gestion d’un projet digital. J’ai vu …

• Un commercial et un technicien être d’accord et employer les mêmes mots pour décrire une fonctionnalité, mais être en désaccord total lors de la validation de celle-ci.
  Dialogue de sourds : le commercial indique que, non, ça ne fonctionne pas en toute bonne foi, le technicien répondant que, oui, tout fonctionne bien pourtant.

• Des commerciaux décrire la mécanique de précision d’un site à des clients (la pensée positive vous connaissez ?), alors que les enjeux stratégiques ne prévoyaient même pas d’explorer ce chemin.

• Des développeurs être impliqués à 300%, et pourtant livrer une balançoire à terre. Ils étaient déjà positionnés sur les starting blocks, ‘full-motivés’ à itérer une nouvelle fois pour le nouveau défi : relever la balançoire ! (lol)

• Le manque de temps, créant des spécifications dans lesquelles la balançoire est ‘peut-être un peu trop proche du tronc ‘, rendant l’utilisation quasi impossible et ‘poussant’ gentiment l’effort à l’équipe de développement. Dommage pour les dév …

• Je me rappelle des devis épais, impressionnants, colorés, mais peu personnalisés en fonction de nos différents projets.

• Et le client, avec un sourire béat, se balancer sur son nouveau jouet : la ‘balançoire-pneu’ !
  En dépit de sa demande initiale de balançoire à trois étages, la ‘balançoire-pneu’ reflétait totalement son originalité et lui allait si bien.

À qui la faute ? Biais cognitif ?

C’est facile de se dire que ‘l’autre’ n’a pas compris, ‘c’est normal, il n’y connaît pas grand chose ‘, qu’il n’a pas su écouter ou prêter attention, mais ça ne résout rien.

Alors comment faire ?

Chaque personne ‘imagine’ le projet à travers ses propres lunettes. Il ne s’agit pas de manque de connaissances, de compétences ou de communication, nous avons tous notre vécu et nos filtres d’interprétation : nos biais cognitifs.

Quelques pistes pour visualiser, clarifier et prioriser

• Avant de parler de fonctionnalités, quel problème résout-on ? Pour qui ?
• Quel changement CONCRET, PHYSIQUE doit-on observer comme preuve de résolution du problème ?
• Quels sont les objectifs de chacun des acteurs du projet et comment chacun comprend ces objectifs ?
• Quels sont les contraintes de chacun ?
• Quels visuels, maquettes rapides peuvent rendre visible ce que des mots peinent à montrer ?

On entend souvent qu’il faut plus ou mieux communiquer.
Là aussi, augmenter ou changer de communication ne sera pas déterminant tant que l’équipe ne travaille pas ensemble.
Il ne s’agit pas non plus de travailler constamment ensemble, mais plutôt de créer des plages d’ateliers aussi courtes que possible pour prendre le diapason et le temps de s’accorder.

Car un projet ne déraille pas faute de compétences.
Il déraille faute d’alignement.

Et l’alignement ne se décrète pas.
Il se construit, volontairement.

Si je reviens en arrière, la CNIL a déclaré Analytics non conforme au RGPD en 2023 et a laissé à la firme quelques mois pour s’ajuster au marché français (et européen).
Nous sommes en 2024, où en est t’on au niveau de la conformité RGPD de google Analytics ?

Proxiquoi ?

En juin 2022, la CNIL a recommandé l’utilisation de la proxyfication et de mesures spécifiques pour utiliser correctement GA4 en conformité avec les directives Européennes et la RGPD.

« La proxyfication de Google Analytics consiste à remplacer certaines informations par le serveur de proxification pouvant participer à la génération d’une empreinte, et supprimer toute autre donnée pouvant mener à une réidentification comme ID de base CRM. »

https://starfox-analytics.com/docs/articles/google-analytics/proxyfication-de-google-analytics-:-une-bonne-idee

Je reprends ci-après une image plus simple à comprendre tirée d’un article très instructif sur le site www.alphalyr.fr/fr/ même si de nombreuses ! questions persistes.

En 2023, que dit la CNIL ?

« Le 10 juillet 2023, la Commission européenne a adopté une nouvelle décision d’adéquation concernant les États-Unis.
Par cette décision, la Commission décide que les modifications apportées par les États-Unis à leur législation nationale permettent désormais d’assurer un niveau de protection adéquat des données personnelles transférées de l’UE vers les organisations situées aux États-Unis».« 

CNIL – https://www.cnil.fr/fr/transferts-de-donnees-vers-les-etats-unis-la-commission-europeenne-adopte-une-nouvelle-decision

En octobre 2023, cette nouvelle magique fait de Google Analytics 4 un outil qui n’est plus illégal en France (même sans proxification et donc sans perte de performance de l’outil !).

Source et liens à explorer ici : https://www.boryl.fr/blog/google-analytics-4-cnil-rgpd/

Comment ont réagi les sociétés en 2023 ?

Les sociétés clientes de boryl.fr (spécialiste marketing automation) migraient généralement vers Piano Analytics, Matomo ou Piwik Pro, en fonction de leur budget.
Pour les sociétés collectant une grande masse de données ou des données très sensibles, Google Analytics 4 étaient tout simplement arreté.
Pour les sociétés dont les enjeux RGPD étaient moindre, GA4 cohabitait avec la nouvelle solution installée. Si la CNIL leur tombaient dessus, elles étaient ainsi prêtes à supprimer GA4 définitivement.

(Sources très intersessantes à creuser : https://www.boryl.fr/blog/google-analytics-4-cnil-rgpd/ )

Que ce passe t’il en 2024 ?

Dans les faits, en mai 2024, GA4 est conforme au RGDP car le loi Américaine a changé. La proxification ne serait pas nécessaire. A titre d’exemple, un site utilisant un CMS faisant ces mises à jour régulièrement serait en conformité sans trop d’effort.
Cependant, on peut toujours se poser la question de comment les données transmises à des tiers seront utilisées, quelles données seront vraiment transmises.

Bien plus, le sujet n’est pas stable et pourrait évoluer dans les mois à venir, nous alerte l’agence marketing Boryl. Plusieurs plaintes en justice réclament l’annulation de l’accord entre les États-Unis et l’Union européenne sur les transferts de données.

Conclusion ?

Sujet complexe. Comme beaucoup de sociétés qui hésitent encore, je dois faire la migration de mon outil statistique. Le choix est difficile mais la pelote de laine a été démélée, prête à être retricotée.
Est-ce que je m’éloigne de la solution utilisée par une grande majorité ou est-ce que j’entre dans des terres inconues mais plus calme.

J’aime assez bien le calme en fait. On travaille bien dans le calme ! Pas vous ?

Comprendre comment le workflow peut être créé devient une aventure en soi. Ci-après quelques vidéos pour commencer à prendre en main l’outil.

Je l’ai entendu maintes fois, je l’utilise moi-même régulièrement, mais quelle est donc son origine, qui la prononcé en premier ? Pourquoi ?
Je pars donc à la recherche de son auteur et le net est unanime : Bruce Willis, oui l’acteur, a prononcé la pharse magique. Mais pourquoi « diantre » Bruce Willis ?
La toile, cependant, ne me livre pas de référence, vidéo ou contexte. Pourquoi cet acteur américain aurait-il utilsé cette pharse ? Je reste curieuse.

Et puis une autre idée me vient. Et si c’est payant, que ce passe t’il ? Suis-je libérée de toutes contre-parties négatives ? La solution est t’elle de payer ? Quelle direction prend le web éthique ? Est ce qu’il faut systématiqument refuser lorsque c’est gratuit ? Quel est l’avenir du gratuit et de l’open source ? …

Parfois les solutions sont complexes à trouver car l’écosystème est en pleine mutation. Mais ce n’est pas une raison pour oublier cette petite pharse si énigmatique et le goût amer qui s’en dégage en ce moment. Je veux me souvenir et pose ce billet ici.

> www.logiciel-libre.ch/accueil

Voici un classement possible : Métriques de comportement – Métriques d’attitude – Métriques descriptive – Métriques de diagnostique – Métriques d’engagement – Métriques de résultats.

1. Métriques de comportement
   Comment l’utilisateur réagit pendant qu’il utilise le produit ou service
2. Métriques d’attitude
   Comment l’utilisateur ressent un produit ou service
3. Métriques descriptive
   Informations descriptives à propos de l’utilisateur et son comportement. Oms servent à créer un persona et identifier des schémas type.
4. Métriques de diagnostique
   Pour diagnostiquer les causes à la base d’une problématique détecte à travers les expériences et les tests d’utilisateurs.
5. Métriques d’engagement
   De quel manière les utilisateurs sont engagés dans le produit ou service.
6. Métriques de résultats
   Afin de pouvoir mesurer l’impact des améliorations UX implémentées.

Maslow était un psychologue américain humaniste, considéré comme le père de l’approche humaniste en psychologie. Il est connu pour son explication de la motivation par la hiérarchie des besoins humains pour arriver à la plénitude et l’accomplissement de soi.
Il décrit cinq grands besoins humains – physiologiques, sécurité, appartenance et sociaux, estime, accomplissement – mais ne les classe pas sous la forme d’une pyramide rigide qui donne à penser à des paliers à franchir et à quitter. Pour lui, ces besoins humains sont dynamiquement fluides, évoluant constamment.

https://www.bain.com/insights/the-elements-of-value-hbr/

https://media.bain.com/elements-of-value/#