Christopher Parola - Comment construire une équipe produit efficace (FR)

Bonjour tout le monde. Bonjour, bonjour, bonjour. Un grand merci à tous les organisateurs de la Floconférence de m'avoir fait venir aujourd'hui. Je suis ravi, ça fait, ben je pense comme beaucoup de personnes assez longtemps que j'ai pas vu autant de personnes dans une salle et du coup je suis très heureux, un peu ému, enfin voilà un mélange de sentiments. Je suis très très très content de pouvoir vous parler aujourd'hui d'un sujet qui me tient vraiment à cœur sous ce titre un peu racoleur, on pourrait le dire, comment construire une équipe produit efficace et adaptée à vos défis. Donc on va parler de produits, on va parler de choses qui s'appliquent à toutes les équipes, de choses qui ne s'appliquent qu'à l'équipe produit. Je suis conscient qu'il est 11h50, que vous allez avoir faim pendant la présentation. Donc il y aura des moments de grands sport où vous allez lever vos mains parce que je poserai des questions et je compte sur vous, si vous ne le faites pas ça va devenir très très très compliqué pour moi. Vous avez encore de l'énergie, c'est bon ? Génial, merci. Alors moi, je n'arrive pas à passer mes slides. Ça marchait, voilà. Donc, je suis Christopher Parola, je suis Chief Product Officer chez Usign. Vous connaissez peut-être Usign, c'est une solution de signature électronique. Je parlerai un petit peu de l'exemple de Usign, pas tant pour vous vendre les merveilles qu'on fait en signature électronique, même si on en fait des pas mal, mais surtout pour vous expliquer la croissance de l'organisation et ce qu'on cherche à mettre en œuvre. J'ai été Chief Product Officer de Meilleurs Agents. J'ai mis les chiffres à côté, c'est les tailles des équipes produits. Donc premier chiffre quand j'arrive dans la boîte et dernier chiffre, soit quand j'y suis encore chez YouSign, soit quand je pars. Donc chez Meilleurs Agents ça a fait du 1 à 40, chez YouSign ça a fait du 4 à 25. Je vous dis pas ça pour la gloire mais juste pour vous donner une idée aussi des tailles d'équipes dont je parle dans ce que je vais vous raconter juste après. Si vous voulez qu'on garde contact après, vous pourrez me retrouver sur Twitter, sur LinkedIn, sur un petit site web, n'hésitez pas, ce sera avec plaisir d'échanger avec vous. Alors construire une équipe produit, bah c'est facile, tout le monde a envie de faire du produit. Alors je vous ai mis ici un petit extrait, c'est un extrait du baromètre de la Product Conference, vous connaissez peut-être cette conférence, où on pose la question à des product managers et des gens qui travaillent dans le produit, je vais dire product people assez régulièrement. Puisqu'on a plein de métiers, on le verra juste après, on leur dit où est-ce que vous voulez travailler en France. Et ils répondent Blablacar, Alan, Doctorlib, Backmarket et j'en passe. Vous connaissez, tout le monde connaît ces entreprises ? Est-ce que tout le monde connaît quelqu'un qui travaille au produit dans une de ces entreprises ? Super. Mais moi aussi et quand je parle avec eux, c'est assez fascinant de se rendre compte à quel point le product manager chez Alan a un job qui n'a rien à voir du tout avec le product manager chez Doctorlib, rien à voir avec Backmarket, rien à voir avec Blablacar. En fait, ils font tous des métiers totalement différents et ça c'est assez fascinant. Et c'est assez fascinant surtout quand on se projette sur des métiers un peu plus communs, alors là je vous ai mis une photo de de boucherie, ça fera marrer les organisateurs, je les ai embêté pour leur dire je veux des repas végétariens pendant les déjeuners. Mais mes grands-parents des deux côtés de ma famille étaient bouchers-charcutiers, j'aime bien penser à eux de temps en temps quand je pense à ce qu'on fait nous aussi parce qu'en fait quand vous vous mettez dans leur basket. On se projette un peu sur ce type de métier, le parcours carrière, la carrière, vous êtes boucher dans une boucherie ou dans une autre boucherie, il y a des petites variations mais ça se ressemble quand même énormément. Et en fait, c'est un peu une caractéristique d'énormément de métiers physiques dans lesquels finalement, on se pose pas trop la question, aujourd'hui je suis coach agile, demain est-ce que je dois me définir coach Lin, est-ce que je dois parler de Kanban, est-ce que je dois parler de Scrum, est-ce que maintenant j'ai des nouvelles compétences, je suis product manager, en fait je suis plus PO, ah ben non, en fait, ça change encore. C'est hyper fascinant, je trouve l'industrie dans laquelle on est, c'est ce qui rend c'est la beauté de la chose mais ce qui rend les choses aussi très complexes. Et donc le message que je veux vous partager avec cette petite intro, c'est vous dire chaque organisation va avoir probablement sa propre définition des fonctions produits et c'est tout à fait normal. Et donc moi je vais pas vous raconter un framework ou ce genre de choses, je vais plutôt essayer de réfléchir avec vous aux questions qu'il faut se poser pour trouver la bonne organisation en fonction du défi qu'on a. Ça vous va ? Tant mieux, on peut plus changer. Donc, si on rentre dans le vif du sujet. La première chose qu'on va voir ensemble, c'est quelle équipe il vous faut pour répondre à votre défi. C'était ça dans dans mon titre, et en fait, on va commencer à définir le défi que vous rencontrez. Parce que ça n'a strictement rien à voir selon les types d'organisation et les tailles de boîtes. Je vais vous raconter le mien chez YouSign, ça vous parlera peut-être, peut-être certains se reconnaîtront. Donc chez YouSign, on a construit une phrase de mission. Je vais vous montrer plein de slides avec une phrase, vous qui connaissez le monde de l'entreprise, je vous laisse imaginer le nombre d'heures qu'on a passé pour pondre ces quelques mots sur un bout de papier. Donc ce qu'on fait, il y aura des slides en anglais aussi. Alors d'une parce qu'on est une société internationale, on est en Allemagne, en Italie, en Pologne en plus d'être en France, mais aussi parce que ça claque beaucoup plus en anglais qu'en français dans nos domaines, vous allez voir. Donc qu'est-ce qu'on fait ? We help European SMEs execute agreement in a fast and secure way, où on aide les PME TPE à contractualiser dans une de manière rapide et sécurisée. C'est ça qu'on fait chez YouSign. C'est ça qu'on fait chez YouSign. Et le problème, problème ou opportunité, c'est vous qui allez me dire, c'est qu'on n'est pas tout seul. Donc on est sur un marché où il y a plus de 100 acteurs de signature électronique en Europe, parce qu'il y a aussi les Américains qui viennent en Europe et c'est un marché qui est aussi hautement régulé. Donc en fait, il y a des organismes dans absolument tous les pays qui sont des organismes de contrôle. Donc on a une certification annuelle comme les organismes bancaires pour prouver que la signature électronique qu'on délivre a les bonnes notions ou les bonnes en tout cas, elle répond au bons critères. Alors je vous épargne toutes les normes évidemment, mais c'est juste pour vous donner un petit peu le dans quel marché on se situe aujourd'hui quand on parle de ces entreprises. Et du coup, on a produit une vision, on s'est dit pour battre la concurrence, ce qu'on va faire, c'est que nous on va donner une plateforme qui est sécurisée, qui fait du contract management, pas juste de la signature, ça veut dire qu'on va essayer d'avoir plus de propositions de valeur et pas une unique proposition de valeur et de donner la meilleure expérience utilisateur. Et finalement, notre seul différenciation sur un marché régulé où tout le monde a les mêmes niveaux de signature, où tout le monde propose le même service, ce sera l'expérience utilisateur. Voilà, ça c'est le défi qu'on s'est fixé. Quand j'étais chez Meilleurs Agents, on était aussi plutôt des outsiders parce que finalement les caractéristiques de boîte se ressemblent. J'arrive chez YouSign, on est une quarantaine de personnes, il y a une levée de fond qui vient de se faire, il y a 100 acteurs, il y a un géant américain que je ne vais pas citer pour ne pas lui faire plus de pub mais vous le connaissez et tout le monde nous confond avec lui en plus parce qu'on a tous les noms pareils, on fait de la signature électronique, on s'appelle tous sign quelque chose comme ça. Au moins c'est universel, signa. il y a une spécificité en Espagne. Euh mais donc du coup, on essaie de se différencier par l'expérience utilisateur. Donc marché très gros, marché avec beaucoup de monde et donc la première chose qu'on se dit, c'est on va avoir de la haute vélocité dans nos équipes et donc il faut absolument les organiser. De la manière qu'on pense être la mieux possible. Alors on a les squads, je vais pas vous apprendre ce que c'est, des équipes pluridisciplinaires auto-organisées. On aime bien les représenter comme ça. Puisque dans les squad, il y a des représentants de plein d'équipes différentes. D'ailleurs, quand vous demandez à quelqu'un d'une squad, dans quelle équipe il est, vous allez voir un product manager, il y a toujours un temps d'arrêt, est-ce qu'il faut qu'il dise qu'il est dans l'équipe produit ou est-ce qu'il faut qu'il dise qu'il est dans sa squad ? Et donc ça c'est plutôt d'ailleurs une caractéristique que ça prend bien la mayonnaise des squads quand on fait ça. Donc on a créé des squads et dans ces squads, donc on en a plusieurs, on a toutes les compétences pour être capable de livrer un produit de A à Z. Et je reviendrai après sur les métiers du produit, mais en gros, on va retrouver les product managers. Classique, product designer, engineering manager, des développeurs. Potentiellement de la quality assistance ou pas, ça va dépendre des types d'équipes et du product marketing management PMM que j'ai noté en part time. Vous avez déjà travaillé avec des product marketing manager ? Pas encore. Et ben on en reparle juste après, super. Et donc ces squads, l'idée c'est d'être capable de les organiser autour d'une thématique commune et qu'elles aient toutes les compétences pour livrer les fonctionnalités qu'elles font. Derrière ces équipes, on a en fait, c'est pas des clones, c'est pas juste une squad est une squad, c'est des différentes typologies de squad. Donc là normalement, il y a peut-être du vocabulaire que vous allez retrouver aussi dans ce que vous connaissez. On a trois types de squad chez YouSign, on les avait aussi chez Meilleurs Agents. On a un type de squad et je vais faire de droite à gauche, les platform team qui sont des équipes qui ont en fait un niveau de focus sur un projet technologique ou technique plutôt au long cours. Par exemple, chez YouSign, on a un moteur de signature. C'est là où il y a toute le c'est le cœur de la machine, le moteur de signature ne marche plus, il y a plus de service pour nos utilisateurs. C'est ce qu'on appelle une plateforme team chez nous. C'est pas une équipe qui a des enjeux de change régulier, c'est pas une équipe, c'est plutôt une équipe qui va avoir des projets sur 6 à 9 mois parce qu'il y a une nouvelle norme qui est sortie, il faut s'y adapter, elle est très bien documentée et en fait il faut faire le travail de la livrer. Ça veut pas dire qu'elle fera pas des choses itératives et incrémentales, mais ça veut dire qu'il y a pas besoin d'une force par exemple de product design ou de product management très orientée sur le lancement de nouveaux produits. C'est plutôt du delivery qu'il faut faire à cet endroit-là. On a un autre type d'équipe qu'on appelle les feature team, qui ont des équipes qui sont plutôt focalisées sur un scope fonctionnel comme leur nom l'indique, et on a un troisième type d'équipe qu'on appelle les impact team. Alors ça c'est un nom et je rends hommage à Nicolas Baron qui est pas avec moi, qui était CTO chez Meilleurs Agents et on s'est suivi chez YouSign donc qui est CTO chez YouSign. On continue de travailler ensemble et on a créé ce terme en 2017 pour essayer de dire aussi qu'il y avait des typologies d'équipes qui pouvaient être organisées non pas sur un périmètre fonctionnel, non pas sur un périmètre technologique, mais plutôt sur un périmètre d'objectifs chiffrés à atteindre. Ce qu'on ce que ça veut dire concrètement, c'est qu'on prend une équipe, je vous donne cet exemple qu'on a aujourd'hui. On a une application chez YouSign où on vend des licences, la licence d'entrée c'est 9 € par mois. Et aujourd'hui pour vendre une licence à 9 € par mois, on a un commercial qui appelle le client, lui fait une démo, lui explique plein de choses et cetera. Notre produit, c'est uploader un PDF et mettre une signature dessus donc c'est pas Rocket Science, ça nécessite pas une formation et un training dingue. Autant vous dire que quand on vend un plan à 9 € mais que ça a pris trois quatre jours de travail à un sales, l'équation économique, elle est pas terrible. Et donc du coup, de ce côté-là, on a envie d'aller faire ce qu'on appelle du self-serve, laisser l'utilisateur acheter par lui-même notre produit. On a une équipe à qui on a dit ton rôle, c'est que 15 % des transactions maintenant soient en self-serve, débrouille-toi et raconte-nous ce qu'il faut faire. Ça c'est ce que nous on appelle une impact team. Elle va pouvoir travailler sur tous les périmètres fonctionnels, elle va pouvoir appeler à l'aide d'autres équipes, des platform team, des feature team, mais elle a toutes les compétences pour décider de son plan pour atteindre cet objectif. Donc ça c'est toujours dans une quête en fait d'autonomie des équipes. Plutôt que d'avoir un comité exécutif qui va dire à l'équipe, on veut faire du self-service, on a pensé à tout, voilà ce qu'on va faire, on préfère dire à l'équipe qui est au contact des clients et des utilisateurs, organise-toi, tu as toutes les compétences pour le faire, recommande-nous un plan et après on le validera ou on l'invalidera au niveau du comité exécutif. Donc on change un petit peu le le paradigme ici. Du coup, bon, on a aussi un autre une autre façon d'organiser les équipes. Donc on a l'unité, la squad, ces squads sont organisées de trois façons différentes, platform, pardon, component, feature, impact team. Et ensuite, on va aussi les structurer en domaines. Donc on va essayer de découper quand même des thématiques de squad à un moment donné. Et ce que ça va donner, c'est des domaines en fait cohérents dans lesquels on va pouvoir avoir un leadership unique et par exemple, on n'a pas inventé la roue. Chez YouSign, on vend une application et une API, on a un domaine qui s'appelle API. Voilà, et donc du coup, c'est les gens qui travaillent plutôt sur la partie enrichissement de notre API. Mais ce qui est intéressant, c'est qu'ils utilisent exactement les mêmes services que les gens qui construisent la plateforme et donc ils sont les component team. Je vais vous montrer un schéma super simple parce que ça peut paraître compliqué. Alors la blague qu'on fait depuis 2017, c'est qu'on me dit il faut mettre des impact team partout, je vois plein de livres blancs sortir sur les impact team, j'étais chez des personnes qui les ont mis en place et qui m'ont demandé de venir à leur plénière pour expliquer pourquoi il fallait en mettre plus en place encore alors que ça marchait pas chez eux les impact team. Donc je voulais juste vous partager ça, évidemment, toutes les équipes ne doivent pas être organisées sur ce modèle-là. Ça va dépendre de la maturité de votre entreprise, ça va dépendre aussi de ce qu'elles ont à atteindre. Et donc pour vous montrer le schéma suivant, ça c'est l'organisation engineering and product chez YouSign. Donc ce que vous avez là, on va pas rentrer dans trop de de détails des noms d'équipes et cetera. En gros, ce que vous retrouvez en bas, c'est il faut vraiment voir ce qu'on retrouve en bas du slide, c'est le socle, c'est ce qu'on appelle les équipes transverses. On va retrouver les équipes infrastructure, les équipes data, les équipes qualité, les équipes product marketing. En fait, c'est tous les gens qui ne sont pas à temps plein dans une squad, mais qui viennent amener de l'expertise à un moment donné à une squad. Juste au-dessus, on a ce qu'on appelle les platform team qui sont nos équipes qui sont où on retrouve ici que des component team. C'est des équipes qui en fait travaillent sur un composant technologique et qu'elles fournissent à l'ensemble de l'entreprise. Donc par exemple, l'équipe qu'on appelle Engine, on l'a appelé comme ça parce que c'est vraiment le cœur, c'est c'est l'engine c'est le moteur de YouSign, ils fournissent des services aux autres équipes, les autres équipes le consomment, le jour où Engine ne fonctionne plus, il y a plus YouSign. Globalement, c'est ça le niveau de pression un petit peu qui est sur cette équipe. Et après, on a d'autres types d'équipes où là, on va retrouver quatre domaines. On a un domaine qu'on appelle intégration, c'est là où on retrouve tout ce qui est API, connecteur à des logiciels tiers, un domaine qu'on appelle le cœur dans lequel on va retrouver tout ce qui est sur l'application YouSign. Et on a aussi voulu faire de la diversification. Donc on a fait de l'acquisition d'entreprise pour les intégrer à YouSign et étendre ce qu'on faisait. Donc avant on faisait que de la signature, maintenant on fait aussi de la préparation de document et de l'archivage de documents. Et donc du coup, on a acheté des sociétés qu'on a mis dans YouSign mais qu'on a mis finalement dans un pot qui est un petit peu à côté du reste des équipes. Et tout à droite, on retrouve un domaine qu'on appelle scale dans lequel on va retrouver toutes les équipes qui contribuent à la croissance. Plutôt via du logiciel interne ou des processus. Et donc ça c'est un modèle d'organisation qui est assez simple finalement. Donc je fais exprès, je vous nomme pas des frameworks d'agilité à l'échelle ou ce genre de choses, mais vous retrouverez, je pense, des éléments dans ce que je vous montre là, mais en gros, on a fait très simple, on a huit squad. Équipe transverse, des des équipes plateforme, trois typologies de squad et basta, ça tourne comme ça. Et donc je vous l'ai mis là, je vais pas vous le redétailler mais ce qui est intéressant, c'est que c'est un modèle qui a marché aussi chez Meilleurs Agents. En fait, c'est exactement le même modèle. On a identifié qu'elle était le cœur du système. Chez Meilleurs Agents, c'était la plateforme de data, si elle ne marchait pas, il y avait plus de service qui était rendu, on l'a mis en bas en se disant c'est nos platform team et par-dessus, on a pluggé des équipes qui elles venaient consommer ses services. Tout roule jusque là ? OK. Donc du coup, on est sur un environnement ultra concurrentiel, on a défini les typologies d'équipe et d'organisation qu'il nous fallait. Maintenant, je vous propose qu'on rentre dans le vif du sujet, quelles compétences il nous faut dans une équipe produit pour travailler dans ce type de contexte. Donc on va commencer par les métiers. Les métiers dans une équipe produit, ils sont variés, il en sort à peu près un par an. Donc il y a des modes qui viennent, qui passent, qui repartent, c'est hyper intéressant. On a les product managers, après on parlera des product owner et des product manager une minute, si ça vous intéresse de d'alimenter un peu ce débat ensemble, c'est toujours rigolo. On a les product designers, product designer, c'est l'ancien terme, vous savez pendant très longtemps, il y avait les job desk qui avaient écrit UX/UI. Bon, c'est product designer, ils font les deux, ils vont aller faire la recherche utilisateur et aussi le design. Si vous voulez les mettre dans une dans une colère noire, dites-leur que on a des jolies couleurs grâce à eux sur ce type de slide. On a les product analyst, c'est ceux qui vont aider l'équipe produit à accéder à la donnée. C'est pas des ingénieurs en data, c'est pas eux qui construisent la BI de l'entreprise, mais c'est plutôt eux qui vont aller faire les analyses complexes. Il faut commencer à faire de l'analyse de cohorte sur des funnels d'acquisition croisés. Waouh, pas facile pour un product manager tout seul d'aller chercher cette data. Donc ils vont venir amener cette couche aux équipes dessus. Ensuite bon quality assistance, on a plutôt tendance à à connaître ces équipes. Product Ops, nouveau job, ils auraient pu l'appeler product coach. Dans la majorité des entreprises, Product Ops, l'idée c'est de se dire l'équipe produit doit apprendre des compétences pour bien faire son discovery et son delivery. Et du coup, on va faire rentrer des gens dans l'organisation pour leur apprendre comment faire de la recherche utilisateur, comment faire des interviews, comment creuser un un un lake de data et cetera. Et donc du coup, ça devient des équipes à part entière dans beaucoup d'organisations. Payfit par exemple, pour pour les citer parce qu'ils étaient sur la première première slide, ont une des plus grosses équipes de product ops en France. Et product marketing managers, c'est un peu le chaînon manquant. De la commercialisation de produit. C'est-à-dire que sans ces gens dans les équipes, aujourd'hui ce qu'on retrouve souvent dans les organisations, c'est une équipe produit qui fait un logiciel, une équipe marketing et sales qui va le mettre à disposition du marché et souvent la connaissance que les équipes produit vont acquérir sur le terrain en interrogeant des utilisateurs est un petit peu perdue à cette étape là. Donc en fait, on sait ce que veulent les utilisateurs, on connaît leur besoin, on a même réussi à le formuler selon les propres mots de l'utilisateur, mais on va pas du tout s'en servir pour le mettre à disposition de l'utilisateur. Et donc les équipes product marketing vont être très orientées en amont sur est-ce qu'il y a un marché pour mon produit et en aval, quand le produit est à disposition, sur est-ce que j'ai les bons canaux de distribution et d'adoption de mon produit. Les termes sont clairs pour tout le monde ? Top. Si quelqu'un n'est pas d'accord, vous pouvez lever la main et dire je m'insure, je ne suis pas d'accord. Donc, ce qui est important pour moi, c'est de vous partager ça, quand vous créez une équipe produit, vous avez vu tous ces jobs, la plus de la moitié sont hyper récents et datent de il y a moins de 5 ans, en plus ils évoluent énormément. Donc je vous ai mis une superbe photo du Big Bang. Pour moi, quand vous êtes à la tête d'une équipe produit, définir les compétences attendues dans cette équipe produit, c'est vraiment la naissance de l'équipe. C'est pas le recrutement, c'est pas les faire bosser ensemble sur une product vision et cetera, c'est définir ce que vous attendez d'eux. Puisqu'en fait, quand vous rejoignez une organisation produit aujourd'hui, c'est l'exemple que je vous prenais au tout début, vous n'avez aucune idée du job que vous allez faire en arrivant, aucune. Et donc définir ces compétences et les mettre à disposition de tout le monde, c'est permettre à l'ensemble des parties prenantes de cette équipe de se dire OK, quand je vais rejoindre YouSign ou Payfit ou Blablacar, c'est ça qu'on va attendre de moi. Alors comment est-ce qu'on définit ces compétences ? Avant de rentrer dedans, j'ai jamais parlé de product owner. Vous avez une préférence ? Qui est pour product owner dans les squad ? Product manager ? Les deux ? pour Big Bang. pour moi, quand vous êtes à la tête d'une équipe produit, définir les compétences attendues dans cette équipe produit, c'est vraiment la naissance de l'équipe. C'est pas le recrutement, c'est pas les faire bosser ensemble sur une product vision et cetera, c'est définir ce que vous attendez d'eux. Parce qu'en fait quand vous rejoignez une organisation produit aujourd'hui, c'est l'exemple que je vous prenais au tout début, vous n'avez aucune idée du job que vous allez faire en arrivant, aucune. Et donc définir ses compétences et les mettre à disposition de tout le monde, c'est permettre à l'ensemble des parties prenantes de cette équipe de se dire, OK, quand je vais rejoindre U sign ou Payfit ou Blablacar, c'est ça qu'on va attendre de moi. Alors, comment est-ce qu'on définit ces compétences ? Avant de rentrer dedans, j'ai jamais parlé de Product owner. Vous avez une préférence, qui est pour Product owner dans les squad ? Product manager ? Les deux ? Top. Je vous remercie pour ça. Je fais juste cette parenthèse parce que je la trouve intéressante, c'est un grand débat. Et je vous mets quelques phrases que euh que j'entends régulièrement et euh bon je suis désolé, je vais pas fermer ce débat d'ontologie et puis en plus je risque de m'attirer les foot de plein de gens qui savent où j'habite. Alors je vais pas je vais pas partager ça. Mais ce que je trouve intéressant, c'est qu'on on continue d'essayer de définir product owner, product manager. Souvent on les définit par une dichotomie en disant Product owner c'est un rôle, un rôle dans une équipe Scrum, Product manager c'est le métier, hyper vexant pour tous les gens qui sont Product owner je trouve, mais on entend énormément cette phrase dans les organisations aujourd'hui. Une autre phrase qu'on peut entendre, c'est Product owner c'est pour le delivery, Product manager c'est pour le Discovery. Pas plus tard que ce matin, je lisais le livre blanc d'une société de conseil qui travaille sur sur des sujets de product management et qui avait écrit ça dans son livre blanc. Et je trouvais ce ce modèle là intéressant, un peu facile, un peu risqué aussi parce que quand vous faites ça, ça veut globalement dire que vous êtes revenu à un cycle en V sans vraiment le dire. Vous avez les penseurs, ils vont vous filer un joli rapport et bonne chance pour le pour le livrer. Et donc c'est assez intéressant, mais bon c'est une tentative de clarification. Euh j'ai versé là-dedans aussi il y a quelques années donc je voilà je je m'inclus dans dans les gens qui disent ça. Et je vous partage cette définition parce que je la trouve assez belle et et qui finalement sort un peu du débat. C'est Melissa Perri. Vous connaissez peut-être Melissa Perri, elle a écrit un livre assez incroyable qui s'appelle Escaping The Build Trap. qui est un livre qui raconte une histoire, vous avez des noms de personnages et c'est assez marrant parce que vous pouvez changer les noms de personnages avec n'importe lequel de vos collègues et je suis sûr que c'est une situation vécue. qui a réussi à universaliser les difficultés qu'on a en entreprise. Et elle dit ça, elle dit le but pour un product manager, c'est tout simplement ça, réduire le risque en étant concentré sur l'apprentissage. Et j'aime bien cette phrase parce que je trouve qu'elle qu'elle comporte toutes les thématiques qu'on a dans ces métiers, la thématique du risque. En fait finalement, le product manager ou le product owner dans beaucoup d'organisations, il a pas le pouvoir de décision finale, c'est pas le CEO de son produit comme parfois on a pu le dire aussi. C'est quelqu'un qui doit réduire le risque et ma conviction personnelle, c'est que pour réduire le risque, il doit savoir à la fois le penser son produit mais à la fois le mettre dans les mains des utilisateurs et donc aller jusqu'au deliver. Voilà, ça vaut ce que ça vaut, mais j'espère que ça met un peu d'eau au moulin du sujet. Donc c'est pour ça que je vais parler que de Product Manager, mais c'est sans aucun jugement, ça englobe pour moi les deux jobs et voilà ce que j'attends quand je parle d'un Product Manager dans mes équipes. Alors, on va se construire un parcours carrière. Donc on a plein de compétences d'équipes produits. Bon déjà on va faire une première chose, on va construire des niveaux. Pour dire à la personne quand tu nous rejoins, tu sors d'école, bienvenue, tu es niveau 1. Puis quand tu seras super développé sur toutes tes compétences, tu seras niveau 5. Jusque là, assez simple. Système de niveau sur les types d'organisation que moi j'ai géré, donc jusqu'à 40, cinquantaine de Product people, honnêtement, 5 niveaux, c'est bien assez. Parce que des fois, on a envie de rentrer dans énormément de détails, d'avoir le niveau A, B, C, D, E, F et puis parfois, on a un product un career pass qui prend 15, 20 niveaux. Bon, c'est un peu complexe et puis après il faut l'utiliser au quotidien. Donc, bon courage pour expliquer à quelqu'un pourquoi il est niveau 18 et pas 19, quoi. C'est c'est pas évident sur ces organisations-là. Et chez Yousign, une particularité qu'on a mis, c'est un système de sous-niveau. Donc en fait, ce qu'on dit au collaborateur, c'est bienvenue dans l'équipe produit. Voilà les compétences qu'on va attendre, tu as 5 niveaux. Et les sous-niveaux, ils sont assez simples. En fait, quand tu veux être niveau 3 de notre parcours carrière, tu dois maîtriser au moins 50% des compétences du niveau 3. Quand tu les maîtrises, tu es 3.1. Si tu maîtrises 75% des compétences, tu es 3.2. 100% des compétences, tu es 3.3 et puis après tu pourras aller chercher le niveau 4. Ce qui est, alors ça vous va vous sembler basique hein, mais c'est vraiment important parce que ça permet aussi de déclarer quelque chose qui est que dans beaucoup d'organisations, on atteint le niveau d'après d'un parcours carrière et ensuite on doit faire ses preuves dans ce niveau. Donc par exemple, on vous dit bah voilà, vous êtes niveau 4, bienvenue dans l'organisation. J'attends de toi que tu prouves que tu as les compétences d'un niveau 4. Nous ce qu'on a choisi de faire, c'est plutôt dire tu es niveau 3.3. Tu vas passer du temps dans ce niveau. Une fois que tu le maîtriseras complètement, tu vas regarder le niveau 4 qui est devant toi. Tu vas regarder les compétences qu'il faut que tu développes, les développer et au moment où tu les as, tu passeras au niveau 4.1. Donc c'est une façon d'utiliser le parcours carrière. Bon, c'est assez généraliste hein, comme comme comme parcours carrière. Donc là, ce qu'il faut retenir, c'est pas forcément s'enflammer sur le nombre de niveaux et avoir une progression une progression régulière. L'autre question qu'on va se poser, qui est peut-être plus intéressante que celle des niveaux, ce qu'il vous faut des généralistes ou des spécialistes dans vos équipes. Et je vais m'arrêter une seconde là-dessus. Bon, généraliste, illustration l'homme orchestre. Il fait un peu de tout, il sait faire de tout. Spécialiste peut-être les les mélomanes auront reconnu Glenn Gould sur son piano qui qui est en train d'enregistrer les Goldberg Variation qui sont très belles. Euh vrai vrai vrai spécialiste, mais spécialiste tellement spécialisé qu'il ne joue qu'un compositeur. Donc ultra ultra spécialisé. Et je vous parle de ça aussi parce que aujourd'hui les parcours carrière qu'on va trouver dans le monde du produit encourage plutôt la spécialisation. Alors quand je parle de spécialiste, je vais peut-être m'arrêter là-tu une seconde. Vous regardez donc sortez de la salle après et regardez un peu les offres d'emploi de Product Manager. Vous aurez souvent préfixé ou suffixé quelque chose. Vous n'êtes pas juste Product Manager, vous êtes Product Manager API, Product Manager acquisition, Product Manager croissance, Product Manager scale et cetera. En fait, on a une certaine tendance dans les entreprises à se dire, j'ai besoin d'un Product Manager pour mon équipe qui travaille plutôt sur le composant à payer, donc je vais prendre quelqu'un qui a fait de la PI pendant 10 ans, le mettre là et ça va bien se passer. Donc c'est quelqu'un qui a développé des compétences très en profondeur sur son domaine, mais pas forcément sur tous les aspects du product management. Là où un généraliste va plutôt avoir un un skill set, donc un un set de compétences qui va être plutôt sur toutes les actions du product manager, qu'est-ce qu'un bon product manager doit savoir faire, pas forcément avoir travaillé des années sur une thématique en particulier, mais ce qui est intéressant, c'est que ce type de profil, vous pouvez le repositionner facilement dans vos équipes. Et donc je vous amène la réponse pour moi, en phase de construction d'une entreprise et dans un marché qui est très mouvant, il faut privilégier les généralistes. Pourquoi est-ce que je vous dis ça ? Parce que je l'ai vu plein de fois. Vous recrutez, donc vous montez votre squad, elle s'appelle API. Donc on dit qu'on travaille sur le composant API. Et vous recrutez un Product Manager spécialisé de l'API. Vous venez de prendre une décision peut-être sans vous en rendre compte, fondamentale, qui vient de dire que pour les 5 prochaines années devant vous, il y aura toujours du travail plus prioritaire que sur tous les autres sujets, sur l'API. C'est ça qu'on vient de définir parce qu'en fait on vient de se dire, il y a une partie de mon flux qui va être dédiée à la pays pour toujours. Et ça c'est une décision que souvent on fait un peu sans s'en rendre compte. Parce qu'on se dit OK, ben j'ai un composant, j'ai envie de le pousser très loin, j'ai envie de travailler beaucoup dessus et on se rend pas forcément compte qu'en prenant cette décision, on s'est engagé sur un chemin dans lequel on vient de décider de la priorité pour l'organisation de ce sujet par rapport aux autres. Parce que je sais pas si vous l'avez déjà vécu, mais prenez allez voir ce product manager API. Et puis tous les développeurs spécialisés dans les API qui adorent faire ça et cetera et dites-leur alors maintenant sur les six prochains mois, on a plutôt un problème sur l'acquisition. Donc on va tous vous prendre et vous faire bosser sur l'acquisition. Ça vous est déjà arrivé ce type de de choses à faire ? Ça a marché ? Je vois des coups ci, coups ça dans la salle. Bon, s'il y en a pour qui ça a marché, envoyez-moi un message juste après parce que je veux apprendre comment on fait. Moi ce que j'ai souvent vu, c'est des levées de boucliers, des gens qui disent jamais de la vie, moi je suis venu pour faire les API, c'est ma compétence, c'est ma spécialité. Je ne veux pas aller travailler sur le reste et même parfois, je n'ai pas les compétences généralistes pour aller regarder le sujet d'à côté. Et donc là, il y a un paradigme ici qui est hyper important pour moi et que je voulais vous partager aujourd'hui. Dans les phases où votre marché est vraiment mouvant et en fait quand on y pense, souvent l'agilité c'était une réponse à ça, c'était une réponse à évidemment maîtriser son delivery, de la prédictibilité et cetera mais aussi à être sur des domaines où finalement, on n'était pas sûr de ce qu'on allait construire et on voulait en voir des petits morceaux, les mettre à disposition des utilisateurs, apprendre et itérer dessus. Et donc quand vous figez votre organisation et que vous la déterminez, ça peut être très compliqué si vous partez sur des modèles de spécialistes. Donc ça c'est un c'est un retour que j'ai appris moi un peu à la dure parce que j'ai eu des équipes où évidemment, j'ai pris des spécialistes et ça a pas ça a pas collé. Alors, j'arrête pas de vous dire les compétences d'un généraliste, qu'est-ce que c'est ? On va parler d'un framework qui est super simple qui s'appelle le core framework. Il a le bon goût de s'appliquer à tous les métiers du produit, donc tous les parcours carrière que je fais dans mes équipes. utilise le Core Framework. Donc être product marketing manager, Core Framework. QA analyse, Core Framework. Product analyste, Core Framework. Core Framework, c'est assez simple. C'est un acronyme évidemment pour communication, organisation, recherche, exécution. Je vais prendre le job de Product Manager, on va un peu caricaturer, on va dire exécution des livrés, recherche Discovery. On parle souvent de ces deux termes et organisation communication, c'est souvent ce qu'on met dans l'espèce de chapeau un peu soft skills. slash skill de PMO. Je sais animer une équipe transverse, je sais faire avancer un sujet. Donc nous en fait tous nos parcours carrière sont définis de cette façon là. Ils ont ces quatre catégories et dans ces quatre catégories ensuite, on détaille des compétences, donc il y a plusieurs lignes qui permettent de dire bah toi, tu es Product Manager de niveau 1. Voilà ce qu'on va attendre de toi sur les compétences d'organisation. Tu sors d'école, on va peut-être pas attendre de toi que tu pilotes un projet qui est validé directement au niveau du comité exécutif. Par contre, on peut attendre de toi que tu pilotes dans ton équipe la prise de décision. Et donc du coup, c'est ça ta compétence organisationnelle qu'on attend de toi. Donc ce framework, il est assez puissant pour les pour les généralistes. Donc voilà, je vous le partage, ça pourra ça pourra peut-être être une autre facette pour vous d'imaginer ça. Et il s'applique à 100% des métiers. Donc encore une fois, c'est la beauté de ce framework, c'est que dans l'ensemble des équipes produit, vous avez un framework commun pour les équipes et ce qui peut créer aussi un peu de cohérence dans une équipe qui est au quotidien va peut-être pas tout le temps travailler ensemble mais plutôt travailler avec ses squad. Pas de questions jusque-là ? Vous me suivez ? Il y a toujours de l'énergie ? Je vous ai mis une parenthèse sur le Discovery parce que j'en ai parlé, il y a plein de framework, il y a un super bouquin qui s'appelle Discovery discipline de Remy Guiot qui est sorti il y a pas longtemps qui est dans les dans les top des ventes. Ce que je voulais vous partager, c'était le framework qu'on a de Discovery qu'on a créé avec l'or qui était d'offre product chez Meilleurs Agents et qu'on poursuit de mettre en œuvre chez Yousign. Et en fait, ce framework, derrière ce framework, on a toute une toolbox. Donc on fait des formations aux nouveaux arrivants, on leur donne plein d'outils, le Lean Canvas, le Business Model Canvas, des problèmes interview, du user interview et cetera. Ça c'est vraiment des outils. Ce qui est important pour moi, c'est le process aujourd'hui. Notre process, c'est un process en quatre étapes. On considère qu'il y a quatre typologies de risques quand vous êtes Product Manager, vous rappelez la définition de Melissa Perri, votre travail c'est de réduire les risques. Et ben on considère qu'une équipe produit, son travail, c'est de réduire ces quatre niveaux de risque. Premier niveau, risque utilisateur. Est-ce que j'ai des utilisateurs qui ont vraiment mon problème ? Vous allez me dire logique, mais il y a tellement de produits où on part directement sur la solution et on ne pense même pas au problème utilisateur qu'à la fin personne ne s'en sert. Les Google Glass, par exemple. Le product risk, est-ce que la proposition de valeur et mes fonctionnalités sont les bonnes pour répondre à ce besoin et est-ce qu'elles sont meilleures que les alternatives existantes. Le channel risk, est-ce que je vais être capable de distribuer mon produit ? Parce que pareil, il y a tellement de belles start-up qu'on fait des beaux produits qui n'ont pas décollé parce qu'elles n'avaient pas su comment le mettre dans les mains des utilisateurs. Et le risque de profitability, c'est de rentabilité. L'idée c'est de se dire, on va mettre une squad sur une thématique, par exemple, je dis n'importe quoi, pendant 6 mois. Euh, et ben, si je reprends mon analogie avec la boucherie, euh, quand vous mettez une squad, allez, on va dire 10 personnes pendant 6 mois sur un projet, à votre avis, combien ça coûte pour l'organisation ? On parle des salaires chargés des personnes. À votre avis, combien ça coûte pour l'organisation ? On parle des salaires chargés des personnes. On parle des salaires chargés des personnes. Plus de 100 000 euros ? OK. Plus de 200 000 euros ? Plus de 300 000 euros ? 400 000 euros ? Je vais tenter une vente aux enchères, j'adore faire ça. Plus d'un demi million ? Ouais, bon ceux qui ont la main levée, ils sont dans le vrai là aujourd'hui. On a complètement perdu ça dans le dans nos projets numériques, mais en fait quand vous investissez 10 personnes, salaire chargé, salaire moyen à 50 cas, vous êtes sur un demi million d'euros sur sur euh la demi-année. Et donc ça c'est hyper intéressant parce que du coup ce coût, ce coût, alors on peut se dire on est une entreprise, on a déjà les salaires qui sont versés, on a déjà employé ces gens. Mais en fait c'est aussi un coût d'opportunité. Vous avez choisi d'investir un demi million sur un sujet plutôt qu'un autre. Et donc on essaie dès le début des projets, de réfléchir à ce risque sur la rentabilité. Donc voilà, je vous partage ça, c'est un framework qui vaut ce qu'il vaut, mais ça vous explique aussi. Typiquement qu'on dans le user risk et le product risk, on est très dans le monde du product management product design. Là où dans le channel risk, profitability risk, on est très dans le monde du product marketing. Est-ce que je vais être capable de distribuer mon produit ? Donc c'est pour ça qu'on commence à voir vraiment l'émergence de ces jobs dans les équipes produits, parce que si on considère que l'équipe produit son rôle, c'est de minimiser tous ces risques, il faut des compétences pour aller les minimiser. Bon, c'était une petite parenthèse, mais qui est intéressante. Alors, autre question, qui sort complètement du monde du product management, mais est-ce que le management est un Graal ? C'est-à-dire, est-ce que quand je suis mon parcours carrière, bah niveau 5, c'est être calife à la place du calife et devenir CPO de l'entreprise parce que le seul moyen d'évoluer dans une organisation, c'est de faire du management. Évidemment la réponse, je vais pas m'attarder dessus, mais c'est un grand grand non. Il faut plusieurs voix dans un parcours carrière. Nous ce qu'on a considéré, c'est qu'on pouvait commencer à choisir sa voix différenciée à partir du niveau 3. Donc jusqu'au niveau 2, vous êtes Product Manager, vous ne managez personne. À partir du niveau 3, vous pouvez dire je veux devenir contributeur individuel. Et donc aller vers de l'expertise à la fin, on va parler de job en en anglais de type Principal Product Manager ou est-ce que je veux aller plutôt vers le management et donc commencer à gérer une équipe, puis piloter des équipes de plus en plus grosses et des domaines fonctionnels de plus en plus gros. Donc voilà, je je m'attarderai pas là-dessus. Je m'attarderai pas là-dessus, j'espère que vous êtes toutes et tous convaincus. Fait intéressant, nous on a une grille de salaire qui est complètement ouverte. Donc les gens savent où ils sont et connaissent les salaires et les salaires sont identiques entre manager et contributeur individuel. Comme ça on est allé au bout de la logique, parce qu'on peut pas dire aux gens c'est exactement pareil, c'est super, prenez les deux voies. Bon, si vous prenez celle du dessus, par contre à la fin vous avez la piscine, celle du dessous vous allez manger des pâtes quoi. Et un autre point qui est intéressant à la construction du parcours carrière, c'est son côté on-off. Des fois on écrit des compétences, je vous prends cet exemple, c'est animer des ateliers de coconception. Oui, non. C'est hyper compliqué. Vous êtes avec votre collaborateur et vous vous dites 'waouh, est-ce que il sait vraiment animer cet atelier de coconception ?' C'est c'est très on-off, très binaire. Alors, tout le monde parle japonais ici et évidemment reconnu la lettre Shu Ha Ri. Alors, tout le monde parle japonais ici et évidemment reconnu la lettre Shu Ha Ri. Voilà, j'en vois qui hoche la tête, il y en a qui sont en train de l'écrire sur leur cahier. Bon, moi je parle pas du tout évidemment, mais mais la philosophie est intéressante. C'est une philosophie qui vient des arts martiaux japonais, qui vient des dojo et l'idée étant de se dire Chou Hari, ça veut dire qu'à un moment donné, avant de complètement maîtriser une compétence, c'est pas on-off, c'est qu'il y a trois niveaux, il y a un niveau où vous êtes apprenti, débutant, vous apprenez à maîtriser le geste. Et donc là il faut le répéter régulièrement. Puis vous le maîtrisez avec un maître de préférence. Puis vous le maîtrisez et là du coup, on considère que vous êtes. euh master, donc vous vous maîtrisez la compétence. Et après, il y a un un niveau ultime où vous transcendez la compétence. Et c'est assez intéressant, c'est le niveau nous on l'a traduit en français. Et après, il y a un un niveau ultime où vous transcendez la compétence. Et c'est assez intéressant, c'est le niveau nous on l'a traduit en français, ça ça prend pas toute la philosophie du terme mais en professeur. Donc en fait dans nos équipes, quand on a notre parcours carrière, on a l'ensemble des compétences listées sur le Core Framework et pour chacune des compétences selon le niveau, on vous dit bah là tu es niveau 1. On attend de toi que tu es à ce que tu sois débutant sur plein de thématiques. Là tu es niveau 2, on attend de toi ce que tu sois peut-être passé euh autonome sur certaines de ces pratiques et puis quand tu vas atteindre le niveau 4 ou 5 d'expertise, là on attend de toi ce que tu puisses apprendre aux nouveaux arrivants dans l'organisation. Et donc ça fait quelque chose d'assez intéressant. Ce que la progression n'est pas juste linéaire et binaire, mais beaucoup plus progressive. Ce qui est intéressant aussi dans d'un point de vue management, c'est que vous savez à un moment donné qui est professeur sur quelle compétence. Ce qui est intéressant aussi dans d'un point de vue management, c'est que vous savez à un moment donné qui est professeur sur quelle compétence et donc ça peut vous aider aussi à transmettre la connaissance et la compétence dans votre équipe, parce que vous pouvez demander à quelqu'un de venir apprendre à une autre personne. Donc c'est le concept de Shouhari qu'on a mis en place dans nos dans nos parcours carrière. Je le précise, j'ai pas mis de de photos du parcours carrière mais il est public hein le parcours. Tous les parcours carrière de Youcent sont publics, donc vous tapez parcours carrière Youcen et vous retrouverez tous les fichiers qu'on utilise pour pour ces parcours avec toutes les compétences et le Chouhari associé. certains aiment peut-être la série The Office, vous aurez reconnu Dwight. Euh l'idée c'est de se dire ici comment est-ce qu'on va utiliser régulièrement le parcours carrière ? Parce que c'est super, on l'a construit, on a fait Chou Ari, on a le Core Framework, on est convaincu de tout ça, génial. Comment est-ce qu'on s'en sert régulièrement ? Nous ce qu'on fait, c'est que tous les 6 mois, on demande à chaque collaborateur de s'autoévaluer sur le parcours carrière pour nous dire où il en est. Chaque manager d'évaluer le collaborateur en cherchant un petit peu de feedback autour de lui. Et ensuite, on va passer une heure de discussion sur les points où on n'est pas d'accord. Pas d'accord pouvant être positif ou négatif parce qu'on a évidemment des billets où il y a des collaborateurs qui se sous-estiment aussi sur certaines compétences et où nous on les voit mieux. Et du coup, assez simple entretien annuel d'évaluation, mais l'avantage d'avoir cette grille du parcours carrière, c'est que c'est pas juste quelles sont tes objectifs ou tes aspirations pour les six prochains mois ou l'année qui vient. Et du coup, assez simple entretien annuel d'évaluation, mais l'avantage d'avoir cette grille du parcours carrière, c'est que c'est pas juste quelles sont tes objectifs ou tes aspirations pour les six prochains mois ou l'année qui vient, mais c'est vraiment quelque chose où on s'est auto-évalué et évalué et on peut se projeter sur des perspectives de croissance, qui peut aussi dire au collaborateur, ben si tu acquiers ces compétences là avec tel niveau, tu vas pouvoir passer d'un niveau à un autre, ce qui va mécaniquement augmenter ta rémunération notamment. Ça change la pas mal la nature des discussions sur les augmentations aussi. C'est pas j'ai fait un bon travail, augmente-moi. C'est plus bah OK, j'ai acquis les bonnes compétences, je pense maintenant mériter le niveau X et on discute sur ce sujet là. Donc on le fait régulièrement. Votre parcours carrière, c'est ni un chef-d'œuvre ni une œuvre éphémère. Je vous ai mis la source, le tableau est à vendre si vous appréciez. Euh l'idée c'est de se dire aussi votre parcours carrière, il doit pouvoir évoluer. Alors, il faut pas qu'il évolue tous les jours parce que vous n'êtes projeté toute votre équipe dessus et vous dites à votre équipe bah maintenant toutes les compétences ont changé, c'est plus le corps framework, c'est autre chose et cetera, c'est terrible. Pire, vous faites ça tout début décembre, juste avant l'entretien de fin d'année, vous ajoutez une bonne dizaine de compétences pour leur dire regarde, tu as tout ça à maîtriser, bon courage sur le chemin. Donc il faut faire très attention au momentum d'évolution du parcours carrière, mais c'est pas un chef-d'œuvre qui est terminé, il faut pouvoir le faire évoluer. Donc moi j'ai un exemple, quand j'ai commencé chez Meilleurs Agents, on était une plateforme, c'est pas une plateforme, pardon, on est plutôt une régie publicitaire pour agence immobilière. Il y avait une audience de particulier qui venait sur la plateforme et on vendait des agences immobilières, le fait d'être exposé sur la plateforme. Et puis on s'est dit en fait, notre plateforme c'est une vraie plateforme comme Uber, comme Blablacar et cetera, on devrait mettre en relation les particuliers avec les bons agents immobiliers pour leur projet. Et ça a complètement changé la dynamique de réflexion, on a commencé à penser en masse critique. Est-ce que à Lyon, on a suffisamment de particuliers pour intéresser les agences et vice versa ? Et donc ça complètement changé notre philosophie sur ce ces travaux-là. Et du coup, on a ajouté toute une partie de compétences sur comprendre les mécaniques d'une plateforme. Donc on l'a fait évoluer à cette occasion. Donc mon message ici, c'est quand vous créez votre parcours carrière pour créer votre équipe produit, ne le faites pas évoluer trop souvent, donc il faut quand même que la première itération soit pas trop mal, mais n'hésitez pas à le faire évoluer en fonction de l'évolution des besoins que vous avez dans votre organisation. form. Et puis on s'est dit, en fait, notre plateforme, c'est une vraie plateforme comme Uber, comme BlaBlaCar et cetera. On devrait mettre en relation les particuliers avec les bons agents immobiliers pour leur projet. Et ça a complètement changé la dynamique de réflexion, c'est qu'on a commencé à penser en masse critique. Est-ce que à Lyon, on a suffisamment de particuliers pour intéresser les agences et vice-versa. Et donc ça a complètement changé notre philosophie sur ce ces travaux-là, et du coup, on a aouté toute une partie de compétences sur comprendre les mécaniques d'une plateforme. Donc on l'a fait évoluer à cette occasion. Donc mon message ici, c'est quand vous créez votre parcours carrière pour créer votre équipe produit, ne le faites pas évoluer trop souvent, donc il vaut quand même que la première itération soit pas trop mal. Mais n'hésitez pas à le faire évoluer en fonction de l'évolution des besoins que vous avez dans votre organisation.

Transcription