Cet article propose donc de faire le tour des principales approches. L’objectif est non seulement de comprendre comment elles s’écrivent, mais aussi de découvrir pourquoi elles existent et dans quels contextes elles peuvent être utilisées.

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

C’est probablement ma première surprise, car 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 remonterait à Extreme Programming (XP), où Ron Jeffries la résumait par la règle des 3C.

• 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.

Après examen du tableau, une chose essentielle ressort : 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.

L’article 1001 façons d’écrire une User Story (et pourquoi elles existent) est apparu en premier sur Carnet Web.

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

L’article Observatoire digital — Avril 2026 est apparu en premier sur Carnet Web.

Quand tout le monde ne voit pas la même chose

Au cours d’un même projet, un commercial et un technicien peuvent être d’accord et employer les mêmes mots pour décrire une fonctionnalité, mais être en désaccord total lors de la livraison de la solution.
Le commercial indique « ça ne fonctionne pas », le technicien répond « pourtant, tout fonctionne ». Tous deux sont de bonne foi.

Un commercial peut décrire à ses clients une fonctionnalité d’un site, alors que les enjeux stratégiques ne prévoyaient même pas d’explorer ce chemin.

Les développeurs impliqués à 300%, peuvent 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 !

Le chef de projet, par manque de temps, peut créer des spécifications dans lesquelles la balançoire est ‘peut-être un peu trop proche du tronc ‘, rendant son utilisation quasi impossible et créant de la dépendance technique pour l’équipe de développement.

Et puis il y a le client.
Il est ravie et se balance avec un grand sourire sur sa nouvelle ‘balançoire-pneu’, malgré sa demande initiale de balançoire innovante à trois étages.

Alors… qui avait mal compris le besoin initial ? Peut-être personne.

Besoin de plus de communication ?

On entend souvent qu’il faut mieux communiquer. Ou communiquer davantage. Pourtant, multiplier les réunions, les mails et les documents ne garantit pas que tout le monde se comprenne mieux. La quantité d’information ne remplace pas la qualité des échanges.

Il peut être plus utile de créer, à certains moments clés du projet, de courtes plages de travail collectif pour confronter les représentations, poser les questions qui dérangent et vérifier que chacun parle bien de la même chose. Il ne s’agit pas de travailler constamment ensemble, mais de savoir quand se retrouver pour prendre le diapason et accorder les instruments.

Car un projet ne déraille pas nécessairement faute de compétences. Il peut dérailler faute d’alignement. Et l’alignement ne se décrète pas. Il se construit, volontairement.

Besoin de pLus de fondations ?

Chacun a simplement construit sa propre représentation du besoin à partir de son métier, de son expérience, de ses contraintes et de ses objectifs propres.

Alors comment éviter de construire cinq balançoires différentes à partir d’une même demande ?

Avant même de parler de fonctionnalités, revenons un peu plus sur les fondations :

• Quel problème cherche-t-on réellement à résoudre ?
• Pour qui ?
• Quel changement concret doit-on observer si le problème est résolu ?
• Quels sont les objectifs de chacun des acteurs du projet ?
• Quelles contraintes chacun doit-il prendre en compte ?
• Qu’est-ce qui doit absolument être commun à tous ?
• Quels visuels, schémas ou maquettes peuvent rendre visible ce que les mots ne permettent pas de préciser ?

Une expression du besoin efficace ne consiste donc pas seulement à recueillir une demande et à la transmettre. Elle consiste à construire progressivement une compréhension commune.

Une symphonie plus qu’une balançoire ?

Finalement, c’est peut-être là que la métaphore de la symphonie prend tout son sens.

Dans un projet digital, chacun possède sa propre partition, son vocabulaire, ses contraintes et sa manière de regarder le projet. L’objectif n’est pas de faire disparaître ces différences, mais de permettre à chacun de jouer dans la même direction.

Un projet bien aligné n’est pas un projet dans lequel tout le monde pense la même chose. C’est un projet dans lequel chacun comprend suffisamment bien ce que les autres cherchent à construire.

L’article Expression du besoin : pourquoi tout le monde ne voit pas la même balançoire est apparu en premier sur Carnet Web.

Une application mobile ne se résume pas à ce que nous voyons à l’écran. En arrière-plan, elle échange avec de nombreux services, parfois grâce à des SDK intégrés par les développeurs. Ces échanges forment de véritables flux de données, dont il n’est pas toujours facile de connaître la destination ou l’usage.

