Mes premiers pas PO

Communauté Scrum Life
1

Bonjour à tous,

Après plusieurs années d’expérience dans la gestion de projet industriel et de service, je cherche à m’orienter maintenant dans le secteur digital, et je vise en particulier le poste de PO car je suis très attirée par l’agilité.

En attendant de trouver un travail, je suis PO stagiaire depuis une semaine dans un incubateur. J’aimerais partager avec vous mes premiers pas. N’hésitez pas à me donner vos feedback afin que je puisse ajuster dans la posture.

Je serai en charge de deux projets. Pour le deuxième, je vais vous raconter ultérieurement, car je vais commencer que jeudi prochain mais déjà pas mal de choses à raconter avec le premier.

Le contexte du projet: Un groupe de développeurs en incubateur a constaté que la plupart des projets développés dans ce dispositif n’ont pas la visibilité qu’ils méritent. Soit ils restent inachevés lorsque les personnes impliquées quittent l’incubateur après avoir trouvé du travail, soit ils sont terminés mais ne sont pas assez valorisés pour être commercialisés.

Pour remédier à ce problème, ce groupe de développeurs a décidé de développer Tree-up, une plateforme qui permettra aux développeurs de collaborer, de promouvoir leurs applications et de trouver des sponsors ou des investisseurs pour les soutenir. Les entreprises et les investisseurs auront également accès à la plateforme pour trouver des projets prometteurs et des développeurs talentueux.

C’est un groupe de 6 développeurs qui sont eux-mêmes porteur du projet et ils ont tous envie de créer plein de fonctionnalités. Lors de mon premier contact avec l’équipe, j’ai été noyée non seulement par les imaginations abondantes, mais aussi par des notes éparpillées, les premiers draf de un peu tout dans tous les outils…

J’ai passé les premiers jours à leur expliquer le fonctionnement du Scrum, et à structurer les documents tout en prenant en main le backlog. J’ai créé des personas pour les aider à structurer les idées, à prioriser les fonctionnalités avec le user story mapping.
Je suis aussi en charge d’animation des différentes cérémonies. Lors de mon premier poker planning, je trouve que ça a pris un peu trop de temps. Et il y a quelques techniques que les développeurs ne maîtrisent pas, ils ont passé beaucoup de temps à discuter entre eux, puis aller chercher le Teach lead, puis même avec des explications qu’ils ont reçu, ils ont quand même passé un certain temps avant d’arriver à trouver un chiffre en consensus. Auriez-vous des conseils pour que cela puisse mieux passer la prochaine fois ? (je précise que j’ai détaillé les périmètres, les critères d’acceptation, DoD et les scénarios de test au mieux que je peux)

Dans l’ensemble je trouve qu’il passe beaucoup de temps pour décider des choses. Comme le projet les tient tout à cœur, et ils sont 6, il passent parfois trop de temps à discuter quelque chose insignifiante (par exemple la couleur ou la taille d’un bouton), et à chaque fois j’essaye de jouer le rôle de facilitateur anglais orienté vers ce qui est le plus prioritaire à faire.

Après avoir fait le tour des différents documents qu’ils ont partagé, je concentre maintenant sur Miro et Jira, je donne des suggestions de temps en temps sur Figma, et je laisse complètement la main sur Gitlab et les autres plateformes qu’ils travaillent du côté technique.

Pour l’instant on vient d’attaquer le sprint N°1, et les 6 sont très motivés avec un niveau de confiance au maximum. Je croise les doigts pour que ça reste !

2

Bonjour,

Quelques questions qui pourraient t’aider :

  • Est-ce que les développeurs ont découvert les US en sprint planning ?
  • Est-il possible de travailler en amont du sprint planning avec eux pour discuter des US, isoler les sujets techniques compliqués, découper les US en éléments plus petits (cf. Ateliers d’affinage) ?
  • Arrives-tu en sprint planning avec plutôt une liste d’US à développeur ce qui peut faire peur aux développeurs qui veulent se rassurer sur le fait de pouvoir tout faire ?
  • Arrives-tu plutôt avec un objectif de valeur à atteindre, ce qui faciliterait le choix des développeurs à sélectionner les US qui peuvent répondre à cet objectif ?
  • As-tu pu expliquer à l’équipe que ce qui comptait était plus de se fixer un objectif atteignable que de s’engager à réaliser entièrement des US et tous ses critères d’acceptation ?

