Talk

La méthode pour coder ce qui compte vraiment

La première version du talk, devant des développeurs.

DevFest Toulouse 2025
13 novembre 2025
Toulouse

Le talk en bref

Le point de départ : un livre s’écrit comme un produit. En écriture comme en code, la vraie question reste la même : pourquoi on le fait ?

Le talk suit Victor, chef de chantier, qui doit commander du béton en urgence. Les 5 pourquoi remontent de sa demande à son vrai besoin : ajuster une commande simplement, dans les conditions réelles du chantier, avec de la traçabilité. Puis trois façons de prioriser : MoSCoW, la matrice valeur / effort et le score RICE.

Les méthodes du talk

Le persona, d’Alan Cooper.
La user story au format Connextra, popularisée par Mike Cohn.
Les 5 pourquoi, de Sakichi Toyoda, chez Toyota.
MoSCoW, de Dai Clegg.
La matrice valeur / effort.
Le score RICE, conçu chez Intercom.

Les 34 slides

Sous chaque slide, son texte, puis, en plus petit, la description de ses images. Ces descriptions servent aux personnes qui lisent la page avec un lecteur d’écran.

© 2025 Cateline Puccetti. Ces slides, leur texte et leurs dessins sont sous licence Creative Commons BY-NC-ND 4.0 : vous pouvez les partager en citant l’autrice et le lien de cette page, sans les modifier ni en faire un usage commercial. Les photos et captures d’autres auteurs gardent leurs propres droits, indiqués sous la slide.