Lors d’une intervention, Esther Onfroy montre justement l’intérêt d’observer ces échanges pour comprendre ce que font réellement nos applications.

Cette approche m’a amenée à me poser une autre question : et si nos sites web étaient eux aussi beaucoup plus bavards qu’on ne l’imagine ?

Regarder ce qui circule

Un SDK permet d’intégrer facilement une fonctionnalité à une application sans développer tout le code nécessaire. Pratique, mais que se passe-t-il une fois le composant installé ?

Il peut accéder à certaines données, communiquer avec une API ou transmettre des informations à un service externe. Pour comprendre ce fonctionnement, il ne suffit donc pas toujours de regarder l’interface ou même le code. Il faut aussi regarder les échanges qui ont réellement lieu.

C’est l’un des intérêts de l’approche présentée par Esther Onfroy : observer les flux réseau permet de rendre visibles des communications qui restent habituellement dans les coulisses.

{Découvrir les travaux d’Esther Onfroy et PiRogue — PTS Project}

Et si WordPress était lui aussi bavard ?

Un site WordPress est rarement constitué uniquement du ‘cœur’ du CMS.
Plugins, extensions et services tiers viennent ajouter des fonctionnalités : formulaire, statistiques, paiement, référencement, newsletter…

Les plugins disponibles sur WordPress.org sont soumis à la GPL et leur code doit être accessible. Mais open source ne signifie pas transparent de bout en bout.

WordPress autorise notamment les plugins qui fonctionnent comme interfaces vers des services externes, à condition que ces services soient clairement documentés. Documentation WordPress sur les services tiers et plugins

On peut alors avoir une chaîne assez simple :

Utilisateur → WordPress → plugin → API → service externe

quelles flux de données sont transmises ? Pourquoi ?

WordPress recommande justement aux développeurs de documenter les données collectées, les éventuels services tiers, les API ou SDK utilisés, ainsi que les cookies, pixels ou scripts externes.

Ces échanges ne sont pas forcément problématiques. Ils peuvent même être indispensables au service proposé.

EX HTTPS

Mais ils peuvent avoir un impact sur la confidentialité, la sécurité ou les performances du site. Une multiplication de requêtes ou de traitements externes peut notamment ajouter des dépendances et du temps de traitement.

Observer plutôt que supposer

Une fonctionnalité répond à un besoin visible. Mais derrière elle peuvent se trouver des requêtes, des API et d’autres services que nous ne voyons pas directement.

C’est peut-être là que réside l’intérêt d’observer les flux : mieux comprendre l’écosystème dans lequel nos outils fonctionnent.

Car installer un composant ne consiste pas seulement à ajouter une fonctionnalité. C’est aussi, parfois, ajouter une nouvelle conversation à notre système.

L’article Outils numériques : flux de données maitrisés ? Esther Onfroy est apparu en premier sur Carnet Web.

L’article Au secours, je fais du produit ! Guide de collaboration est apparu en premier sur Carnet Web.

Kaizen ça veut dire quoi?

Une rapide recherche sur mon dictionnaire en ligne préféré m’indique que ‘kaizen’ est la fusion entre deux mots japonais : ‘kai’, qui signifie ‘changement’ et ‘zen’ ‘meilleur’. Mais encore?

Kaizen c’est quoi?

J’apprends aussi que que ce n’est pas un outil. Ce n’est pas une méthode ou une organisation prête à être reproduite. Le Kaizen est une philosophie dont le concept aurait été utilisé au sortir de la deuxième guerre mondiale, alors que le peuple Japonais avait à sortir la tête de l’eau pour penser à reconstruire.

Philosophie de la ‘corvée d’entraide’?

Cette philosophie / activité « s’apparenterait à la « corvée d’entraide », où un groupe d’individus s’entraide pour rapidement passer au travers d’une problématique. »

Et là mon imagination s’envole. Je vois ces jeunes étudiants (environ 8 ans) distribuer eux-même le repas dans leur classe à midi, chacun ayant un rôle, puis après avoir mangé dans la bonne humeur, ils débarrassent bols et miettes, balaient le sol, lavent les tables, font la vaisselle sans l’intervention du professeur.
Surprise par ces gestes, je ne comprends pas cette scène sur le coup.

J’image aussi une ville au sortir de la destruction d’une bombe, partagée entre pleurs, peurs, et l’envi de redresser la tête coute que coute pour demander à son voisin comment il va et lui porter secours. Je me demande : si chacun fait un geste pour tenter d’améliorer cette ville de gravas, à quelle vitesse la vie reprendrait?