Tu as plutôt un intérêt en tant que PO a avoir un logiciel qui évolue rapidement avec de la valeur. Mais tu n’as pas besoin que tous les critères d’acceptation prévus soient réalisés. Les US peuvent être découpées, certains sujets pris plus tard parce que trop techniques.
Avec cela comme paradigme, ça doit dégonfler l’enjeu de l’estimation en poker planning pour l’équipe. L’estimation doit presque là pour savoir si le sujet est assez petit pour pouvoir être sélectionné et livré vite pour prendre du feedback et apporter de la valeur.
Egalement, il y a des sujets qui devront aussi être débattus pendant le sprint par l’équipe, tout n’est pas à voir pendant le sprint planning. Par exemple, si le choix du bouton est important, il faudra en discuter au moment de traiter l’US et s’assurer que le PO est dispo à ce moment là pour valider le choix de l’équipe.

C’est mes éléments de réponse, ça n’engage que moi, mais j’espère que ça aidera :slight_smile:

2 « J'aime »
3

En tant qu’ancien PM, il y a plein de bons outils, pratiques, activités de la gestion de projet à transmettre à l’équipe.

Et après, il faut bien apprendre à « lâcher prise », laisser l’équipe (se) prendre en main. Laisser l’équipe construire, proposer, imaginer, …

PO c’est écouter, rassembler, comparer, ordonner. supposer, reformuler…

Je reste convaincu par la genèse du PO. Au sein de l’équipe, il représente l’utilisateur. Il incarne un persona vivant. Mais il le fait en s’outillant pour écouter, observer, analyser les vrais utilisateurs.

La première chose qui m’irrite généralement dans une équipe, c’est quand j’entends que le PO « VALIDE » le travail de l’équipe. C’est une horreur que je vois dans beaucoup de DOD. Il n’y a pas plus infantilisant et déresponsabilisant pour les membres de l’équipe. C’est d’ailleurs le même problème avec les équipes QA « hors de l’équipe ».

J’ai toujours trouvé qu’un bon PO pourrait faire un bon Scrum master de secours.

Il a les connaissances et les réflexes pour endosser le rôle, mais aura la réserve de ne pas s’engager dans une double casquette schizophrénique (pour lui et pour l’équipe).

3 « J'aime »
4

C’est étrange de passer de gestion de projet à product owner… mais d’être en charge de projets.

Attention au mindset.

Un projet améliore une situation dans une période prévue avec des ressources (humaines, matérielles, et financières ) allouées. En scrum,… c’est un sprint.

Chaque sprint est un nouveau « projet ». On va juste essayer de garder d’un projet à l’autre ce qui est économique à garder (la même équipe qui tente de s’améliorer dans son auto-gestion)

Mais le but de chaque sprint est bien d’arriver à ce que ce soit le dernier. Le but n’est pas de découper un gros truc en petit et d’enchainer les petits morceaux, mais bien de s’arrêter dès que l’essentiel est là .(ce qui arrive bien plus tôt quand on a le focus sur ce qui apporte le plus de valeur le plus tôt … )

arriver à ce que ce soit le dernier
C’est un fameux harakiri d’équipe, ça. ?

Ben non parce qu’on pourra alors renouveler l’expérience avec un nouveau PRODUIT et se lancer dans une série de nouveaux projets-sprint afin d’offrir aux utilisateurs un autre PRODUIT à valeur forte pour lui. Et ne pas se laisser tenter par tirer sur la ficelle en laissant le précédent sous respirateur artificiel.

3 « J'aime »
5

Leur demander 3 x la même chose, mais de manière différente ?

1 - Leur demander pourquoi et pour quoi ces fonctionnalités
2 - leur demander pour que l’utilisateur puisse faire « quoi » ? (le afin que de la user story)
3 - leur demander "quel nouveau comportement (bénéfique) vous voudriez voir apparaitre chez les utilisateurs.

Quand on a la réponse à la troisième, on peut oublier les réponses des questions 1 et 2, même si l’équipe récupéra probablement ces réponses pendant la réalisation. Mais en tant que PO, se concentrer sur la réponse du 3. (et le dire, le montrer, à l’équipe, l’afficher dans le board.).
Mettre en place ce qu’il faut (analyse, métrique, test, …) pour valider ou invalider qu’on observe bien ce changement chez l’utilisateur, et que ça lui est bien bénéfique (directement ou indirectement)