1 Tech Speak’Her. La méthode pour coder ce qui compte VRAIMENT. Cateline Puccetti. Logo de Tech Speak’Her, une bulle de dialogue dessinée en circuits. Photo de Cateline, tout sourire, une tasse à la main, à côté d’un petit micro.
2 Qui suis-je ? Depuis 2008 dans l’édition logicielle, avec une expertise B2B, SaaS RH, accessibilité, user centric. Lead Product Management, Product Design et Product Marketing. Logos des quatre éditeurs : Holy-Dis, Eurécia, Berger-Levrault et iSYBUY.
3 Comment j’ai appris mon métier ? Quatre illustrations, une par façon d’apprendre : une pelle plantée dans un tas de terre pour le terrain, une conseillère au casque pour le service client, une lectrice plongée dans un livre pour la formation continue, trois collègues qui discutent pour les équipes produit.
4 Side-project : autrice. Mon crédo : l’écriture d’un livre comme l’écriture d’un produit. Cycle itératif : écriture, relecture, correction, bêta-test, mise en ligne, suivi des résultats… et on recommence. Mais il ne manque pas un truc ? Photo de Cateline, un roman de sa série Deux traits entre les mains.
5 Quand j’ai commencé à écrire, je ne savais pas si j’allais publier. Est-ce que je voulais être lue ?
6 En écriture comme en code, la vraie question, c’est toujours la même : pourquoi on le fait ? On parle de la quête du héros !
7 Une méthode pour coder ce qui compte VRAIMENT, en trois temps : pourquoi, prioriser, (se) parler. Dans le titre, le mot « écrire » est barré et remplacé par « coder ».
8 Partie 1 : le pourquoi.
9 Qui pense avoir travaillé sur des fonctionnalités inutiles ? Un héros sans quête…
10 Qui a déjà demandé au product manager ou au product owner : à qui ça sert ? À quoi ça sert ?
11 Les user stories. Qui les lit vraiment ? Et pourtant, les réponses à beaucoup de questions doivent être dedans, dès les trois premières lignes…
12 En tant que : qui a un besoin ? Fait référence au persona : son métier, son contexte d’utilisation, son niveau sur les « nouvelles technos »… Deux portraits dessinés de personas, une femme et un homme.
13 Victor : chef de chantier, dans un environnement bruyant, travail entrecoupé, sur son téléphone mobile, avec des gants. À l’aise sur des fonctions simples, mais n’expérimente pas, pas un geek. Parle français, mais ce n’est pas sa langue maternelle. Je peux me représenter mon « héros », ici Victor, ou Indiana Jones pour ceux qui préfèrent. Photo d’un chef de chantier en casque et gilet orange, son téléphone à la main, devant un immeuble en construction.
14 Je veux : quelle action ou quel comportement ? Victor veut passer une commande de béton de toute urgence pour son chantier. Il veut appuyer sur le bouton bleu de son téléphone depuis l’écran d’accueil. Mon héros Indiana Jones veut trouver le Graal. La phrase sur le bouton bleu est barrée de deux grandes croix.
15 Je veux : quelle action ou quel comportement ? On parle bien d’une action liée au métier de Victor, et non liée à une application en soi. Si on n’arrive pas à formuler en dehors de l’application l’action de Victor, est-ce qu’elle existe vraiment ?
16 Afin de : le bénéfice métier. 1. Pourquoi Victor doit passer une commande de toute urgence ? Parce qu’il lui manque 10 m² pour finir la dalle maintenant.
17 Scénario 1. Afin de : le bénéfice métier. 2. Pourquoi veut-il finir sa dalle maintenant ? Parce que le béton déjà coulé va commencer à sécher dans 45 minutes, et s’il n’est pas unifié, il faudra tout casser et recommencer. 3. Pourquoi se retrouve-t-il dans cette situation de dernière minute ? Parce qu’en coulant, il s’est rendu compte que la dalle a une épaisseur réelle de 22 cm au lieu des 20 cm théoriques.
18 Scénario 1. Afin de : le bénéfice métier. 4. Pourquoi cette urgence devient-elle un problème de temps critique ? Parce qu’il doit d’abord vérifier quel fournisseur peut livrer dans les 30 minutes : son fournisseur habituel est à 45 minutes, mais peut-être qu’un concurrent plus proche a du stock… 5. Pourquoi l’information s’est perdue ? Parce que le téléphone ne trace pas le contenu des échanges.
19 Scénario 2. Afin de : le bénéfice métier. 2. Pourquoi il lui manque 10 m² de béton ? Parce que la quantité initialement commandée n’était pas suffisante. 3. Pourquoi la quantité commandée n’était pas suffisante ? Parce que le métrage du chantier a été ajusté en dernière minute, et la commande n’a pas été mise à jour.
20 Scénario 2. Afin de : le bénéfice métier. 4. Pourquoi la commande n’a pas été mise à jour ? Parce que la communication entre le fournisseur et le chantier s’est faite par téléphone, et l’information s’est perdue. 5. Pourquoi l’information s’est perdue ? Parce que le téléphone ne trace pas le contenu des échanges.
21 Le besoin n’est pas uniquement « commander vite ». Le vrai besoin, c’est : pouvoir ajuster une commande simplement, dans les conditions réelles du chantier, avec de la traçabilité pour le chantier comme pour le fournisseur.
22 Alors, quelle solution coder pour Victor ?
23 Solutions. 1. Lui permettre de modifier sa commande directement depuis le chantier via une application mobile ? Oui : répond au besoin réel (gain de temps, simplicité, contexte d’usage). Logo d’iSYBUY.
24 Solutions. 2. Créer une alerte automatique quand une quantité paraît incohérente avec la surface déclarée. Oui : aide à anticiper, évite les urgences sans alourdir le flux.
25 Solutions. 3. Ajouter une validation avant chaque commande pour éviter les erreurs. Peut-être, mais apporte aussi de la lenteur, plus de contraintes. Adapté au rythme terrain quand il faut une commande en urgence ?
26 Les 5 pourquoi : remonter à la racine du besoin, découvrir la vraie valeur pour l’utilisateur final, mettre en place une solution pérenne. Et pour ça, ne pas hésiter à parler aux utilisateurs…
27 Partie 2 : prioriser.
28 Mais tout est toujours urgent ! Non ?
29 Plusieurs façons de prioriser.
30 MoSCoW, priorisation sur le fonctionnel : Must, Should, Could, Would. Must : indispensable pour livrer. Sans ça, la feature ne sert à rien.
31 Valeur / effort, simple et rapide. Estimer la valeur ou l’impact (du besoin) : pour l’utilisateur, pour le business… Estimer l’effort (de la solution envisagée) : de dev et de QA, de commercialisation… Une matrice à quatre cases, la valeur en hauteur, l’effort en largeur. Beaucoup de valeur et beaucoup d’effort : big bets et projets. Beaucoup de valeur, peu d’effort : quick win. Peu de valeur, beaucoup d’effort : une poubelle. Peu de valeur, peu d’effort : fill in. La valeur pour l’utilisateur est notée en étoiles, celle pour le business en pièces d’euros.
32 R.I.C.E., score calculé. Scénario 1. Reach : 50 000 chefs de chantier. Multiplié par Impact : 5 € par utilisateur. Multiplié par Confidence : 50 %. Divisé par Effort : 500 jours-homme, soit 25 k€. 50 k × 5 × 50 % ÷ 25 k = 5.
33 R.I.C.E., plus « précis ». Scénario 2. Reach, la portée (nombre d’utilisateurs) : 50 000 chefs de chantier. Impact, le gain estimé par utilisateur : 5 €. Confidence, la confiance dans la solution : 50 %. Effort, l’estimation de l’effort : 500 jours-homme, soit 25 k€. 50 k × 5 × 50 % ÷ 25 k = 5.
34 Mais tout est toujours urgent !