Même si le Japon ne correspond qu’à 0,28 % de la superficie terrestre, le pays est le site de 18,5 % des séismes de magnitude 6 ou plus. Autant dire que tous les ans, chaque japonais subit plusieurs secousses dont la plupart laissent que peu de dégâts car le Japon a appris à vivre avec (constructions antisismiques, gestes de survie appris et répétés à l’école ou en entreprise, kit de survie obligatoire, éducation constante, …).
Tout ceci pour me rappeler la réalité des japonais : vivant sur plusieurs failles sismiques en activités, ils ont du s’adapter naturellement à leur milieu et pour s’en sortir sans trop de casse, chacun doit veiller sur son voisin, c’est-à-dire la société, au quotidien.

C’est sans doute ce que ces écoliers essayent de transmettre : apprendre la « corvée d’entraide », où comment un groupe d’individus s’entraide pour passer rapidement au travers d’une problématique.

Kaizen dans l’entreprise

La méthode ‘kaban’ et le diagramme de Pareto, utilisée entre autre dans la gestion de projet, seraient nés des antres de cette philosophie Kaizen.
Simplification des flux, amélioration de la qualité, amélioration des délais, amélioration de la productivité, amélioration des conditions de travail, cette philosophie sans âge pointe le bout de son nez dans tous les services d’une entreprise pour observer, reporter, agir.

Les détracteurs de cette méthode insisteront sur le fait que appliqué sans se pencher sur la pensée à l’origine du concept, l’entreprise s’automatise parfois en produisant plans, méthodes, tableaux, … oubliant peut-être parfois que seule la présence de tableaux et diagrammes se suffisent pas à faire entrer l’entreprise dans un cercle vertueux d’amélioration vers le succès.

Kaizen? Laisser l’homme observer et agir

L’essence du Kaizen est au delà de la méthode. C’est une production humaine et douce qui consiste à apporter de petites améliorations tous les jours de manières constante et avec une volonté inébranlable afin d’atteindre la perfection, en prenant le risque de ne jamais l’atteindre et de toujours améliorer.
Ce n’est pas un travail. Ça ne se compte pas en heure mais peut-être en minutes que chacun pourra exploiter demain, après-demain, dans 10 ans, … créant de vrais changements humains sur le long terme.
On peut l’utiliser en entreprise, mais pour que cet esprit soit installé dans un service, c’est qu’il aura d’abord eu une valeur personnel importante.
La question a se poser est alors comment donner l’information aux individus afin d’adhérer (ou non) à ce principe de vie? Ou comment développer l’esprit Kaizen au delà de la méthode?

Concrètement, ça peut être de ne pas s’attacher aux plans ou tableaux d’hier s’ils ne servent pas et les reconstruire aujourd’hui, si notre emploi du temps le permet, pour voir s’ils peuvent être plus utile.
Ou s’assoir sur le murée d’en face, lever son nez, observer son environnement, dire bonjour à son voisin et finir par avoir une conversation passionnée sur l’utilisation des gants sur son poste de travail.
Une à une, à la vitesse d’un goutte d’eau qui rempli l’océan. Rien de plus mais tout est dis.

Les 10 règles Kaizen à méditer

Mazaaki Imai diffusa les règles de Kaizen dans ces deux livres ‘Kaizen’ et ‘Gamba zaizen’ (1997). Il y définie 10 règles Kaizen comme clé du succès à long terme, toutes à méditer avant d’en saisir le sens et domaines d’application.
Une d’entre elle vous fera peut-être sourire vous rappelant une sagesse interne oubliée. Ma règle du moment est la numéro 3 : tellement vrai.

1. Osez remettre en question les pratiques actuelles
2. Voyez comment réussir un projet plutôt que de dire que cela ne fonctionnera jamais
3. Il ne faut jamais chercher des excuses à un problème et encore moins des coupables mais remettez les pratiques actuelles en cause
4. Ne visez pas la perfection du 1er coup, mais cherchez simplement l’amélioration
5. N’attendez pas pour corrigez les erreurs, il faut réagir dès qu’elles apparaissent
6. Prioriser les solutions qui ne nécessitent pas d’investissement
7. Même si cela fonctionne bien, cherchez des idées pour toujours améliorer votre travail
8. Identifiez la cause première de votre problème et posez-vous la question « pourquoi » 5 fois de suite
9. Avant de prendre des décisions, demandez les idées de 10 personnes plutôt que le savoir d’une seule
10. L’amélioration est infinie