Mon boulot de PO est d’ordonner le backlog et d’observer ce que les utilisateurs du produit disent et font des valeurs ajoutées, livrées par l’équipe.

Ceci étant, je trouve que tu as un contexte riche. Il est plus facile de « canaliser » une bande d’hyper motivés, que d’allumer de la motivation dans une bande de bagnard qui n’a pas choisi d’être là.

2 « J'aime »
6

Merci à Christophe et Nicolas de m’avoir répondu. Et surtout pour vos conseils

Pour le premier sprint, j’ai fait des choses un peu à l’envers. Je m’explique : à partir du US mapping qu’on a défini ensemble, je mets en avance une poignée des fonctionnalités qui me semble les plus prioritaires et je laisse équipe décider ce qu’elle veut prendre pour le sprint 1.
Puis on a évalué celles choisies pour se servir des valeurs vôtés cette fois ci comme une référence pour la prochaine fois. On s’est dit, sprint 1, c’est de l’expérience, c’est de l’apprentissage. Pourtant le vote a été compliqué quand même. La prochaine fois, on doit servir de cette expérience pour voter mieux, et voter plus.
Et pour cela, je fais de mon mieux pour avoir un backlog bien carré , bien détaillé.
Ces jours ci, ils sont focus dans la recherche d’une solution technique qu’ils ne maîtrisent pas encore bien, la confiance baisse un peu mais je suis que dès qu’ils auront compris comment ça fonctionne, ça va repartir et ils sont toujours motivés, donc je reste confiance dans l’atteinte du sprint goal

7

Je commence le projet 2 aujourd’hui et ça a l’'air plus compliqué que le premier.

Une équipe de 4 dev + un testeur a la mission de développer le site e-commerce d’une boutique dont le testeur est propriétaire.

Il vend depuis 6 mois sur Etsy et profite le cadre de l’incubateur pour faire son site web.

Il vend tout et n’importe quoi qu’il trouve sympa. Pas de public cible. Il n’a pas de stock, mais ils ne fait pas de drop shipping non plus. Quand il a une commande, il commande à son tour chez le fournisseur, se fait livrer chez lui, vérifie l’article puis livrer chez le client . Délai de livraison long, non maîtrisé. → je me demande comment créer un site pertinent si on ne sait pas quel est notre audience cible. Je l’ai proposé de l’épauler dans une étude de marché et la recherche d’identification (ce qu’il ne l’a jamais fait avant), ainsi qu’une analyse des données clientèle des ventes qu’il a pu réaliser pendant ces derniers mois en fin de déterminer son segment. Je l’ai fait parce que sinon j’ai l’impression de construire une maison sans fondation, mais cela me semble éloigner des missions d’un PO. Que faites-vous à ma place ?

Quant à son site web, il ne veut pas exactement ce qu’il veut et change avis régulièrement et cela agace les développeurs qui doivent modifier leur travail régulièrement.
L’ambiance dans l’équipe n’est pas top. J’ai l’impression que les développeurs collaborent tant bien que mal ensemble, mais la relation avec le porteur du projet est vraiment mauvais. Maintenant j’interviens entre les deux. Soit je gère bien la situation et la tension sera moins forte, soit je me retrouve entre les deux feux.

La motivation de l’équipe est basse. Aucune organisation dans le backlog. Ils mettent des dizaines de fonctionnalités dans le sprint et terminer le sprint avec une poignée de fonctionnalités que personne a touché, et plusieurs en cours de développement, plusieurs tests en cours, plusieurs bugs à corriger, et très peu terminé terminé. L’équipe est découragée par la quantité de travail et ne voit pas le bout. Pour le prochain sprint, on les a dit de ne pas prendre de nouvelles fonctionnalités, juste terminé ceux qui sont en cours et je vais profiter ce temps-là pour faire un tri dans leur backlog (mais ils en ont une bonne centaine, ça va me prendre un moment :smiley: )

La situation n’est pas simple mais je trouve que challeging et je ferai le nécessaire pour que d’ici quelques sprint j’aurais deux équipes motivés avec des projets qui avancent régulièrement.

8

A mon sens, tu es dans ton rôle car le PO est à la croisée des chemins. En tant que PO tu dois souvent jouer les équilibristes entre la volonté du client et le fait que le PO doit « protéger » son équipe de dev que l’agilité mal maîtrisée peut cramer.

Ton rôle est donc de comprendre le besoin du client, qui la plupart du temps, croit savoir ce qu’il veut mais n’en sait rien et arbitrer sur la pertinence ou non d’instruire ce besoin. C’est toute la difficulté du rôle (et sa raison d’être). Il faut guider ton client vers des réponses par la discovery, les maquettes et parfois en acceptant de tirer des enseignements des choix de dev foireux (en faisant en sorte que ce soit le chemin le moins coûteux pour tout le monde). Et parfois, résister à la pression.

Il ne faut pas négliger la dimension psychologique dans le rôle de PO car même si ton client à l’air agaçant, il y a sans doute une raison. Il peut avoir peur de se lancer vraiment, il ne sait pas par quel bout prendre le sujet, il n’y connaît rien, il ne se rend pas compte de ce que ca implique côté dev, il n’arrive pas à se projeter dans une idée abstraite de ce que pourrait être le site etc. C’est à toi de l’accompagner pour lever ces problèmes car sinon ça va être très désagréable pour tout le monde et pour toi en premier lieu vu que tu vas te retrouver au milieu du mécontentement du client et des dév!

Pour les dév, ils vont se motiver tout seuls quand ils auront l’impression d’être respectés en n’étant pas pris pour des machines et lorsqu’ils seront prioritaires sur les demandes exagérées des clients. Si en plus il savent où ils vont et pourquoi ils font ça, ils vont même faire des propositions!

En fait, on bosse plus sur de l’humain que sur la technologie elle-même. Le plus dur c’est quand il y a de la politique interne car là, on est loin d’avoir toutes les cartes.

1 « J'aime »
9

Je reviens vous raconter la suite de mon stage.

On m’a confié un 3e projet il y a quelques jours. L’entreprise lance une nouvelle activité de portage salarial et il faut créé une plateforme permettant automatiser la création des contrats, des fiches de paie, ordre de mission…

Tous les jours, je suis ravie d’apprendre des nouvelles choses. La communication passe bien. J’arrive à les adhérer au projet, la motivation est améliorée. On a commencé par des tâches simples qui les font gagner en confiance. Ils m’expliquent des choses techniques et je leur explique tout ce qui tourne autour de l’agilité, le fonctionnement des sprint…

J’aimerais vous demander, où je peux trouver des idées de serious game pour sensibiliser mes équipes sur les rituels d’agile ? Il faut que le jeux est réalisable en ligne car les 3 équipes sont toutes en full remote .

J’aimerais savoir aussi, un PO est censé de pouvoir gérer comment de projet en même temps ? Parce que là, je suis complètement sous l’eau, au point qu’une bonne partie de mes soirées et WE y passent. Je me questionne si cela est normale ou c’est parce-que je manque d’efficacité ?

10

Bonjour Hanh,

Je suis circonspect par rapport à ce que tu nous présentes…
Ce qui me gêne les plus c’est la confusion des genres…

« 6 développeurs qui […] ont tous envie de créer plein de fonctionnalités »
« Je suis aussi en charge d’animation des différentes cérémonies. »
« il passent parfois trop de temps à discuter quelque chose insignifiante (par exemple la couleur ou la taille d’un bouton) »
" je laisse équipe décider ce qu’elle veut prendre pour le sprint 1"
" trouver des idées de serious game pour sensibiliser mes équipes sur les rituels d’agile ?"

Le PO est le représentant du métier (le client) au sein de l’équipe Scrum. Sa raison d’être, c’est de rédiger les US nécessaire pour délivrer les fonctionnalités attendues par le client et de les prioriser afin de délivrer la meilleure valeur. C’est lui qui pilote la « Definition of Done », après débat avec l’équipe Scrum

Dans ce que tu expliques, tu recouvres aussi (ou surtout ?) le rôle de Scrum Master, puisque tu animes toutes les cérémonies, que tu organises des team building, etc …

Je bondis un peu quand je lis que les DEV « choisissent ce qu’ils vont prendre dans le Sprint » ou qu’ils débattent de la couleur ou la forme du bouton. Certes il doit y avoir discussion, mais c’est le PO qui arbitre quand les DEV ont exposés avantages / inconvénients des différents choix. Durée max : 2 mn.