L’article Kaizen, c’est qui au juste? est apparu en premier sur Carnet Web.

Rien de magique, la seule présence d’un témoin extérieur, même s’il est en plastique, nous permettrait de faire une pause et regarder le problème d’un œil nouveau. Le fait d’expliquer son problème d’une voix intelligible permettrait de poser un jalon et de repartir mentalement vers une autre série d’itération.

Sur mon bureau, pas de canard jaune. Il pourrait pourtant tenir compagnie à ma petite figurine que j’invite sur ma table lorsque j’ai besoin d’énergie fraîche. Grâce à ce petit tour de passe-passe, j’en ai traversé des moments difficiles, à excaver des solutions de ma tête enlisée.

La vie c’est simple comme un canard !

L’article Développer avec Mr Canard est apparu en premier sur Carnet Web.

Pourquoi un certificat SSL?

Le certificat SSL est un protocole pour sécuriser les données sur les serveurs. Cette certification sera à demander auprès d’une société tierce, et ce n’est qu’une fois installé sur votre serveur et votre site configuré, que vos visiteurs bénéficieront du fameux https sécurisé.

Le moteur de recherche Google a largement contribué à sa généralisation. Les sites e-commerce ou entreprises gérant des données très sensibles se sont aussitôt penchés sur le certificat SSL et la migration de leurs sites en https. On pouvait alors reconnaître les sociétés ayant fait le pas en examinant la forme de l’url dans le navigateur.

On trouve encore certains sites en http mais ils se font rares car le moteur de recherche, leader incontournable, Google accorde des points négatifs qui ont un impact handicapant pour le référencement naturel (SEO).
Vous avez certainement déjà atterri sur une page comportant un horrible message ‘Échec de la connexion sécurisée’ : la porte d’entrée d’un site sans SSL ressemble à ça.
Pour résumer, pas de certificat SSL, et vous n’existez plus face à vos concurrents.

Il existe plusieurs types de certificats

Très souvent, les hébergements de sites web sur serveur mutualisé, inclut (ou propose) un certificat SSL. Si vous gérez vous-même votre serveur, il faudra installer le certificat par vous même.

Comme rien n’est simple en matière de web (c’est bien connu ), plusieurs types de certification s’offrent à vous. Les trois premiers facteurs pour faire votre choix seront sans doute le prix, le niveau de sécurité nécessaire, le niveau technique dont vous disposez.

Que valent les certificats gratuits?

Notons que certains certificats sont totalement gratuits. Il s’agit de Let’s encrypte et de Cloudflare (octobre 2020).
Inutile de paraphraser l’article très clair de www.tophebergeur.com/tutoriels/seo/https-traditionnel-letsencrypt-cloudflare qui détaille bien les différences. Mon but ici est de résumer et de faire écho. N’hésitez pas à faire un tour sur le site lorsque vous aurez besoin de plus de renseignements ou d’une comparaison avantages/inconvénients des certificats payant / gratuit Lets’ encrypte / gratuit Cloudflare.

Pourquoi pas Cloudflare ?

Pour un grand nombre de blog ou de site ‘vitrine’ ne proposant pas d’ouverture de compte, d’achat en ligne, le certificat Cloudflare peut largement suffire. La procédure est simple mais elle demandera de respecter 3 étapes : créer un compte Cloudflare et demander son certificat; attendre que votre site soit ‘reconnu’ par Clouflare; télécharger le plugin WordPress ‘Really simple SSL’ et le configurer. (j’ajoute en fin d’article des vidéos qui m’ont accompagné pour l’installation).

Je résume ici les avantages du certificat Cloudflare :

• Gratuit,
• Rapide à mettre en place, pas tracas de configuration,
• Certificat sans durée de vie (90 jours pour let’s encrypte; ou 1 an pour les certificats payants), dont pas de renouvellement à programmer,
• Optimisation du chargement des pages de VOTRE site à travers l’auto-minifier JS, CSS et HTML que propose Cloudflare,
• Une sécurité pour des blogs et sites ‘vitrine’

Ressources pour l’installation de Cloudflare

Ces vidéos pourront aider à installer le certificat (bah oui, moi je partage, moi!). Ces deux vidéos se complètent pour une installation de a à z. (et j’ajoute à ma to-do list : ‘trouver comment faire un tuto vidéo’).

L’article Certificat SSL est apparu en premier sur Carnet Web.