C’est la dimension « arbitre » que je ne sens pas dans tous tes récits. Le PO est avant tout un expert métier, capable de canaliser à la fois le donneur d’ordre et les Dev, comme l’explique aussi @ALO au dessus. Il est assisté par le SM qui rappelle (martelle) les bonnes pratiques de rédaction/découpage des US, qui s’assure qu’elle sont correctement comprises, pesées, … avant d’être embarquées (ou pas) en Sprint planning.

Je m’interroge sincèrement sur le rôle qui t’es confié. Penses tu pouvoir être en quelques semaines expert métier sur des sujets aussi éloignés qu’une plateforme collaborative, une boutique en ligne et une appli RH … ? C’est pas donné, même à un PO senior… En d’autre termes, est-ce que l’on ne t’envoie pas au casse pipe avec ce rôle clé, avec tout le respect que je te dois ?

11

Bonjour Hanh,
Non je confirme, ce n’est pas un manque d’efficacité.
Un rôle de PO sur un produit avec une équipe est déjà un rôle à plein temps. (déjà une bonne partie des nouveaux PO se sentent sous l’eau dans ce cas de figure dans mon entreprise)
Un rôle de PO sur deux produits avec deux équipes, le gage de grande efficacité de quelqu’un d’expérimenté et très à l’aise.
3 produits extrêmement différents et 3 équipes en étant débutante : :skull_and_crossbones: attention danger ! Je te conseille d’alerter de suite ton employeur que ça risque de ne pas passer ! Fais attention à toi surtout.

12

Waouh :face_with_spiral_eyes: 3 équipes pour un stage ? Je suis impressionné par le volume de travail qu’on te confie…
De plus, quand on croise que ton rôle n’a pas l’air très clair entre un poste de SM ou de PO

13

@arkalezard @Carole_G @Norbert merci d’avoir lu mes longs messages et merci pour vos avis.

Il est clair que je ne suis pas dans un organisme mature en agilité ou les rôles sont clairement définis. Cependant, je suis aspirante PO, et ce stage non rémunéré est tout ce que je trouve pour l’instant. Donc je me pose même pas la question si la situation est casse-pipe, ce qui m’importe et comment tirer meilleur partie de cette expérience pour me monter en compétence rapidement. Et sur ce point, je m’inspire beaucoup de ce qui est échangé sur ce forum, de vos feedback…
Mon but est d’apprendre le plus de choses rapidement et trouver un travail.

J’ai toujours travaillé dans les entreprises qui nous imposent de forte pression, de nous faire naviguer dans les eaux troubles, de nous faire porter les plus de casquette possible… Ni la charge, ni la complexité de la situation me font peur. Dans l’entreprise que je suis actuel, il n’y a pas de SM, si je ne porte pas cette casquette, personne ne fera. Et honnêtement ça me fait autant plaisir d’effectuer les tâches de SM que les tâches de PO. Et ça va aussi dans mes personnalités, j’ai envie avoir le travail fait, sans trop poser la question si c’est à moi de faire.

Lors de cette semaine, ça passe merveilleusement bien avec mes deux premières équipes. La première commence à monter en compétence très rapidement, habitué à travailler ensemble, grande motivation, bonne cohérence. La deuxième à un peu plus de mal techniquement et quelques membres traversent des situations personne n’est difficile, mais elle avance à son rythme et tout le monde essaie de persévérer. Ma relation avec ces deux groupes passe bien, il respectent mes arbitrages. Depuis que j’ai mis en place la météo d’esprit, j’ai l’impression que les équipes se communiquent encore mieux.

14

Par contre, j’ai pas mal de soucis avec le 3e équipe et j’aurais bien aimé avoir vos conseils pour savoir ce que je dois faire. Il s’agit de construire une plate-forme le portage salarial. Les clients sont les directeurs (Ils sont 3 et chacun a sa spécialité). L’Équipe Dev sont des étudiants ingénieurs en stage fin d’études, ils sont tous basés dans les pays maghrébins.

  • les clients m’ont dit qu’il faut livrer le MVP le plus rapidement possible et n’hésite pas à les impliquer dans le process de développement. Cependant, ça fait plus une semaine que je demande des infos complémentaires pour le Discovery, avec des relances, mais j’attends encore les documents…

  • on me demande de montrer une maquette rapidement mais quand je demande d’avoir l’aide d’un designer, ma demande se trouve passe en ping-pong d’une équipe à l’autre, et je finis par devoir réaliser moi-même cette maquette la veille de la Réunion. Les directeurs ça va très bien que je ai demandé avoir cette ressource, ils n’ont pas mis ça à ma disposition mais ils sont contents d’avoir des maquettes de moi.

  • ça fait plusieurs jours que je voir que les dev sont assez junior en technique bien qu’ils sont en Bac+5 informatique, j’ai demandé aux tech leads de voir s’il y a des points techniques à briefer / préparer avec l’Équipe dev, ils ont dit que tout est ok, et cet après-midi, en pleine poker planning, 2 tech lead débarquent pour dire directement aux dev qu’il faut tout mettre en standby, ils vont donner des exercices aux dev pour qu’ils s’entrainent avant et que sinon, ca sert à rien de commencer un sprint, ils vont rien produire… je suis d’accord sur ce dernier point, mais pourquoi on m’a jamais dit avant ?!? Et j’aurais préféré qu’ils me préviennent avant au lieu de faire comme ça au milieu de mon planning. ils me previendront quand ils sont techniquement prets, mais ne refusent de me donner une visibilité concernant le délai nécessaire pour les faire monter en compétence

  • les dev ont beaucoup de problèmes de discipline. Beaucoup de retard (jusqu’à une heure de retard), quand on leur explique que des choses, ils n’écoutent pas et reposent la question juste derrière (à plusieurs reprises), certains sont des têtu et veulent toujours avoir le dernier mot même si le reste de l’équipe lui explique l’inverse, en pleine réunion, ils se permettent de switcher en arabe… Ça fait des jours qu’on est ensemble, j’arrive petit à petit à redresser cette situation mais encore du travail à faire (et c’est pénible !)

  • ils parlent tout convenablement le français, mais parfois, quand on rentre dans les fonctionnalités nécessitant une certaine connaissance générale (en contrat de travail, les CRA, les fiches de paie…) ils ne comprennent pas tout. Seulement une ou deux personnes de l’équipe comprennent même si j’ai expliqué trois fois, il faut que je leur donne 10 mn pour qu’ils s’expliquent entre eux en arabe, puis quand on rebascule en français, je dois demander ceux qui n’ont pas compris d’expliquer le problème de leur propre mot pour vérifier qu’ils ont bien compris. Parfois ce n’est pas gagné, et ça reparte pour un second tour en arabe, et une nouvelle vérification derrière…Bref, beaucoup d’énergie et temps déployé !!!

  • j’ai demandé les directeurs de statuer sur la gouvernance du projet (point Régulier, qui contact qui, process …) mais j’attends toujours

Pourriez-vous me conseiller Quel est la meilleure posture à tenir pour bien gérer cette situation ?
Merci à tous et bonne soirée

15

Bonjour tout le monde,

Je fais face à de nouveaux défis dans mes projets et j’aimerais solliciter l’avis de la communauté. Pour plus de clarté, je vais créer des sujets distincts pour chaque problème et j’espère que vous pourrez partager vos idées et vos suggestions.

16

C’est flippant quand même
Pense avant tout à te protéger toi, ça semble un environnement pas facile

17

@nicobiot Merci à ta bienveillance.
J’ai envie de devenir PO, je suis hyper motivée et résiliente. Mon objectif est de, malgré des conditions pas très favorable, tirer le plus d’expérience de cette période

18

Il est important et indispensable de se focaliser sur un seul objectif.

Tu dois décider de travailler sur 1 seul objectif donc renoncer aux autres.
« décider c’est reconncer »

C’est avoir le courage de dire « non ».

Un retour aux sources ?

19

Je ferais personnellement assez gaffe aux informations venant de monsieur Hollub. Notamment pour sa compréhension parcellaire de Scrum et du design de produit/solution. C’est notamment la personne qui m’a soutenu mordicus sur Twitter qu’il suffit de demander au client pour savoir ce dont il a besoin… =/

Dans le genre mensonge et vérité parcellaire…

20

@Samuel_Abiassi Je ne comprends pas, le twitte partagé ne correspond pas à ton message.